Języki skryptowe, interpretatory, Java i C#

Witam.
Chciałbym się dowiedzieć jakie różnice wyczuwacie (widzicie) pomiędzy językami skryptowymi, językami interpretowanymi, i językami hmmm... kompilowanymi "just in time". Nie chodzi mi tutaj o jakieś regułki czy inne tego typu opinie. Chodzi mi o wasze odczucie. Czy nie mozna by ich "zaszufladkować" pod jedną nazwą np. języków interpretowanych ? Jeśli chodzi o mnie to wydaje mi się że języki z tych trzech kategori różnią się jedynie "inteligencją" ich interpretatorów (już widze jak zwolennicy Javy czy C# krzyczą że głupoty mówie - no może). Co wy sądzicie na ten temat ?

Nie no, JIT ma roznego rodzaju cacheowanie i inne tego typu bajery i jest na prawde o wiele szybszy od maszyn wirtualnych, kolejna rzec to taka, ze latwiej (szybciej) zainterpretowac np bytekod Javy (kiedy jeszcze Java smigala na typowym VMie) niz typowy skryptowy jezyk jak PHP. Wiec nie powiedzialbym, ze to to samo.

Moze i to sa "regulki" ale nikt nie napisal jeszcze dwoch identycznych, duzych programow w roznych jezykach wiec ciezko tu mowic o odczuciach, mozna oczywiscie zaimplementowac jakies klasyczne algorytmy ale jednak to nie to samo co normalny, funkcjonalny program okienkowy (tj taki ktorego uzywamy na codzien).

Jakby nie patrzec to te technologie sie troche roznia, wiec po co ta roznice zacierac?

1. Interpretery, nie "interpretatory".
2. Ponieważ ostatnio dużo robię w pythonie, to na jego przykładzie mogę się trochę wypowiedzieć.

W przekonaniu wielu Python to język skryptowy. Zastępuje różne skrypty powłoki systemowej w zadaniach administracyjnych, tak jak Perl.

Inni patrzą na Pythona jak na odpowiednik Javy. W końcu kompiluje się do wykonywalnego bajtkodu i wykorzystywany jest w podobnych zastosowaniach.

Do Pythona jest też moduł zapewniający JIT - psyco. Więc i pod tą kategorię podpada. Co więcej zastosowanie psyco można ograniczyć tylko do wybranych funkcji/metod, podczas gdy pozostała cześć będzie chodzić "normalnie".

Jak więc widać, różnica jest dosyć mglista.

Jeżeli przyjąć, że języki skryptowe to te, które przetwarzają "od razu" kod, czyli nie budują drzewa wywodu a później kodu pośredniego tylko operują od razu po odczytaniu instrukcji to... takich języków próżno by szukać. PHP z tego co wiem również jest analizowany i powstaje język pośredni. On dopiero jest interpretowany. To "prawie" to samo co bajtkod Javy.
Nie jestem, czy nawet języki typu bash są od razu wykonywane, czy jednak jakieś sprawdzanie składni i generowanie kodu pośredniego występuje.

Różnica pomiędzy "zwykłym" interpretowanym a JIT też jak na przykładzie Pythona pokazałem, jest dosyć niejasna, oprócz oczywiście szybkości wykonywania. Zwłaszcza, że często nie ma w ogóle sensu kompilacji niektórych fragmentów kodu. Lepiej mieć mieszankę.

Moim zdaniem takie rozróżnienie jest teraz sztuczne. Zresztą rozróżnienie na język kompilowany a interpretowany jest również sztuczny, choć może bardziej utrwalony przez historię. Bo czy taki BASIC jest językiem interpretowanym, jeżeli istnieje jego kompilator?

dorzuce swoje 3 grosze - PHP jest kompilowany w momencie pierwszego otwarcia danego pliku i poki nie wykryje sie zmiany, poty jest wynik kompilacji uzywany :) natomaist co do kategoryzacji, to to jest tak samo jak z budynkami.. masz budynki jedno, dwu, trzypietrowe.. niekt nie mowi ze jedne sa gorsze, inne lepsze. tak wiec masz 'jezyki' (a raczej hm.. platformy) interpretowane, interpretowane z prekompilacja, kompilowane podwojnie (prekompilacja+JIT), i kompilowane.. tak jak budynki - w konkretnych przypadkach uzywa sie danego typu, bo sie bardziej nadaje, ale w innym przypadku bedzie do bani i trzeba wziac inny

Dryobates napisał(a)

Nie jestem, czy nawet języki typu bash są od razu wykonywane, czy jednak jakieś sprawdzanie składni i generowanie kodu pośredniego występuje.

Chyba nie bardzo. Tzn. sprawdzana jest chyba składnia aktualnie przetwarzanej linii. Mam np. taki skrypt:

echo "Hello World"
/usr/bin/jakis_program_ktory_wykonuje_sie_kilka_minut
rm -rf /

Uruchamiam go, echo przechodzi szybko, drugie polecenie trwa dlugo (jak wskazuje nazwa). W międzyczasie otwieram ten plik i zmieniam ostatnią linię na: ls -lah /. Po kilku minutach kończy się jakis_program... i widzę listing katalogu /, a nie efakty jego "utylizacji". Gdyby najpierw skrypt był w całości przetwarzany i "kompilowany", po wywołaniu tego skryptu jedyne co mógłbym zrobić to poszukać płytki z ostatnim backupem systemu :), tak mi się przynajmniej wydaje.

quetzalcoatl napisał(a)

dorzuce swoje 3 grosze - PHP jest kompilowany w momencie pierwszego otwarcia danego pliku i poki nie wykryje sie zmiany, poty jest wynik kompilacji uzywany :)

ciekawe.. a gdzie zapisuje te pliki ?

Domyślnie w TEMP, a jak brak praw to nigdzie, ale istnieje cała gama narzędzi klasy PHP accelerator ze standardowym APC na czele, które umożliwiają konfigurację ścieżek i ustawień oraz dodatkowe mechanizmy optymalizacji cache'owania. Szczegółów nie znam, nie używam takich dodatków.

Moze ja jestem za glupi na ta dyskusje ale wszelkie stwierdzenia ,ze nie rozroznienia jezykow na interpretowane i wykonywane sa sztuczne troche do mnie nie dociera. Podam dwa skrajne przyklady : pierwszy do assmebler ,drugi bash. oba jezyki laczy chyba jedynie to ,ze mozna zakodowac je w vi. Asembler najpierw trakwowany jest przez kompilator ,ktory sprawdza skladnie i poprawnosc wywolywania argumantow (szczescie ,ze nie preprocesor) ,a wynikowy program moze byc w formacie .com ,ktory jest praktycznie identyczny z obszarem pamieci ,w ktorej zostaje uruchomiony. Bash z kolei nie tworzy nic, co mozna by bylo przyrownac do kodu maszynowego. jest przenosny ale wolniejszy (sparc,x86,ia64 itp.) mozna uruchamiac programy systemowe ,tak jakbysmy wpisywali do konsoli polecenia. Roznica nie jest historyczna ,a jest najlogiczniejszym podzialem jaki mozna wymyslic. Po prostu (z mojego punktu widzenia: kompilowane kody zrodlowe daja rozkazy zakodowane maszynowo ,a interpretowane sa w biegu ,co doprowadza do sytuacji ,gdzie mozemy zmieniac program ,w trakcie jego dzialania) oczywiscie jezyki typu java ,czy python zacieraja troche granice miedzy przykladami ,ktore ja podalem ale czy np.
wprowadzenie minivanow oznacza ,ze nie mozemy dzielic samochodow na osobowe i ciezarowe?
Moze gadam glupoty ale mnie ubodlo ,ze coraz wiecejprogramistow zajmuje sie narzedziami najnowszymi i nie pamieta jak sie uzywalo asemblera i c++ na skrzyz. Pozdrawiam

hmpf tylko ze jezyk kompilowany(taki jak np. C) po skompilowaniu do binarki zawiera rozkazy wykonywane od razu przez procesor, natomiast interpretowany jest tlumaczony do bajtokodu*, ktory nastepnie jest wykonywany przez interpreter, ktory nastepnie zmusza do pracy procesor tak a tak, przy czym bajtokod nie jest jeszcze w pelni zrozumialy dla procesora.

*bledy celowe

duce74gosc napisał(a)

kompilowane kody zrodlowe daja rozkazy zakodowane maszynowo ,a interpretowane sa w biegu ,co doprowadza do sytuacji ,gdzie mozemy zmieniac program ,w trakcie jego dzialania)

