🚀 go-pugleaf

"Michal Przybylek" <mrp@neostrada.pl> wrote:

> Czyli jak bedziemy programowac ?

Mialo byc:

Czyli jak chcielibysmy programowac ?


mp

Dnia Mon, 17 Oct 2005 21:50:38 +0200, Michal Przybylek skrobie:
> "A.L." <alewando@kapturek62.com> wrote:

> > Przerazajace jet tylko to ze juz minelo 5 lat 21 stulecia i wyglada
> > na to ze za kolejnych lat 10 bedziemy programowac tak jak za Krola
> > Cwieczka...

> Czyli jak bedziemy programowac ?

> Zamiast pod Windows za pomoca Eclipse w Javie, to pod Linuksem za pomoca
> Emacsa w Haskellu ?

> Pytam powaznie.

Tak się akurat składa, że żadna z tych rzeczy nie dominuje w dzisiejszej
inżynierii oprogramowania i nawet się na to nie zanosi. Więc pytanie jest co
najmniej bez sensu.

> Reaserch w programowaniu nastepuje caly czas dosc dynamicznie. Tylko, ze
> teraz smietanka komputerowej inteligencji zrzeszyla sie przy Haskellu i
> programowaniu funkcyjnym.

Taaa... udało im się nawet wyeliminować zmienne stanu. Super.

Problem tylko w tym, że Haskell nie nadaje się do tworzenia oprogramowania.
Nie przeczę, jest niezaprzeczalnie jeśli nie najlepszym, to jednym z
najlepszych funkcjonalnych języków programowania, ale do cholery, nie
oszukujmy się, jest i pozostanie na wieki językiem niszowym. I to nie tylko z
powodu małej wydajności, ale z tego powodu, że... jest językiem programowania
funkcjonalnego (czy też wręcz "czysto-funkcjonalnego").

Haskellem, jak sam powiedziałeś, zajmuje się "śmietanka komputerowej
inteligencji". I tak też pozostanie on językiem "śmietanki". O tym, żeby
wszedł do masowego użytkowania, można jedynie pomarzyć.

> Ah, i dla nich Emacs jest optymalnym narzedziem, w
> koncu "Emasc mozna sobie zaprogramowac tak, aby robil to wszystko co dowolne
> inne IDE, zas w druga strone sie nie da".

Mnie to w sumie rybka. I tak nie używam żadnych IDE. A edytor mam tak
skonfigurowany, jak to mi jest w ogólności potrzebne.

Nb. już widzę tych gości, jak każdy z nich ma skonfigurowany edytor na własne
potrzeby (i jak jeden nie może pracować z edytorem drugiego). Sama śmietanka
przecież, na pewno każdy jest indywidualistą.

> ps. Poczytaj sobie ten papier (dostepny online):

> "Arrows, Robots, and Functional Reactive Programming"
> Hudak, Courtney, Nilsson, Peterson

No dobrze, wszystko pięknie i ładnie (no, jeśli pominiemy oksymoron w postaci
połączenia określeń "Haskell" i "critical performance"). Tylko jest w tym
wszystkim jeden drobny szczegół: średnia "komputerowej inteligencji" wcale nie
rośnie. Gdyby było inaczej, Java nigdy nie zdobyłaby popularności (pomijając,
że w ogóle by nie powstała), a ktoś, kto nie potrafi pisać w Lispie nie byłby
programistą.

To znaczy: być może Haskell zdobędzie sobie trochę większą popularność w tej
właśnie dziedzinie. Ale bynajmniej nie spowoduje to, że jego popularność
rozszerzy się na jakiekolwiek inne dziedziny.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > Zamiast pod Windows za pomoca Eclipse w Javie, to pod
> >Linuksem za pomoca Emacsa w Haskellu ?
>
> > Pytam powaznie.
>
> Tak się akurat składa, że żadna z tych rzeczy nie dominuje
> w dzisiejszej inżynierii oprogramowania i nawet się na to nie
> zanosi. Więc pytanie jest co najmniej bez sensu.

Pytanie ma sens. Przemysl prosze.

Reszta wnioskow jest generalnie OK :-)


mp

Dnia Tue, 18 Oct 2005 18:43:15 +0200, Michal Przybylek skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > > Zamiast pod Windows za pomoca Eclipse w Javie, to pod
> > >Linuksem za pomoca Emacsa w Haskellu ?
> >
> > > Pytam powaznie.
> >
> > Tak się akurat składa, że żadna z tych rzeczy nie dominuje
> > w dzisiejszej inżynierii oprogramowania i nawet się na to nie
> > zanosi. Więc pytanie jest co najmniej bez sensu.

> Pytanie ma sens. Przemysl prosze.

Pytanie nie ma sensu. Przynajmniej dla mnie.

Z przyczyn osobistych - nie programuję pod Windowsem, nie używam Eclipsa, nie
robię w Haskellu i nie używam również Emacsa. I nie zamierzam. Ale to akurat
możemy pominąć.

Emacs jest, owszem, popularny, tylko jakoś tak się dziwnie dzieje, że
większość programistów wybiera jednak windowsowe, ładnie klikane, GUI-owe IDE
(muszę dodawać, że NATYWNE?). U mnie w firmie np. dużą popularnością cieszy
się Visual SlickEdit. Użytkowników Eclipse'a mogę policzyć na palcach u
jednej ręki. Nawet w tych zespołach, które piszą w Javie.

Jest trochę użytkowników Emacsa (aczkolwiek jeśli chodzi o edytory zdalne, to
jednak więcej użytkowników ma vim). Ale stosują go raczej jako zdalny edytor
pod X-ami, niż jako środowisko programowania. A jak widzę, jak tego Emacsa
obsługują, to wydaje mi się, że po prostu ten edytor łatwiej im było
dostosować do windowsowych przyzwyczajeń.

Tyle co do IDE/edytora.

Co do systemu - tu nie przeczę, że konieczności używania windowsa jako systemu
do obsługi komputera nie ma już dziś. Poza tym Linux, jak się okazuje,
znacznie lepiej nadaje się jako system na maszynę roboczą dla programisty.
Żeby mieć podobny komfort pracy pod Windowsem, konieczna jest jeszcze
instalacja Cygwina - dzięki czemu mamy niby-linuxopodobne środowisko o
wydajności 70% tego, co wyciągnie Linux.

Co do ewentualnej przesiadki na Linuxa jestem jednak sceptyczny - niektóre
firmy mają np. konkretne umowy z Microsoftem, więc z Windowsów nie zrezygnują.
Tragedia to się dopiero robi, jak poczta jest na Exchange'u i bez Outlooka nie
ma się pełnej funkcjonalności.


Wracając jednak do kluczowej sprawy, czyli języka: przecież na dobrą sprawę
Haskell nie jest wcale tak znów młodszy od Javy (o ile wiem, te języki
powstały mniej więcej w tym samym czasie). Co prawda w przypadku Javy dużą
rolę odegrał marketing firmy Sun, ale to jeszcze o niczym nie świadczy w
stosunku do Haskella (C++-owi jakoś nikt marketingu nie robił). Skoro więc nie
zdobył on nawet części tej popularności co Java i C++, to znaczy, że istniały
ku temu bardzo istotne powody. I nie sądzę, żeby się te powody kiedykolwiek
zmieniły.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

Dnia Tue, 18 Oct 2005 18:43:39 +0200, Michal Przybylek skrobie:
> No wiec sie pytam - jak chcieli bysmy programowac, a jak programujemy, ze
> jest zle ?

