Od laika do programisty..

Twórca C# (Anders Hejlsberg, ten sam co stworzył Delphi i pewnie dlatego C# celuje w programistów o takim samym IQ jak programiści Delphi)
hmm, z pewnością C# stworzył człowiek o tym samym IQ co Delphi (z poprawką na dodatkowe lata doświadczeń), ale czyżbyś sugerował, że z IQ użytkowników Delphi czy C# jest coś nie tak?

Wibowit napisał(a)

Tyle, że dla wielu prościej to znaczy: postawić static przed każdą metodą. Polecam zrobienie wstępnej wersji projektu, wrzucenie do sieci i wystawienie do oceny np na forum 4p :]

No i właśnie mówię o eliminowaniu takich błędów. Nawet, jak na początku zrobią wszystko static, to później dojdą do wniosku, że jednak to ma być inaczej bo nagle nie będzie działać, tak jak trzeba. Sztuka uczyć się na własnych błędach, a nie wiedzieć wszystko od początku.

allocer napisał(a)

No i właśnie mówię o eliminowaniu takich błędów. Nawet, jak na początku zrobią wszystko static, to później dojdą do wniosku, że jednak to ma być inaczej bo nagle nie będzie działać, tak jak trzeba. Sztuka uczyć się na własnych błędach, a nie wiedzieć wszystko od początku.

Masz rację w tym i w poprzednim poście. Ja sam przeszedłem drogę od takiego static-jedna klasa per projekt-komponenty z toolboxa na formę klepacza do całkiem nieźle ogarniającego OOP i technologię programisty w ciągu jakichś dwóch lat. Uczyłem się w dużej mierze na swoich błędach, ale też oczywiście z książek, blogów oraz pomagając na forach osobnikom, którzy mieli ten sam poziom (nie)umiejętności jak ja, tylko zamiast samemu pomyśleć i coś rozwiązać woleli spytać w necie.
Ale niektórzy nie są zdolni do samodzielnej nauki i dochodzenia do jakichkolwiek wniosków na podstawie swoich błędów oraz doświadczeń. Oni wiedzą tylko tyle, ile nauczono ich na ich uniwersytetach, i nie wiedzą nawet, że można się rozwijać samemu. Ale co zrobisz?

somekind napisał(a)

Masz rację w tym i w poprzednim poście. Ja sam przeszedłem drogę od takiego static-jedna klasa per projekt-komponenty z toolboxa na formę klepacza do całkiem nieźle ogarniającego OOP i technologię programisty w ciągu jakichś dwóch lat. Uczyłem się w dużej mierze na swoich błędach, ale też oczywiście z książek, blogów oraz pomagając na forach osobnikom, którzy mieli ten sam poziom (nie)umiejętności jak ja, tylko zamiast samemu pomyśleć i coś rozwiązać woleli spytać w necie.
Ale niektórzy nie są zdolni do samodzielnej nauki i dochodzenia do jakichkolwiek wniosków na podstawie swoich błędów oraz doświadczeń. Oni wiedzą tylko tyle, ile nauczono ich na ich uniwersytetach, i nie wiedzą nawet, że można się rozwijać samemu. Ale co zrobisz?

Prawda jest taka, że na początku zawsze się popełnia błędy, bo nie da się wejść w coś i robić to od razu perfekcyjnie. Ogarnięcie OOP to też nie jest prosta rzecz, bo trzeba najpierw dobrze zrozumieć teorię, co za co odpowiada itp., a następnie napisać tyle rzeczy ile potrzeba.
Co do tych, którzy nie umieją, a co gorsza nie wiedzą, że można i trzeba się rozwijać samemu. Otóż informatyka, a szczególnie programowanie jest taką dziedziną, w której jeśli zatrzymasz się na jeden dzień, to na drugi obudzisz się z ręką w nocniku, bo wszystko płynie bardzo szybko. Poznawanie nowych technologii, rozwijanie umiejętności - po prostu stawanie się lepszym w tym co robisz jest tu najważniejsze. Ja np. nie rozumiem ludzi, którzy poszli na informatykę i robią tylko tyle ile jest na wykładzie/ćwiczeniach, nie doskonaląc się dalej. Niektórzy przychodzą na informatykę tylko temu, że wybrali ją eliminacji prób i błędów lub nie dostali się na wymarzoną japonistykę.
Już było wiele razy mówione na tym forum, zresztą kiedy się studiuje to dobrze widać, że studia nikogo programować nie nauczą - pokażą jakieś tam podstawy, ale to i tak za mało jeśli myśli się poważnie o zostaniu programistą. Każdy ma prawo popełniać błędy, nawet jeśli programuje już X lat, lecz musi otwarcie się przyznawać (przed samym sobą), że czegoś nie potrafi. Trzeba się rozwijać niezależnie od formy (czy to grupa kumpli, którzy razem coś piszą, czy sam piszesz projekty na swoje konto).

