takie oto pytanie zawitało dzisiaj w moim RSS readerze, zadane przez GT – przepraszam Cię Grzesiu, że nie w komentarzach tylko tak tutaj – ale pytanie ciekawe, a odpowiedź zbyt długa, żeby ją wklepywać jako comment – a ping backa powinieneś dostać [jeśli masz włączonego]. nie traktuj tego więc jako atak – to czysta polemika (:
“A kto pamięta LOGO? Proste to było do bólu, ale uczyło myślenia.”
oj pamiętam ci ja logo, pamiętam – uczyłem się go na bosmanach 8. założeniem logo była edukacja i na początq lat 9o’ miało to sens. kilka lat temu [ok 4-5] miałem nieprzyjemność uczenia logo – takiego nowego, z innym edytorem, niby-obiektowego etc. mając porównanie czasów ‘wtedy’ oraz ‘dziś’ mogę śmiało powiedzieć – LOGO TO SYF. język nieprzemyślany, gdzie na siłę wtrącono część obiektowości, pozostawiając w wielu miejscach podejście strukturalne, totalnie zwalony edytor, który wręcz zmusza do zrobienia bałaganu w kodzie, ciężko cokolwiek znaleźć – po prostu masakra. jedyne czego można po logo oczekiwać to nauczenia się totalnie złych manier programowania, niespójności i raczej się można zrazić niż nauczyć. do dziś na murach można spotkać napisy ‘punk not dead’ a nawet czasem odbędzie się jakiś koncert – gdzie 8o% ludzi jest powyżej 4otki. z logo jest podobnie – należy pochylić czoło nad kawałkiem historii i zapomnieć.
“W systemie DOS, podobnie jak w ośmiobitowcach (nie wnikam czy było to Atari, Commodore, Spectrum czy jeszcze coś innego) proste środowisko programistyczne było dostępne od ręki. A teraz?”
a teraz od wieków w windzie jest WSH, od niedawna powershell, w linuxach bash… oj bez GUI? no to TCL … ale po co w ogóle szukać po jakiejś niszy? czemu nie Java lub .NET – pierwsze prawdziwie języki obiektowe? być może ponieważ:
“Pomijam już to, że środowiska programistyczne zazwyczaj są olbrzymimi pakietami oprogramowania, które zachowują się nieraz tak, jakby były samodzielnymi systemami.”
oraz
“Pomijając kwestie środowiska, programowanie w XXI wieku nie jest tak proste jak kiedyś. Dawniej dało się napisać program mieszczący się w jednym pliku, bez tony #include i innych Using.”
nie prawda. do napisania ‘hello world’ potrzebujesz dokładnie tylko samo kodu – no ok. z jednego includa trzeba dodać. i bardzo dobrze. ale jeśli chcesz coś narysować, napisać lub skorzystać np z sieci – kiedyś musiałeś napisać toooooonę kodu – teraz dołączasz bibliotekę, która i tak działa o niebo lepiej niż większość by to sama zrobiła. i jest przenośne. zamiast uczyć się ‘jak coś działa’ [np. przebijanie się przez RFC od TCP/IP] sqpiasz się na logice – w końcu developer nie musi być architektem. równie dobrze można powiedzieć, że najlepszy był assembler. po co mam pisać algorytm na rysowanie koła, skoro mogę po prostu napisać rysujOkrag(10) q:
co do kompilatora – nie trzeba instalować visual studio – może owszem, microsoft ma taką politykę, że .net kojarzy się z VS, ale przecież wystarczy dobry edytor z podkreślaniem składni [np. pspad] – zarówno do javy jak i .neta i zainstalowany framework/VM. nie jestem ‘na bieżąco’ ale są małe środowiska do obu tych języków – po szybkim googlaniu np. tutaj. małe, szybkie, do pierwszych zabaw wystarczą – wcale nie trzeba SQL ani pierdyliona dodatków.
Tylko, czy przypadkiem nie stało się tak, że zginęła w tym radość z napisania czegoś, co działa? Czy dzisiaj dziesięciolatek ma szansę siąść i napisać kilka albo kilkadziesiąt linii kodu, które zapytają o imię i wyświetlą okienko, w którym to imię zostanie wstawione w komunikat "Jasio umie programować!"?
imho – nie. co więcej – ma szansę to zrobić bez problemu, ponieważ to nie jest na tym etapie kwestia języka tylko nauczyciela oraz kompilatora. taka aplikacja to w javie tyle samo kodu w VB – a jeśli jest go więcej wizualnie, to i tak ‘sprytny edytor’ doda wszystko co potrzebne na początek – a co to oznacza można wytłumaczyć później.
różnica polega jednak na tym, że jak ktoś się zacznie uczyć języków strukturalnych, a już nie-daj-wielki-informatyku takich archaizmów jak BASIC, to potem będzie musiał się na nowo uczyć obiektowych. wiem – bo sam przez to przeszedłem i przełamanie sposobu myślenia jest dość bolesne. developerem nie zostałem [czego trochę żałuję, ale tak się potoczyło], ale miałem okazję kombinować w różnych wynalazkach – logo, basic, pascal, c, c++, java, .net, php, vbs+hta, sql, vba, fortran, c-MPI, shellowe cmd, bash itd – i po wszystkich przejściach, zakochałem się w obiektowości. dla tego z resztą tak dobrze gada mi się z AD a tak bardzo nie znoszę poronionego SQL. imho warto zainwestować czas od razu w coś, co będzie przyszłościowe, zamiast babrać się w oldschoolu. nie twierdzę, że to nie ma wartości edukacyjnych, ale to ślepa uliczka i pewne zderzenie z rzeczywistością jeśli ktoś w tym kierunq będzie podążał.
“Mówiąc w największym skrócie: Jestem za powrotem BASICa do łask!”
w-życiu-never! (;
jeśli chodzi o 1o latków – ale nie tylko – to polecam grę CeeBot – imho do osób, które chcą efekty zobaczyć najszybciej – docieranie poprzez fabułę jest najefektywniejszy – i nie tylko zobaczymy ‘jaś jest programistą’ ale w ciągu kilq chwil można sterować własnym robotem! Chciałem nawet robić z tego zajęcia, ale licencja edu była za droga na moją kieszeń, a uczelnia nie chciała wydawać ):
n.
przez co cały czas Windows odpowiadało KRB_ERR_RESPONSE_TOO_BIG 
Tak, apple schodzi na psy. Gdzie podziało się prawdziwe pionierstwo? Czemu flagowym produktem jest zacofany technologicznie i uzależniony od zakupów w iTunes iPhone?
) enter i nie ma serwisów 
zabić 
Co do LOGO - zgadzam się. To było głupawe, ale rysowało się w tym fajnie. Dzieciak _chciał_ zrozumieć pętle przy malowaniu czegkolwiek więcej niż trójkąta.
Co do BASICa. Tu pojawia się zasadnicze pytanie: uczyć podstaw programowania wiedząc, że za parę lat trzeba będzie wszystko przewrócić do góry nogami? Czy poczekać i od razu nauczyć porządnego podejścia do programowania. Osobiście uważam, że nauczyć jednego a potem przestawiać. I tak robi się tak z młodymi ludźmi we wszystkich innych dziedzinach i źle na tym nie wychodzą.
Co do SmallBasica i alternatywnych środowisk. Sorry. SmallBasic jest prostszy do postawienia i uruchomienia. To, co pokazałeś też nie jest bardzo trudne, ale jednak trudniejsze. To dla Ciebie, inżyniera-zawodowca żyjącego z IT to takie proste. Dla innych może nie aż tak.
A na koniec co do odwiecznego konfliktu pomiędzy programowaniem obiektowym a proceduralnym. Cóż. Jeżeli mam wybór - wolę proceduralne. Stare dobre podejśce “algorytmy+struktury danych=cośtam” jest mi bardzo bliskie. Ale mimo różnych programistycznych zajęć w CV, teraz to ja jestem prosty ITPro a nie żaden programista ;)
Wiele miejsc tej polemiki budzi moj sprzeciw, jednak jeden fragment sklonil mnie do wypowiedzenia sie. Piszesz:
“[..] i po wszystkich przejściach, zakochałem się w obiektowości. dla tego z resztą tak dobrze gada mi się z AD a tak bardzo nie znoszę poronionego SQL. imho warto zainwestować czas od razu w coś, co będzie przyszłościowe, zamiast babrać się w oldschoolu.”
Pomijam bledy ortograficzne, bo to nie ma znaczenia.
Ale skad wiesz, ze .NET, etc. sa bardziej przyszlosciowe od ‘poronionego SQL’? Chcialbym zwrocic uwage, ze SQL trzyma sie bardzo dobrze na rynku i jest to bardzo stabilny jezyk, w ktorym nie nastepuja powazne zmiany z wersji na wersje, co ma miejsce chociazby w C#, czy VB.NET, etc. Jednym slowem inzynier, ktory opanuje sql dzis, z powodzeniem bedzie mogl stosowac swoja wiedze jutro, czy za 10 lat (zakladajac, ze obecnie panujaca wersja to SQL-92 z drobnymi modyfikacjami) i tworzyc rozwiazania, ktorych przeniesienie na platforme konkurencyjna bedzie trudne, ale nie niemozliwe i raczej dotyczylo drobnych szczegolow (brak obslugi procedur skladowanych, etc.). Jesli mam byc szczery, to uwazam, ze wiazanie sie ze srodowiskiem .NET przy duzych systemach, gdzie planujemy strategie i rozwoj nie na 1-2 lata, a myslimy o 5-10 i nie dzialamy ‘z projektu na projekt’, a raczej tworzymy wlasna platforme do tworzenia aplikacji, moze byc klopotliwe i ciezkie w utrzymaniu. Tym bardziej, biorac pod uwage, ze wiekszosc aplikacji jest sterowana danymi i to one sa centralna czescia aplikacji, a .NET dostarcza tylko mechanizmy do ‘wyciagniecia’ tych danych i odpowiedniej prezentacji. A tu nie ma wiekszego znaczenia, czy wezmiemy starego borlanda, czy wpf - przy czym w tym pierwszym przypadku nie bedziemy sie musieli za 5 lat martwic o zmiany we Frameworku dostarczanym przez zewnetrzna firme, na ktora jestesmy, bylo nie bylo, skazani poprzez swoj wybor.
Jezyki bardzo sie zmieniaja, wspolczesny C# jest zarowno obiektowy, jak i proceduralny, a do tego czesciowo deklaratywny i funkcyjny. Jezyki typu Ruby wymuszaja na tworcach pojscie w kierunku jezykow dynamicznych i kompilator to juz nie wszystko. Z jednej strony to bardzo fajnie, a z drugiej powoduje poczucie totalnej mieszanki, ktora nie wiadomo jak bedzie wygladala za lat 2-3, nie mowiac juz 5-10.
Zeby nie bylo - ja wybralem C#, ale to kwestia skali. Soft robie glownie na wlasny uzytek (wewnatrz firmy) i odbiorcow mam dobrze zlokalizowanych, wiec nad zmianami sam panuje.
@mgrzeg: porównanie .net i sql jest co najmniej dziwne - to dwie zupełnie różne działki. że .net jest przyszłościowy wiem, bo obserwuje rynek od lat, widzę jak rozwija się windows i wszystko wskazuje w tym celu. nie znam dokładnych statystyk wykorzystania języków, ale założę się pierwsza trójka to C [drivery, kernel etc], .NET [jako rodzina - bo w końcu różnice są w składnie - i tu aplikacje] i java [web i aplikacje multiplatformowe, mobile].
co do sql - to że jest poroniony jest moją opinią - próbowałem wiele razy do tego usiąść i za każdym razem kosztowało mnie to masę nerwów. na uczelni miałem podstawy obiektowych baz danych i mam nadzieję, że świat kiedyś dorośnie do wykorzystania tego pomysłu przynajmniej w części. AD - który jest obiektowy, jest trywialny do oprogramowania, i nie zależy od dziwnego języka - to jest w przypadq sql dla mnie największą zagwozdką - jak to jest, że ta baza jest tak potwornie ‘osadzona na języq’. czy nie można zostawić silnika, jako DB a napisać nowego API, nowego języka? - uh. to nie moja działka. dla mnie sql to nośnik danych, a jak jest coś dużego do zoptymalizowania, projektuje je ktoś, kto się w tym specjalizuje (: