Programozási nyelv

Fórumok

Sziasztok!

Melyik programozási nyelvet érdemesebb inkább megtanulni?
A Rubyt vagy a perlt? Vagy valami mást?

Szívesen fogadok véleményeket :)

Jelenleg ismerem a következőket: HTML, PHP, MySQL, kicsi Bash

tmms

Hozzászólások

Én a Rubyt a sokoldalúsága miatt választottam anno, GUI-n/Weben/scriptelésben is erős, szeretem. Előtte C/perl/php/bash/awk ment, de egyik se volt elég sokoldalú. Ezt a Pythonról is el lehet mondani, bár weben a Railsnek nincs párja. ;)

Egyetlen hátránya a gyenge memóriakezelése, mind GUI-n, mind Weben zabálja a ramot.

Én asztali alkalmazásokat C/C++-ban, webes alkalmazásokat Java-ban, és PHP-ben szoktam írni. :)
Egyébként magam részéről a Ruby-t ajánlanám a kettő közül. Perl-t főleg akkor, ha sok szöveges adatot kell feldolgoznod.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Attól függ, mit szeretnél csinálni. Például szövegfeldolgozásra a Python is találó választás.
Repertoár: C, C++, C#, Java, Javascript, PERL, PHP, Python, Ruby, TCL.
Aztán persze előbb-utóbb a HTML leíró nyelv ismerete és SQL ismerete sem árt.

Mindegyiknek megvan, mely munkákhoz praktikus. Persze ettől a többire is jó.

+1

És szerintem a C azért is fontos, mert "nevelő hatású", ugyanis elég hardver-közeli, így jobban meg lehet érteni, mitől is lassú vagy gyors egy adott algoritmus futása egy gépen.

Szerintem szép dolog az a fejlett nyelvekben, hogy van bennük alapból összetett adatstruktúrák, pl. asszociatív tömb, halmaz, mindenféle listák meg egyéb nyalánkságok, de ezekben egy 20 karakteres utasítássorozat a háttérben egy igen összetett folyamatot indíthat el. Így egy elegánsan kifejezett kód mondjuk Pythonban rém lassú futású lehet, és ha valaki nem tud a háttérről, nagyon nem hatékony programot fog írni.

A C elég közel áll a processzorok utasításkészletéhez, ami egyrészt nehezítés, másrészt viszont lehetővé teszi a hatékony végeredmény elérését. Akkor is, ha ténylegesen Pythonban programozol, csak a fejedben van a C tapasztalata.

Mindamellett a C nem assembly, tehát áttekinthető, hordozható kódot lehet benne írni.

Szumma-szummárum: tanulj meg C-ben is, megéri.

Ez nem meglepő. A C++ normális használatához először is kurvajól meg kell tanulni a C-t. Ez a rész nem kihagyható. Aztán kurvasokat kell ismerkedni a C++-szal. Nem lehet "kicsit" megtanulni a C++... Vagy beletolod azt az 1-2-3 év intenzív ismerkedést, ami ehhez kell, vagy csak a nyelvi elemeket fogod ismerni, de hatékonyan és korrektül használni nem.

Milyen indoklást szeretnél?

Ha nem tudod megmondani, hogy a leírt kód mit fog csinálni, hogyan is működik belül, akkor nem tudsz C++-ban programozni. Mivel a nyelv működése kibaszottul bonyolult ÉS nagyon sok egyszerű konstrukció sem azt csinálja, mint amit a nyeretlen kétéves programozó várna, ezért annak az esélye, hogy valamit körülbelülre tudsz, hogy mit fog csinálni, az nem elég.

A valóság és a körülbelüli közötti különbség pont annyi, mint a működő program, és az időnként leakelő, crashelő program között.

Az a nyelv, amin te csak magas szinten programozol, a háttérben a dolgokat meg oldja meg a rendszer, te azzal nem szeretnél törődni, nos az a nyelv nem a C++! Vannak ilyen nyelvek is bőven.

Szóval indoklásként: az a C++ tudás, amihez képest rossz szokásokat lehet kialakítani a C tudásával, az fabatkát nem ér, az nem C++ tudás.

Nézd, olyan dolgokra gondolok, hogy castolások. C-ben megszokod a (típus) formát, és máris van egy rossz szokásod. char* agyonhasználata. const-mentesség. Meg még számtalan egyéb. Szerintem te valami egészen másról beszélsz, mint én, nem tudom miről, de szerintem az, hogy valaki nem keni-vágja a C++ objektummodellt teljes mélységében, és a rengeteg ortogonális szabály között néha eltéved ha elég mélyre megyünk még nem jelenti, hogy ne tudna jó programot írni, sőt. A C++ igenis magas szintű programozást IS támogat. Ha te csak azt látod, hogy a C++ egy kiegészítése a C-nek, akkor a felét se érted a nyelvnek.
----
Hülye pelikán

Ugyanarról beszélünk.

Az, aki "megszokta" a castolósdit C-ben, meg jön a "char * agyonhasználata", az nem gondolkodik, ergó nem tudja használni a nyelvet. Tehát nem tanulta meg a C++-t, hiába tud C-ben bármit is - mellesleg aki a fenti dolgokat úgy csinálja C-ben, hogy nem érti pontosan, mikor mi történik, az C-ben sem tud igazán programozni.

az, hogy valaki nem keni-vágja a C++ objektummodellt teljes mélységében, és a rengeteg ortogonális szabály között néha eltéved ha elég mélyre megyünk még nem jelenti, hogy ne tudna jó programot írni

Az a gond, hogy C++-ban nincs olyan, hogy egy-két dolgot nem ismerek, hát jó, majd azokat a dolgokat nem használom, és hát attól még jó programokat írok úgyis.
A C++ nyelvi extráit kb. egyben tudod elkerülni, de ezt már írtam lentebb is. Exception és template-ek nélkül nincs STL, az exception kezelés és a memóriamenedzsment pedig olyan szintű láp, amiben nagyon hamar elmerülsz, ha "magas" szinten óhajtasz csak programozni.

A C++ igenis magas szintű programozást IS támogat.

Persze. De abban a pillanatban, amint elfelejted végiggondolni, hogy mi történik a háttérben, csúnyán rá fogsz faragni.

Arról volt szó, hogy rossz szokások. Mivel a C++ nem tiltja a C legnagyobb részét, ezért simán átkerül ha valaki nem figyel oda. Te azt mondod, hogy a C tudás nélkül a C++ mit sem ér, én meg azt, hogy minek tanuljunk C-t, amikor a C++-ban nagyrészt benne van. Ha a C++-t tudod, akkor a C-t is tudod. Körkörös az érvelésed, vedd észre.
Először abból indulsz ki, hogy C++-t nem lehet C előképzettség nélkül normálisan tanulni, utólag pedig abból, hogy ha a C++-t megtanultad, akkor a C-s dolgokkal is tisztában vagy, ami igaz, de nem volt rá szükség a C tanulására.

A C++ sokkal kezdőbarátabb nyelv, mint a C. Simán lehet templateket használni anélkül, hogy fogalmad lenne róla, mik azok. Legjobb példa az iostream. Mindenki tudja, hogy kell kiírni a cout-tal, pedig esetleg azt sem tudja, hogy ott egy operátortúlterhelés van, nemhogy az egy template egy példányának egy példánya. Érted. Magas szintről is lehet nézni, és lehet hatékonyan programozni. Minél kevésbé kell lemenni, annál jobb, annál absztraktabb, annál újrafelhasználhatóbb, és annál tisztább lesz a kód. Vectort bárki tud használni, ha mindig újra kéne írni new-delete párossal magadnak, az már nem lenne szép.
Ugyanígy a memóriamenedzsment. Sok GC implementáció van. Ha valaki olyan céghez megy, ahol ilyet használnak, és betartja a szabályokat, akkor nem kell menedzselnie a memóriát. De ha kell is, nem egy túl bonyolult dolog alapszinten. Amúgy is használjon mindenki RAII-t. Viszont a C-s rossz szokások megint tévútra vihetnek itt, és azt is new-delete-el oldja meg, amit nem kéne.

>De abban a pillanatban, amint elfelejted végiggondolni, hogy mi történik a háttérben, csúnyán rá fogsz faragni.

Vagy nem. Ha okos vagy, és szép kódot írsz, nem fogsz beleesni ilyenekbe. Ez elég nagy különbség a C és a C++ között amúgy, C++-ban LEHET ilyan kódot írni.
----
Hülye pelikán

> >De abban a pillanatban, amint elfelejted végiggondolni, hogy mi történik a háttérben, csúnyán rá fogsz faragni.

> Vagy nem. Ha okos vagy, és szép kódot írsz, nem fogsz beleesni ilyenekbe. Ez elég nagy különbség a C és a C++ között amúgy, C++-ban LEHET ilyan kódot írni.

C-ben is, es hogy egy hasonlattal eljek: ha labonlovod magad, C-ben, azonnal kiderul, mig C++-ban konnyen lehet hogy kismillio reteg fajdalomcsillapito alatt is alig erzed meg, hogy itt bizony baj van.

--
|8]

A template csúnya mint szintaxis. A kézi memóriakezelés pedig "error prone". Így értem a csúnyát, nem esztétikailag, hanem hogy mennyire elegáns. A template nagyon elegáns megoldás lehet sok problémára, még ha ronda is, de ennek is egy jó részét el lehet fedni a felhasználó elől, lásd stl.
----
Hülye pelikán

Nézd, minden lehetséges. Minden. De itt nem arról van szó, hogy valami lehetséges-e vagy sem, hanem hogy mennyire támogatja a nyelv. C-ben nem jellemző ez, hiszen ha már olyan kódot ír az ember, akkor van számtalan alkalmasabb nyelv.
Arról volt szó, hogy a template ad egy absztrakciós szintet, amit a memóriakezelés nem.
----
Hülye pelikán

Nem errol volt szo. Lasd itt, meg itt.

Elso allitasom az, hogy a templatek rondak, es semmivel sem kevesebb a hibalehetoseg a hasznalatukkal, mint a C-s kezi memoriakezeles eseten (sot..).

A masodik allitasom az, hogy C-ben is el lehet kerulni a kozvetlen kezi memoriakezelest, ha epp az az ember ingerenciaja, es nem is olyan nagyon nehez. Nyilvan van olyan nyelv ami alkalmasabb a memoriakezeles elkerulesere, de attol nem lesz az adott nyelv alkalmasabb a konkret feladatra.

--
|8]

A hibalehetőségek... a templateben az a szép, hogy nem kell látnod, hogy mi template vagy mi nem, és úgy is működik. Ha meg használod, és okosan, akkor segít magasabb szintre vinni a programot. Ez nem mondható el a memóriakezelésről. Azt mindig jobb elrejteni, ha lehet.

Egyelőre nem látom, hogy destruktorok nélkül hogy lehetséges elkerülni a memóriakezelést (az, hogy nem te hívod a free()-t hanem azt mondod, hogy dont_need_this_pointer_anymore() nem számít a memóriakezelés elkerülésének).
----
Hülye pelikán

Ismerni kell az adott nyelv "képességeit" és a gondolkodásmódját meg kell megtanulni.

Asztali alkalmazásfejlesztésre kezdésnek javát vagy c#-ot javasolnék.

Írtam nem egy kódolási szabványt, normális szerkesztővel és programozóval nincs gond a betartásával. A lyukkártya miatt kényszerű folytatólagos sor (hint: Fortran) baromi rég kiment a divatból...

Ha valaki nem tud olvasható kódot írni, akkor az NE kódoljon olyan környezetben, ahol az általa leírtakat másoknak elfogadható időn belül kell tudni értelmezni/használni/továbbfejleszteni, ilyen egyszerű.

Elég egyszer olyan szerkesztőből menteni a python forrást, ami másképp kezeli a tabulálást, pl. n darab szóközt tab-bal helyettesít vagy viszont... Nem csak az olvashatóság megy a kukába, hanem a működés is. Vagy nem?

Velemenyem szerint amelyik editor kepes kezelni a python szintaxist, az legyen kepes felismerni az inkonzisztens bekezdeseket is. Egyebkent a fordito is felismeri az ilyet, es szol erte. (Az editorom (SciTE) meg rikito szinnel jelzi, ha inkonzisztens.)

Nem az a baj egyebkent hogy van ceges coding style policy, hanem az, hogy nalunk elegge elbaszott.

Azért ezeket mondtam, mert ezek tartalmaznak alapból GUI készítéshez eszközöket. A többi népszerűvel hamar el lehet jutni oda, hogy király, akkor most keressünk valami jó grafikus toolkitet. Én a javát ismerem valamennyire, szerintem elég jó a tanulási görbéje, tehát már kis tudással is lehet igényes dolgokat csinálni, aztán ahogy egyre többet tudsz, egyre bonyolultabb appokat tudsz csinálni. Mondjuk az első néhány java appomat szívesen letagadnám, idő kellett az oop szemlélet megszokásához.

Java2k esetleg Malbolge, persze csak nagyon elszantaknak :]

javascript node.js

OpenBSD 5.0/i386 theo for the prezident:D

Inkább perl. De már nem menő... C# az most nagyon megy a .NET-tel...
--
h0bb1t
<3 Ubi

ki a #@$&t érdekel, hogy menő-e.

amúgy ez a hitvita is biztos, hogy lement már itt párszor.

a perl mindenre jó egy kicsit, gyorsan lehet vele eredményt produkálni, szigszalag. van, akinek ez bejön.

én mondjuk azért szeretem, mert végtelenül tömör bír lenni, az életben is lábrázást kapok a felesleges köröktől.

O'Reilly könyvekből majdhogynem játszva lehet megtanulni, nagyon szórakoztatóak.

nem erdekel, hogy tomor vagy nem tomor. kifejezo legyen, atlathato es konzisztens. nem hiszem, hogy manapsag szamit barmit, ha rovidebb a forras, esetleg tobbet kell 'beirni'. azert zarojelben, mert egy ertelmes IDE-ben mar tobb a tab-enter mint a gepeles. felesleges korok meg minden nyelvben csak akkor vannak, ha nem kovet az ember alapveto szemleleteket.

A WPF hatalmas előnye, hogy kizárt dolog, hogy Windows-on kívül más platformon elinduljon.

- a .NET 3.5 extrém sok bütykölés után elindul wine alatt, mondjuk 10%-os valószínűséggel menni is fog a programod.
- a .NET 3.5 SP-k és a 4.0 már installáláskor fagynak wine alatt
- a Mono sem támogatja a WPF-et
...

Szóval WPF a legutolsó lehetséges megoldás.

Meglepődtem rajtad és Saxuson, mert ugye ez a Magyar Unix Portál fóruma (HUP).

Namost egy olyan hozzászólás, hogy a unix kompatibilitás nem szempont, arra utal, hogy valószínűleg rossz fórumon vagytok, csak ez még nem tisztázódott bennetek. ;)

Egyébként én szeretem a C#-ot, de a Microsoft sajnos képtelen rendes többplatformos alkalmazásokat írni (náluk a cross-platformos C# azt jelenti, hogy Windows 2000-en, XP-n, Vistán, meg Win7-en is elmegy).

Szerk.: a WPF meg még csak nem is szabványos. A C# cross-platformos szabványosított része (ECMA) gyakorlatilag semmire sem jó (a Windows Form is hiányzik belőle, nem csak a WPF). A Mono is ezért bukott meg Linux alatt. Nem lehet egy komplett grafikus felületet (GNOME) rá építeni, mert a szabványos rész kevés, a sok Microsoft szar támogatása meg jogi aggályokat vet fel.

Ahhoz képest, hogy az Unix kompatibilitás nem szempont, OSX alatt tök jól eljátszok OpenRA-val multiban ;)

@vross platform: MS-nél C# esetén a cross platform annyit tesz, hogy beágyazott rendeszerektől a mobiltelefonokon és (jövőbeni) tableteken át a PC-kig. De ez már annyiszor le lett itt flamelve.

Mono meg nem azért bukott meg Linux alatt, mert nincs hozzá grafikus toolkit (ld. GTK#), hanem, mert maga a közösség nem fogadta be, mert fújfúj MS, biztos a $átántól való!!!

Mellesleg a Java sem standard, ráadásul most perpill az Oracle kezében van és szerintem még sok egyéb más sincs szabványosítva, vagy ha igen, arra is szarnak (ld. C vs GNUizmus jegyében készült Linux only C kódok).

"Magyar Unix Portál". Hol mi? ;) Én már csak hupot látok.

----------------
Lvl86 Troll

Az Android GUI nagyon szépen megy és a sebességgel sincs gond, még 600 MHz-es CPU-n sem.

Igaz, hogy Android alatt DalvikVM van, nem JVM. Nem mélyedtem el a részletekben, fogalmam sincs a kettő közti különbségről, csak azt látom, hogy az Android telefonok GUI-ja hasít, mint állat.

Epp most volt (nem is egy) projektunk, Komoly Ceg Komoly Szoftveret teszteltuk Komoly Infrastrukturaval a segge alatt. Ugy 5 percig tartott beboritani az egeszet.

De egye fene, mutass nekem barmit, amit javaban irtak, es ra mernek mondani 9 9-es rendelkezesreallast. :)

--
"You're NOT paranoid, we really are out to get you!"

Nem hiszem, hogy a nyelv hibaja lenne, ha rossz a benne irt program. Eleg nagy bajok lennenek, ha a Java-s programok csak ugy beborulnanak ha olyan kedvuk van. Azert nem kis projektekben hasznalnak Java-t.

Azt sajnos elismerem, hogy sok a Java-s ganyolo. Ennek pl. olyan oka is van, hogy amerikai egyetemeken a Java-t tanitjak jatszos nyelvnek.

"Nem hiszem, hogy a nyelv hibaja lenne, ha rossz a benne irt program."

Ez a szornyu, hogy nem volt "rossz" egyik sem.

"ha a Java-s programok csak ugy beborulnanak ha olyan kedvuk van"

Nem "ha kedvuk van", hanem "ha kemenyen utik oket". De teny, igy sem szep toluk.

"Azert nem kis projektekben hasznalnak Java-t."

Mint az emlitettek... :)

--
"You're NOT paranoid, we really are out to get you!"

Dehogynem, elég körbenézni az ezoterikus nyelvek között :P
http://esolangs.org/wiki/Magritte http://esolangs.org/wiki/Bitxtreme http://esolangs.org/wiki/Compute

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Szerintem inkább írni :-) – valóban vannak perl-kódok, amelynél egy átlagos C program fordítás után tar.gz-be csomagolva olvashatóbb, de ha valaki követ egy kódolási stílust, szerintem nincs vele para. :)

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Azt a nyelvet tanuld meg, amiben egyszer majd dolgozni is szeretnél.

Mit szeretnél fejleszteni? Vállalati rendszereket, sima weboldalakat, beágyazott rendszereket, vagy asztali alkalmazásokat, esetleg mobil alkalmazásokat?

Ha ezt kitalálod, akkor már könnyebb a nyelvet és a hozzá tartozó technológiákat megtanulni. PL. asztali alkalmazásnál nem feltétel az sql ismerete, vállalati rendszernél pedig az apache httpd lelkivilága...

Akkor viszont c, vagy valamelyik interpreter nyelv. C-nek előnye amit feljebb is írtak, hogy nagyon hatékony, közel van az utasításkészlethez (ráadásul mikorkontrollerekbe is könnyen beletanul az ember c alapokkal), az interpreter nyelvekből a pythont ismerem, abban sokkal nehezebb hibázni, meg mindenre van már kész lib. Ruby állítólag hasonló, prelről semmit nem tudok.

Perlnek mar 2x is nekifutottam, mert meg akartam tanulni, es szuksegem volt egy tesztelo programra egy TCP/IP-n hallgato (C) programomhoz, de mind a ketszer lepattantam rola. A tesztelo proggit megirtam, de nagyon randa lett szerintem. Aztan megirtam a tesztelot Pythonban is. A megoldas egyszeru, elegans es nagyon atlathato lett. Azota Pythonban irok minden scriptnyelvre valo feladatot. Beleszerettem. :)

Van olyan nyelv, ami segíti (kényszeríti) a szép kódot, van ami nem. Ez fontos különbség, mert a programozók is emberek, nem félistenek. Nem abból kell kiindulni, hogy mire LEHET képes az ember, hanem abból, hogy mire szokott képes lenni. Főleg az indiaiak (bár az ő kódjuk szép, csak f*szság).
----
Hülye pelikán

Parancssorhoz nem létfontosságú az OOP. Bár igazából még mindig nem tudom, mit szeretnél csinálni. Egyszerűbb cuccokra bash is elég, bár sok zegzuga van, sokáig tart rendesen begyakorolni ahhoz képest, amilyen korlátai vannak. getopt azért van. :)

C akkor jön szóba, ha nem zavar, hogy minden egyes sztringművelethez érteni kell a pointereket, tömböket, helyfoglalást. pl. visszatérés sztringgel már fejvakarással jár: ki foglalja le a helyet, ki szabadítsa fel, statikus jó vagy dinamikus kell, stb. Listák-konténerek nincsenek nyelvi szinten, magadnak kell írni, vagy keresni. getopt() itt is van. :)

C++ még úgy is jó, mint egy ,,jobb C'', stl-lel vagy boost-tal pláne, ha most nincs kedved OOP-hoz. Részemről az egyik ajánlat.

Perlt sokan szeretik, szövegfeldolgozásra kitűnő. Bár nekem speciel az egyetlen programnyelv, amit anno használtam, de már erősen felejtem. :-)

Ruby pár dologban tetszett (OOP), másokban nem, és mivel a Rails se hoz lázba, hanyagoltam.

Pythont nézegetem, ígéretesnek tűnik. Részemről a másik ajánlat.

Attól függ, mire akarod használni. De tényleg.

A kérdésedből az nem jön le egészen, hogy már tudsz valamiben, csak ehhez még a Rubyt vagy Perlt vagy hasonló jellegűek közül egyet meg akarsz tanulni, vagy az első programnyelvedet akarod kiválasztani.

Ha felmerül a Ruby és a Perl, akkor én bedobnám a Pythont is az alternatívák közé, mert ebbe a családba tartozik, de választani közülük csak az alapján lehetne, ha tudnánk, mire akarod használni, mert mindegyiknek vannak előnyei és hátrányai.

Ha úgy általában kérdezed, mit érdemes tanulni, akkor a Ruby/Perl/Python egyikét mindenképp, akár első nyelvnek is, de látókör-bővítés céljából később érdemes megtanulni C-ben, majd után C++-ban is.

Utána meg látni fogod, mire van szükséged, így mehetsz a Java, C# vagy bármi felé. De egy szkriptnyelvet és egy fordítóprogramosat mindenképp ismerj meg.

A java szerintem egy jó választás, az elején elég gyorsan lehet benne fejlődni, később meg ott az EE amit tanulhatsz, és még sok pénzt is kereshetsz vele.
A haskell meg érdekes, én szabadidőmben szívesen tanulgatom. Persze egyszerűnek nem egyszerű(főleg az elején), de szerintem érdemes megnézni. :)

C-vel kezd. És ha akarsz ott meg is állhatsz.

--
GPLv3-as hozzászólás.

Sziasztok!

Melyik programozási nyelvet érdemesebb inkább megtanulni?
A Rubyt vagy a perlt? Vagy valami mást?

Szívesen fogadok véleményeket :)

Jelenleg ismerem a következőket: HTML, PHP, MySQL, kicsi Bash

tmms

Hol lácc te itt "Asztali és/vagy webes alkalmazások" címü kritériumot?

--
GPLv3-as hozzászólás.

A jelenlegi tudásod alapján most a Perl jön. Utána viszont nem lesz nehéz a Ruby sem. A Python nem érdekel? E három ismeretében már egész jól el tudod dönteni, hogy mit szeretsz igazán, ill. hogy mi alkalmas az adott feladathoz leginkább.
(A jelenlegi nyelvek ismeretében szándékosan nem ajánlgattam C/C++-t, Java-t, Smalltalk-ot, Haskell-t, Lisp-et, Scheme-et, Prolog, stb-stb.)

Clojure. Mert az mas, mint a tobbi, cserebe kivaloan hasznalhatoak belole a Javas cuccok.

Kivaloan alkalmas mind desktop app, mind webes alkalmazas fejlesztesere is, mindkettore van nem egy open source pelda.

--
|8]

en a kovetkezo utat jartam be:
(zx81) basic, (4th) forth, z80 assembly, 386 assembly (tasm/masm), (turbo) pascal, (borland) c, mawk.exe, bash, pic assembly, gforth, tcl, zope, rebol, ruby, nodejs

probalkoztam python-nal meg perl-el is de okadek volt mind2 az awk utan, mivel awk-al lehet parancssorbol, interaktivan kifejleszteni az alkalmazas darabjait. a bash-ra ugyanez igaz, foleg ha hasznalsz benne fuggvenyeket is. python alkalmatlan hatekony interaktiv parancssori fejlesztesre, a perl meg tul cryptic es nem intuitiv.

php-t nem emlitettem, mer az kvazi kovetkezik a tobbi nyelvbol, meg en forditottam 1 php konyv (egy reszet) a kiskapunak..., de csak debuggoltam php-t, from scratch sose irtam.

mindezek tudataban egyertelmuen a Rebol-t ajanlanam kovetkezo nyelvnek, mert az a legpraktikusabb az osszes emlitett nyelv kozul es a pofad leszakad ha megnezed mimindent tud. csak cimszavakban:

- 1 db vegrehajthato file
- kb 500kB a parancssori verzioja
- kb 1MB a grafikus verzioja
- cross platform: windows / linux / mac / bsd
(regebbi verzioi vannak csomo mas platformra is)
- ossz fuggosege a c++ library meg az adott OS grafikus layere (gdi/x11/carbon)
- az exe tartalmazza a kovetkezo protokol kliensek forrasat defaultbol:
SMTP ESMTP POP IMAP HTTP FTP NNTP
- sajat celnyelvet tudsz vele csinalni bazi konnyen (mmint DSL-t Domain Specific Language)
- grafikus valtozat tud png-t menteni es gif-et/jpg-et beolvasni kulon lib nelkul
- cross-platform read/write clipboard:// lehetoseg (Windowson is)
- TCP/MD5/SHA1/HMAC checksum-ok, base64 beepitve (Windowson is)
- van egy egyszeru beepitett szovegszerkesztoje is, tehat az is mindig keznel van minden platformon
- nem azzal kell kezdened a programodat, ha epp csak a pocsodet is akarod megfogni vele, h 826ezer buzi includeot meg importot irsz az elejere amit sose birsz megjegyezni h melyik nyelv okoszisztemajaban hogy hivnak, mert ezek a mindennapi eszkozok mindd benne vannak 1xuen! pl ilyen egy Cross-platform Hash-a-Pass