Chcielibyśmy programować tak, żeby:
 - móc programować generycznie (bo powtarzanie kodu wiąże się z powtarzaniem
   błędów)
 - móc programować bezpiecznie, tzn. tak, żeby programistę zniechęcać do
   stosowania niebezpiecznych konstrukcji
 - móc programować łatwo i szybko, tzn. żeby narzut związany z samym językiem
   programowania w stosunku do tego, co chcemy w nim zrobić, był w miarę
   niewielki
 - móc programować sprawnie, tzn. tak, żeby ilość pojawiających się
   przypadkiem błędów funkcjonalnych była niewielka, a błędy łatwe do
   znalezienia
 - móc programować przewidywalnie, tzn. tak, żeby język nie zaskakiwał
   użytkownika nagłym spowolnieniem pracy w nieoczekiwanych momentach i nagłym
   zżeraniem zasobów w nieoczekiwanych ilościach

A tak programujemy, że jest źle:
 - programujemy na czuja
 - języki nie dostarczają nam zadowalającego generyzmu
 - błędy są wykrywane na zbyt późnym etapie
 - programujemy niezbyt intencjonalnie (zbyt duża rozbieżność w źródłach
   pomiędzy intencją programisty a zapisem składniowym)
 - programujemy mało przewidywalnie (język nakłada zbyt duży overhead, za
   który płacimy, nie mając z niego korzyści)
 - języki dają duży overhead na tworzenie oprogramowania

Wiele z tych cech wynika ze specyfiki języka, czasem z wyboru konkretnej
drogi. Na przykład typizacja statyczna ma bardzo dobre osiągi jeśli chodzi o
wydajność i sprawdzanie błędów w czasie kompilacji, ale powoduje duży overhead
podczas pisania i konieczność godzenia się na zależności. Dynamiczna typizacja
jest znacznie prostsza zarówno w stosowaniu, jak i w implementacji, nie
nakłada na kod takich zależności, ale zarówno dodaje overhead na run-time, jak
i nie pozwala na wczesne wykrywanie błędów. To są sprawy nie do pogodzenia.

> Bo:

> Jak dla mnie mamy _dobre_ jezyki programowania. Takie, w ktorych _mozna_
> pisac dobre programy (przypomne tylko, ze jeszcze calkiem niedawno dominowal
> jezyk, w ktorym _nie dalo sie_ tworzyc dobrych programow).

Jeśli mówisz o języku C, to muszę cię zmartwić - w tym języku dziś powstaje
najwięcej oprogramowania.

> Jasne, ze wolalbym Haskell, Lisp, lub Smalltalk, ale skoro jest tak, a nie
> inaczej, to moge polubic tez Jave i C#.

Z Haskellem problem polega na tym, że trzeba sie przestawić na inny sposób
myślenia, który jest większości programistom obcy.

Z Lispem problem polega na jego totalnie nieludzkiej składni (jak tą składnię
można było zrobić dobrze, pokazuje wystarczająco język Tcl).

Smalltalk... no cóż. Skoro Javy nie przebił, to niewykluczone, że jednak ta
statyczna typizacja ma swoje istotne zalety.

> Jak dla mnie, mamy _bardzo dobre_ narzedzia do tworzenia oprogramowania.
> Takie o jakich kilkanascie lat temu moglismy tylko pomarzyc. Jezeli
> programowanie w Smalltalku 20 lat temu wygladalo podobnie jak programowania
> w Dolphinie teraz, to ja sie tylko ciesze, ze nie musialem programowac 20
> lat temu.

W którym Dolphinie, jeśli można wiedzieć?

Prawda jest taka, że najważniejszą rolę odgrywa tutaj tzw. czynnik ludzki.
Innymi słowy, programujemy tak, jak programujemy, bo takich mamy programistów.
Inaczej mówiąc, bo większości programistów takie problemy nie przeszkadzają.



-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

On Tue, 18 Oct 2005 22:12:45 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
 
>
>A tak programujemy, że jest źle:
> - programujemy na czuja
> - języki nie dostarczają nam zadowalającego generyzmu
> - błędy są wykrywane na zbyt późnym etapie
> - programujemy niezbyt intencjonalnie (zbyt duża rozbieżność w źródłach
>   pomiędzy intencją programisty a zapisem składniowym)
> - programujemy mało przewidywalnie (język nakłada zbyt duży overhead, za
>   który płacimy, nie mając z niego korzyści)
> - języki dają duży overhead na tworzenie oprogramowania
>
>Wiele z tych cech wynika ze specyfiki języka, czasem z wyboru konkretnej
>drogi. Na przykład typizacja statyczna ma bardzo dobre osiągi jeśli chodzi o
>wydajność i sprawdzanie błędów w czasie kompilacji, ale powoduje duży overhead
....

Panowie, mnie nie o to chodzi. Mnei chodzi o to ze w ogole wszystkie
jezyki  sa d do... i o to ze programowanie tak jak robimy dzisiaj to
manufaktura. Dyskusja czy ten jezyk jest lepszy czy ten gorszy
przypomina dyskusje facetow zajmujacych sie zawodowo kopaniem rowow
i dyskutujacych zawziecia jakiej firmy kilof jest lepszy. Problem
polega na tym ze najlepsza jest koparka.

Czy za 10 lat bedziemy programowac w C#, C++ i Javie?... Tak linia
po linii? Edytorem Emacs czy vi? Pod Windows, a moze kto wie, ho,
ho, pod Linuksem?... A za lat 20?.. A za lat 30?... Mam nadzieje ze
nie. A jak nie, to jak?...

A.L.

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > > > Zamiast pod Windows za pomoca Eclipse w Javie, to pod
> > > >Linuksem za pomoca Emacsa w Haskellu ?
> > >
> > > > Pytam powaznie.
> > >
> > > Tak się akurat składa, że żadna z tych rzeczy nie dominuje
> > > w dzisiejszej inżynierii oprogramowania i nawet się na to nie
> > > zanosi. Więc pytanie jest co najmniej bez sensu.
>
> > Pytanie ma sens. Przemysl prosze.
>
> Pytanie nie ma sensu. Przynajmniej dla mnie.

Ma sens. Formalnie - do postawienia pytania wystarczyl mi kwantyfikator
egzystencjalny...

Ale mniejsza z tym (glownym zadaniem postawienia owego pytania bylo
zbudowanie odpowiedniego kontekstu wypowiedzi).


mp

"A.L." <alewando@kapturek62.com> wrote:

> Czy za 10 lat bedziemy programowac w C#, C++ i Javie?... Tak linia
> po linii? Edytorem Emacs czy vi? Pod Windows, a moze kto wie, ho,
> ho, pod Linuksem?... A za lat 20?.. A za lat 30?... Mam nadzieje ze
> nie. A jak nie, to jak?...

OK, zgoda, rozumiem o czym mowisz. Przy czym dla mnie wlasnie narzedzia typu
Eclipse, czy NetBeans sa _malutkim_ kroczkiem w strone tego "innego
programowania" (nie wiem kiedy ostatni raz widziales te srodowiska...).

Ah, no i mnie co bedzie za 10 lat, juz raczej dotykac nie bedzie. Wiec nie
wiaze z tym jakichkolwiek nadziei.


mp

"Michal Przybylek" <mrp@neostrada.pl> writes:

[...]

> Czyli jak bedziemy programowac ?

