Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości grup
dyskusyjnych:ilgbun$bfi$...@n...onet.pl...
>[O tym, czego nie ma w Delphi/Pascalu]
> Nie ma wielobazowego dziedziczenia. [...]
> Nie było nawet czegokolwiek co ma związek ze strukturami danych innymi niz
> indeksowane. [...]
> STL nie może być bo nie ma szablonów nawet w sensie tak prymitywnych jak
> pomiana typu. [...]

Dziękuję za odpowiedź. Okazało się że w Pascalu (Delphi) nie ma w/w rzeczy.

Podkreślam - nie oceniam czy to dobrze, czy źle - a jedynie ustalam, co jest
prawdą, a co mitem.

Stwierdzam, że mitem jest, że w Pascalu jest "wszystko to co w C++". Co
właśnie sobie udowodniliśmy.

slawek

do góry

Użytkownik "A.L." <l...@a...com> napisał w wiadomości grup
dyskusyjnych:qkdnn6hl3is57qdgt74nkpl1dhqhkig47a@4ax.
com...
> Bzdura. Do Pascala i do Delphi byla cala kupa bibliotek robiacych
> listy i inne struktury danych. Owszem, robi sie to inaczej nie przy
> pomocy "szablonow", ale bez wiekszcych trudnosci. Do dzis mam ksiazki
> dyskietki. 5 calowe ;)

A ja mam karty perforowane.

Niemniej jednak, biblioteki STL nie było i nie ma.

Oczywiście, symetrycznie, dla C/C++ nie ma różnych rzeczy dostępnych dla
Pascala.

slawek

do góry

On Sun, 13 Mar 2011 11:00:04 +0100, "slawek" <s...@h...pl> wrote:

>
>Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości grup
>dyskusyjnych:ilgbun$bfi$...@n...onet.pl...
>>[O tym, czego nie ma w Delphi/Pascalu]
>> Nie ma wielobazowego dziedziczenia. [...]
>> Nie było nawet czegokolwiek co ma związek ze strukturami danych innymi niz
>> indeksowane. [...]
>> STL nie może być bo nie ma szablonów nawet w sensie tak prymitywnych jak
>> pomiana typu. [...]
>
>Dziękuję za odpowiedź. Okazało się że w Pascalu (Delphi) nie ma w/w rzeczy.
>
>Podkreślam - nie oceniam czy to dobrze, czy źle - a jedynie ustalam, co jest
>prawdą, a co mitem.
>
>Stwierdzam, że mitem jest, że w Pascalu jest "wszystko to co w C++". Co
>właśnie sobie udowodniliśmy.
>
>slawek
>
No generyki już są:
http://docwiki.embarcadero.com/RADStudio/XE/en/Gener
ics_Index

Proste to jak proste ale jest. Można sobie już napisać generyczne
sortowanie bąbelkowe ;)
--
Grzegorz Krukowski

do góry

On Sun, 13 Mar 2011 11:00:04 +0100, "slawek" <s...@h...pl> wrote:

>
>Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości grup
>dyskusyjnych:ilgbun$bfi$...@n...onet.pl...
>>[O tym, czego nie ma w Delphi/Pascalu]
>> Nie ma wielobazowego dziedziczenia. [...]
>> Nie było nawet czegokolwiek co ma związek ze strukturami danych innymi niz
>> indeksowane. [...]
>> STL nie może być bo nie ma szablonów nawet w sensie tak prymitywnych jak
>> pomiana typu. [...]
>
>Dziękuję za odpowiedź. Okazało się że w Pascalu (Delphi) nie ma w/w rzeczy.
>
>Podkreślam - nie oceniam czy to dobrze, czy źle - a jedynie ustalam, co jest
>prawdą, a co mitem.
>
>Stwierdzam, że mitem jest, że w Pascalu jest "wszystko to co w C++". Co
>właśnie sobie udowodniliśmy.
>
>slawek
>

No generyki już są, w Delphi i w FreePascalu:

http://docwiki.embarcadero.com/RADStudio/XE/en/Gener
ics_Index
http://www.freepascal.org/docs-html/ref/refch8.html#
refse42.html

Działają w najprostszy sposób, tj. klasy są parametryzowane typami.
Można więc napisać generyczne sortowanie bąbelkowe ...
--
Grzegorz Krukowski

do góry

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.

>> Zamiast w języku 1 opisywać częsc problemów a w języku 2 inną część
>> można wszystko pokazac w jednym oszczędzając czas i klarując rozwiązania.
> Można, ale ani w ten sposób nie oszczędzisz czasu, ani nie otrzymasz
> klarowniejszych rozwiązań.

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

> 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.

> 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.

> 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.

> I do tego lepiej nadają się małe i proste języki skupione na
> realizacji określonego paradygmatu czy nawet określonych założeń
> dydatktycznych.