epp hetfon kedden osszedobtunk pl egy BDD teszt frameworkot benne haverommal: http://repos.rebol.info/malako
(igy nez ki a futtatasanak az eredmenye: http://repos.rebol.info/malako/out.html)
((( amugy a http://vowsjs.org -ban irt tesztjeinket migraljuk at erre a sajat cuccra, ami egy nodejs-ben irt TDD async framework)))

ez meg egy grafikus pelda: http://onetom.posterous.com/a-card-game-on-the-ibasket-part-1

bar van egy egesz jo Rebol-ban irt webserver (Cheyenne) , azert web alkalmazashoz inkabb a nodejs alapu Express frameworkot ajanlanam.

@dap: "weben a Railsnek nincs párja"
az express az elegge parja mar a railsnek manapsag, raadasul a http://heroku.com is tamogatja a node-os app-ok deployment-jet.

Rossz a sorrend: Először tanuld meg, hogy mi az, hogy programozási nyelv. Ha ez megvan, utána tanulj meg programozni. Ha ez megvan, akkor válassz egy feladatot, amihez kereshetsz már programozási nyelvet.

----------------
Lvl86 Troll

Ez most kb olyan, hogy matekórán elsőben kezdjük el a halmazelméletet okítani, sőt, kezdjük a logikai alapokkal. Hülyeség. Programozási nyelv nélkül nehéz megérteni az elméletet, úgy tanulsz a legkönnyebben, ha közben gyakorlod is.

Amúgy az én javaslatom mindenképpen a Python, általános célú (kb mindenhol használható a nagyon célhelyeken kívül), nagyon erős ÉS szép/következetes nyelv. Jah, és van interaktív interpretere, ami tanuláshoz felbecsülhetetlenül értékes.
----
Hülye pelikán

Egyrészt: a []-s részt TE tetted oda, nem ő. Gondolom, hogy a html és az sql ismeretekkel van bajod, mindkettő igen hasznos ilyen-olyan programozásnál.
Másrészt: a programozási nyelv sok definíciójába belefér viszonylag sokminden, a html biztos, a mysql-nél attól függ, mit értünk alatta (gyanítom, hogy a kérdező sem az adott implementációra hanem az sql nyelv dialektusára gondolt).
----
Hülye pelikán

Tisztázzunk valamit.

"A programming language is an artificial language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs that control the behavior of a machine and/or to express algorithms precisely."

A html pont leírja, hogy hogy jelenítse meg a weboldalt (a css-el meg kutyaf*szával együtt). Magas szinten programozol, a virtuális géped a böngésző.
Az SQL meg az adatbázis működését befolyásolod.
----
Hülye pelikán

Segítő kérdés: ha engem Mindenható Úristennek hívnak, az azt jelenti, hogy én vagyok a mindenható úristen?

Mégegyszer: itt arról volt szó, hogy egyfelől saxus szerint a kérdező programozási nyelvnek tartja a html-t és az sql-t, amit nem látok alátámasztva, másfelől hogy nem is nagy hülyeség, hiszen a programozási nyelv definíciója nem egzakt, és sokba pont beleférnek a leírónyelvek is.
----
Hülye pelikán

A HTML Turing-teljes? Szerintem elegge egyszeru a programozasi nyelv definicioja, csak jol kell megfogalmazni, es ismerni hozza par fogalmat.
Az, hogy a HTML-be beagyazhato a JS, ami mar az, nem jelenti azt, hogy a HTML is az lenne.
Ha nem ertesz ezzel egyet, akkor legyszi irj egy olyan HTML programot, ami kiszamolja mondjuk egy inputkent megadott szam faktorialisat..

--
I have come to the conclusion, that the matrix must have some bad bullet lag.

Tisztában vagyok vele, hogy nem Turing-teljes. Naés? Ez a programozási nyelv definíciója? Nem, nem ez. Az általam idézett definícióba belefér szinte akármi.

Az a baj, hogy habzik a szátok. Én nem azt írtam le, hogy a html szerintem egy programozási nyelv. Azt írtam le, hogy a definíciók annyira nem egzaktak, hogy simán belefér tetszőleges leíró nyelv is, és hoztam egy népszerű példát, amit amúgy a kérdező is megemlített. Nyílván hagyományos értelemben nem tekintem én sem programozási nyelvnek, de simán tekinthető annak, ha akarjuk.
----
Hülye pelikán

"Segítő kérdés: ha engem Mindenható Úristennek hívnak, az azt jelenti, hogy én vagyok a mindenható úristen?"

Amennyiben a tulajdonságaid miatt kaptad a nevet, akkor igen.
Amennyiben te adod magadnak a nevet , akkor az sokat elárul az elmeállapotodról, és ez megmagyarázza a HTML-el kapcsolatos sajátos érvelésedet is.

Mégegyszer: tökmindegy mit gondolsz, és mit hiszel, a HTML nem programozási nyelv. Pont.
A te logikád szerint az XML és a BBCODE is programozási nyelv lenne.....
Olvass utána.

Örök, eldönthetetlen vita ez, mert szerintem személyfüggő.

Van, aki az általánosságokban nem bír gondolkozni, csak a konkrét dolgokkal bír mit kezdeni. Neki muszáj először egy nyelv pár utasítását megismerni, megtapasztalni, hogy is megy ez a gyakorlatban. Aztán lesz valami kép benne, és tanulhat meg módszeresen programozni, folyamatábrákat meg stuktogrammokat rajzolni, stb.

Más meg jól elvan a teljesen absztrakt dolgokkal egy jó darabig, bírja is követni egy konkrét nyelv nélkül is és elég neki csak utána géphez nyúlni.

Szerintem ez elsőből van több, csak sokan közülük abba a hibába szoktak esni, hogy a kezdeti kódfaragás után nem állnak meg az absztraktabb megközelítést megismerni és így nem jutnak komoly szintre.

Azok, akik bírják az absztrakt kezdést, jó programozók, rendszertervezők lehetnek, csak sokszor rossz oktatók válnak belőlük, mert nehezen értik meg, miért nem jó a diákok nagy részénél a teljesen elvont kezdés.

Legalábbis én így látom ismeretségi körömben.

+1. A könnyű kezdés után ott a kísértés abbahagyni a fejlődést. Aki így tesz, az valóban csak kódfaragó marad. ha valaki fordítva indul, és az elméleti dolgokon rágja át magát előbb, az utána kvázi bármelyik nyelven meg fogja tudni oldani a kiadott feladatot, és néi gyakorlat után a nyelv kiválasztásában is az optimumra fog törekedni.

mit mondanak a nagyok (Guy Steele, Douglas Crockford, Josh Bloch, Alex Payne, Bruce Tate):
http://www.infoq.com/presentations/Future-of-Programming-Languages

39:00-tol kezdodoen van a kovetkezo osszefoglalo:
- Io, Prolog
- Scheme & Assembly
- barmely 3 nyelv, mert az osszehasonlitasuk tanit a legtobbet & Clojure
- Forth & Factor
- (Scheme again :) & Rebol & (Assembly)

C - Rendszerhez programokat írni legjobb
C++ - GUI programokat írni legjobb (esetleg ehhez wxWidgets)
Java - Ha több platformos program kell, esetleg weben kell futnia
Perl - Ha rendszergazda lennél, könnyebbé teheted vele az életed

---
http://szit.hu

Megint kötekednem kell: GUI-ra C#-ot?

Windows Forms, vagy Gtk#?

Mert ugye ez a kettő hordozható egyáltalán.
- Windows Forms-ot kívánni egy kezdő programozónak szerintem komoly sértés. Én nem bírtam Windows Forms-ot használni Qt után, mert mindig az 56,134-117,234 pozíciókra kellett ablakot pakolni, amitől elszállt az agyam. Ki a fenét érdekel, hogy mi az az 56,134? A XI. században nem megy az automatikus méretezés? Nekem kell egy átméretezés után kiszámolni a 45,120-at?
- A Gtk# meg olyan amilyen. Itt természetesen az 56,134-es baromkodástól legalább mentesülsz, de a Gtk bughalmaz verzióról verzióra történő szarakodásaitól és nyakatekert fejére állított API-jától nem.

Lentebb leírtam, hogy a WPF nem hordozható. Ha keresztplatformos alkalmazást akarsz, akkor nem használhatod, mert később esélyed sem lesz Linuxra vagy Macra áttenned. Éppen ezért amikor a C#-pal ismerkedtem én eleve kizártam, mert a Windows-t havonta egyszer, ha betöltöm. Maradt a Windows Forms és a Gtk#, melyek színvonaluk miatt hanyagolhatóak.

Azaz, ha keresztplatformos alkalmazást akarsz, grafikus felülettel, a C# mint nyelv felejthető.

C++ és Qt, legalábbis szerintem.

Webes alkalmazásra a C# is tökéletesen megfelelne.

(Nem látok egetrengető különbséget C# és Java között, az egyetlen, ami a Java mellett szól, a keresztplatformosság. Személyes véleményem az, hogy pont emiatt C#-os projektből kizárólag olyannak érdemes nekifogni, ami vígan elmegy mono alatt is).

(Sajnos a keresztplatformos problémák miatt soha sehová nem szoktam C#-ot javasolni, mert a java legalább ugyanannyit tud és emellett hordozható is)

C++: rendszerhez programokat írni. Amit a C tud azt a C++ is.
Python: egyszerű scriptek, GUI-s programok (Tk csodákra képes). A Javas sorod minden része igaz ide is, sőt, még a C++-ra is. Ahol van JVM ott általában van C++ fordító is. Nem értem ezt a fetisizmust a fordítás hiányával, miért gondolják még mindig az emberek, hogy a Java valamiben platformfüggetlenebb, mint a C/C++ nyelvek.
Rendszergazdáknak is szintén inkább a Python. Az is a sztenderd kiszerelés része linuxokon, és erősebb nyelv.
----
Hülye pelikán

A python egyatalan nem erosebb nyelv a perlnel, masreszt probalj meg benne gyors onelinert irni. perl -npe csodakra kepes.

A JVMet meg azert szeretjuk, mert nem kell a programot ujraforditani, es a fordito esetleges hulyesegeivel meg bugjaival szivni. Igaz, ez utobbiak ritkak, de akkor is kenyelmes hogy van egy jarom es szevasz, megy mindenhol nagyjabol (Note: JVM, nem Java. Javat nem szeretem, de a JVM jo dolog). Lenyeg: platformfuggetlenebb, mert bar a jol megirt C++ kod is lefordul mindenhol, ahol van Java, utobbit nem kell mindenhol leforditani.

--
|8]

Mit hívsz te erős nyelvnek? A Python azért erős nyelv, mert tömören nagyon összetett dolgokat lehet benne kifejezni. Lehet, hogy nem értek eléggé a Perlhez, de nekem nem tűnt ilyen téren egyenlőnek (vagy jobbnak akár).

A JVM-ben könnyen igazad is lehet. Azért írtam amit írtam, mert nem látom azt a hatalmas különbséget a JVM implementációk és a fordítók eltérősége között, mindkettő okozhat gondot, de nem vagyok szakértője a témának. Alapvetően szakértő az tud fordítani akárhol, aki meg user annak úgyis előre fordítasz célplatformra.
----
Hülye pelikán

Nem ertesz elegge a perlhez. Ha mas nem, a significant whitespace miatt python sokkal kevesbe lehet tomor. Raadasul perlhez ott van a CPAN, amivel szereny velemenyem szerint, a mai napig sem tudta meg semmi felvenni a versenyt.

JVM-mel kapcsolatban: en, mint fejleszto, baromira nem akarok minden architekturara, OS-re, stb forditani. Tegyuk fel, irtam egy tok jo programot, valami JVM-re fordulo nyelvben. Csinalok belole egy JAR-t, elfut mindenhol nagyjabol. Ha ugyanezt C++-ben csinalom, akkor az osszes platformra, ahol lefordulhat, forgathatom, ha a usereimnek binarist akarok adni. Az meg azt jelenti, hogy be kell szerezzek megfelelo kornyezetet az osszes ilyen platformbol. Koszonom, maradok a JVM-nel, mint fejleszto, mert kenyelmesebb.

Szivtam mar eleget azzal hogy ~8 platformra forditok C programot. Egy-egy uj release ~3-4 ora munka mire lefordul mindenutt, es fenn kell tartanom hozza egy rakas chrootot meg ket virtualis gepet. JVM-es csomagnal ilyen gondom nincs, ~15 perc alatt osszerakok egy uj releaset, es az elfut ugyanezen a 8 platformon. Nem kell hozza N chroot, se virtualis gepek.

--
|8]

"Koszonom, maradok a JVM-nel, mint fejleszto, mert kenyelmesebb."

Teljesen érthető, és aki ebben a bizniszben dolgozik, valószínűleg egészségesen (vagy azon túlmenően is) lusta, tehát nincs jogalapja ezt az álláspontot kritizálni.

Azt viszont meg kell jegyeznem, hogy elképesztően csúnya és/vagy nehézkesen használható (a clipboard esetleges kezelése a legkeserűbb pirula) javás konfig-/installuikat képesek készíteni egészen drága (és alapvetően profi) *ware-rendszerekhez is - kb. a hobbiból, mezitlábas tk-ban írt frontprogramokhoz tudnám hasonlítani.

Amen. Ugyanez igaz Perlre is, ott sem kotelezo onelinert irni space nelkul, sot, normalis esetben nem is tesz ilyet az ember, perlt is lehet tokeletesen szepen indentalni, atlathatora meg minden. Ellenben ha arra van szukseged, akkor lehet egysoros kis izet is irni pikk-pakk. Pythonban nem.

--
|8]

Ok, tevedtem. Van amit bele lehet eroszakolni Python onelinerbe. De az emlitett peldak nemelyike meg olvashatatlanabb, mint ugyanaz Perlben. Pl. a file edit in place, az valami borzalom. Ugyanaz perlben: perl -pi -e 's/at/op/g *

Hat eg es fold.

--
|8]

A Perl egy célnyelv, beleraktak rengeteg speciálisan célcuccot. A Python általános célú, és így is majdnem olyan tömör azokon a területeken is, ahol a Perl veri. Ez a nagy eredmény, ezért mondom, hogy a Python iszonyatosan erős nyelv, mert általánosan tömör.
----
Hülye pelikán

Mi egyeb? Mert ez egy dolog. Egy meg nem rengeteg, es konkretan a regexp nyelvi szintre emelesevel nem sporol sokat az ember az esetek tobbsegeben. (Ketsegtelen, hogy cserebe igy sokkal kenyelmesebb, mint Pythonban, ami szamomra legalabbis sokkal erosebb nyelvve teszi a Perlt, mert tomoren es egyszeruen ki tudom fejezni vele amit akarok)

Turing teljessegrol... brainfuck is turing teljes. Ettol meg ossze tudom hasonlitani a Pythonnal, es merem allitani, meg te is egyetertenel velem, hogy a Python erosebb nyelv a Brainfucknal. :)

--
|8]