Tak, jak do tej pory: w niektórych zastosowaniach imperatywnie, 
w innych deklaratywnie, stosując odpowiednie języki do przynależnych 
im zastosowań.  

-- 
http://www.piotr.dembiński.prv.pl
szukam pracy

On Wed, 19 Oct 2005 21:24:01 +0200, pdemb@gazeta.pl (Piotr Dembiñski)
wrote:

>"Michal Przybylek" <mrp@neostrada.pl> writes:
>
>[...]
>
>> Czyli jak bedziemy programowac ?
>
>Tak, jak do tej pory: w niektórych zastosowaniach imperatywnie, 
>w innych deklaratywnie, stosuj±c odpowiednie jêzyki do przynale¿nych 
>im zastosowañ.  

Tia?... Niejaki Kurzweil w skojej najnowszej ksiazce "Singularity is
Near" przewiduje ze za 25 lat komputer typu desktop osiagnie moc
oblizeniowa rowna mocy ludzkiego mozgu. I ten mozg bedziemy
programowac w rodzaju "if cost_tam then cost_tam else cos_innego"?...

Cos mi sie wierzyc nie chce...

A.L.

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> Z Lispem problem polega na jego totalnie nieludzkiej składni
> (jak tą składnię można było zrobić dobrze, pokazuje
> wystarczająco język Tcl).

Zgadzam sie z tym, ze skladnia Lispu moze byc jednym z powodow, dla ktorych
ten jezyk nie jest popularny (BTW: Dylan ma "normalna" skladnie, a od Lispu
jest zdechly jeszcze bardziej), ale...

Sektor, czy Ty _w koncu_ wezmiesz pod uwage to, ze _sa_ ludzie ktorzy
skladnie Lisp'u lubia ? I, ze najczesciej ci co skladni Lispu nie lubia,
Lispu nie znaja, w Lispie nie napisali czegokolwiek, lub napisali niewiele.

Lacznie z Toba, Sektor. Tak, lacznie z Toba !

Przez cale zycie miales do czynienia ze skladnia infiksowa, wiec jestes do
niej przyzwyczajony. Odzwyczajenie sie zwykle wymaga wysilku i czasu.

Wyobraz sobie, ze ja tez mialem cale zycie do czynienia, ze skladnia
infiksowa. Wyobraz sobie, ze kiedy pierwszy raz przyszedlem do Lispu, to tez
mnie jego skladnia odrzucila. Wyobraz tez sobie, ze teraz, uwazam, ze
skladnia Lispu jest w wielu zastosowaniach najczytelniejsza skladnia jaka
kiedykolwiek powstala.

> W którym Dolphinie, jeśli można wiedzieć?

Dolphin Smallatalk, o ile dobrze pamietam.


mp

"Michal Przybylek" <mrp@neostrada.pl> writes:

[...]

> Jak dla mnie mamy _dobre_ jezyki programowania. Takie, w ktorych
> _mozna_ pisac dobre programy (przypomne tylko, ze jeszcze calkiem
> niedawno dominowal jezyk, w ktorym _nie dalo sie_ tworzyc dobrych
> programow).

VB nadal jest popularny.

"Michal Przybylek" <mrp@neostrada.pl> writes:

[...]

> - Java jest krok wstecz za C++, bo ma odsmiecanie,

To żart?

A.L. <alewando@kapturek62.com> writes:

[...]

> Dyskusja czy ten jezyk jest lepszy czy ten gorszy przypomina
> dyskusje facetow zajmujacych sie zawodowo kopaniem rowow 
> i dyskutujacych zawziecia jakiej firmy kilof jest lepszy. 
> Problem polega na tym ze najlepsza jest koparka.

Jeśli tak postawić sprawę, to ja czekam na środowiska deweloperskie,
które przypominają gry komputerowe :)

-- 
http://www.piotr.dembiński.prv.pl

A.L. <lewando_won_@kalabambuko.com> writes:

> On Wed, 19 Oct 2005 21:24:01 +0200, pdemb@gazeta.pl (Piotr
> Dembiñski)
> wrote:
>
>>"Michal Przybylek" <mrp@neostrada.pl> writes:
>>
>>[...]
>>
>>> Czyli jak bedziemy programowac ?
>>
>>Tak, jak do tej pory: w niektórych zastosowaniach imperatywnie, 
>>w innych deklaratywnie, stosując odpowiednie języki do przynależnych 
>>im zastosowań.  
>
> Tia?... Niejaki Kurzweil w skojej najnowszej ksiazce "Singularity is
> Near" przewiduje ze za 25 lat komputer typu desktop osiagnie moc
> oblizeniowa rowna mocy ludzkiego mozgu. I ten mozg bedziemy
> programowac w rodzaju "if cost_tam then cost_tam else
> cos_innego"?...

Nie, bo w AI stosuje się regułę rezolucji, a nie takie tam proste if-y
:-P

> Cos mi sie wierzyc nie chce...

Ja tam czekam na programy pozwalające zarabiać na udostępnianiu mocy
obliczeniowej swojego peceta :)

"Michal Przybylek" <mrp@neostrada.pl> writes:

[...]

> Wyobraz sobie, ze ja tez mialem cale zycie do czynienia, ze skladnia
> infiksowa. Wyobraz sobie, ze kiedy pierwszy raz przyszedlem 
> do Lispu, to tez mnie jego skladnia odrzucila. Wyobraz tez sobie, 
> ze teraz, uwazam, ze skladnia Lispu jest w wielu zastosowaniach
> najczytelniejsza skladnia jaka kiedykolwiek powstala.

Zgadzam się.  Dla mnie na przykład

  (+ 1 2 3 4 5 6 7) 

jest bardziej czytelne od 

  1 + 2 + 3 + 4 + 5 + 6 + 7.

W końcu to się czyta 'dodaj do siebie ...', a nie 'jeden dodaj dwa ...'.

-- 
http://www.piotr.dembiński.prv.pl

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> > Wyobraz sobie, ze ja tez mialem cale zycie do czynienia, ze skladnia
> > infiksowa. Wyobraz sobie, ze kiedy pierwszy raz przyszedlem
> > do Lispu, to tez mnie jego skladnia odrzucila. Wyobraz tez sobie,
> > ze teraz, uwazam, ze skladnia Lispu jest w wielu zastosowaniach
> > najczytelniejsza skladnia jaka kiedykolwiek powstala.
>
> Zgadzam się.  Dla mnie na przykład
>
>   (+ 1 2 3 4 5 6 7)
>
> jest bardziej czytelne od
>
>   1 + 2 + 3 + 4 + 5 + 6 + 7.
>
> W końcu to się czyta 'dodaj do siebie ...', a nie 'jeden dodaj dwa ...'.

Akurat nie mialem na mysli zastosowan numerycznych :-)

Skladnia Lispu jest "drozsza" od standardowej, ale za to, w szczegolnosci:

- wyrazenia sa zapisywane zawsze w ten sam sposob,

- sposob zapisu kompozycji wyrazen bedzie zazwyczaj bardzo zblizony,

- nawiasy w Lispach sa zawsze w jeden sposob zapisywane i zawsze znaczace,

- nazwa operacji wystepuje zawsze na poczatku (a oczywiscie rozumienie
wyrazenia musimy zaczynac od zrozumienia sensu operacji, a nie jej
argumentow).

- inne wymuszenia skladni Lispu - np. sposob wprowadzania zmiennych,
wykonywanie akcji, ...


