On Wed, 15 Dec 2010 12:35:37 +0100, "R. P."
<r...@w...to.wp.pl> wrote:

>A.L. wrote:
>> On Wed, 15 Dec 2010 01:19:20 +0100, "Grzegorz Niemirowski"
>> <g...@p...onet.pl> wrote:
>>
>>> A.L. <l...@a...com> napisał(a):
>>>> Jak juz uczyc sie staroci, to dlaczego nei Fortran albo Cobol?...
>>> A zrobisz w nich szybko ładne GUI? W Delphi się mimo wszystko da.
>> Nowa fala to "functional programming", a glowni gracze to F# dla .NET
>> i Scala dla JVM. Neidlugo nei bedzie mozna znalezc pracy jak sie tego
>> nie bedzie znalo :)
>
>Functional programming jest zbyt malo intuicyjne, zeby calkowicie
>wyparlo podejscie imperatywne. Co nie znaczy, ze neguje przydatnosc F#
>czy Scali. Absolutnie nie! Ale nie zgodze sie ze stwierdzeniem, ze "nie
>bedzie mozna znalezc pracy jak sie tego nie bedzie znalo".

Odpowiadajac wszyskim ktorzy skomentowali F# i Jave - oczywiscie,
programowanie funkcyjne nie wyprze "konwencjonalnego" programowania,
albowiem nie jest ono "uniwersalnie lepsze". Skonczyly sei czasy gdy
aplikacje byly "jezykowo monolityczne" - teraz do kazdego kawalka
mzona miec inny jezyk ktory najlepiej nadaje sie do okreslonego celu.
A inne paradygmaty niz proceuuralne maja sie dobrze, chociaz nei sa
widoczne dla ludzi zajmujacych sie glownie pisaniem GUI do baz danych.
Nizej podpisany ma kawalek aplikacji napisany w jezyku Prolog,
albowiem napisanie tego w czyms innym byloby w zasadzie niemozliwe.
Pisze "w zasaczie", bo wszystko mozna napisac we wszystkim, jest tylko
sprawa czasu i kosztow. Ow Prolog doskonale wspolpracuje z serwerem w
javie i GUI w C#.

JJEzyji funkcjonalne wydaje sie atrakcyjne ze wzgledu na pojawienei
sei "multicore processors" (nie pisze wielordzeniowych bo "rdzen" jest
zlym tlumaczeniem slowa "core"; w tym konteksie "core" powinno byc
przetlumaczone na "jadro"). Wedle prognoz, za 10 lat pzrecietny
procesor przecietnego peceta bedzie mial 64 jadra. Nei da sie
aplikacji korzystajacej z tych jader napisac w javie - model
wspolbieznosci javt ma 40 lat.

Jezyki funkcyjne automatycznei rozwiazuja jeden z zasadnicych
problemow wspolbieznosci - "data integrity". Caly wysilek przy
programowaniu wspolbieznym idzie w ochrone zmiennych przed dostepem z
wielu watkow. jeden watek mzoe zmeinac wartosc zmiennej gdy drugi
watek chce czytac. W jezykach funkcyjnych anienne sa "immutable" - gdy
podstawi sie jakas wartosc pod zmienna, tel wartosci nie mozna juz
zmienic. Wiwc problem wspolbieznej modyfikacji rozwiewa sie.

Sprawa otwarta pozostaje jak F# i Scala beda wspierac owe problemy.
Scala ma "agenty", F# inne mechanizmy. jak do tej pory kompletnie
rozwiazal to jezyk Erlang, stosowany zresata szeroko w przemysle.
Erlang jest "open", proponuje sie zapoznac.


W kazdym razie - za 20 lat bedziemy programowac inaczej niz dizsiaj.
Jak - nei wiadomo, ale widac trendy. Wiec moze z tym "jak sie nei
bedzie znalo XXX to sie nei znajdzie pracy" to przesada, ale uwazam ze
jak ktos jest w wieku maturalno/studenckim i serio interesuje sie
inzynieria programwoania, powinien wykraczac w przyszlosc, a nei
zadowalac sie terazniejszoscia czy siegac po nazredzia ze smietnika
historii.

Co nei wyklucza interesowania sie historia - sam dla zabawy
implementuje historyczny kompilator Algolu 60 zwany KDF9. W Javie :)

A.L.

P.S. Pzrepraszam za literowki ale pisze na bardzoe malym ekranie i
wlasnei wolaja mnie na meeting i nie ma mczasy poprawiac