Perl alatt egy kis-nagybetűs összehasonlítás is regex-szel megy, ami ugye bődületes lassú a normál libchez képest.

A nyelvi tétellé emelésnek ez a mellékhatása.

Ráadásul szívtam is egy nagyot, mert a perl automatikusan memcpy-t hív az esetek zömében regexnél. Egy 25mbyte-os string első pár karakterét akartam vizsgálni, a végeredmény betegesen lassú lett.

Szóval nem minden tuti, ha a regex nyelvi elem.

Információelméleti szempontból nem gáz: Ugye adott bit egy 50%-50%-os vagy igen vagy nem esélyt kódol, entrópiát számolva: -log_2(0.5) = 1 (bit)

mondjuk 99%-1% valószínűség eloszlásnál az egyik eset tárolására elég: -log_2(0.99)= 0.0145 bit

Ezt persze önmagában nem tudod egy az egyben lekódolni, de sok ilyet együtt pl. aritmetikai kódolással (elég jó közelítéssel) igen.

Őőőőő.... Ezt ez emeletes hülyeséget honnan veszed, hogy kis-nagybetűs összehasonlítás csak regexppel megy?
Ha jól értem, arra gondolsz, hogy if (uc $string1 eq uc $string2) {} vagy épp
(uc $s1 eq uc $s2)?v1:v2

1. Hova kellett ehhez regexp?!
2. A regexp elemzők közül a perl-é magasan ver bármi más implementációt! Nem véletlen, hogy még a rendes lib-et is úgy hívják, ha C-ből akarsz, hogy libpcre (Vagyis "Perl Compat Reg.Exp.")
3. Pont az emeli ki a többi kazal C-style szintaxisú nyelv közül, hogy a regexp nyelvi elem. Minden másra, ahol meg kraft kell, ott a C! ;-) Uram bocsá, ha komplex böszme nagy rendszer, ahova skálázni kell, vagy még más speciális szempontok esetén, akkor meg ott a Java.

Biztosan nem értesz a perlhez.
Nóoffensz, nem szégyen az, csak azért írom, nehogy az maradjon az errefelé kíváncsiskodó kezdőben, hogy a python elég tömör, a perl meg nem annyira.