mp

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> > - Java jest krok wstecz za C++, bo ma odsmiecanie,
>
> To żart?

Juz pisalem bylem, ze nie.

Zreszta nie jest to nawet dziwne - przypomnij sobie tylko jaki byl glowny
zarzut wobec Javy u jej zarania.


mp

"Michal Przybylek" <mrp@neostrada.pl> writes:

> "Piotr Dembiński" <pdemb@gazeta.pl> wrote:
>
>> > - Java jest krok wstecz za C++, bo ma odsmiecanie,
>>
>> To żart?
>
> Juz pisalem bylem, ze nie.
>
> Zreszta nie jest to nawet dziwne - przypomnij sobie tylko jaki byl
> glowny zarzut wobec Javy u jej zarania.

Nie wiem.  Może to, że jest powolna?

Dnia Tue, 18 Oct 2005 21:40:31 -0500, A.L. skrobie:
> Panowie, mnie nie o to chodzi. Mnei chodzi o to ze w ogole wszystkie
> jezyki  sa d do... i o to ze programowanie tak jak robimy dzisiaj to
> manufaktura.

No bo tak się programuje w przemyśle. Kto jak kto, ale pan powinieneś się już
do tego przyzwyczaić.

Ale skoro - jak pan uważasz - wszystkie języki są do tego tam, to co pana
zdaniem brakuje tym językom, żeby były lepsze. Albo jakie one miałyby być w
ogole, zeby byly dobre.

> Dyskusja czy ten jezyk jest lepszy czy ten gorszy
> przypomina dyskusje facetow zajmujacych sie zawodowo kopaniem rowow
> i dyskutujacych zawziecia jakiej firmy kilof jest lepszy. Problem
> polega na tym ze najlepsza jest koparka.

Czyli inny komputer, ktory bedzie programowal zamiast czlowieka, a czlowiek
bedzie mu mowil tylko np.: napisz aplikacje do obslugi hotelu.

Albo wlasciwie to w ogole nie bedzie aplikacji, tylko beda
pozycje/moduly/przykladowe sposoby obslugi i uzytkownik bedzie je tylko
wybieral, a narzedzie skladalo je do kupy.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Wed, 19 Oct 2005 22:11:03 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>Dnia Tue, 18 Oct 2005 21:40:31 -0500, A.L. skrobie:
>> Panowie, mnie nie o to chodzi. Mnei chodzi o to ze w ogole wszystkie
>> jezyki  sa d do... i o to ze programowanie tak jak robimy dzisiaj to
>> manufaktura.
>
>No bo tak siê programuje w przemy¶le. Kto jak kto, ale pan powiniene¶ siê ju¿
>do tego przyzwyczaiæ.
>
>Ale skoro - jak pan uwa¿asz - wszystkie jêzyki s± do tego tam, to co pana
>zdaniem brakuje tym jêzykom, ¿eby by³y lepsze. Albo jakie one mia³yby byæ w
>ogole, zeby byly dobre.

Ciagle sie nei rozumiemy: mnie chodzi o to zeby jezykow nie bylo W
OGOLE...

A.L.

Dnia Wed, 19 Oct 2005 17:17:28 -0500, A.L. skrobie:
> >Ale skoro - jak pan uwa?asz - wszystkie j?zyki s? do tego tam, to co pana
> >zdaniem brakuje tym j?zykom, ?eby by?y lepsze. Albo jakie one mia?yby by? w
> >ogole, zeby byly dobre.

> Ciagle sie nei rozumiemy: mnie chodzi o to zeby jezykow nie bylo W
> OGOLE...

W zasadzie nie wiem, co mam odpowiedzieć. Mam kilka możliwości, które spróbuję
posortować od najgorszej do najgłupszej.

Kopytko. No ale pewnie nie każdy wie o co chodzi. Ja zresztą też nie.

Mógłbym odpowiedzieć: No nareszcie się rozumiemy. Ale to zbyt naiwne.

Ewentualnie: No to właściwie co miałoby być zamiast języków programowania?
Czy to ma sens? Panie Andrzeju, może zadawanie tego pytania miałoby sens,
gdyby nie fakt, że usiłujesz pan z nami grać w kotka i myszkę.

Inna możliwość: Wg pana zapewne najlepiej zamknąć w miarę jak najszybciej całą
inżynierię oprogramowania, bo w sumie wszystko jest złe: języki programowania
są do doo..., przydatność narzędzi diagramowych zerowa, a mojej propozycji,
żeby tworzenie aplikacji zwalić w 90% na komputery też jakoś nie zyskała nawet
drobnego zainteresowania, o entuzjaźmie nawet nie marząc. Ale nie wiem...

Zresztą co za różnica.

Pisanie programów w postaci tekstowej było od zawsze. Nieważne, czy ten tekst
był symboliczny, czy trzeba go było ręcznie kodować, czy co. Pisaliśmy tekstem
od początku powstania inżynierii oprogramowania i piszemy tekstem do dziś.

Więc będziemy dalej pisać w językach programowania.
Ludzie od diagramów dalej będą twierdzić, że tak się pisze fajniej.
Czasem przemysł nawet na to jakoś zareaguje.
Ludzie od języków funkcjonalnych nadal będą narzekać, że paskudne języki
zwyciężają.

I tylko świstak się kiedyś przekręci od nadmiaru wpierdalanych czekoladek.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Wed, 19 Oct 2005 21:35:35 +0200, Michal Przybylek skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > Z Lispem problem polega na jego totalnie nieludzkiej składni
> > (jak tą składnię można było zrobić dobrze, pokazuje
> > wystarczająco język Tcl).

> Zgadzam sie z tym, ze skladnia Lispu moze byc jednym z powodow, dla ktorych
> ten jezyk nie jest popularny (BTW: Dylan ma "normalna" skladnie, a od Lispu
> jest zdechly jeszcze bardziej), ale...

Powodów popularności danego języka programowania jest jeszcze wiele różnych
innych.

> Sektor, czy Ty _w koncu_ wezmiesz pod uwage to, ze _sa_ ludzie ktorzy
> skladnie Lisp'u lubia ?

To ich problem!

> I, ze najczesciej ci co skladni Lispu nie lubia,
> Lispu nie znaja, w Lispie nie napisali czegokolwiek, lub napisali niewiele.

Dzieje się tak z bardzo prostej przyczyny. Po prostu ci, którzy w Lispie
napisali cokolwiek więcej, niż niewiele, to ci, których składnia Lispa nie
odrzuciła na tyle, żeby ich totalnie zniechęcić do tego języka.

Pamiętaj o tym, że składnia języka jest czymś, z czym ktoś stykający się z
językiem po raz pierwszy ma kontakt jako pierwszą rzeczą w tym języku. Jeśli
taka składnia będzie dla niego stanowić barierę w akceptacji zbyt długo, to o
ile taki ktoś nie będzie miał obowiązku się go uczyć, rzuci to w cholerę.

Dlatego brak akceptacji dla składni Lispa jest PRZYCZYNĄ, a nie SKUTKIEM tego,
że dany osobnik niczego w nim nie napisał.

> Lacznie z Toba, Sektor. Tak, lacznie z Toba !

W oburzeniu?

> Przez cale zycie miales do czynienia ze skladnia infiksowa, wiec jestes do
> niej przyzwyczajony. Odzwyczajenie sie zwykle wymaga wysilku i czasu.

