•  
    b.......k

    +13

    pokaż komentarz

    Ciekawe, tym bardziej, że można samemu edytować kod, a z początku tego nie zauważyłem, myślałem, że są tylko gotowe przykłady. Dziwne tylko, że w pascalu.

    •  

      pokaż komentarz

      @b1ackjack: Wynika to prawdopodobnie z tego, że na UW zaczynają naukę od pascala. A bierze się to stąd, że pozwala robić rzeczy, na które nie pozwalają inne języki: np deklarowanie funkcji (wewnętrznych) w innych funkcjach.

    •  

      pokaż komentarz

      @Kylo_EL: Ale po co deklarować funkcję wewnętrzną w funkcji? Na przykładzie C++ mamy klasy, wszystko ładnie idzie czytelnie rozpisać a nie potem szukanie deklaracji funkcji w tonie zmiennych, kodu i na dodatek innych funkcjach.

    •  

      pokaż komentarz

      @Kyoshinn: Nikt tu nie mówi o obiektowym programowaniu. To zdaje się miało właśnie służyć zwiększeniu czytelności kodu. Jeśli masz wyspecjalizowaną funkcję która działa tylko w trakcie innej funkcji na tych samych danych, to możesz ją schować wewnątrz. W c++ tak nie zrobisz - masz jeden poziom, wszystkie funkcje wypisane jak lecą.
      To się przydaje też, np do opakowania funkcji która wymaga pewnych argumentów początkowych, tak, żeby nie trzeba było ich podawać.
      Do tego dochodzą wtedy ciekawe zagadnienia związane z rekurencją i ogólnie jest to ponoć ciekawszy materiał do nauki.

    •  

      pokaż komentarz

      @Kylo_EL: Kwestia jest inna, pascal został stworzony do celów naukowych, i według mnie doskonale się do tego nadaje. Nie można brać się za programowanie obiektowe, jeżeli nie zna się programowania strukturalnego, koniec kropka. Braki w podstawach prędzej czy później wyjdą na wierzch

    •  

      pokaż komentarz

      @Ratll: Też nie to, pascal został stworzony tak żeby był po prostu czytelny, c++ jest po prostu nieczytelne i można niektóre rzeczy w nim tak zamotać że długo by trzeba tłumaczyć co tam właściwie pisze.

    •  

      pokaż komentarz

      @Kyoshinn: Wszędzie tam, gdzie wykorzystywane są callbacki. Zamiast deklarować na zewnątrz klasę będącą obiektem funkcyjnym, robisz to na potrzeby danej metody/funkcji. W C++0x dodano tą funkcjonalność:

      http://en.wikipedia.org/wiki/C%2B%2B0x#Lambda_functions_and_expressions

    •  

      pokaż komentarz

      @Ratll:
      C jest strukturalne i praktycznie stosowane choćby w linuxie.
      Pascal już chyba nie jest zbyt aktywnie stosowany

    •  

      pokaż komentarz

      @Kylo_EL:
      Większość nowoczesnych języków ma tego typu mechanizmy. W Pythonie każda funkcja/metoda jest zwyczajnym obiektem, więc możesz je tworzyć kiedy chcesz, przekazywać do innych metod, itp. W Javascripcie jest tak samo, w Rubym chyba też, w PHP również dodali taką funkcjonalność. W Javie możesz definiować anonimowe implementacje interfejsów - nie jest to może to samo, ale wykorzystuje się w podobny sposób.

      Myślę, że Python jest świetnym językiem do nauczania. Jest bardzo prosty i czytelny, nawet dla nowicjusza.

    •  

      pokaż komentarz

      @ecikowaty: Chyba nie o to do końca chodziło Kylo_EL. W Pascalu przecież też nie ma lambda abstrakcji. Pewnie miał na myśli po prostu zagnieżdżenie procedury, czy funkcji.

      Moim zdaniem jest to bardzo ładny język do nauki programowania strukturalnego, ma kilka braków, ale udostępnia na przykład prawdziwe moduły z eleganckimi blokami aktualizacyjnymi, blok deklaracji zmiennych to też fajna, choć kontrowersyjna sprawa, tablice mogą być indeksowane od dowolnej liczby - taki bajer. W Pascalu tablica to tablica, i ma odpowiedni typ, nie jest to po prostu kawałek pamięci odpowiedniego rozmiaru - znowu kontrowersja (tak samo z rekordami). Przypisanie to nie symbol równości, a symbol przypisania (czytany "staje się"). Ogólnie w miarę fajny język i doskonały do celów edukacyjnych, choć w C też dałoby się studentów nauczyć.

      C++ absolutnie się nie nadaje jeśli chodzi o wstęp do programowania. To jest wielka kobyła i można o nim bardzo grube książki pisać. W dodatku nierzadko dobrze napisany kod w tym języku jest nieczytelny.

    •  

      pokaż komentarz

      @Brut_all: Zgadza się, od czasu Javy, C#, Pythona, itp. Pascal powinien być martwy. Ale nie jest, dzięki naszym kochanym uczelniom (np. na Politechnice Rzeszowskiej obowiązuje cykl Pascal -> C -> C++, oczywiście w konsoli).

    •  

      pokaż komentarz

      @Kylo_EL: To o czym piszesz nazywa się *"domknięciem"* i jest dostępne w wielu różnych językach. Nawet w JavaScripcie. Jak sobie zobaczysz kod źródłowy popularnego JQuery, to możesz zauważyć że cała biblioteka to funkcja w funkcji w funkcji... Jednym słowem kaszana :) Domknięcia są fajne ale bez przesadyzmu.

    •  

      pokaż komentarz

      @UmCykCyk: Nie o to mu chodziło, bo w Pascalu nie ma domknięć.

    •  

      pokaż komentarz

      @krzat: EEEee a długo się ciągnie Pascal i C na polibudzie ?? ;/ bo się tam wybieram na zaoczne i nie wiem czy dobrze robię ...

    •  

      pokaż komentarz

      @Kyoshinn: Przecież Pascal - Turbo Pascal pozwala tworzyć klasy.
      Czasami deklarowanie funkcji w funkcji ułatwia interpretacje programu oraz skraca jego treść - trudniej zabłądzić. Można też napisać obiekt - klasę i w nim robić to, czego potrzebujemy.
      Mi się strasznie podoba składnia tego języka. Do nauki w sam raz ale szybko można się przyzwyczaić i potem trudno go "odstawić".
      Da się w nim napisać ciekawe rzeczy. Mimo jego podeszłego wieku.

    •  

      pokaż komentarz

      @arek09: Na dziennych: I sem. Pascal, II sem. C, III sem. C++

    •  

      pokaż komentarz

      @Kylo_EL: Kłamiesz ;-) To nieprawda, że inne języki nie pozwalają deklarować funkcji wewnątrz funkcji. Pozwala na to np. JavaScript, Smalltalk, Ruby, oraz większość języków, które obsługują tzw. funkcje lambda [anonimowe funkcje/bloki] i domknięcia [closures], a trochę ich jest. Zwłaszcza tych wywodzących się z rodziny "funkcyjnych".
      Jednak jeśli o mnie chodzi, to nie jestem do końca przekonany, czy to taka zaleta. Może jest to wygodne z początku, albo do jakichś prostych funkcyjek. Jednak obsługa domknięć może sprawiać spore problemy z debugowaniem później takiego kodu, bo powoduje, że funkcja staje się zależna od środowiska, w jakim została zdefiniowana. Więc gdy coś z nią nie tak, musisz zdebugować całe to środowisko zewnętrzne, z którego mogła ona skorzystać, oraz wszystkie jego powiązania.

    •  

      pokaż komentarz

      @SasQ: No ok, niektóre nie pozwalają. Z tym, że nikt normalny nie będzie zaczynał nauki od JS, albo od 100% obiektowego Smalltalka. Tu po prostu pascal jest używany do nauki programowania strukturalnego - od czegoś trzeba zacząć i faktycznie tego mechanizmu nie da się pokazać np w c lub c++. Wykorzystanie funkcji wewnętrznych było używane przy omawianiu zasięgu zmiennych i funkcji.
      Jak już człowieka nauczą pisać programy strukturalne to zaczynają naukę programowania obiektowego. Nie ma co od razu skakać na głęboką wodę, od jakiś podstaw trzeba zacząć i póki co pascal jest uznawany za spełniający to zastosowanie.

      Oczywiście przy większych projektach to pewnie może być uciążliwe.

    •  

      pokaż komentarz

      @SasQ:
      Domknięcia są świetne do przekazywania callbacków. W takim przypadku ten problem, o którym piszesz, nie występuje, gdyż środowiskiem jest po prostu obiekt, który stworzył to domknięcie i tyle. Tak więc ładnie tutaj zachodzi enkapsulacja, a debugowanie wygląda mniej więcej tak, jak w przypadku normalnej, nazywanej metody.

      Za to w wielu systuacjach domknięcia potrafią znacznie zwiększyć czytelność kodu. Jeśli np. korzystamy z jakiejś biblioteki do asymetrycznego pobierania danych z internetu, to dzięki callbackom mamy wszystko w jednym miejscu - zarówno wywołanie połączenia asymetrycznego, jak i późniejsze odebranie danych. Inaczej by trzeba np. zaimplementować jakiś interfejs służący do odbierania danych, dodać osobną metodę i rozbić proces w dwa różne miejsca w kodzie. Co gorsze, jeśli przy wysyłaniu zapytania mieliśmy jakieś parametry, itp., które chcemy mieć też przy odbiorze, to musimy je gdzieś tymczasowo zapamiętać, a jeśli wysyłamy wiele takich zapytań równolegle, to już w ogóle super. W takiej sytuacji domknięcia vs. nie_domknięcia, to może być różnica typu: 5 lnijek kodu w jednym miejscu vs 30 linijek w kilku miejscach lub nawet w osobnych klasach.

      Oczywiście z domknięciami łatwo przedobrzyć, zwłaszcza, gdy ktoś lubi wszędzie wtykać "magię". Jednak generalnie uważam je za bardzo dobre narzędzie programistyczne.

      Jako ciekawostkę dodam, że jeśli się coś dobrze rozplanuje, to nieraz nawet pozornie pokręcone pomysły sie okazują całkiem w porządku. Np. w Pythonie występuje coś takiego, jak dekoratory funkcji. Są to funkcje (A), które przyjmują w argumentach inne funkcje (B), same deklarują jeszcze jedną, anonimową funkcję (C), funkcja C wywołuje B, a A zwraca C. Jest to swego rodzaju idiom, wykorzystuje się to w wielu miejscach, w tym parę takich dekoratorów jest częścią języka i daje to ciekawe możliwości, a jest, o dziwo, całkiem przejrzyste ;-)

  •  

    pokaż komentarz

    Pascal to przeżytek. Ktoś w tych czasach coś w tym języku w ogóle pisze? C++, # sharp, czy java - to rozumiem, ale Pascal?

    •  

      pokaż komentarz

      @gabinetcieni: Za chwilę milion osób zapyta o to samo, więc czuję się zobowiązany do jak najszybszego ugaszenia iskierki oburzenia widokiem tego jakże archaicznego przeżytku programistycznego zanim wszystkich nas pochłonie flamewar.

      Uwaga: Do celów edukacyjnych, czyli nauki programowania, napisania swojej pierwszej implementacji algorytmu Dijkstry, jakiegoś prostego samobalansującego się drzewka BST, kolejki priorytetowej, czy MergeSorta jest to bardzo dobry język. Wymusza dobre praktyki programistyczne. W dodatku Pascal to bardzo dobra notacja do zapisywania kodu na tablicy.

      Edit: Dla osób, które uczą się programować języki wymienione przez kolegę wyżej nie nadają się najlepiej, w szczególności C++ nie nadaje się wcale.

    •  

      pokaż komentarz

      @kubi: a niby dlaczego C++ nie nadaję się w cale? W moim przekonaniu nadaję się bardzo dobrze jeśli ktoś chce zaczynać w celach bardziej zaawansowanych niż semestr informatyki na UJ ;P

      * jest blisko "rzeczywistości" - klasy z właściwościami i jakimiś działaniami
      * jest bliski "maszynowości" - wskaźniki, zmienne "czyste"

    •  
      M...........s

      +4

      pokaż komentarz

      @Pussty: Bo początkujący się załamie gdy zobaczy wskaźniki.

    •  

      pokaż komentarz

      @Pussty: Nauka języka programowania takiego jak Pascal, czy C zajmuje może z tydzień, jeśli osoba jest już zaznajomiona z koncepcjami takimi, jak wskaźniki, dynamiczna alokacja pamięci, instrukcje sterujące wykonaniem programu (while, if, else). Pascal jest przyjazny dla kogoś, kto nigdy nie programował.

      Druga, ważniejsza sprawa to zastosowanie tego języka. Na wstępie do programowania uczy się takich rzeczy, jak sortowanie, przeszukiwanie grafów, tworzenie prostych struktur danych, jak kopiec, albo lista, jakieś gramatyki bezkontekstowe też się pojawiły. W sumie nie wiem, czego dokładnie uczą na Pascalowym potoku, bo na niego nie chodziłem, ale i tak wszystkiego w detalu nie wymienię, można zajrzeć do programu. Obiektowość jest nieprzydatna, tego się uczy na innych przedmiotach.

      Nauczenie się C++ to jest pół roku systematycznej pracy (programista powinien mieć jeszcze doświadczenie, ale od czegoś trzeba zacząć). Mówię tutaj o dobrej znajomości semantyki tego języka. Dobry programista powinien wiedzieć dokładnie, kiedy obiekt jest konstruowany (a co nawet ważniejsze, kiedy niszczony), co jeżeli w pewnym momencie zostanie rzucony wyjątek, jaka jest odporność na wyjątki klas z biblioteki standardowej, wiedzieć, jak poprawnie pisać swoje klasy, żeby były odporne na wyjątki, co to jest RAII, const correctness, safe bool idiom, jak za pomocą template'ów stworzyć poprawny system kontroli typów, mieć dobrą znajomość bardzo pomocnych bibliotek boosta, wiedzieć kiedy jaka metoda jest wywoływana i z jakiej reguły to wynika, itd. To, co tu wymieniłem, jest jedynie bardzo niewielką cząstką ogromu wiedzy i umiejętności, którą trzeba posiąść, żeby porywać się na pisanie czegoś w tym piekielnym języku, a zrozumienie wynikowego kodu wymaga ciężkiego zastanowienia, albo kilobajtów komentarzy.

      Pod tym względem Java i C# są lepsze, ale po co pchać nowicjuszy w obiektowość? Niech się chociaż nauczą łączyć elementy listy wskaźnikami. Poza tym te języki mają Garbage Collectory, a nawyk sprzątania po sobie trzeba wykształcać od początku.

      Naturalnym konkurentem jest C, ale jego też można nauczyć się w tydzień, a zdecydowana większość umiejętności przenosi się po prostu od razu z Pascala. Natomiast nie kładzie takiego nacisku na dobre praktyki, jest może trochę trudniejszy dla młodych padawanów.

      @Mephistofeles: Pascal też jest wyposażony we wskaźniki, nie o to chodzi.

    •  

      pokaż komentarz

      @kubi: Problem w tym, że na MIMUW nauka Pascala nie kończy się na wprowadzeniu do programowania i wymaga się tej wiedzy min. przy egzaminach na drugi poziom studiów, więc to trochę paranoja. Uczelnie zachodnie już dawno zastąpiły Pascala Pythonem. Tutaj garść celnych spostrzeżeń: http://mcsp.wartburg.edu/zelle/python/python-first.html

      A powód utrzymywanie bieżącego stanu rzeczy jest niestety prozaiczny... Ot, skostniałość umysłowa kadry naukowej. Podobnych kwiatów jest więcej na innych przedmiotach - starczy wymienić choćby nadmierne przywiązanie do strukturalnych metodyk projektowania aplikacji, które w dzisiejszym biznesie mają już charakter.. historyczny

    •  

      pokaż komentarz

      @evapor: Jak byłem na potoku funkcyjnym to będą ode mnie OCamla wymagali? Poważnie, człowiek niektóre niuanse zapomina.

      Co do nauczania to wiadomo, że w Stanach jest lepiej, ale MIM to przyzwoita uczelnia. Nie wiem, co miałeś na myśli z tymi strukturalnymi metodykami, może przybliż o co Ci chodziło to się zgodzę, albo nie zgodzę.

    •  

      pokaż komentarz

      @Pussty: dlaczego C++ nie nadaje się wcale?
      Ano dlatego, że:
      1. Nawet najprostszy, nie robiący niczego program, wymaga napisania już jakiegoś kodu [minimalny kod w C++ to int main() { } ], co już wymaga od początkującego sporej wiedzy specyficznej dla C++, mianowicie:
      * Co to jest funkcja?
      * Co to jest blok?
      * Co to jest funkcja startowa i czemu musi się nazywać main? [mam na myśli standardową implementację C++ nie-embedded]
      * Dlaczego muszą po niej być te puste nawiasy okrągłe i klamerkowe?
      * Dlaczego ona musi zwracać int i komu?
      * Co to jest ten int?
      * Niuanse związane z rozmiarem typu int w pamięci na różnych maszynach [wg standardu, choć nawet na jednej architekturze int może teoretycznie mieć różne rozmiary] i dozwolone zakresy wartości.
      * No i do cholery dlaczego muszę cokolwiek napisać, by program nie robił nic?! :-P
      A to nawet jeszcze nie jest "Hello, World!" :-P
      2. Żeby wypisać coś na stdout, choćby powitanie, trzeba dodatkowo wiedzieć:
      * Czym są strumienie wejścia/wyjścia?
      * Jak w C++ nazywają się obiekty, które sterują ich pracą?
      * Co to u diabła są te obiekty?
      * Jak z nich skorzystać, czyli jak dołączyć nagłówek z ich deklaracją?
      * Co to do cholery jest ten nagłówek i co robi?
      * Co to są deklaracje?
      * Czym się różni nagłówek od biblioteki?
      * Czym się różni #include <coś> od #include "coś"?
      * Dlaczego muszę cin, cout, endl itp. poprzedzać std:: lub ewentualnie dopisać using namespace std; gdzieś na początku? Co to do cholery wszystko znaczy i czym są te namespace?
      * Co to są stałe dosłowne tekstowe?
      * Jaki mają typ? [i oczywiście wszystkie związane z tym niuanse, czyli dlaczego przestawianie znaków w tablicy znaków to zły pomysł i dlaczego nie mogę sklejać napisów z napisami i napisów z liczbami ;-P]
      * Co to jest backslash-code?
      * Co to są operatory wstawiania/wyjmowania do/ze strumienia?
      * Co to są manipulatory?
      * Jak zobaczyć wynik działania programu, skoro okienko z wynikami od razu się zamyka po skończeniu programu [Windows], lub w ogóle się nie wyświetla [Linux/BSD itp. Unix-like]? I dlaczego wstrzymywanie pracy po zakończeniu to zły pomysł, a uruchamianie z już otwartej konsoli dobry?
      Sporo, jak na proste "Hello, World!" ;-P Dalej jest tylko gorzej...
      3. Wszędzie jeżące się wskaźniki, bo mało jest podręczników do nauki C++, które używałyby std::string czy std::vector zamiast gołych tablic i kłujących wskaźników. W zasadzie znam tylko jedną taką książkę: "Accelerated C++ programming by examples" Koeniga & Moo.
      4. Typ std::string jest "spasiony", na co narzekali nawet sami wielcy guru C++, jak Sutter czy Alexandrescu, co utrudnia jego rozszerzanie i reużycie. Ma skomplikowany interfejs, po kilka [nawet do 12!] wersji tej samej funkcji różniących się parametrami. Jak początkujący ma się w tym gąszczu połapać? :-P Nie mówiąc już o całej reszcie szablonowego kodu pojemników. Po prostu bariera wejścia jest bardzo wysoka jak dla początkujących. Sporo rzeczy trzeba wiedzieć, żeby choć zacząć pisać użyteczne programy.
      5. Iteratory. Zamiast stanowić wygodną i bezpieczną abstrakcję do iterowania po pojemnikach, opakowującą kłujące wskaźniki w swoim wnętrzu, same upodabniają się do wskaźników, z wszystkimi ich wadami, czyli błędy wyjścia poza zakres, odwołanie do nieistniejących danych, konieczność ręcznego zestawiania pętli itp.
      Ech, no nic, długo można by wymieniać. Znam wiele języków programowania i uczyłem kolegów programować w wielu różnych językach, ale nauczenie kogoś programować w C++ wymaga sporego wysiłku już na wstępie, ze strony ucznia jak i nauczyciela. Z innymi językami [jak choćby Pascal czy Python] tej trudności jakoś nie ma.

    •  

      pokaż komentarz

      @kubi: Do celów edukacyjnych, czyli nauki programowania, napisania swojej pierwszej implementacji algorytmu Dijkstry, jakiegoś prostego samobalansującego się drzewka BST, kolejki priorytetowej, czy MergeSorta jest to bardzo dobry język.
      Do celów edukacyjnych? Chyba jeśli się uczysz jak zostać programistą systemowym, który implementuje biblioteki algorytmów i struktur danych od zera. To jest zdecydowanie wyższy poziom, niż nauka programowania od podstaw.

      Wymusza dobre praktyki programistyczne.
      Po pierwsze: zdefiniuj "dobre". Jeśli pisanie niskopoziomowego proceduralnego kodu na wskaźnikach i tablicach uważasz za "dobre praktyki", to współczuję.
      Po drugie: Właśnie w tym problem, jeśli wymusza. Bo to sprawia, że ludzie zaczynają myśleć, że to jedyny sposób pisania programów. I później zalewają świat pokracznym niskopoziomowym kodem, który najpierw trzeba rozgryźć i połowę przepisać, by go użyć we własnym kodzie. Tak się rodzą algorytmiczni zboczeńcy, którzy uważają, że każdy algorytm można napisać z użyciem gołych tablic i wskaźników i zostawić takie rozbebeszone użytkownikom. Tak powstają ludzie, którzy uważają podejście obiektowe za zbędny nadmiarowy dodatek i dość, że jeszcze nie piszą tego w gołym assemblerze, w końcu też się da.

    •  

      pokaż komentarz

      @Mephistofeles: Bo początkujący się załamie gdy zobaczy wskaźniki.
      Przecież Pascal też ma wskaźniki :-P
      Natomiast podoba mi się to, co Bjarne Stroustrup (ojciec C++) napisał na ten temat w swojej książce:
      "C++ posiada mechanizmy, które są stworzone do niskopoziomowego manipulowania sprzętem w sposób bezpośredni i wydajny, bez przejmowania się bezpieczeństwem lub łatwością zrozumienia. Ale posiada też mechanizmy do ukrywania takiego kodu pod eleganckimi i bezpiecznymi interfejsami."
      oraz w FAQ na swojej stronie:
      "C++ offers both low-level and high-level features. C++ has low-level parts, such as pointers, arrays, and casts. These facilities are (almost identical to what C offers) are essential (in some form or other) for close-to-the-hardware work. So, if you want low-level language facilities, yes C++ provides a well-tried set of facilities for you. However, when you don't want to use low-level features, you don't need to use the C++ facilities (directly). Instead, you can rely on higher-level facilities, including libraries. For example, if you don't want to use arrays and pointers, standard library strings and containers are (better) alternatives in many cases. If you use only low-level facilities, you are almost certainly wasting time and complicating maintenance without performance advantages (see Learning Standard C++ as a New Language). You may also be laying your systems open to attacks (e.g. buffer overflows)."

      Podsumowując:
      Źle jest, jeśli język oferuje tylko niskopoziomowe narzędzia.
      Źle jest, gdy programiści mając do dyspozycji język oferujący narzędzia zarówno niskopoziomowe, jak i wysokopoziomowe, używają tych niskopoziomowych, nagich, nie ubranych w wygodne interfejsy wysokopoziomowe. A to dlatego, że:
      "Enkapsulacja jest podstawą programowania obiektowego (i nie tylko). Mądrzy ludzie juz przed Twoim urodzeniem zauważyli, że tak jest po prostu jest lepiej. Tak samo jak lepiej jest, gdy silnik samochodu jest zakryty klapą, gdy winda w budynku jest zbudowana tak, by nie dało się bez demontażu rozmaitych osłon włożyć gdzieś ręki, itd. Podobnie, lepiej jest jak nasze własne wnętrzności są w środku. Zasada enkaspulacji jest stara jak świat."
      [Sebastian Kaliszewski na pl.comp.lang.c]
      :-)

    •  

      pokaż komentarz

      @SasQ: @Pussty: dlaczego C++ nie nadaje się wcale?
      Ano dlatego, że:

      ok, a teraz opisz propozycję swoją w podobny sposób :)
      Propozycję na język dla początkujących.

      Ale mam tylko jedno ale... Rozpisujesz właściwie cały język, ale po co? Początkującemu wystarczy powiedzieć:
      "dziś zaczynamy, przyjmijmy ze na naszym poziomie wiemy tylko tyle że program musi mieć:

      #inlcude <iostream>

      int main(){
      //a tu piszesz swój bardzo liniowy program :)
      }
      "

      kilka lekcji później [po zapoznaniu z instrukcjami sterującymi, typami podstawowymi, można wprowadzać ucznia w dalsze boje, a jeśli liniowość mu wystarcza to po co go pchać dalej, jak strukturalność z funkcjami mu starcza, to po co go pchać dalej :)

      Bo u Ciebie wygląda to tak jakbyś chciał uczyć kogoś jeździć samochodem, zaczynał od wykładu i egzaminu z zagadnień rafineryjnych, konstrukcyjnych, mechanicznych, geodezyjnych, i tak dalej, zamiast powiedzieć: To kierownica - kręć jak chcesz skręcić. To hamulec - jak chcesz się zatrzymać wciskaj go. To gaz - pozwala przyspieszyć i utrzymywać prędkość. A w przypadku nie automatycznej skrzyni biegów, jeszcze wyjaśniasz sprzęgło...
      A dopiero później można przeprowadzać dokształcanie w sprawach których chce poznać nasz uczeń.
      Bo jeśli chce produkować samochody to niech się uczy też konstrukcji i mechaniki.
      Bo jeśli chce produkować paliwo, to niech zagłębia się w geodezję i rafineryjność.
      Bo jeśli chce być super kierowcą to uczyć go w tym zakresie.
      A jeśli chce tylko jeździć, to niech zna przepisy, podstawowe zachowania i interakcje z pojazdem :)

    •  

      pokaż komentarz

      @SasQ: @kubi: Do celów edukacyjnych, czyli nauki programowania, napisania swojej pierwszej implementacji algorytmu Dijkstry, jakiegoś prostego samobalansującego się drzewka BST, kolejki priorytetowej, czy MergeSorta jest to bardzo dobry język.
      Do celów edukacyjnych? Chyba jeśli się uczysz jak zostać programistą systemowym, który implementuje biblioteki algorytmów i struktur danych od zera. To jest zdecydowanie wyższy poziom, niż nauka programowania od podstaw.


      Wiec dla Ciebie cele edukacyjne to interakcje tekstowe [lub graficzne] programu z użytkownikiem?
      Natomiast implementacje matematyki to już wysoki poziom?

    •  

      pokaż komentarz

      @Pussty: Co dla mnie jest celem edukacyjnym, to nie musi być dla kogoś innego, bo ludzie rozpoczynają naukę języka na różnych poziomach i z różnymi doświadczeniami z wcześniejszych języków. Ja to akurat jestem "poliglotą" i programuję w różnych językach odkąd pamiętam. Ale potrafię jeszcze wczuć się w rolę początkującego, który nie miał jeszcze styczności z żadnym językiem i chce po prostu napisać coś prostego, co już działa i daje jakieś widoczne efekty. Chyba się ze mną zgodzisz, że w takim przypadku pisanie kilkunastu linijek w stylu:
      import bla.bla.bla;
      public class MyFirstProgram {
      public static void main(String[] args) {
      System.out.println("Hello, World!");
      }
      }
      nie jest zbyt przyjemnym startem z danym językiem [w tym przykładzie z rozgadaną Javą]. Prawda?
      Cel edukacyjny zależy od tego, na jakim jesteś już poziomie i czego teraz chcesz się nauczyć. Dobry język "edukacyjny" powinien z tym współgrać na każdym etapie edukacji. Nie tylko edukacji "akademickiej" na wyższej uczelni.
      Jeśli w jakimś innym języku ten sam początkujący może po prostu napisać:
      print "Hello, World!"
      lub nawet po prostu:
      "Hello, World!"
      w interpreterze, to zgadnij, który język wyda mu się prostszy do nauczenia i bardziej zrozumiały na jego poziomie wiedzy? ;-J

    •  

      pokaż komentarz

      @SasQ: ten z najprostszą możliwością interpretacji poleceń programisty :) wiec dla anglojęzycznych ludzi wychodzi na to, że będzie to: COBOL :P

      I przyznaję rację, że Java czy C# nie nadają się na początek, z uwagi na swoje właściwości czysto klasowe.

      Natomiast pewnie musiałbym zacząć poznawać pascala albo pythona, żeby móc się wypowiedzieć w sprawie który lepszy dla początkujących.

      I ostatecznie dalej będę mówił że początki w c++ nie są złe, ale ja nigdy nie chciałem robić jakiś wielkich i użytecznych rzeczy od samego początku nauki...

      Przyznam się szczerze, że to wszystko przez to że dawno dawno temu [chyba z 10lat] jak zacząłem przygodę z komputerem kolega przyniósł mi Colobota i tak poznałem w tej grze język C-Bot podobny do Javy/C++.
      Następnie gdy poszedłem do LO stwierdziłem że rzucam web design i nawet nie zagłębiałem się w PHP, zacząłem zabawy w interpretowanie algorytmów matematycznych w C/C++.
      Dopiero na studiach przebolałem Pascala, Lispa, Prologa, PHPa, Basha, poznałem Jave, C#, matlabowy, oprogramowywałem µC w C i wydaje mi się, że dobrze się stało że C++ mnie wciągnęło :) na ten pierwszy raz dogłębniej ;)

    •  

      pokaż komentarz

      @Pussty: ten z najprostszą możliwością interpretacji poleceń programisty :)
      Dokładnie tak. Interpreter to fajna rzecz, gdy się chce przetestować jakiś fragment kodu "na żywca", bez konieczności kompilowania go ze źródła w pliku tekstowym. (Oczywiście to nie argument przeciw kompilacji: dobrze jest, gdy język można używać zarówno w wersji interpretowanej, jak i kompilowanej. A jeśli ma tylko kompilator, to niech przynajmniej jego używanie będzie proste.)
      I dlatego podoba mi się, jak podchodzą do tego "nowoczesne" języki takie jak Python czy Ruby. Szczególnie ten drugi stawia na prostotę i ma sporo genialnych tutoriali. Niektóre nawet mają interpretery online, dzięki którym można testować fragmenty kodu bezpośrednio w przeglądarce (przykład: http://tryruby.org/ )

    •  

      pokaż komentarz

      @SasQ: Po zapoznaniu się ze składnią [za wikipedia] stwierdzam, że Ruby jest fajny :) dla początkujących.

      Wiec chyba koniec dyskusji :) dzięki za rozmowę :)

    •  

      pokaż komentarz

      @Pussty: I przyznaję rację, że Java czy C# nie nadają się na początek, z uwagi na swoje właściwości czysto klasowe.
      Myślę, że to nie aż tak bardzo wina "czystej klasowości", tylko składni, jakiej używają do opisania tego. Można przecież zdefiniować język tak, żeby np. wszelki kod wklepany "na czysto" w źródle, poza jakimikolwiek klamerkami, był domyślnie traktowany jako zawartość klasy main, albo modułu głównego.
      Nie zawsze jest potrzebna specjalna dodatkowa składnia, by coś powiedzieć. Wiele rzeczy można brać "z domysłu". Np. w języku, który aktualnie projektuję, postanowiłem pójść właśnie na takie uproszczenia, jak to powyżej [w wersji z modułami]. Myślę też nad możliwością taką, która pozwoliłaby na łatwą przemianę fragmentu kodu proceduralnego w moduł, a gdy uzna, że potrzebuje więcej instancji współdzielonych danych, moduł mógłby przekształcić następnie w klasę, stopniowo dodając drobne poprawki w kodzie. Dzięki temu programista mógłby rozwijać program stopniowo i dodawać wszelkie "komplikacje" dopiero wtedy, gdy rzeczywiście będą mu do czegoś potrzebne [ myśl zasady "Nie używam --> nie płacę." ;-) ]. Oczywiście bez utraty kompatybilności z kodem obiektowym.

      i nawet nie zagłębiałem się w PHP
      Dziękuj bogom! :-) PHP to okrutna sraczka ;-) Większość składni i ficzerów zerżnięte z innych języków [głównie z Javy], niestety nawet zerżnąć dobrze nie umieli :-P i powstał z tego nieprzemyślany chaotyczny zlepek nie zawsze pasujących do siebie elementów. Pełno w nim też dziwacznych bugów i pułapek. Nie wiem, czym on sobie zasłużył na taką popularność...

    •  

      pokaż komentarz

      @SasQ: co do PHP [Piszesz ch##owe Programy :P] myślę, że popularny, ponieważ był jakby pierwszy, "łatwy" na świecie, pewnego rodzaju framework dla perla...

      Kiedyś myślałem nad RoRem [wiem, to jak zend w php - framework], ale jak mówiłem porzuciłem web :)

      Jeśli Twój język będzie ogólnie dostępny :) a nie piszesz na korporacyjne zlecenie :) chętnie bym się zapoznał z nim :)

      życzę powodzenia :)

    •  

      pokaż komentarz

      @SasQ:
      "Myślę też nad możliwością taką, która pozwoliłaby na łatwą przemianę fragmentu kodu proceduralnego w moduł, a gdy uzna, że potrzebuje więcej instancji współdzielonych danych, moduł mógłby przekształcić następnie w klasę, stopniowo dodając drobne poprawki w kodzie."

      Podobnie jest to zrobione w Pythonie. W plikach Pythona (modułach) mogą się znajdować klasy, ale mogą też w nich leżeć funkcje, czy jakieś "statyczne" obiekty luzem, możesz w nich nawet umieścić normalny kod i zostanie od wykonany przy wczytywaniu pliku. Definicje klas, funkcji, czy metod to tak naprawdę zwyczajny, wykonywalny kod, którego działanie polega na przypisaniu definiowanego obiektu do jakiejś zmiennej.

  •  

    pokaż komentarz

    bleh, pascal, aż ciarki przechodzą ;p

  •  

    pokaż komentarz

    wg. mnie lepiej uczyć się normalnie programować, zaczynając od hello world niż zaprzątać sobie głowę takimi diagramami :)

  •  

    pokaż komentarz

    Ja się tam lepiej orientuje w kodzie niż w tych diagramach, musieliby najpierw zrobić coś odwrotnego tj. diagram -> kod żebym nauczył się je interpretować. Do tego programowanie w kodzie rozwija wyobraźnię.