Természetesen, ha van egy adott feladatot ellátó python osztály, annak használata sokkal rövidebb kódot eredményez, mint egy ekvivalens perl from szkrecs - és ilyenkor szokott kiderülni, hogy a cpan.orgon 10 éve ott figyel egy (oo) modul, ami visszabillenti a világot a maga (adott esetben egysoros) kerékvágásába.

"hogy a Java valamiben platformfüggetlenebb, mint a C/C++ nyelvek."

Próbálj meg az alap C eszközeivel platformfüggetlen threadingent megvalósítani Linux-Windows között. (2012-ben ez legyen már elég alapvető igény, mikor egy mobiltelefonban van 4 mag lassan).

Az nem platformfüggetlenség, hogy telerakod #ifdef -ekkel a kódot.

----------------
Lvl86 Troll

Ez csak részben igaz.

Ha C++-t Qt-vel együtthasználod, akkor máris egy java-val összehasonlítható hordozható rendszert kapsz. Jó dokumentációval és könnyű programozhatósággal.

Abban sajnos egyet kell értenem, hogy egy szál indításához az "#if defined(WIN32)" matyóhímzés nem kezdőknek való.

Annyit mondanék, hogy ha már a C++-t választod, akkor egy normális hordozható lib is kellene hozzá, ami elrejti az operációsrendszer specifikus baromkodásokat.

Pontosan ez. Az volt a kérdés, hogy megoldható-e hordozhatóan: meg. C++-ban alapból van szálkezelés nyelvi és könyvtári szinten támogatva, de maradjunk a C-nél. Ahhoz is vannak hordozható libek (sőt, C-hez van a világon a legtöbb lib érzésem szerint, ahogy a bácsi mondta: "This world runs on C and C++"). C++-nál a nyelv egyik ereje, hogy libeket lehet benne írni. Úgy volt tervezve a használat, hogy az ember minél ritkábban nyúljon a sima nyelvhez, főleg libeken keresztül használja. A C meg alapból elég minimalista, nyílván libekre fog támaszkodni. Tehát igazságtalan elvárni, hogy a standard könyvtárával operáljon, más volt a tervezési elv, de ugyanúgy képes rá platformfüggetlenül.
----
Hülye pelikán

Pontosan. A Java is csak annyira hordozhato mint a JVM. Lehet, hogy a C nem a legkenyelmesebb nyelv, de szinte megkerulhetetlen*.

*megkerulheto, de felesleges. Ha valaki csak azert NEM akar C-t hasznalni, mert az C, akkor az egy barom. Ha meg valaki azert nem akar C-t hasznalni, mert bonyolult, akkor az menjen vissza Logo-zni.

Hehe. Pont ezt mondtam haveromnak én is, amikor felmerült ez a "This world runs on C and C++", C++ fordítót tudsz írni C++-ban, de JVM-et nem tudsz írni Javaban (ami persze nem igaz, de ahhoz kell egy nem-hagyományos Java compiler, vagy dupla réteg virtuális gép lesz).
----
Hülye pelikán

Minden fordítót mindenben tudsz írni, csak nem feltétlen érdemes.
Bash interpretert is tudsz bash-ban írni, bár nem ajánlom.

Semmi sem akadályoz meg abban, hogy a /usr/bin/bash bájtjait te magad rakd össze egyesével.

Java fordítót és JVM-et is írhatnál java-ban, de valószínűleg az észszerűség megkövetelt egy mikroprocesszohoz közelebbi nyelvet.

Igen, vannak esetek, amikor a C/C++ jobb, máskor meg a java. Ha bagóért felveszel indiai programozókat, akkor java.
Egy jó C/C++ programozó drága, a java olcsóbb.

Elrettentő példának egy indiai kód, ami 95%-ban ment, de néha fagyott:


char * function(int param)
  {
    char buffer[100];
    sprintf(buffer, "%d", param);
    return buffer;
  }

Pedig de: (Maxine manual)

1 Building the boot image

Now let's build a [boot image]. In this step, Maxine runs on a host JVM to configure a prototype, then compiles its own code and data to create an executable program for the target platform.

2 Running Maxine

Now that Maxine has compiled itself, we can run it as a standard Java VM. The max vm command handles the details of class and library paths and provides an interface similar to the standard java launcher command.

A C-t akkor kell használni, ha szükség van rá. Nagyon sok esetben semmi szükség nincs rá.

Az irányvonal mindenképp az, hogy minél magasabb absztrakciós szinten lehessen programot fejleszteni, minél kevésbé kelljen a nyelv nyűgeivel foglalkozni, és a valódi probléma megoldásán tudjunk dolgozni.

Ez az irányvonal tökéletesen kirajzolódik a függvény, függvénykönyvtár, osztály, tervezési minta vonalon.

Mi történne, ha kivennéd a new-t? Ezt írnád:

MyClass x = MyClass();

A fordító pontosan tudja, mit hogy kell létrehozni. Mivel stacken csak bizonyos meghatározott típusok jönnek létre, felesleges külön kulcsszóval jelezni, hogy ez a heapre kerüljön, hiszen mindenképpen oda kerül.
----
Hülye pelikán

Igaz, de szerintem rontana a kod olvashatosagan es a Java egyszerusegenek resze az olvashatosag is. Ha nagyon el akarod rejten a new-t akkor meg lehet egy statikus metodust irni ami megcsinalja, azonban nem hiszem, hogy ez sokat segitene. Olyannal meg nem talalkoztam, hogy valaki ne tudna, hogy mikor kell new-zni. (malloc mas kerdes) Inkabb a delete/free szokott gond lenni, mert nem figyelnek arra, hogy milyen sorrendben es mit kell "elengedni". (Kulonosen akkor ha egy fuggveny hivas allokalta a memoriat. Az katasztrofa szokott lenni. ld. readline.) Azt meg mar ugyis megoldja neked a Java...

Hat... Jo dolog az absztrakcio, de azert a kod legyen mar egyertelmu olvasas kozben, hogy most fv hivas vagy peldanyositas van. Szvsz.

De ha mar itt tartunk, lassan elovehetjuk a Delphi-t/ObjectPascal-t es hopp, nincs new kulcsszo, ha irtani akarjatok :P


var 
  foo: TFoo;
  bar: TBar;
begin
  foo := TFoo.Create;
  bar := TBar.Create(foo);

----------------
Lvl86 Troll

Az absztrakció lényege, hogy elrejti, hogy ez most függvényhívás vagy példányosítás. Azaz ha én a típust kicserélem egy factoryfüggvényre akkor sincs semmi gond, ugyanaz a kód fut tovább. Lásd Python.

Ez most olyan, hogy a C++ függvény templatek a paramétereikből kitalálják a típusparamétereket (ha tudják). Ez is elrejti a felhasználó elől, hogy templateről van szó, mégsem sír érte senki.
----
Hülye pelikán

Egyetértek a kérdéssel.

A nyelv nem azért jobb B nyelvnél, mert a "new "-t nem kell kiírni. Szerintem huszadrangú kérdés, hogy van-e new, vagy nincs.

Gondolom a java-ban azért nincs statikus példányosítás, mert a filozófia az volt, hogy a lehető legkevesebbet kelljen a programozónak gondolkozni, hogy melyik a helyes. A redundanciákat kiszedték a nyelvből.

Nekem a C# jobban tetszik, mint a java (szintaktikailag), de a keresztplaform hiánya miatt nem tudom senkinek sem jó szívvel ajánlani. Az MS mérnökei jól megtervezték, de a cég politikája miatt nem versenyképes a java-val.

Igen, vegulis ez egy ertheto dolog, de szerintem a Java-ban akkor sem lenne szerencses. Egyreszt van mar ra egy (rendkivul gaz) megoldas, masreszt soha sem tudhatnad, hogy valoban egy uj objektumot kapsz-e.

Megoldas lehetne meg a new opcionalissa tetele. Igy pl. az a resze a kodnak amit eleve new nelkul irtal az menne tovabbra is, ahol viszont valami jo okod volt ra, hogy new-t hasznalj, ott azonnal bukna a dolog es tudnad, hogy hol vannak azok a kritikus reszek amiknel feltetelezted, hogy uj objektumot fogsz kapni. Esetleg lehetne egy metodus es egy konstruktor is ugyanolyan parameterekkel. Attol fuggoen, hogy new vagy nem new valasztana a fordito...

OK, vegulis elfogadhato egy ilyen igeny.

Semmi baj a Delphis hozzáállással.

Minden nyelvben hasznos a konzisztencia: OO szemléletben ez pl. azt jelentheti, hogy minden metódushoz/művelethez van egy felelős objektum: és obj. példányosításkor a felelős abszolút lehet az objektum osztálya.

Nagyon szép példa az ilyen konzisztensen OO hozzáállásra pl. a Smalltalk feltételes utasítása:

http://en.wikipedia.org/wiki/Smalltalk#Control_structures
Itt az if-re sincs nyelvi kulcsszó, a Boolean objektum felelős azért, hogy a neki küldött kódblokkot a saját értékétől függően lefuttatja-e vagy sem....