Co za totalna bzdura! Wydaje się, że zapomniałeś już, o czym pisałem w
ostatnim zdaniu, które zacytowałeś. Weź to przeczytaj jeszcze raz, a potem
wejdź sobie np. na http://pl.wikipedia.org/wiki/Tcl lub ewentualnie
http://pl.wikipedia.org/wiki/Expect i wtedy się dowiesz, dlaczego składnia
prefixowa może być całkiem akceptowalna pod warunkiem, że się z nią nie
przegina.

> Wyobraz sobie, ze ja tez mialem cale zycie do czynienia, ze skladnia
> infiksowa. Wyobraz sobie, ze kiedy pierwszy raz przyszedlem do Lispu, to tez
> mnie jego skladnia odrzucila. Wyobraz tez sobie, ze teraz, uwazam, ze
> skladnia Lispu jest w wielu zastosowaniach najczytelniejsza skladnia jaka
> kiedykolwiek powstala.

Dobrze, przestań, bo się rozpłaczę.

Wskażę ci kilka drobnych aspektów, dla których uważam, że składnię Tcl-a
zrobiono znacznie LEPIEJ, niż składnię Lispa, mimo że składnia Tcl-a była w
istocie WZOROWANA na Lispie:

1. W Tcl-u obowiązuje oddzielanie instrukcji przez podział na linijki.
Alternatywnie można by było żądać średnika na koniec każdej instrukcji, efekt
byłby mniej więcej ten sam - ale w sumie moim zdaniem tak też jest dobrze.
Efekt jest taki, że kod wykonywalny dzieli się na elementy tam, gdzie są końce
linii i średniki. W Lispie musisz sobie ten kod dzielić na kawałki ręcznie,
wstawiając w odpowiednich miejscach nawiasy.

2. Napisanie danego elementu bez żadnych dodatkowych określeń powoduje jego
ewaluację (i trzeba użyć znaku ' żeby go przed tym powstrzymać). W Tcl-u
ewaluację (czyli wykonywanie instrukcji i zwracanie jej wartości jako
wyrażenia) wykonuje się tylko jeśli argumenty są w []. Czyli inaczej: jeśli
napiszemy:
	a
To oznacza nic innego, niż po prostu "a". Dopiero gdy napiszemy [a] to chodzi
nam o wartość funkcji o nazwie 'a', a gdy $a - o wartość zmiennej o nazwie
'a'.

W Lispie jeśli napiszemy:
	a
To najpierw zostanie znaleziony zdefiniowany atom o nazwie 'a', zostanie on
zwartościowany (zakładając, że zostanie znaleziony) i dopiero to, co powstanie
po tym zwartościowaniu jest przekazywane dalej. Żeby zażądać nie
wartościowania pojedynczego atomu lub listy, trzeba tego zażądać jawnie przez
znak '. Oczywiście to nie wszystko - to, czy rzeczywiście nastąpi tam
wartościowanie danego elementu, zależy jeszcze od kontekstu (czyli tego, co
było pierwszym elementem listy, w której dany atom występuje).

Efekt jest taki, że poniższy kawałek kodu (wyciągnąłem to z Emacsa):

(defun gtypist-mode-get-list-of-labels()
  "Get the list of gtypist-labels in this buffer (alist name . position)."
  (save-excursion
    (let ((deactivate-mark)
	  (labels))
      (goto-char (point-min))
      (while (re-search-forward "^\\*:\\(.+\\)[\t ]*" nil t nil)
	(setq labels (nconc labels (list (cons (match-string 1) (point))))))
      labels)))

Napisany wedle składni Tcl-a wyglądałby tak:

defun gtypist-mode-get-list-of-labels {} \
  "Get the list of gtypist-labels in this buffer (alist name . position)." {

  save-excursion [let "deactivate-mark [labels]" {
	goto-char [point-min]
	while { [re-search-forward "^\\*:\\(.+\\)[\t ]*" {} [t] {}] } {
		setq labels [nconc labels [cons [match-string 1] [point]]]
	}
	labels
  }]
}

Chociaż dla tej linijki:

	setq labels [nconc labels [cons [match-string 1] [point]]]

Można by jeszcze rozważyć "alternatywne" podejście (ale to już jest "własne
rozszerzenie"):

	match-string 1 | cons - [point] | nconc labels - | setq labels -


Nie chcę pokazywać palcem, które z nich ma więcej pokręconych nawiasów i nie
do końca oczywistych na pierwszy rzut oka zachowań.

Podchodząc do tego inaczej (używając '' jako "quotation"):

W Tcl-u 'a' zawsze znaczy 'a', a nie wartość zmiennej 'a', czy wartość funkcji
(rezultat wywołania) o nazwie 'a', tylko po prostu 'a'. Wartość tekstowa o
jednym znaku (no dobrze, nazwijmy to 'atom').

Może 'a' w danym kontekście oznaczać zmienną (dokładnie to NAZWĘ zmiennej),
ale jeśli już, to jest to nevertheless tekst jak każdy inny. Tak samo, goły
tekst może być gdzieś potraktowany jako nazwa funkcji do wywołania. Nie ma
jednak czegoś takiego, że "normalnie to ten symbol będzie się wartościował,
ale w przypadku użycia takich-a-takich słów kluczowych...". W Tcl-u w
napisanym wyrażeniu symbol nigdy nie jest "wartościowany", jeśli nie
określono, jak ma się to zrobić. Funkcja, owszem, może to sama zrobić na
własną rękę, ale to już jest wtedy specyfika danej funkcji (dodam, że jest to
właściwość raczej rzadko spotykana, co najwyżej praktykuje się przekazywanie
zmiennej przez nazwę).

Byłoby to dla mnie bardziej przemawiające, gdyby w Lispie w KAŻDYM kontekście
atom znaczył atom, a zwartościowanie atomy zawsze znaczyło zwartościowanie
atomu (i ZAWSZE zaznaczało się to przez użycie ' lub jego nieużycie). Jeśli
zatem mamy funkcję 'setq', która ustawia zmienną, to zmienna powinna być
podawana jako "zacytowany atom":

(setq 'a b)

które tak właśnie by przepisało zawartosć 'b' do 'a'. Podobnie defun:

(defun 'gtypist-mode-get-list-of-labels () ... )

A w ogóle to najlepiej by było, gdyby po prostu wartościowanie każdego atomu
odbywało się poprzez jawne tego oznaczenie, a sam atom, jeśli jest częścią
jakiejś listy, był po prostu atomem.


Mam przeciwko składni Lispa znacznie poważniejsze rzeczy, niż taka po prostu
"notacja prefixowa". W końcu w Tcl-u też jest:

set x [string index [lindex $z 2] 10]

gdy np. w C++ brzmiałoby to:

x = z[2][10];


> > W którym Dolphinie, jeśli można wiedzieć?

> Dolphin Smallatalk, o ile dobrze pamietam.

Pytam, bo po pierwsze nie dla wszystkich jest to oczywiste, a po drugie, swoją
wypowiedź sformułowałeś w tak cudaczny sposób, że jedyny wniosek, jaki z tego
mogłem wyciągnąć to taki, że ten Dolphin musi być jakimś strasznym badziewiem.
Pewnie nie to miałeś na myśli, ale niestety tak to sformułowałeś.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Wed, 19 Oct 2005 22:05:25 +0200, Piotr Dembiński skrobie:
> "Michal Przybylek" <mrp@neostrada.pl> writes:

> [...]

> > Wyobraz sobie, ze ja tez mialem cale zycie do czynienia, ze skladnia
> > infiksowa. Wyobraz sobie, ze kiedy pierwszy raz przyszedlem 
> > do Lispu, to tez mnie jego skladnia odrzucila. Wyobraz tez sobie, 
> > ze teraz, uwazam, ze skladnia Lispu jest w wielu zastosowaniach
> > najczytelniejsza skladnia jaka kiedykolwiek powstala.

> Zgadzam się.  Dla mnie na przykład

>   (+ 1 2 3 4 5 6 7) 

> jest bardziej czytelne od 

>   1 + 2 + 3 + 4 + 5 + 6 + 7.

> W końcu to się czyta 'dodaj do siebie ...', a nie 'jeden dodaj dwa ...'.

Pod warunkiem, że nie wygląda to mniej więcej w ten sposób:

(= (+ a (* 2 b (+ g 3)) 1) (rm (+ a 3) (* b 10)))

(dla niezorientowanych: tak wygląda wersja "normalna":

  (a + (2*b * (g+3)) + 1 == rm( a+3, b*10 ))

)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Wed, 19 Oct 2005 21:56:06 +0200, Piotr Dembiński skrobie:
> Ja tam czekam na programy pozwalające zarabiać na udostępnianiu mocy
> obliczeniowej swojego peceta :)

Taa... przede wszystkim to przydałby się program pozwalający samemy zarządzać
i mieć wpływ na to, kto zarabia na tym, że masz włączony komputer.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

[...]

Sektro, naucz Ty sie Lispu, dobrze ?

I chocby poszukaj sobie od czego skrotem jest "setq".

> > Dolphin Smallatalk, o ile dobrze pamietam.
>
> Pytam, bo po pierwsze nie dla wszystkich jest to oczywiste,
> a po drugie, swoją wypowiedź sformułowałeś w tak cudaczny
> sposób, że jedyny wniosek, jaki z tego mogłem wyciągnąć
> to taki, że ten Dolphin musi być jakimś strasznym badziewiem.
> Pewnie nie to miałeś na myśli, ale niestety tak to sformułowałeś.

Dokladnie to mialem na mysli.

Jest to CHOLERNE badziewie. Od samego srodowiska, az po dokumentacje.


mp

Piotr Dembiński napisał(a):
> "Michal Przybylek" <mrp@neostrada.pl> writes:
> 
> [...]
> 
> 
>>Wyobraz sobie, ze ja tez mialem cale zycie do czynienia, ze skladnia
>>infiksowa. Wyobraz sobie, ze kiedy pierwszy raz przyszedlem 
>>do Lispu, to tez mnie jego skladnia odrzucila. Wyobraz tez sobie, 
>>ze teraz, uwazam, ze skladnia Lispu jest w wielu zastosowaniach
>>najczytelniejsza skladnia jaka kiedykolwiek powstala.
> 
> 
> Zgadzam się.  Dla mnie na przykład
> 
>   (+ 1 2 3 4 5 6 7) 
> 
> jest bardziej czytelne od 
> 
>   1 + 2 + 3 + 4 + 5 + 6 + 7.
> 
> W końcu to się czyta 'dodaj do siebie ...', a nie 'jeden dodaj dwa ...'.
> 
A dla mnie i mojego dziecka nie :-) .

A tak bardziej poważnie, czy zamiast myśleć tyle nad składniami języków, 
nie warto zastanowić się nad zawartością bibliotek podstawowych i 
niezależnych producentów?
Wszak lepiej napisać kilka znaków w języku o brzydkiej składni, niż 
kilkanaście tysięcy w języku o składni przepięknej.

Pozdrawiam


-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

On Thu, 20 Oct 2005 10:40:35 +0200, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
>
>[...]
>
>Sektro, naucz Ty sie Lispu, dobrze ?
>
>I chocby poszukaj sobie od czego skrotem jest "setq".
>
>> > Dolphin Smallatalk, o ile dobrze pamietam.
>>
>> Pytam, bo po pierwsze nie dla wszystkich jest to oczywiste,
>> a po drugie, swoją wypowiedź sformułowałeś w tak cudaczny
>> sposób, że jedyny wniosek, jaki z tego mogłem wyciągnąć
>> to taki, że ten Dolphin musi być jakimś strasznym badziewiem.
>> Pewnie nie to miałeś na myśli, ale niestety tak to sformułowałeś.
>
>Dokladnie to mialem na mysli.
>
>Jest to CHOLERNE badziewie. Od samego srodowiska, az po dokumentacje.
>
>

Smalltalk czy Dolphin?...

A.L.

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

[...]

>>   (+ 1 2 3 4 5 6 7) jest bardziej czytelne od   1 + 2 + 3 + 4 + 5 +
>> 6 + 7.
>> W końcu to się czyta 'dodaj do siebie ...', a nie 'jeden dodaj dwa
>> ...'.
>>
> A dla mnie i mojego dziecka nie :-) .

Ale dla nauczyciela matematyki Twojego dziecka pewnie już tak.

Piotr Dembiński napisał(a):
> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:
> 
> [...]
> 
> 
>>>  (+ 1 2 3 4 5 6 7) jest bardziej czytelne od   1 + 2 + 3 + 4 + 5 +
>>>6 + 7.
>>>W końcu to się czyta 'dodaj do siebie ...', a nie 'jeden dodaj dwa
>>>...'.
>>>
>>
>>A dla mnie i mojego dziecka nie :-) .
> 
> 
> Ale dla nauczyciela matematyki Twojego dziecka pewnie już tak.
Problem w tym, że moje dziecko ma 4,5 roku, więc nauczyciel matematyki 
nie istnieje :-).
Czy tutaj nie próbuje się pokazać na siłę, że zapis używający mniejszej 
ilości znaków jest bardziej czytelny?