Assembler też jest interpretowany 'w biegu' przez procesor i również możemy zmieniać program w trakcie jego działania ;]
Trochę zły przykład dałeś.

To prawda, szczerze mowiac pozno bylo i nie przemyslalem do konca co pisze. Ale rozumiecie moj tok myslenia. Assembler-a nie wiem ,czy zmienisz w trakcie dzialania programu , bo caly program (biorac pod uwage rozmiary progsow w assemblerze ,bedzie to caly program) jest ladowany do pamieci w trakcie uruchomienia. jak chcesz cos zmienic to musisz miec access do komorek pamieci ,ktore sa aktualnie uzywane przez inny program ,a szczerze mowiac nie wiem (spalem troche na bezpieczenstwie systemow operacyjnych) czy system (winda ,czy linux) zgodzi sie (moduly obslugi pamieci) na to ,zebys manipulowal w rozkazach jednego programu z poziomu innego programu. Tak czy siak chodzilo mi o to, ze mozesz np w bashu napisac program na 100 linijek ,i jak sie wykonuje 12 linijka to zmieniasz 24 ,zapisujesz plik i program bedzie pracowal po zmianie, bo interperer nie spawdzi ,czy jakies zmiany zostaly przeprowadzone. Troche odbiegam od tematu wiec juz nie bede :P</wiki>

Słyszałeś o SMC? Kod /jeżeli strona pamięci, na której się znajduje ma prawo do zapisu/ może być dowolnie modyfikowany, przykład pod windę, format fasm-a:

Format PE GUI 4.0
entry start

section '.deus' code data readable writeable executable

start:
         xor      eax, eax
         mov      word [$+9], 0x9090         ; zamiana nastepnej instrukcji na nopy
_ud2:
         ud2                                 ; wywolanie wyjatku undefined opcode - wysypanie programu
         push     eax
         push     eax
         push     _info
         push     eax
         call     [MessageBox]
         retn

_info    db 'SMC dziala!', 0
user32   db 'user32.dll', 0
_MessageBox dw 0
         db 'MessageBoxA', 0

         align    0x20
         data     import
         dd       0, 0, 0, rva user32, rva MessageBox
         rd       5
         end      data
MessageBox        dd rva _MessageBox, 0

I co? Program powinien sypnąć wyjątkiem ale nadpisuje 'nieprzyjemną' instrukcję nop'ami - jednobajtowymi instrukcjami nie robiacymi nic. Zamiast się wysypać wyświetla info.
Modyfikacja kodu w pamięci to podstawa we wszelakich hookerach, loaderach, protectorach... ba, same systemy oepracyjne też są do tego przystosowane - wide align dla hotfix'ów w native api xp\2k3. Myślisz, że jak bardziej zaawansowane boty do gier działają?

duce74 napisał(a)

Assembler-a nie wiem ,czy zmienisz w trakcie dzialania programu , bo caly program (biorac pod uwage rozmiary progsow w assemblerze ,bedzie to caly program) jest ladowany do pamieci w trakcie uruchomienia. jak chcesz cos zmienic to musisz miec access do komorek pamieci ,ktore sa aktualnie uzywane przez inny program ,a szczerze mowiac nie wiem (spalem troche na bezpieczenstwie systemow operacyjnych) czy system (winda ,czy linux) zgodzi sie (moduly obslugi pamieci) na to ,zebys manipulowal w rozkazach jednego programu z poziomu innego programu.
Faktycznie spałeś - co robią debuggery? Aby działaś debugger musi być w stanie modyfikować w runtime kod śledzonego programu. Hm... a debugger to zwykły program, nie? :-)

duce74 napisał(a)

Moze gadam glupoty ale mnie ubodlo ,ze coraz wiecejprogramistow zajmuje sie narzedziami najnowszymi i nie pamieta jak sie uzywalo asemblera i c++ na skrzyz.

mnie niesamowicie bodzie, ze cala masa najnowszych informatykow i programistow w ogole nie slyszala slowa assembler, a C/C++ uwazaja za nieuzywany przez nikogo przezytek..

a w temacie:
w ogole to malo zauwaza, ze jezyk to jedno, a srodowisko wykonawcze - to drugie.. co to w ogole za gadka ze "jezyk jest interpretowany" "jezyk jest kompilowany".. przeciez to zalezy jak srodowisko wykonawcze sie napisze. kto mi zabroni napisac interpreter C++ ktory bedzie wszystko liniapolinii wykoywac, albo kompilator BASH do kodu maszynowego (pomijam trudnosci w dynamizmie kodu, ale by sie dalo)?

