On 13/03/2011 10:50, Sebastian Biały wrote:
> On 2011-03-13 02:57, Andrzej Jarzabek wrote:
>> No ale właśnie piszę - łączenie tego wszysztkiego w tym zastosowaniu
>> jest wadą, bo niepotrzebnie komplikuje język.
>
> Algorytmy sa takie że czasem łaczą rozwiązania optymalne z różnych
> dziedzin.

Co jednak niewiele zmienia w kwestii, czy programowania funkcyjnego
lepiej uczyć na małych językach stricte funkcyjnych, a programowania
proceduralnego na małych językach stricte proceduralnych.

> A klarowniej otrzymasz upychając częśc funkcyjną rozwiązania w język
> niefunkcyjny bądź odwrotnie?

Klarowniej będzie, jeśli studentom uczonym programowania proceduralnego
pokazujesz rozwiązania proceduralne, a nie np. funkcyjne, w momencie
kiedy nie znają podstaw programowania funkcyjnego.

>> nieistotne szczegóły. Lepiej do nauki określonych klass zagadnień
>> stosować małe, proste języki, które dobrze te zagadnienia wspierają bez
>> kompromisów w celu wspierania innych rzeczy.
>
> Co prawda ten fragment można 10x łatwiej napisać lambdą, ale nie możemy
> bo mamy Pascala. Natomiast cała reszta jes spoko.

Przecież nie chodzi o to, żeby napisać łatwiej.

>> No ale przecież masz małe i dobre języki do uczenia rzeczy na przecięciu
>> programowania funkcyjnego i imperatywnego. Np. Scheme.
>
> I np Scala. I 0 wsparcia do Scali i 0 dydaktyków do Scheme. E nie. To
> nie przejdzie.

Nie wiem o jakie wsparcie chodzi, ale chyba nie zamierzasz przyjmować
takiego kryterium "X jest dobrym językiem dydaktycznym" -> "ktoś uczy X
na uczelni w Myciskach Niżnych".

>> A ja mówię o tym, że żeby pisać poezję, najpierw dobrze jest opanować
>> alfabet.
>
> Ten alfabet ma dziury. W C++ też, ale troche mniej.

Do różnych literek masz różne czytanki.

>> Ale przecież ja nie postuluję stosowania Pascala w przemyśle.
>
> To jest podstawowy problem dydaktyki: czy na pewno uczyć rzeczy
> nieprzydatnych w jakiejś częsci czy może niewiele tracąc uczyć
> przydatnych? Zazwyczaj "na drugim roku" należy na kusie C/C++ odkrecać
> sposoby myślenia studenta np. "liczymy od 1" albo "jak wyjść z funkcji".
> Traci się na to sporo czasu.

A według mnie ważna część bycia sensownym programistą to umiejętność
radzenia sobie z takimi pierdołami.

>>> Standardowy Pascal to średniowiecze.
>> I co za problem? Nie nadaje się do nauczenia jak wygląda lista albo jak
>> działa quicksort?
>
> Quicksort tak.
>
> Lista nie bo dostajesz w łeb od razu jakimiś znaczkami "^".

Nie rozumiem, o co chodzi z tymi znaczkami. I czy według ciebie raczej
należy uczyć tego w języku bez "jakichś znaczków '^'" - i jaki to niby
język? Bo chyba nie C++?

> Nie. Ale wyjście w coś bardziej skomplikowanego rezalizuje sie i tak na
> innych jezykach i zazwyczaj są to języki klamrowe. Wiedza o składni
> pascala jest bezużyteczna. A jej wyjaśnienie zajmuje mase czasu.

Wiedza o składni Pascala jest równie bezużyteczna ddla kogoś, kto
programuje w języku klamrowym, co wiedza o tym, jak jest skonstruowana
lista dwukierunkowa, dla kogoś, kto używa std::list czy innego
java.util.LinkedList.

> Jesli faktycznie chcemy wyrzucić skladnie padcala do śmieci to tak
> naprawdę nie ma znaczenia jaki to będzie języki i też nijak na korzyśc
> Pascala nic nie przemawia.

Składnia to szczegół, ale przecież są inne języki o dużych walorach
edukacyjnych o podobnej składni: Modula-2 i Ada.

Ale przede wszystkim chodzi o to, że w ramach nauki dobrze się też
zetknąć z różnymi rozwiązaniami, składniami i "design philosophies".
Uczenie się tego to nie jest strata czasu, nawet jeśli danej składni nie
będzie się używać w praktyce.