Félreértés ne essék, nem azért jó az ilyesmi mert sokkal objektum orientáltabb, hanem mert sokkal konzisztensebb. Felőlem lehet más metodológiában is egy nyelv, ha emellett konzisztens, és nem kell figyelni vagy megtanulni a kivételes, átlagról eltérő megoldásokat.

Erre válaszolok, válaszolhatnék a többire is.

El kellene különíteni 3 dolgot:

1, a java nyelv
2, a java bytekódot
3, a program végrehajtása

A nyelv egy formalizált leírása annak, hogy milyen nyelvi elemeid vannak. Ez a java esetén
sikerült elég konzisztensre összerakni.

A bytekód egy adathalmaz, ami fordítás során a java forrásból keletkezik

A programot pedig valamilyen rendszer hajtja végre. Ez általában a JVM. Viszont, lehetőség van java-ból platform specifikus binárist-t is fordítani, ilyen megoldást szállít pl. az Excelsior JET.

Akár Perlt, Pythont vagy Rubyt tanulsz, okosabb és ügyesebb leszel. Ha van kapacitásod, akkor fél év elteltével vágj bele egy másik nyelvbe is, majd megint fél év elteltével mérlegelj, hogy melyik jobb.

Én Perl, Ruby, Python sorrendben tanultam, és nekem a Python jött be, utána a Ruby és csak utána a Perl. Ha e három nyelvből lehet választani, akkor minden feladatra Pythont választok (és még sose bántam meg). Ha Pythont nem lehet, akkor Rubyt (és még sose bántam meg). Ha Rubyt sem lehet, akkor Perlt.

A Perl nagy előnye a másik kettőhöz képest, hogy elterjedtebb (telepíthető és általában telepítve is van), főleg egzotikus Unixokon és egzotikus nem Unixokon. Nagy hátránya a szintaxisa és a szószátyár és körülményes objektum-orientált programozása. Ezek kis projekteknél nem számítanak, de 1000 sor felett Rubyban vagy Pythonban sokkal absztraktabb, tömörebb, könnyebben módosítható kódot lehet írni alapból, mint Perlben -- tehát lustán programozva is jobb kódot kapunk, ha Pythonban kezdjük.

Kezdetnek kettő három olyan (imperatív) nyelvet érdemes megtanulni és használni, ami felkelti az érdeklődésedet a tulajdonságai alapján vagy mert jó megoldásokat nyújt a te problémáidra.

Aztán, ha már mindent tudsz ezekről, akkor jöhet a (deklaratív, funkcionális) Lisp/Scheme vonal.
Ha szerencséd van (az intellektus egy bizonyos ritka konfigurációja leledzik benned), akkor az eddig magad köré épített falak résein keresztül észreveszed a programozói nirvána egy csillanását, és nem túl sok erőfeszítés árán megvilágosodsz. Ezentúl a korábbi gyengécske
nyelveken (kényszerűen) programozva is jobb programokat fogsz készíteni, de a teljes harmónia állapotába csak Lisp-et használva jutsz el. Csak kevés szerencsésnek adatik meg, hogy már a kezdetektől Lisp-et tanul és használ.

Hahó!

>> Aztán, ha már mindent tudsz ezekről, akkor jöhet a (deklaratív, funkcionális) Lisp/Scheme vonal.

Biztos, hogy a LISP/Scheme vonulat deklaratív, és nem inkább applikatív?

Szvsz. deklaratív talán a PROLOG és mondjuk az SQL, hiszen ezeknél a nyelveknél azt kell deklarálni, hogy milyenek az elfogadható eredmények, és nem a működés vagy végrehajtás menetét/lépéseit, hiszen az mindkettőnél adott. Azt írjuk le, hogy mit szeretnénk elérni, s nem azt, hogy hogyan.

G.
P.S. Azért a funkcionális megközelítésnek, legyen az LISP/Scheme/Sml/OCaml/Haskell (s.í.t.) nagyon nagy +1!
============================================
"Share what you know. Learn what you don't."

Azért szokás deklaratívnak tekinteni a funkcionális stílust:

Mert a függvények funkcionális programnyelv esetén definícióként, nem pedig utasítás(ok)ként olvashatók/olvasandók!!!!

A matematikában teljesen elfogadott pl. úgy definiálni a faktoriálist, hogy:

(n természetes szám esetén)
0!=1 és n! = n*(n-1)!

Ha ugyanezt írod pl. Haskellben:
fact 0 = 1
fact n = n* fact (n-1)

Akkor csak a procedurális beidegződésed mondatja veled azt, hogy majd rekurzív utasításhívás történik: valójában azonban pontosan a fenti színtiszta matematikai DEFINÍCIÓT adtad meg egy más függvénynévvel.

Egy számítógépekhez nem értő - konkrét megvalósulást nem ismerő - matematikus nem is láthat különbséget a kettő között: ekvivalens deklaratív megfogalmazások

Röviden: Ne utasításként hanem definícióként olvasd, és mindjárt deklaratív lesz... ;)

Ó, már azt hittem, senki sem hozza fel... =) Egy-két idézet ezzel kapcsolatban a klasszikusoktól:

I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone. -- Joel Spolsky, The Perils of Java Schools

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs. -- Paul Graham, Beating the Averages

Azért más a két nyelv; bash előnye, hogy a rendszer alapértelmezett shellje ugyanaz, mint a szkript nyelve. Ott nem érdemes nehezíteni a globális változók használatát.

A Python egy OOP nyelv, elsősorban alkalmazásfejlesztésre. Szerintem pont jó így a globális változók kezelése.

Ésszerűség. Hányszor írjam le? Ez nem igénytelenség, ez rossz stílus. De ennek a kiküszöbölése komplexitást visz a rendszerbe, ami kis kódoknál felesleges. Ahhoz tudnám hasonlítani, amikor meghívni a függvényt több erőforrást igényel, mint maga a függvénykód végrehajtása.

Kevesebb szemellenző, több ésszerűség. A hülyék hülyék maradnak, aki nem tud programozni annak az ilyen elvek sem segítenek.
----
Hülye pelikán

"Ésszerűség. Hányszor írjam le?"
Nem lehet merni. Mindenkinek mas a kuszob.

Mennyire visz komplexitast a rendszerbe, ha szubrutinokat hasznal es atadja neki ami kell parameterkent? Ha 10 sor az egesz akkor legfeljebb egy szubrutinja meg egy call-ja lesz.
Viszont ha boviteni kell, akkor nem kell utolag atirni az eredetit (legalabbis ezert nem).

Amikor írtad, hogy milyen jók a globális változók többszálúságnál, megállt bennem az ütő.

Még szerencse, hogy hozzátetted, hogy a mutex a globális nálad.

(alapvetően a globális mutexet is kerülni kell, példa: globális usb mutex egyszerre lokkolná az egeret és a pendrive-ot. A legtöbb esetben a pointerezgetés a helyes megoldás, csak azokat a szálakat állítod meg, amelyek ténylegesen érintve vannak)

Nem csak mutexekhez gondoltam.
Mas pelda:
Van 2 szalad. Az egyik szal valamilyen modon a userrel kommunikal es a kapott informaciok alapjan kiszamolja egy motor kivant sebesseget. A masik szal meg fogja ezt a sebesseget es a megfelelo gyorsulas mellett beallitja. Van olyan limitalt kornyezet ahol erre az idealis megoldas egy globalis valtozo amit az egyik szal ir, a masik meg olvas. Versenyhelyzet nincs es nulla az overhead.

---

Persze, nem akarsz egy mutexet hasznalni mindenhez. Azonban lehetnek olyan esetek amikor ugyis csak 1 vagy 2 mutexed van a programban es egy programresznek ugyis mindig ugyanazt a mutexet kell hasznalnia. Ebben az esetben lenyegesen jobb megoldas globalis valtozokent hasznalni oket egyszeruen azert mert sokkal kisebb a hiba lehetosege. Persze, egy bizonyos komplexitas folott ez mar rossz megoldas. Ezert is kell a programozonak felmernie, hogy hogyan erdemes. Ha meg ugy dontok, hogy nekem globalis valtozo kell, akkor szeretnem ha a nyelv nem mondana azt, hogy nem hasznalhatom...

Nem ismerem a lebegőpontos aritmetika mélységeit, de egyáltalán nem vagyok meggyőződve arról, hogy nem lesz szinkronizálási problémád.

PC-n a lebegőpontos processzor miatt még akár működhet is, de azt feltételezni, hogy a lebegőpontos kiírás atomi művelet, szerintem túlzás.

Javaban megy, mert a JVM garantálja neked, hogy a primitív típusok kezelése atomi legyen és elrejti az eltérő architektúrákból adódó különbségeket.

De mondjuk olyan architektúrán, ahol nincs lebegőpontos processzor már lehetnek problémák.