a nie czepiajac sie tego:
roznica miedzy jezykami interpretowanymi a kompilowanymi jest prosta: interpretowane sa wykonywane na biezaco, z "tekstem" jako zrodlem. polecenie-po-poleceniu. jezyki kompilowane - to sa jezyki w ktorych tekst jest przetwarzany wstepnie na prostszy zapis (->nizszego poziomu! np. C++ -> asm). jezyki maszynowe - to sa te ktorych "slowa" kodu wiernie odpowiadaja wynikowemu kodowi

asm - mozna uwazac za maszynowy. choc tak na prawde jezyk maszynowy jest jeszcze ponizej asm. formalnie, asm jest kompilowany

c/c++ - kompilowany. ciekawostka: widzialem kiedys maszyne wirtualna C/C++, w takim wypadku patrz java/php

skrypty bash'a - to jest jezyk prawdziwie interpretowany. i pewnie taki pozostanie

Java, VB, PHP itp - kiedys byly interpretowane, ale teraz to sa hybrydy. Teraz sa kompilowane w locie lub wstepnie, wiec formalnie, sa to jezyki kompilowane. Tworzony jest przy tym kod posredni, ktory ... tez jest jezykiem. W kodzie posrednim tez mozna cos napisac "z palca" (acz nie polecam). W php, kod posredni jest interpretowany. W javie - interpretowany (JVM) albo (JIT) kompilowany w locie na kod procesora. W VB - o ile dobrze pamietam to caly .NET (vb,mc++,c#,f#,j#..) zachowuje sie jak "java w trybie allways-JIT", czyli zaraz po odpaleniu kod posredni jes tlumaczony na kod procesora. czyli: struktura warstwowa. kompilacja-interpretacja, albo kompilacja-kompilacja

ktos wspomnial o procesorze interpretujacym kod maszynowy.. oczywiscie. w procesorach np. RISC sa czesto mikroparsery tlumaczace np. kody x86 na risc.. ale bez przesady. abstrakcja o jezykach ucina sie na tym co zostanie wyslane do procka :)

moje odczucia są takie że języki interpretowane, skryptowe są z reguły bardziej prymitywne i dlatego się ich nie kompiluje. uważam że Java jest kompilowana, nawet jeśli to jest bytecode to co z tego? kompilowana na VM czy na inną maszyne? Ostatnio pisałem interpreter... jest zdecydowana różnica między translacją do czegoś, a uruchomieniem danego kodu... tyle moich osobistych odczuć.

gaborek napisał(a)

moje odczucia są takie że języki interpretowane, skryptowe są z reguły bardziej prymitywne i dlatego się ich nie kompiluje.

:-D :-D [rotfl]

mnie niesamowicie bodzie, ze cala masa najnowszych informatykow i programistow w ogole nie slyszala slowa assembler, a C/C++ uwazaja za nieuzywany przez nikogo przezytek..

A dlaczego cię tak to bodzie? Pewnie tak ze 30 lat temu, ludzie oburzali się, że nowe pokolonie nie pisało w kodzie 0-1, tylko jakichś assemblerów używa. A języki wyższego rzędu to jakiś syf dla laików ;)

mnie niesamowicie bodzie, ze cala masa najnowszych informatykow i programistow w ogole nie slyszala slowa assembler, a C/C++ uwazaja za nieuzywany przez nikogo przezytek..

Lol, w jakim sensie prymitywne?
Prymitywne, że mało skomplikowane? To może poczytaj trochę o Lispie i oceń czy jest prymitywny.
Prymitywne, że łatwiej zaimplementować? Tak się skłąda, że ja też pisałem swój język skryptowy. W kompilowanych językach (nieważne czy do bytecodu czy do assemblera) dużo prościej jest przeprowadzić optymalizację i ogółem nie trzeba zwracać wielkiej uwagi na szybkość działania samego kompilatora.

entersandman napisał(a)

mnie niesamowicie bodzie, ze cala masa najnowszych informatykow i programistow w ogole nie slyszala slowa assembler, a C/C++ uwazaja za nieuzywany przez nikogo przezytek..