Jeżeli chodzi o sam temat czytelności kodu, to nie raz są toczone na ten 
temat dyskusje - dla przykładu podam C++/C#
* czy pisać
if(warunek)
{
	wyrażenie
}
czy
if(warunek)
	wyrażenie
* czy używać operatora ?: czy if
* czy używać nawiasów tam, gdzie właściwą kolejność wyznacza już 
"operator precedence"

I wiele tych dyskusji kończy się wnioskami, że minimalizm nie jest 
zawsze najlepszy.

Pamiętając, że nie sztuką jest napisanie systemu a utrzymanie go, to 
widzę, że egzotyczna składnia może być przyczyną zguby - jak "zginie" 
ostatnia osoba rozumiejąca kod, to będzie problem ze znalezieniem następcy.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

[...]

> I wiele tych dyskusji kończy się wnioskami, że minimalizm nie jest
> zawsze najlepszy.

Nie widzę tu minimalizmu.  Prostota -- tak, ale nie minimalizm.

> Pamiętając, że nie sztuką jest napisanie systemu a utrzymanie go, 
> to widzę, że egzotyczna składnia może być przyczyną zguby

Right.  Tyle że to właśnie Lisp ma składnię prostą do bólu, 
w odróżnieniu na przykład od C++.

> - jak "zginie" ostatnia osoba rozumiejąca kod, to będzie problem ze
> znalezieniem następcy.

Hieroglify też odcyfrowano ;)

-- 
http://www.piotr.dembiński.prv.pl

pdemb@gazeta.pl (Piotr Dembiński) writes:

[...]

>> Pamiętając, że nie sztuką jest napisanie systemu a utrzymanie go,
>> to widzę, że egzotyczna składnia może być przyczyną zguby
>
> Right.  Tyle że to właśnie Lisp ma składnię prostą do bólu, 
> w odróżnieniu na przykład od C++.