A megoldás valóban gyors, de olyan dolgot használsz ki, amit bár a PC lehetővé tesz, de a C nyelv egyáltalán nem garantál neked, éppen ezért nem minden lehetséges architektúrán fog működni.

Utoljara ilyet olyan cuccon hasznaltam ahol nem volt mas lehetoseg arra, hogy masik thread-nek informaciot adj at. (Mellesleg lebegopontos szamokat sem ismerte...) Egyebkent az egyik szal csak erteket adott a valtozonak, a masik meg csak egy masik (lokalis) valtozoban levo masolattal dolgozott. Nem hiszem, hogy egy egyszeru int ertekadas barmilyen rendszeren problemas lenne. :)

Igen, de nincs olyan idopillanat amikor 'a' erteke elterne 'b'-tol vagy az ertekadas elotti ertektol. Igy nincs semmi gond. Maga az ertekadas egy muveletben tortenik.
Persze, el tudnek kepzelni valami egeszen kreten cuccot ahol mondjuk Byte-onkent kene kimenteni egy int-et, de az adott cucc nem ilyen volt. Raadasul (mint emlitettem) az adott eszkozon nincs mas mod a szalak kozotti kommunikaciora.

"de nincs olyan idopillanat amikor 'a' erteke elterne 'b'-tol "
Amikor tobb szal tobb magon piszkalja a memoriat, siman elofordulhat. A CPU egyik magjanak pipelinejaba bekerul egy b1 ertek, es a-nak b1 lesz az erteke.
Ezzel parhuzamosan egy masik mag a memorianak a megfelelo reszere (b helyere) egy masik adatot (b2) ir be. Debuggerben megnezed, es latod, hogy a != b lesz.
Csak akkor lesz ez tenyleg atomi muvelet ha megfelelo lockkal letiltod a memoriaba irast az ertekadas utasitas vegrehajtasa alatt a tobbi magra.

1. a kedvetekert megneztem, es az adott cucc kepes ket memoriaterulet kozott MOV-olni
2. szerintem a peldamban eleg egyertelmu volt, hogy ilyen eset nem fordulhat elo, de akkor picit reszltesebben:

van egy globalis valtozo:
int v;

van egy thread ami ebben a loop-ban van:

while(1) {
int tmp;
/* nemi beszelgetes a userrel, meg szamolgatas, tmp-ben levo erteket kell atadni a masik thread-nek */
v=tmp;
}

a masik thread meg ebben:

while(1) {
int tmp = v;
/* tmp-vel dolgozunk tovabb es a megfelelo sebesseget allitjuk elo*/
}

A kommunikacio egyiranyu. Ha v ketszer valtozik mikozben a masodik loop csak egyszer olvasta ki akkor sincs semmi. -> jo megoldas...
hol a gond?

Már hogy ne fordulhatna elő: egy a = b az két művelet: egyszer betöltünk egy értéket a memóriából egy regiszterbe, majd utána visszaírunk. Na most ha pont akkor vált az olvasó thread, mikor kiolvasta, de még nem írta vissza és míg az olvasó thread és azalatt frissíti az író thread, már van különbség. Az más kérdés, hogy egy ilyen szoftvernél ez kb. elhanyagolható időbeli késleltetés.

De amúgy ki lehet próbálni: el kell indítani ugyanazon a változón (még csak nem is kell globálisnak lennie, egy osztály helyi adattagja is simán jó erre, mert végső soron a memória egy nagy egész) is, ha elindítunk egy threaden egy i-- -t, egy másikon egy i++-t, jó eséllyel el fog mászni 0-tól.

----------------
Lvl86 Troll

Na akkor meg egyszer: csak egy szal modositja a valtozot. A tobbi szalat csak a pillanatnyi ertek erdekli. Es mit emlitettem: nincs olyan pillanat amikor nem az 'a' erteke nem az 'a' regi erteke vagy 'b' lenne. Ha a ket muvelet kozott tortenik az olvasas egy masik thread-bol, akkor egyszeruen a regi 'a'-t kapod meg. Az meg akkor is az 'a' pillanatnyi erteke.

JLS 17.7 -et ajanlom figyelmedbe azzal kapcsolatban, hogy "a primitiv tipusok kezelese atomi".

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write.

Writes and reads of volatile long and double values are always atomic.

Ami a fejemben van, de a wikipédia is elég jót ad:
"Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs."

Így folytatja:
"Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance."

Nálam az OO elválaszthatatlan része az öröklődés is, de a "mezei" definíciót véve sem OO nyelv sem a Python, sem a C++.
----
Hülye pelikán

Attól függ, hogy hogyan csinálod. Én már láttam C-t is objektumorientált stílusban programozni.

myclass.c

myclass_new()
myclass_destroy()
myclass_mymethod(myclass *, ...)
...

Bizonyos nyelvek jobban támogatják az OOP-t, mások kevésbé. C++-t lehet OOP-ben is programozni, meg máshogy is.
A C-t limitáltan lehet OOP-ben programozni, az öröklés már egy kissé gázos szituáció.

Az hogy egy nyelv OO, nem zarja ki azt hogy legyen benne lehetoseg mas paradigma szerint is kodolni. A Python az elsodlegesen OO (gyakorlatilag a nyelv osszes eleme OO alapokon van implementalva) de ugyanugy lehet benne funkcionalis es imperativ kodot is irni (bar az utobbi azert mar kicsit csikorog).

Nézd, szerintem nézd át az anyagot mégegyszer. Az imperatív egyáltalán nem illik ide, az OO nyelvek is imperatívak többnyire.
Mégegyszer: a Java az OO. A Python nem. Lásd meg a különbséget: a Java alapvetően ojjektumok kölcsönhatásaiként képzeli el a fejlesztést, a Python csak felajánlja ezt a lehetőséget.
----
Hülye pelikán

Képzeld, 2012 pont azt jelenti, hogy már nem csak C van, hanem sok-sok egyéb nyelv. Minden problémához a megfelelő eszköz. Ezek szkriptnyelvek. Ha csak összerakok gyorsan egy kis szkriptet, ami elvégez valamit amit bashben túl bonyolult lenne (vagy ha Win alatt vagyok akkor a command.com nem is képes rá), akkor hadd használjak már globális változókat. Nagyobb szkriptnél persze kerülendő, de a célterület megkívánja, hogy benne legyen a nyelvben. A szintaxis meg jó, mert felhívja rá a figyelmet.
----
Hülye pelikán

Jaj, ez a globális változóktól való félelem.

Aztán utána jön az, hogy mégiscsak el kellene érni valami - egyébként glogálisan használt - adatot és hopp máris lehet szarlapátolást csinálni hosszú-hosszú órákon keresztül, mert a singleton büdös és muszáj 3 rétegen keresztülinjektálni valami adatot.

Az egyéb speciális eseteket, mikor a használt környezet pont nem enged átadni triviális módon valami adatot, ne is soroljuk ide.

Szóval lenne annak is értelme ésszel használva.

----------------
Lvl86 Troll

"és hopp máris lehet szarlapátolást csinálni hosszú-hosszú órákon keresztül, mert a singleton büdös és muszáj 3 rétegen keresztülinjektálni valami adatot"

Mert az uj adatot mindenkeppen kulon kell vegigeroszakolni a renszeren es veletlenul sincsen olyan logikai struktura, amibe plussz mezoken belepasszol es amit mar amugy is "keresztulinjektal" a rendszer 3 retegen?

De lenne: egy globális objektum, amelyet elér minden és azon keresztül lehet az adatmodellt írni/olvasni. :)

De hogy konkretizáljam: .NET WPF, Binding esetén saját IValueConverter, aminek szüksége lett volna az adatok közül 1-2 adatra. Kb. fél napom elment rá, hogy körbenézzem, hogyan lehetne a parameter-re rábindelni valahogy - az UserControlon belül egyébként elérhető - adatokat, ahelyett, hogy egy nagy közösből menjen.

De ugyanilyen az is, amikor mondjuk egy DIC-et - ami köré van építve az egész szoftver - taszigálnak végig mindenhol csillió-billió objektumon keresztül, mikor lehetett volna szimplán globális is.

----------------
Lvl86 Troll

NA ez pont a "Poe's Law" esete, nem tudom eldönteni ironizál vagy komolyan gondolja. :)

Eleve hogy web framework-öt hasonlít össze egy programnyelvvel.

A másik meg a professzionalizmus általa hangoztatott definíciója, amikor közhelyszerűen elterjedt a szakmában az ellentétes vélekedés: kizárólag olyanokat kell alkalmazni akik maximálisan szeretik/élvezik a programozást...

Szóval gondolom ironizálni vagy kifigurázni akarja a jelenséget, csak több jelzést kéne adnia hogy tényleg ez a helyzet... Ami elbizonytalanít, hogy felmerülnek valós szempontok is (mennyi a library szintű támogatás, mennyire könnyen olvasható más kódja)