A dlaczego cię tak to bodzie? Pewnie tak ze 30 lat temu, ludzie oburzali się, że nowe pokolonie nie pisało w kodzie 0-1, tylko jakichś assemblerów używa. A języki wyższego rzędu to jakiś syf dla laików ;)

Przeciez nie powiedzial, ze jezyki wyzszego rzedu to syf ;) Nie nadinterpretuj. Mnie tez to bodzie. Glownie dlatego, ze swiadomosc istnienia asemblera i jako takie pojecie czym sie to je oznacza, ze mamy jako takie pojecie jak to w srodku dziala. Komputer juz nie jest czarna skrzynka, ktora przyjmuje klikniecia w IDE i wypluwa sliczny, gotowy, blyszczacy program z dumna plakietka v1.0 made by Mastah.

A c++ jest i bedzie jezykiem, ktory poczatkujacemu programiscie otwiera oczy na to czym miedzy innymi jest prawdziwe programowanie. Mozna na nim obrazowac paradygmat strukturalny, obiektowy, funkcyjny (a czemu nie), itp. Nie uzywajac przy okazji skladni rodem z Pascala (nie obrazajac jezyka), pt. 'uwaga bede teraz deklarowal zmienna o nazwie mojaZmienna'.

Dla mnie c++ jest w sam raz, bo nie jest jezykiem akademickim, jak wyzej Pascal. Do tego mozna w nim pisac naprawde wiele (jesli nie wszystko) i pokazuje jak skomplikowane moze byc pisanie kodu samo w sobie. To taka dobra przestroga dla tych, co nie sa do konca przekonani czy chca spedzac godziny szukajac srednika ;)

entersandman napisał(a)

A dlaczego cię tak to bodzie? Pewnie tak ze 30 lat temu, ludzie oburzali się, że nowe pokolonie nie pisało w kodzie 0-1, tylko jakichś assemblerów używa. A języki wyższego rzędu to jakiś syf dla laików ;)

nie. boda mnie programisci/informatycy/doktorzy itp, ktorzy uwazaja ze pozjadali wszystkie rozumy i pchaja na slepo wszedzie "najnowsze osiagniecia technik informatycznych", a w gruncie rzeczy nie znaja/pozapominali cala mase "starych, przestarzalych" rzeczy, ktore sie swietnie sprawdzaja, maja mniejsze wymagania, dzialaja szybciej, itp tylko wymagaja .. wiekszej wiedzy. IMHO, szczytem tego o czym mowie jest Vista, ktora praktycznie jest starym dobrym XP tylko ze z nowym UI (zreszta, to nowe UI to tylko jest 'na wierzchu'). Porownaj wymagania sprzetowe Visty i XP, oraz co tak a prawde Vista wprowadza nowego. n-o-w-e-g-o! czegos takiego czego jeszcze nie widziales nigdy we grze, programie graficznym, jakies distro linuksa dla fanatykow czegostam, itp. zdziwie sie jesli znajdziesz. a przeciez te wszystkie rzeczy maja wymagania czesto 3 krotnie mniejsze, jak tego dokonaly? A ze 30 lat temu to akurat bylo wrecz przeciwnie

sie wkurzylem i troche nie na temat napisalem.. Johny w miedzy czasie widac tez posta pisal i ujal duzo lepiej to co mialem na mysli :)

Przeciez nie powiedzial, ze jezyki wyzszego rzedu to syf

Heh, ja tylko sobie wyobrażam co się działa xx lat temu, gdy języki wyższego rzędu dopiero wchodziły ;)

Do tego mozna w nim pisac naprawde wiele (jesli nie wszystko) i pokazuje jak skomplikowane moze byc pisanie kodu samo w sobie. To taka dobra przestroga dla tych, co nie sa do konca przekonani czy chca spedzac godziny szukajac srednika

Szczerze mówiąc ja nie mam ochoty spędzać paru godzin na szukanie średnika, ani nieaktualnego wskaźnika. Dlatego po mału przerzucam się na Javę, która pozwola mi się skupić na trochę poważniejszych sprawach niż głupie błędy. Moim zdaniem języki przyszłości pozwolą zapisywać programy w sposób matematyczny, bez wnikania w szczegóły sprzętu. Ale to jest oczywiście tylko moje zdanie ;)