Acha, osobiście C++ znam lepiej od Lispa.

"A.L." <alewando@kapturek62.com> wrote:

> >Jest to CHOLERNE badziewie. Od samego srodowiska,
> >az po dokumentacje.
> >
> >
> 
> Smalltalk czy Dolphin?...

Dolphin, oczywiscie.


mp

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> wrote:

> Czy tutaj nie próbuje się pokazać na siłę, że zapis używający
> mniejszej ilości znaków jest bardziej czytelny?

Kurde, jeszcze raz powtorze. Skladnia Lispu jest zazwyczaj _rozwleklejsza_
od standardowej skladni, ale za to ma inne unikalne wlasnosci, ktore czynia
ja w _wielu_ zastosowaniach (uwaga, uwaga - nie "we wszystkich" ; w
szczegolnosci nie w zastosowaniach "matematycznych", o czym mowilem pietro
wyzej) czytelniejsza od standardowej.

Kiedy powstawala Ada, ludzie zrobili sobie spis zalozen, wedle ktorych jezyk
bedzie projektowany. Jedno z nich brzmialo jakos tak "programy maja byc
maksymalnie czytelne, godzimy sie na poswiecenie latwosci zapisu kodu na
rzecz jego czytelnosci". Jezeli przejrzysz Ade, to zobaczysz, ze ma ona
wiele konstrukcyjnych ficzerow, ktore powoduja, ze kod jest rozwleklejszy
niz w jej podobnych jezykach.

O Lispie mozesz myslec podobnie.

O perlu mozesz myslec jak o zupelnym odwroceniu tej idei.

Dyskusje o jakich nizej piszesz w Lispach nie przechodza, bo wszystko
zapisuje sie w jeden i ten sam sposob.


"A.L." <alewando@kapturek62.com> wrote:

> Moge pokazac przyklady w Lispie...

Alez prosze. Pokaz mi dowolny rzeczywisty przyklad, ktory jest nieczytelny.


mp

Dnia Thu, 20 Oct 2005 15:46:49 +0200, Piotr Dembiński skrobie:
> > Pamiętając, że nie sztuką jest napisanie systemu a utrzymanie go, 
> > to widzę, że egzotyczna składnia może być przyczyną zguby

> Right.  Tyle że to właśnie Lisp ma składnię prostą do bólu, 
> w odróżnieniu na przykład od C++.

Prostą składnię to ma Tcl. Składnia Lispa nie ma niczego wspólnego z prostotą.

To jedna sprawa. Druga sprawa to to, czy rzeczywiście prostota składni jest
dobra. Okazuje się, że to jeszcze mocno zależy od tego, jaka ta składnia jest,
poza tym, że prosta. Ma być nie tylko prosta, ale i przyjazna. Składnia Tcl-a
taka jest. Lispa nie.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Thu, 20 Oct 2005 16:07:40 +0200, Michal Przybylek skrobie:
> "A.L." <alewando@kapturek62.com> wrote:

> > Moge pokazac przyklady w Lispie...

> Alez prosze. Pokaz mi dowolny rzeczywisty przyklad, ktory jest nieczytelny.

Mam lepszą propozycję - pokaż mi przykład w Lispie, który jest czytelny.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Użytkownik A.L. napisał:

>>Ale skoro - jak pan uwa¿asz - wszystkie jêzyki s± do tego tam, to co pana
>>zdaniem brakuje tym jêzykom, ¿eby by³y lepsze. Albo jakie one mia³yby byæ w
>>ogole, zeby byly dobre.
> 
> 
> Ciagle sie nei rozumiemy: mnie chodzi o to zeby jezykow nie bylo W
> OGOLE...

To _byłby_ postęp. Jednak świat (na razie przynajmniej) woli handlować 
nowymi akronimami, bo to i ryzyko mniejsze, i brzmi fachowo.

Niestety nauki podstawowe nam się przytkały, a pochodną tego jest brak 
postępu u inżynierów. Matematyka bez przełomów, w fizyce ostatnie 
wielkie zmiany były 100 lat temu. Wiem, że wydaje się to odległe, jednak 
nowe idee zawsze płynęły z nauk podstawowych, a konsumowano to dopiero 
po jakimś czasie. Np. na Księżyc można było teoretycznie lecieć za 
czasów Newtona, a technologicznie to dopiero 300 lat później.

M.

Użytkownik Sektor van Skijlen napisał:

> Dnia Wed, 19 Oct 2005 17:17:28 -0500, A.L. skrobie:
> 
>>>Ale skoro - jak pan uwa?asz - wszystkie j?zyki s? do tego tam, to co pana
>>>zdaniem brakuje tym j?zykom, ?eby by?y lepsze. Albo jakie one mia?yby by? w
>>>ogole, zeby byly dobre.
> 
> 
>>Ciagle sie nei rozumiemy: mnie chodzi o to zeby jezykow nie bylo W
>>OGOLE...
[...]
> Pisanie programów w postaci tekstowej było od zawsze. Nieważne, czy ten tekst

A czy do maszyny różnicowej Babbage'a pisało się program tekstem?

Czy wiesz, że są języki, w których liczebniki to jeden, dwa, wiele. I 
tak od zawsze. Co więcej, to wystarcza w codziennym życiu plemiennym.


M.

m <midge@nospam.pl> writes:

[...]

>> Pisanie programów w postaci tekstowej było od zawsze. Nieważne, 
>> czy ten tekst
>
> A czy do maszyny różnicowej Babbage'a pisało się program tekstem?

Kiedyś się dziurkowało :^D

Piotr Dembiński napisał(a):
> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:
[...]
>>- jak "zginie" ostatnia osoba rozumiejąca kod, to będzie problem ze
>>znalezieniem następcy.
> 
> 
> Hieroglify też odcyfrowano ;)
> 
Ale tu nikt nie zastanawiał się na napisaniem ich od nowa bo inny był 
cel :-) .

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Michal Przybylek napisał(a):
> "A.L." <alewando@kapturek62.com> wrote:
> 
> 
>>A jezyki?... Owszem, wykonano kilka zasadniczych krokow.
>>Do tylu.
> 
> 
> Aha, na temat obserwacji krokowych (kiedy to na stwierdzenie dlaczego jakis
> jezyk jest "krok wstecz" za innym jezykiem domagalem sie uzasadnienia):
> 
> - Java jest krok wstecz za C++, bo nie ma wskaznikow,
> - Java jest krok wstecz za C++, bo ma odsmiecanie,
> - Java jest krok w przod przed Smalltalkiem, bo ma lokalne klasy,
> - Smalltalk jest dwa kroki wstecz za Simula, bo ma dynamiczne typy i nie ma
> lokalnych klas.
> 

Pozwolicie ze sie wtrace. Sparafrazuje:

"<wstaw> jest krok wstecz za <wstaw>, bo ma odsmiecanie"

Automatyczne odsmiecanie ma ogromne znaczenie i jest krokiem 
niewatpliwie na przod dla komercyjnie wytwarzanego oprogramowania. 
Nieraz jest potrzeba, aby nie stosowac GC i wtedy sie tego nie robi, ale 
w ogromnej wiekszosc przypadkow to wielkie ulatwienie. Nie zawsze 
programiscie potrzebna jest kontrola nad kazdym aspektem kodu.