Datego do pokazania fraktali w gimnazjum używałem Logo. Ale nie
nazywalem tego nauką programowania.

> 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.

>> 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 "^".

> Jeśli chodzi o naukę kopania rowów, to nie będę się kłócił, bo na pewno
> znasz się lepiej.

<Ziew>

> A na innych uczelniach uczą, że tylko bubblesort? Bo tylko do tego się
> Pascal nadaje?

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.

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.

do góry

On 2011-03-12 23:48, Wit Jakuczun wrote:
> Oddać cesarzowi co cesarskie, czyli kawałek funkcyjny napisać w języku
> funkcyjnym. Albo kawałek programowania w logice w języku, który to
> wspiera, np. w prologu.

Jedyna nadzieja w .NET które ma pewną wartwę wspólną danych. Ale jesli
nie masz takiej gwarancji i musisz budować interfejsy komunikacyjne to
serdecznie współczuje wyboru, szczególnie ze problemy funkcyjne sa na
tyle małe że mozna je spokojnie embedowac w języku zamiast pisać 10x
większy kod do wymiany danych.

do góry

On 2011-03-13 00:09, A.L. wrote:
>>> Nie, drogi Kolego. Jakies 40 lat temu w dziedzinie makroporcesorow
>>> robiono rzeczy takie o ktorych makrogeneratorowi C++ zwanemu
>>> "templates" nawet sie nie sni.
>> Generatory kodu we wszelakiej postaci mocno odbiegają od tematu wątku.
>> Ale tak, stosuje sporadycznie. Zaryzykuje że sa słabo związane z
>> konkretnym językiem.
> Makro a generatory kodu to dwie zupelnei inne rzeczy

Możesz wyjasnić różnice? Na jakimś prostym przykładzie.

do góry

On 13/03/2011 10:17, Grzegorz Krukowski wrote:
> On Sun, 13 Mar 2011 11:00:04 +0100, "slawek"<s...@h...pl> wrote:
>
> No generyki już są, w Delphi i w FreePascalu:

Także: jeśli rozpatrujemy walory dydaktyczne Pascala, to po nauczeniu
podstaw w Pascalu można przejść na Adę, która ma generyki w standardzie.

do góry

On 13/03/2011 05:19, Jacek wrote:
> Dnia Sun, 13 Mar 2011 01:14:25 +0000, Andrzej Jarzabek napisał(a):
>>
>> Na dzień dobry składnia jest strasznie kaszaniasta: np. dosyć podobne
>> wywołania metod czasem trzeba poprzedzić instrukcją Call, a czasem nie,
>> w zależności od liczby argumentów. Tak w ogóle strasznie głęboko się nie
>> wgryzałem, ale nawet przy banalnie prostych skryptach człowiek się
>> natyka na takie dziwactwa.
>
> You are not required to use the Call keyword when calling a procedure.
> However, if you use the Call keyword to call a procedure that requires
> arguments, argumentlist must be enclosed in parentheses. If you omit the
> Call keyword, you also must omit the parentheses around argumentlist. If
> you use either Call syntax to call any intrinsic or user-defined function,
> the function's return value is discarded.

To już by było wystarczająco złe, ale miałem tak, że wywoływałem bez
call, z argumentami i nawiasami i czasem działało, a czasem nie, w
zależności od liczby argumentów.

Ogólnie problem VB jest taki, że wprowadza zbyt dużą dowolność w składni
(argumenty w nawiasach lub bez nawiasów, zmienne można deklarować lub
nie itd.), a kiedy z konieczności doprowadza to do sprzeczności,
rozwiązuje je okropnie zawiłymi regułami.

do góry

W dniu 2011-03-13 11:53, Sebastian Biały pisze:
> On 2011-03-12 23:48, Wit Jakuczun wrote:
>> Oddać cesarzowi co cesarskie, czyli kawałek funkcyjny napisać w języku
>> funkcyjnym. Albo kawałek programowania w logice w języku, który to
>> wspiera, np. w prologu.
>
> Jedyna nadzieja w .NET które ma pewną wartwę wspólną danych. Ale jesli
> nie masz takiej gwarancji i musisz budować interfejsy komunikacyjne to
> serdecznie współczuje wyboru, szczególnie ze problemy funkcyjne sa na
> tyle małe że mozna je spokojnie embedowac w języku zamiast pisać 10x
> większy kod do wymiany danych.
Kod do wymiany jest bardzo prosty. Ale fakt, F# wydaje się ciekawy.
Tylko, że mi kompletnie nieprzydatny by był.

A kawałek pisałem w Prologu i napisanie go w .Net byłoby raczej mało
sensowne. To nie był mały kawałek.

Są też inne zalety takiego rozdzielenia. Na przykład koncepcyjnie od
początku mam możliwość liczenia rozproszonego.

Pozdrawiam,
Wit

do góry