paradygmat... funkcyjny (a czemu nie)
A tu mnie zaciekawiłeś. Mógłbyś podać jakiś przykład/link?

MHO, szczytem tego o czym mowie jest Vista, ktora praktycznie jest starym dobrym XP tylko ze z nowym UI (zreszta, to nowe UI to tylko jest 'na wierzchu'). Porownaj wymagania sprzetowe Visty i XP, oraz co tak a prawde Vista wprowadza nowego. n-o-w-e-g-o! czegos takiego czego jeszcze nie widziales nigdy we grze, programie graficznym, jakies distro linuksa dla fanatykow czegostam, itp. zdziwie sie jesli znajdziesz. a przeciez te wszystkie rzeczy maja wymagania czesto 3 krotnie mniejsze, jak tego dokonaly? A ze 30 lat temu to akurat bylo wrecz przeciwnie

Być może sama Vista nie wprowadza pozornie niczego nowego. Jest tylko jedno ale - być może została napisana przy użyciu technik, które dużo bardziej ułatwią konserwację kodu, które ułatwią wprowadzanie poprawek i dzięki której programowanie staje się sztuką a nie żmudnym zajęciem :). Podobnie było z Uniksem, który początkowo był pisany w assemblerze. Ogromnym krokiem na przód, było przepisanie go na C. Pomimo tego, że stał się wolniejszy uzyskał przenośność a i utrzymanie było dużo prostsze.

To szukanie srednika jest przyslowiowe. Jezeli potrafisz go tyle szukac (masz tyle zaparcia) i masz wiedze na temat dzialania komputera (takiego prawdziwego dzialania), algorytmow, struktur danych, itp - bedziesz umial napisac od razu sensowny algorytm, ktory np. korzysta z List.Sort(). ALE WIEDZAC czym jest lista i dlaczego z niej akurat korzystasz i jakie sortowanie w niej jest wykorzystywane w tym wypadku i dlaczego akurat takie dla Ciebie jest najlepsze.

Antyprzyklad w ktoryms z ostatnich watkow na forum - jak posortowac elementy w stosie... To jest wlasnie niezrozumienie idei (bez przytyku dla autora - nie twierdzil, ze to jedyne sluszne rozwiazanie).

entersandman napisał(a)

johny_bravo napisał(a)

paradygmat... funkcyjny (a czemu nie)

A tu mnie zaciekawiłeś. Mógłbyś podać jakiś przykład/link?

Bossem programowania funkcyjnego nie jestem, ledwie co znam idee. Ale co stoi na przeszkodzie pisac funkcje w c++, uzywac rekurencji zamiast petli, zwracac wynik przez return + np. skrocony if (unikamy tymczasowych zmiennych). Fakt, nie jest to jezyk stworzony do tego paradygmatu, ale dla zobrazowania mozna taki kod napisac - na przyklad ludziom na pierwszym/drugim roku studiow, ktorzy juz c++ znaja, zeby pokazac o co mniej wiecej chodzi w podejsciu funkcyjnym. Nie skupiaja sie wtedy na skladni (jak w przypadku, gdy na szybko tlumaczyc skladnie powiedzmy Haskella), a na pytaniach 'po co?' i 'dlaczego tak?'

po prostu języki skryptowe czy interpretowane kojarzą mi się z Bash'em, HTML'em, Prologiem, (Lisp ma już prawie 50 lat więc prymitywny jest w dosłownym tego słowa znaczaniu - epoka kamienia łupanego :D )... mówie o swoich uczuciach więc prosze się nie śmiać :P

Pisałem w języku w którym nie ma zmiennych i instrukcji przypisania... powiem tak - jeżeli coś się skompiluje to zazwyczaj działa poprawnie i tak jak tego chciałem jest to olbrzymi plus.

Nie wyobrażam sobie funkcjonalnego C++ :D

Czy nie zchodzimy znowu na temat: wojna poziomów języków programowania?

IMHO, juz dawno na nim jestesmy;)

Eeee, tam. Jak kto woli, to niech pisze i na najnizszym poziomie, jak mu to ulatwia zycie/sprawia fajde, itp. I tak samo po drugiej stronie - jak ktos chce klikac w Delphi - jego sprawa. Ale nie zapominajmy do czego poszczegolne elementy zostaly wymyslone i nie wysylajmy w niebyt takiego np. c++ tylko dlatego, ze jest java, czy c#...