Dlaczego uwazasz, ze korzystanie (nie chodzi mi o konkretny jezyk) z GC 
jest krokiem wstecz ? Przyjales jakis konkrenty punkt widzenia, ale nie 
wiem czy nie jest on niszowy i czy mozesz uogolnic go na wiekszosc.

-- 
Piotr Karczmarz
www: http://karczmarz.com/ (w trakcie budowy)

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

> Piotr Dembiński napisał(a):
>> "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:
> [...]
>>>- jak "zginie" ostatnia osoba rozumiejąca kod, to będzie problem 
>>>ze znalezieniem następcy.
>> Hieroglify też odcyfrowano ;)
>>
> Ale tu nikt nie zastanawiał się na napisaniem ich od nowa 
> bo inny był cel :-) .

Oczami wyobraźni widzę, jak za czterdzieści lat grupa
naukowców-historyków odtwarza znaczenie starodawnego skryptu 
CGI napisanego w Perlu 5 ;)

-- 
http://www.piotr.dembiński.prv.pl

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > > Moge pokazac przyklady w Lispie...
>
> > Alez prosze. Pokaz mi dowolny rzeczywisty przyklad,
> > ktory jest nieczytelny.
>
> Mam lepszą propozycję - pokaż mi przykład w Lispie,
> który jest czytelny.

To niw jest lepsza propozycja. Poprosilem o przyklad, bo niepokoje sie, ze
AL moze miec takie samo pojecie o Lispie jak Ty.

Pozatym w swietle tego, ze "w kazdym jezyku mozna napisac dobry program"
pozytywny przyklad czegokolwiek by nie wniosl.


mp

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> >> > - Java jest krok wstecz za C++, bo ma odsmiecanie,
> >>
> >> To żart?
> >
> > Juz pisalem bylem, ze nie.
> >
> > Zreszta nie jest to nawet dziwne - przypomnij sobie tylko jaki byl
> > glowny zarzut wobec Javy u jej zarania.
>
> Nie wiem.  Może to, że jest powolna?

Ze jest powolna, bo jezyk z GC nie moze byc wydajny. Ten poglad utrzymywal
sie powszechnie jeszcze gdzies z trzy lata temu.


mp

"Michal Przybylek" <mrp@neostrada.pl> writes:

[...]

>> > Zreszta nie jest to nawet dziwne - przypomnij sobie tylko jaki
>> > byl glowny zarzut wobec Javy u jej zarania.
>>
>> Nie wiem.  Może to, że jest powolna?
>
> Ze jest powolna, bo jezyk z GC nie moze byc wydajny. 

Na przykład CPython jest całkiem wydajny -- na oko to nawet bardziej
niż Java, przynajmniej w prostych zastosowaniach.

Dnia Wed, 19 Oct 2005 14:32:11 -0500, A.L. napisał(a):

> Tia?... Niejaki Kurzweil w skojej najnowszej ksiazce "Singularity is
> Near" przewiduje ze za 25 lat komputer typu desktop osiagnie moc
> oblizeniowa rowna mocy ludzkiego mozgu. I ten mozg bedziemy
> programowac w rodzaju "if cost_tam then cost_tam else cos_innego"?...
> 
> Cos mi sie wierzyc nie chce...

Wtedy komputery będą programować nas...

-- 
Pozdrawiam
Miroo

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> >> > Zreszta nie jest to nawet dziwne - przypomnij sobie tylko jaki
> >> > byl glowny zarzut wobec Javy u jej zarania.
> >>
> >> Nie wiem.  Może to, że jest powolna?
> >
> > Ze jest powolna, bo jezyk z GC nie moze byc wydajny.
>
> Na przykład CPython jest całkiem wydajny -- na oko to nawet
> bardziej niż Java, przynajmniej w prostych zastosowaniach.

Widze, ze coraz bardziej zaczyna sie rozjezdzac to co ja pisze z tym co inni
czytaja.

Musze wziasc urlop na grupach dyskusyjnych.


mp

Dnia Fri, 21 Oct 2005 14:36:13 +0200, Michal Przybylek skrobie:
> "Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> > >> > - Java jest krok wstecz za C++, bo ma odsmiecanie,
> > >>
> > >> To żart?
> > >
> > > Juz pisalem bylem, ze nie.
> > >
> > > Zreszta nie jest to nawet dziwne - przypomnij sobie tylko jaki byl
> > > glowny zarzut wobec Javy u jej zarania.
> >
> > Nie wiem.  Może to, że jest powolna?

> Ze jest powolna, bo jezyk z GC nie moze byc wydajny. Ten poglad utrzymywal
> sie powszechnie jeszcze gdzies z trzy lata temu.

Sun sobie niestety sam na to zapracował.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

> Ale "filozoficznie" - absolutnie sie nie zgadzam. Jeśli robię jakiś 
> framework z użyciem generics i narzucam, ze jakiś tam typ X można 
> konkretyzować tylko klasami które np. dziedziczą z jakiejś mojej klasy 
> Y, implementują jakiś interfejs.. daje mi to konkretną kontrolę i 
> możliwość w miarę bezpiecznej ewolucji frameworku. Mam pewność, ze jeśli 
> ktoś czegoś tam nie odziedziczy to mu się kod nie skompiluje ( kontrola 
> na zasadzie:  akurat przypadkiem klasa Z ma metodę setValue() którą 
> wywołuje to jak dla mnie nie jest szczęśliwe rozwiązanie)
> 
> W przypadku C++ kilka razy się potknąłem o ten problem, fakt, głownie z 
> powodu przeciążania operatorów. Zaskakująco dużo istotnych typów potrafi 
>   mieć przypadkiem pokryty operator + , -> czy inne takie. Niekoniecznie 
> w sposób zgodny z tym jaki twórca  generycznego kodu w którym się tego 
> użyje przewidywał).

Taaa.
A jaka masz gwarancje ze ten interfejs bedzie poprawnie zaimplementowny??
Dokaladnie taka sama jak w przypadku przeciazania operatorow w C++ dlatego 
wszelkie argumenty przeciwko przeciazniu sa z palca wyssane.

W Pythonie jest overloading w C# tez. Sa to jezyki nowsze niz Java, a C# 
zaprojektowny po doglebnym zbadaniu rynku i zapotrzebowania i jakos ich tworcy 
nie zrezygnowali z tego..dlaczego?? Bo niby po co?? czy rezygnacja z tego daje 
jakies konkretne korzysci?? NIE.

Pewnie zaraz powiesz ze daje bo co bedzie jak jakis idiota zaimplementuje 
operator np.:[] w sposob kompletnie nierozumialy, ale co z tego jesli tan sam 
idiota usiadzie przy Javie i zaimplemntuje Get w sposb jeszcze bardziej 
debilny i nieprzewidywalny??

Osobiscie lubie Jave, ale cholernie mi w niej brakuje operator overloading, 
bylby to 100 razy przyjemniejszy jezyk.

Pamietajmy ze programowanie bylo, jest i bedzie zwiazne z ludzmi, a jesli cos 
jest zwiazne z ludzmi to niestaty, ale takze z tymi glupszymi i nie da sie 
wyeliminowac ich wplywu.

Pozdro. 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Michal Przybylek" <mrp@neostrada.pl> writes:

[...]

> I czy na tyle czesto uzywac, ze trzeba wprowadzac dla tego 
> specjalny mechanizm wspierany bezposrednio w jezyku ?

Na tyle często, że się wprowadza.
TSD to Python też ma przeciążanie operatorów :)