Ja stawiam tezę, że większość programistów jest bezkrytyczna w stosunku do siebie (tak jak osławiony na tym forum polaczek17) i powiela w kółko te same błędy bo nie widzi w nich nic złego, albo po prostu ich (nikły) stan wiedzy ich zadowala.

Wysłanie projektu na to forum szybko zburzy to samozadowolenie ;]

kial123 napisał(a)

Wiem, ze wielu z was zaczynało jako 9-10 latki a nawet wczesniej i teraz są naprawde dobrze obeznani w funkcjonowaniu systemu i przeróżnych jezykach programowania.

Masz rację, ale w miejscach, w których oni obecnie się znajdują, takie umiejętności są zupełnie zbędne. Nikt jeszcze nie napisał kompilatora, który dałby się uruchomić na ścianie z materaców.

Nie sądzę, aby dziesięcioletnie dziecko było w stanie tyle pojąć i zrozumieć z szeroko pojętego programowania, ile np. prawidłowo edukujący się licealista czy absolwent szkoły średniej. Za dużo braków w podstawowej wiedzy i za mało rozwinięte kojarzenie. (No bo z czym kojarzyć, skoro w głowie jeszcze niewiele?)

Natomiast jeżeli dobrze rozplanowuje sobie czas i nauke to może zostane dobrym programistom w wieku 26 lat :/

Ja sobie mogę snuć plany o tym, co będę umiał w wieku 26 lat. Ale to dlatego, że mam 25, więc jestem w stanie wyznaczyć sobie realne do spełnienia cele. 10 lat, to zdecydowanie zbyt długa perspektywa, żeby móc coś takiego realnie dokładnie planować. Jeśli chcesz coś robić, to to rób, a nie gadaj o tym.

Tak, zdaje rozszerzona bo docelowo chce isc na budownictwo na politechnike, ale zobaczymy jak mi pojdzie programowanie.

Znasz kogoś, kto tak zrobił? Bo moim zdaniem to dwa ciężkie kierunki, wymagające bardzo szerokiej wiedzy i w zasadzie niepowiązane. Matematyka jest częściowo wspólna, a częściowo nie, fizyka w obu tych dziedzinach zupełnie inna, a do tego budownictwo wymaga wiedzy np. z chemii.

Wibowit napisał(a)

Podobnie twórca Groovy powiedział, że gdyby znał Scalę wcześniej to by w ogóle tego języka nie stworzył.

Ciekawe, czy Stephenson zbudowałby lokomotywę parową, gdyby wiedział, że za niecałe 200 lat powstanie TGV. Takie gadanie o historii alternatywnej jest trochę mało naukowe. ;)

Twórca C# (Anders Hejlsberg, ten sam co stworzył Delphi i pewnie dlatego C# celuje w programistów o takim samym IQ jak programiści Delphi) popełnił karygodny błąd i oparł jego składnię o składnię Javy.

Błąd? Składnia podobna do C/C++/Javy, czy też język imperatywny sam w sobie sprawia, że wielu dotychczasowych programistów może się go nauczyć łatwiej niż języka z innego paradygmatu. Błędem byłoby stworzenie języka, którego nikt by nie chciał.
A to wszytko wynika z tego, że ileś lat temu, języki imperatywne zdobyły prymat nad funkcjonalnymi.

Potem zaczął dokładać coraz to nowsze słowa kluczowe i próbował wprowadzić do języka jakieś ludzkie konstrukcje, niestety nawet gdy się dorobi do małego Fiata cztery turbosprężarki to nadal nie będzie to Porsche.

IMHO, tych słów kluczowych, dołożonych od 1 wersji wcale tak dużo nie jest. No i warto mieć czasem jedno słowo, które zastępuje 10 linijek kodu, jakoś tak czytelniej się robi.

W przypadku Javy dokładanie nowych ficzerów jest sporo wolniejsze i fanatycznie wymuszana jest wsteczna kompatybilność (niestety), ale bardziej przemyślane.

Bardziej przemyślane, bo? To, że coś się robi w inny sposób nie znaczy jeszcze, że jest bardziej przemyślane. A taki brak enumów, typów bez znaku czy też przeciążania operatorów jest raczej w ogóle nieprzemyślany.

somekind napisał(a)

Wibowit napisał(a)

Podobnie twórca Groovy powiedział, że gdyby znał Scalę wcześniej to by w ogóle tego języka nie stworzył.

Ciekawe, czy Stephenson zbudowałby lokomotywę parową, gdyby wiedział, że za niecałe 200 lat powstanie TGV. Takie gadanie o historii alternatywnej jest trochę mało naukowe. ;)
Scala była planowana od 2001 i wydana oficjalnie w 2003, Groovy było planowane od 2003 i wydane w 2004.

somekind napisał(a)

język imperatywny sam w sobie sprawia, że wielu dotychczasowych programistów może się go nauczyć łatwiej niż języka z innego paradygmatu.
obsługi szpadla też jest się łatwiej nauczyć niż koparki :P

A taki brak enumów
przecież są