Mi szczerze mowiac zupelnie obojetne czy jezyk jest interpretowany, kompilowany, czy tez czyta i wykonuje go pan Zdzisiu, pod warunkiem, ze takie rozwiazanie spelnia dokladnie wszystkie moje wymagania. Jezeli klient ma dostep tylko do serwera z php, to nie bede go na sile przekonywal, ze ja wole ASP.NET. Jak szybciej napisze maly skrypcik w bashu niz w c++, to uzyje basha - mimo, ze jest interpretowany i w ogole 'be' ;)

gaborek napisał(a)

(Lisp ma już prawie 50 lat więc prymitywny jest w dosłownym tego słowa znaczaniu - epoka kamienia łupanego :D )

:) A jednak jako język ma większe możliwości od wielu, ba, zdecydowanej większości języków wcześniej wymienionych.

Po zobaczeniu możliwości programowania funkcyjnego w Common Lispie doszedłem do wniosku, że inne języki mają tylko jego namiastkę. Nawet obiektówa w CL wymiata - jedna z najlepszych dostępnych.

gaborek napisał(a)

po prostu języki skryptowe czy interpretowane kojarzą mi się z Bash'em, HTML'em, Prologiem, (Lisp ma już prawie 50 lat więc prymitywny jest w dosłownym tego słowa znaczaniu - epoka kamienia łupanego :D )... mówie o swoich uczuciach więc prosze się nie śmiać :P

Nie wyobrażam sobie funkcjonalnego C++ :D

Bo to byłoby rzeczywiście dość dziwne.
A Lisp prymitywny... jesteś może studentem i uczysz się Scheme? Scheme brakuje dużo rzeczy (chociaż prymitywnym bym go nie nazwał - szczególnie w porównaniu z C++ z jego wskaźnikami!) jak np. hash tablice, pętle, OO/MOP - ale Common Lisp to wszystko posiada.

Implementacja podstawowej rzeczy jaką jest np. generator w lispie zajmuje dwie linijki - a w c++ musiałbyś tworzyć klasę z akcesorem... conajmniej 10x więcej pisania, gorsza czytelność i mniejsze możliwości.

A same pętle? while() i for() vs loop... :D

A prolog... język programowania logicznego. Nie nadaje się do 'normalnych' programów? Być może.
Nie zmienia to jednak faktu, że jest na dużo wyższym poziomie niż c++...

ale to ciekawe że ludzie dopiero teraz się zachwycają czymś co wymyślono 50 lat temu, nie? A niektórymi rzeczami dopiero będą się zachwycać. Przecież w Javie generalnie nie ma nowych ideii, a jaką podniete budzi?:D Za 5 lat będzie się o programowaniu obiektowym mówić tak jak teraz o imperatywnym i w modzie będzie funkcjonalne... Pewnie jeszcze bardzo długo będzie potrzebne C/C++ ale to nie zmienia faktów ;-)

5 lat to za dużo? Erricson zrobił Erlanga, możliwości ma zarąbiste...przesadziłem że obiektowe będzie tak zponiewierane, ale funkcjonalne( a może funkcyjne? ) zaczyna być praktyczne i przydatne.

nie pisałem w Lispie, natomiast Haskell mi się podoba - troche nowsze narzędzie.

gaborek napisał(a)

ale to ciekawe że ludzie dopiero teraz się zachwycają czymś co wymyślono 50 lat temu, nie? A niektórymi rzeczami dopiero będą się zachwycać . Przecież w Javie generalnie nie ma nowych ideii, a jaką podniete budzi?:D Za 5 lat będzie się o programowaniu obiektowym mówić tak jak teraz o imperatywnym i w modzie będzie funkcjonalne...

Hm... raczej 'znowu'. W latach 60-80 lisp był chyba najpopularniejszym językiem, firmy kupowały straszliwie drogie komputery żeby lisp dobrze działał (stąd ten mit, że lisp jest wolny...).

Za 5 lat? Bo ja wiem - imho trochę za krótko, chociaż kto wie...
Największą szansę ma chyba F# - ruby on rails powoli osiąga szczyt swojej popularności (to tylko moje zdanie), a python jest funkcyjny tylko teoretycznie.

Ale kiedyś - na pewno :)

(przydałby się nowy standard lispa, z lepiej ujednoliconym OO...)