É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ó.
É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.
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.
Ezt a fenti két hozzászólást akár meg is indokolhatnátok, mert szerintem alaptalan. C++-t legjobb C nélkül tanulni, mert csak rossz szokásokat alakít ki.
----
Hülye pelikán
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
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.
Nem, C-ben néha MUSZÁJ csúnyát csinálni. Ha C++-ban akarok írni egy split függvényt, megtehetem úgy, hogy ne kellejen a usernek semmiféle memóriakezeléssel törődnie, C-ben ez lehetetlen általánosan.
----
Hülye pelikán
Sohasem elkerulhetetlen csunyat csinalni. Persze attol is fugg, mit hivsz csunyanak, en a memoriakezelest nem gondolom annak, ellenben a templateket igen.
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
A template is ugyanolyan error prone, mint a kezi memoriakezeles (amit elobb utobb C++-ban sem uszol meg, ha barmi nagyobbat irsz), cserebe meg szintaktikailag is ronda.
A template ad egy absztrakciós szintet, a memóriakezelés nem. És simán meg lehet úszni, ha valaki más írta az alacsonyabb szintű részét a programnak. Naked new-t, mutatókat kerülni ahol lehet.
----
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
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.
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
Ha tetszik a Perl, akkor kezdj azzal! Károdra nem fog válni. Később úgyis tanulsz majd mást is. Hobbi szintű tanulásnál amúgy is fontos, hogy az elején jól érezd magad azzal amit tanulsz, hogy ne menjen el a kedved tőle.
Í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.
+1, ha tuljutottal a kezdeti "sokkon", hogy a formazas hatarozza meg a blokkokat, akkor eleg szimpi nyelv, velemenyem szerint. A kotott formazas miatt legalabb nem kell sokfele kodolasi stilussal megbaratkoznod, ha mas kodjat kell olvasnod/modositanod.
Ma felmondtam.
Sajnos csak februárban volt időm állást keresni (azért nem munkát, mert az mindig van), de így sem alakult rosszul a dolog. C#-hoz és Linuxhoz kell érteni.
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.
Ahol nem számít jobban a láthatóság, mint a procedurális nyelvekben, ott nagyon egyszerű - csak minek...
Ahol meg számít, ott csak annak egyszerű, aki nagyon rálát - de annak meg minden egyszerű.
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.
Elter a velemenyunk, szerintem perl teljesen jo nyelv. Ellenben a Java mint nyelv, fostalicska (pl szerettem volna a minap unix domain socketet kezelni javabol, nem kivanom senki masnak az elmenyt :P).
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
...
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.
Az abevjava-val elégedett vagyok. Megbízható és minden gépen elmegy.
A java megoldotta. C#-ot kizárólag akkor engednék meg közbeszerzésnél, ha megy Linux, Mac és Win alatt is, emellett az állam megkapja a programforrást, amit módosíthat.
Hogy érted, a java sem standard? A nyelv az tök standard, le van írva a specifikációban, hogy minek kell benne lennie, teljesen egyértelműen. Példa esetleg?
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.
Yep. Meg ahogy kollega is emliti lentebb, AppEngine, G+ szinten Java. Twitternel is van jonehany Java vagy legalabb JVM alapu stuff (Storm, tobbek kozt, http://twitter.github.com/ -n teljes lista, jonehany Javas meg Scalas elemmel).
Őőő, használok egy Galaxy Tab 10.1-et, de az utolsó dolog ami eszembe jut az Androidról, az a "hasítás". A "lag" annál inkább (iPad1-gyel összehasonlítva).
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.
Adott rendszert adott terhelésre/rendelkezésre állásra méretezünk. Nyilván ahogy nő a
rendelkezésre állás kívánalma, úgy nő a rendszer ára is. Ilyen egyszerű az egész.
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. :)
+1 , sőt +sok. Bármilyen nyelvben lehet olvashatatlan/értelmezhetetlen kódot írni, ha valaki trehány, és ugyanígy lehet szép és beszédes kódot elkövetni, ha igényes a kóder.
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...
Olyan alkalmazásokat szeretnék írni, melyhez nem szükséges gui, de asztali programnyelv. Webes alkalmazásokat html és php párossal készítek, az rendben is van, de valami másik irányban szeretnék haladni.
> melyhez nem szükséges gui, de asztali programnyelv
Konkrétan milyen feladatokat szeretnél megoldani?
És milyen interfész érdekel: parancssor, vagy karakteres, de interaktív UI? (Egész más dolog a kettő).
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. :)
Ha ronda lett, akkor rondán írtad meg: szépen, átláthatóan kódot írni is meg kell tanulni, ennyi az egész.
Perl-ben egyébként egy TCP-s kliens pl. a Net::EasyTCP használatával nagyon szépre megírható, nem kell hozzá semmi varázslat.
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.
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. :)
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.)
Elsőre a hozzászólásod végére írt linket cython-nak olvastam. :) http://cython.org - Python --> C --> GCC --> python alá töltődő .so fájl. Aranyos gyorsítása az interpretált nyelvnek.
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
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.
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
"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
Én meg leírom a beosztottamnak, hogy milyen programot kell készíteni, az hogyan nézzen ki.
Mindezt egy Word doksiban tesztem. Nagyon magas szinten programozok, a virtuális gép a programozó,
ő fordítja ezt le a gép számára érthető nyelvre.
saxusnak is: pontosan. Itt csak az absztrakció szintjében van különbség. A html egy fokkal magasabb szintű, mint a hagyományos prognyelvek, amiket ti mondotok, azok többel. Végső soron a mosógépet meg a videófelvevőt is programozod.
----
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.
Akkor neked marhára másképp tanították a dolgokat... Anno fogtunk egy sima füzetet, egy folyamatábra-sablont, meg egy adatstruktúrák és algoritmusok témájú (tan)könyvet (Seymour Lipschutz: Adatszerkezetek), és megtanultuk az alapvető dolgokat előbb.
Ö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.
+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.
Itt tobbszaz altalanos feladat van megoldva egy csomo nyelvben, arra tokeletesen alkalmas hogy osszehasonlitsd melyik nyelv stilusa szamodra atlathatobb/eszerubb/erthetobb.
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
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.
Az, hogy te mit csinálsz Linux alatt, az konkrétan nem érdekel, először csináljanak egy normális, 2012-es desktop igényekhez tervezett grafikus alrendszert rá (X, broaf), aztán térjünk vissza a témára.
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ő.
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)
az igaz, hogy nem hordozhato, nem lattam azt a hozzaszolasod. ritka esetnek szamit, hogy win/linux/mac tamogatas is kell, de abban egyet ertek, hogy erre a java alkalmasabb.
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.
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.
"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.
Az, hogy ki hogyan hasznalja a platformot, nem mervado a platformra onmagara nezve. Kit erdekel, hogy XYZ szar telepitot csinal a javas progijahoz? Ez nem a Javat, hanem a fejlesztot minositi.
"Ha ugyanezt C++-ben csinalom, akkor az osszes platformra, ahol lefordulhat, forgathatom, ha a usereimnek binarist akarok adni."
A platform meg hagyjan, de szamit a fordito is, mivel nincs ABI.
A tömörséget én nem a whitespace hiányával tartom ekvivalensnek. Amikor Python kódot írok, akkor rosszul érzem magam, ha le kell írnom egy ciklust, és biztos vagyok benne, hogy ezt elegánsabban is meg lehetett volna oldani.
----
Hülye pelikán
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.
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 *
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
Milyen specialis celcuccokra gondolsz? A perl -pi opciojara? Vagy milyen egyeb rengetegre?
Egy nyelv egyebkent sem attol lesz eros, hogy tomor, inkabb attol, hogy sokat tud. Tudasban pedig a perl es a python nagyjabol megegyeznek, elobbihez viszont van CPAN, ami verhetetlen.
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. :)
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.
A leginkább a feladat syntax ellenőrzéshez hasonlított, csak a bemenet túl nagy volt.
(megmértem és az idő 98.25%-a memcpy-ben töltődött, azóta ablakot használok és szupergyors)
Őőőőő.... 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.
Remek, aztán az egyik beemelt lib X, a másik Y, a harmadik Z módszerrel oldja meg a threadingot (vagy akármi mást, amire nincs szabvány megoldás) és máris kész a káosz ;)
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.
Ez nem teljesen igaz. A nyelv, es a nyelv implementacioja nem ugyanaz. - pl.: ott a google dalvik vm-je, .net-en futo ikvm, vagy a blu-rayben hasznalt bd-j...
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:
Java fordítót is írhatsz Javaban, és Java futtatókörnyezetet is. Almát hasonlítasz körtével amikor C++ fordítót hasonlítasz össze JVM-mel.
C++ runtime-ot (libstdc++) tudsz írni alacsonyabb szintű runtime nélkül?
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.
+1 erősen. Sokat magyaráztam embereknek, hogy az absztrakció fontos. Ha nem muszáj, ne menjünk le, és a C ebben nem segít. Én a Javaban sem értem a new kulcsszó szerepét. Gyakorlatilag elvették egy absztrakciós réteg lehetőségét.
----
Hülye pelikán
" Én a Javaban sem értem a new kulcsszó szerepét. Gyakorlatilag elvették egy absztrakciós réteg lehetőségét."
Mi van??? Egyebkent hogy a fenebe hoznal letre egy uj objektumot?
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...
Nem az a lényeg, hogy mikor kell nyúzni, hanem hogy ha úgyis nyúzni kell, akkor akár el is hagyhatjuk, és akkor mint lentebb is írtam, kicserélhető statikus metódusra bármikor, és a kód nem fog eltörni.
----
Hülye pelikán
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
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.
Jól mondod: kevesebb az absztrakció. Ahogy néztem Javaban általában egy jó megoldása van egy feladatnak. Ezt lehet előnynek tekinteni (indiai programozók) vagy hátránynak (ha mégis egy másik megoldás lenne ideális).
----
Hülye pelikán
Hát ha érdekel, akkor mondjuk olvasd el az írásomat. Ha ki akarod cserélni alatta, kódváltoztatás nélkül megteheted. Pythonban ez működik, használják is.
----
Hülye pelikán
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...
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:
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.
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.
Apropó körülményes OOP (annyira egyébként nem is, igen, picit nagy a boilerplate egy osztályhoz, de C++-ban (pedig az meeeennnnyire OO!) se sokkal kisebb): manapság a Moose, Moo, Mo menő modulok. :)
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.
>> 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
Ez jó, köszi. Sajnos látszik belőle mennyire olvashatatlanná és feleslegesen bonyolúlttá tették Python-t v2-höz képest is - illetve szerintem az is lejön, hogy Ruby fényévekkel olvashatóbb nagyon sok helyen. Persze nem csak ez számít, de ez is fontos.
en egyre jobban szeretem a pythont, amit nagyon utalok, az az, hogy kulon meg kell mondanom, ha globalis valtozohoz nyulok, mert amugy a lokalis scope reszekent definialja.
2012 van. Mar eleve olyan programozasi nyelveket kellene hasznalnunk, ami szintaktikaban sem engedi a globalis valtozokat, de a minimum az, hogy azokban a nyelvekben amiben ez letezik, ott nem hasznaljuk.
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).
Thread-ek kozotti kommunikaciohoz pl. hasznosak a globalis valtozok. Illetve rovid programoknal celszerubb lehet valamit globalissa tenni. (pl. a fene akar egy mutex valtozora pointert atadni amikor ugyis csak egy van)
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. :)
a = b LEGALÁBB két műveletből áll, ha mindkettő memóriacím, legalábbis amikor én utóljára assemblyztem.
A másik pedig, hogy az a = 2 is lehet több művelet, platformtól függően.
----
Hülye pelikán
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.
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.
Képzelj el egy platformot, ahol ilyen-olyan okok miatt 64 bites az int a 32 bites platform C fordítóján is. Ekkor legalább két művelet lesz minden int művelet.
----
Hülye pelikán
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
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ó.
Senki nem mondta, hogy C-ben ne lehetne OOP-t programozni. Attól még a nyelv nem lesz az. Nem attól OOP a nyelv, hogy támogatja (a C egyébként nem támogatja), hanem hogy az az alap stílus, hozzáállás a nyelvben. OO pl a Java vagy a Smalltalk.
----
Hülye pelikán
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
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.
"é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.
Szerintem nem véletlenül van így: így biztos, hogy szándékosan módosítasz globális változót. Ha nem ez a fő nyelved akkor könnyű megszokásból elnézni.
----
Hülye pelikán
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)
Hozzászólások
Mihez?
Csak tanulni, egy olyan nyelvet amivel lehet asztali és/vagy webes alkalmazásokat készíteni :)
=> Ubuntu User <=
Leginkább mindet.
Nincs olyan, ami mindenre jó. Pláne a felsorolt két nyelv nem jó mindenre...
É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ó.
Jelenleg html, php, mysql az elfogadható szinten megy számomra. C, és C++ távol áll tőlem. :)
=> Ubuntu User <=
c-t azert erdemes valamilyen szinten megismerni, foleg ha jobban szeretned megerteni a unix belso vilagat
--
NetBSD - Simplicity is prerequisite for reliability
+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.
Hát nem hiszem, hogy szükségem lesz rá, számomra bonyolult is, bár régen C++-al ismerkedtem, de attól a hajam is kihullott.
=> Ubuntu User <=
C++-szal kezdeni C nélkül.... Ez elég nehéz. Talán egy nagyon jó, C-hez és C++-hoz is jól értő tanárod/haverod segítségével.
A C meg nem bonyolult. Inkább túl egyszerű, ezért kisebb problémákhoz is saját rutinokat kell írni vagy külső libeket használni.
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.
Ezt a fenti két hozzászólást akár meg is indokolhatnátok, mert szerintem alaptalan. C++-t legjobb C nélkül tanulni, mert csak rossz szokásokat alakít ki.
----
Hülye pelikán
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]
Nem, C-ben néha MUSZÁJ csúnyát csinálni. Ha C++-ban akarok írni egy split függvényt, megtehetem úgy, hogy ne kellejen a usernek semmiféle memóriakezeléssel törődnie, C-ben ez lehetetlen általánosan.
----
Hülye pelikán
azert ez attol is fugg, hogy mit hivsz csunyanak. Engem pl. nem zavar ha nekem kell kezelnem a memoriat.
Sohasem elkerulhetetlen csunyat csinalni. Persze attol is fugg, mit hivsz csunyanak, en a memoriakezelest nem gondolom annak, ellenben a templateket igen.
--
|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
A template is ugyanolyan error prone, mint a kezi memoriakezeles (amit elobb utobb C++-ban sem uszol meg, ha barmi nagyobbat irsz), cserebe meg szintaktikailag is ronda.
--
|8]
A template ad egy absztrakciós szintet, a memóriakezelés nem. És simán meg lehet úszni, ha valaki más írta az alacsonyabb szintű részét a programnak. Naked new-t, mutatókat kerülni ahol lehet.
----
Hülye pelikán
Ha valaki mas irta az alacsonyabb szintu reszet, akkor C-ben is el lehet kerulni mindenfele kozvetlen memoriakezelest.
--
|8]
Egyrészt: nem.
Másrészt: a mutatókat még akkor sem, ha igaz lenne, amit mondasz.
----
Hülye pelikán
Szerintem hanyagoljuk a vitat, mert nem latsz tovabb a szemellenzodnel. Elottem itt a kod, ami alapjan irtam, amit irtam.
--
|8]
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
Python, Javascript a javaslatom.
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.
Azok nem valami egyszerűek :/
=> Ubuntu User <=
Ha egyszerűre vágysz, akkor javaslom a Whitespace, vagy a Brainfuck nyelvet. :)
Python + tk? Ez tényleg faék.
http://www.pythonware.com/library/tkinter/introduction/
Pythonnal próbálkoztam de valahogy nem jön be. A perl az tetszik, Rubyt meg nem ismerem :D
=> Ubuntu User <=
Ha tetszik a Perl, akkor kezdj azzal! Károdra nem fog válni. Később úgyis tanulsz majd mást is. Hobbi szintű tanulásnál amúgy is fontos, hogy az elején jól érezd magad azzal amit tanulsz, hogy ne menjen el a kedved tőle.
python csak eleinte furcsa, de én mondjuk most ismerkedem a 3.2-vel és ez már egészen szimpatikus.
Egészen addig, amíg nem lesz hányingered a formázási ökörségétől...
/o\
Már én is kezdem elviselni egyébként, de ha gyorsan kell valami "egyszer használatos" dolgot csinálni, akkor azért inkább elkerülöm.
Szerintem pont ez a nagyszeru benne. Latnad a ceges C coding style policy-nket... Pythonban legalabb nem birnak nagyon elqrni.
Í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.
→ olyan editort kell használni, ami érti a modeline-t.
+1, ha tuljutottal a kezdeti "sokkon", hogy a formazas hatarozza meg a blokkokat, akkor eleg szimpi nyelv, velemenyem szerint. A kotott formazas miatt legalabb nem kell sokfele kodolasi stilussal megbaratkoznod, ha mas kodjat kell olvasnod/modositanod.
A mostani projektemen használom a Rubyt.
De januárban nekiállok új munkahelyet keresni. A Ruby válóok.
Fuszenecker_Róbert
Ma felmondtam.
Sajnos csak februárban volt időm állást keresni (azért nem munkát, mert az mindig van), de így sem alakult rosszul a dolog. C#-hoz és Linuxhoz kell érteni.
Fuszenecker_Róbert
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.
~"idő kellett az oop szemlélet megszokásához."
Elhiszem :)
=> Ubuntu User <=
Hint: gtk2-perl :-)
java eleg egyszeru nyelv pedig
--
NetBSD - Simplicity is prerequisite for reliability
"java eleg egyszeru nyelv pedig"
Ahol nem számít jobban a láthatóság, mint a procedurális nyelvekben, ott nagyon egyszerű - csak minek...
Ahol meg számít, ott csak annak egyszerű, aki nagyon rálát - de annak meg minden egyszerű.
+1
Kérdés: alma, vagy körte? Válasz: lekváros kenyér. A lekváros kenyér az alma, vagy körte?
pizza!
Java2k esetleg Malbolge, persze csak nagyon elszantaknak :]
javascript node.js
OpenBSD 5.0/i386 theo for the prezident:D
+1
--
[laca@arch ~]$ %blow
bash: fg: %blow: no such job
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.
OMG :)
a perl az igazan a write once, read never nyelv.
Csak akkor ha nem tudsz olvasni ;)
--
|8], aki a miheztartas vegett megprobalta megerteni a ~12 evvel ezelott irt perl kodjat, es megertette. (Pedig ritka szar kod volt az)
irhatnam azt is, hogy egy fostalicska. most jobb?
ha grafikus felulet kell: C# + WPF
ha rendszerkozeli cucc (kernel/driver/etc): C
minden masra ott a Java ;)
Elter a velemenyunk, szerintem perl teljesen jo nyelv. Ellenben a Java mint nyelv, fostalicska (pl szerettem volna a minap unix domain socketet kezelni javabol, nem kivanom senki masnak az elmenyt :P).
--
|8]
:-)
http://dl.dropbox.com/u/16568958/picard-fail_499x327.jpg
Többször kértem, hogy kommentbe ne illesszünk be képek képként.
--
trey @ gépház
Gopher rulez :-) Kérem a hsz. törlését. Egyébként én csak most futottam bel először a "nerakjálbeképetmertalynxemmelnemmegy" problémádba.
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.
nem szempont a binugz kompatibilitas ;)
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 abevjava-val elégedett vagyok. Megbízható és minden gépen elmegy.
A java megoldotta. C#-ot kizárólag akkor engednék meg közbeszerzésnél, ha megy Linux, Mac és Win alatt is, emellett az állam megkapja a programforrást, amit módosíthat.
Hogy érted, a java sem standard? A nyelv az tök standard, le van írva a specifikációban, hogy minek kell benne lennie, teljesen egyértelműen. Példa esetleg?
Nincs nemzetkozi szabvanyugyi szervezet, amely a Java-t specifikalna, valamint egy ceg tulajdona a Java markanev.
nem szempont a binugz kompatibilitas ;)
Naja, de Solarison se megy ;)
Ha már binugz, akkor inkább slowaris, nem? :-D
"minden masra ott a Java ;)"
Felteve, hogy nincs szukseged se teljesitmenyre, se rendelkezesreallasra. :)
--
"You're NOT paranoid, we really are out to get you!"
Szerintem ezzel sokan nem ertenenek egyet. Lasd pl a Google-t, akik igen aktivan hasznalnak javat. Vagy a twittert, csak hogy kettot mondjak.
--
|8]
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.
Nem csak az Androidrol van szo. Ott a Google App Engine peldaul. Vagy a Google+: http://highscalability.com/blog/2011/7/12/google-is-built-using-tools-y…
Yep. Meg ahogy kollega is emliti lentebb, AppEngine, G+ szinten Java. Twitternel is van jonehany Java vagy legalabb JVM alapu stuff (Storm, tobbek kozt, http://twitter.github.com/ -n teljes lista, jonehany Javas meg Scalas elemmel).
A JVM durvan jo cucc.
--
|8]
Őőő, használok egy Galaxy Tab 10.1-et, de az utolsó dolog ami eszembe jut az Androidról, az a "hasítás". A "lag" annál inkább (iPad1-gyel összehasonlítva).
ezen csak nevetni tudok, sajnalom :) foleg a rendelkezesreallas dolgon:)
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.
+1. Tetszőleges nyelven lehet szar kódot írni, az ellen nem véd.
>De egye fene, mutass nekem barmit, amit javaban irtak, es ra mernek mondani 9 9-es rendelkezesre >allast. :)
ez a hw-en szokott megbukni, nem a sw-en.
"ez a hw-en szokott megbukni, nem a sw-en."
Ja, ugy 5 9-ig.
--
"You're NOT paranoid, we really are out to get you!"
Feladat, környezet, terhelés? Hogy definiálod az x 9-es rendelkezésre állást, milyen körülmények között?
Tetszőleges sw-t meg lehet borítani, ez független a nyelvtől.
"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!"
"Ez a szornyu, hogy nem volt "rossz" egyik sem."
Akkor mivel volt a baj?
"Nem "ha kedvuk van", hanem "ha kemenyen utik oket". De teny, igy sem szep toluk."
Es ugyanez C++ban nem rohad le?
+1
Gmail backendje pl Java. G+ detto. Egesz jo rendelkezesre allassal rendelkezik mindketto.
Twitternel is igen sok dologra hasznaljak ha nem is a Javat, de a JVM-et (Storm pl, meg egy rakas Scala cuccuk is van).
--
|8]
"Egesz jo rendelkezesre allassal rendelkezik mindketto."
A gmail rendelkezesreallasa egyaltalan nem "egesz jo". Ha mondjuk a 112-es segelyhivo allna ennyit, mar lenne par halottunk.
--
"You're NOT paranoid, we really are out to get you!"
En Google Apps-on levelezek. Nem emlekszem, hogy egyszer is allt volna. (Nem azt mondom, hogy nem volt doglott, de most nem ugrik be egy eset sem.)
+1
--
|8]
Adott rendszert adott terhelésre/rendelkezésre állásra méretezünk. Nyilván ahogy nő a
rendelkezésre állás kívánalma, úgy nő a rendszer ára is. Ilyen egyszerű az egész.
+1
Hulladek megoldast barmiben ossze lehet rakni. Az ellen a nyelv nem ved.
Ja Arra pluszoltam hogy nevetseges az az allitas h a java=rossz rendelkezesre allas.
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
+1 :P
--
NetBSD - Simplicity is prerequisite for reliability
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. :)
+1 , sőt +sok. Bármilyen nyelvben lehet olvashatatlan/értelmezhetetlen kódot írni, ha valaki trehány, és ugyanígy lehet szép és beszédes kódot elkövetni, ha igényes a kóder.
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...
Olyan alkalmazásokat szeretnék írni, melyhez nem szükséges gui, de asztali programnyelv. Webes alkalmazásokat html és php párossal készítek, az rendben is van, de valami másik irányban szeretnék haladni.
=> Ubuntu User <=
> melyhez nem szükséges gui, de asztali programnyelv
Konkrétan milyen feladatokat szeretnél megoldani?
És milyen interfész érdekel: parancssor, vagy karakteres, de interaktív UI? (Egész más dolog a kettő).
Nem baj az sem, ha parancssoros, sőt... :)
=> Ubuntu User <=
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. :)
Ha ronda lett, akkor rondán írtad meg: szépen, átláthatóan kódot írni is meg kell tanulni, ennyi az egész.
Perl-ben egyébként egy TCP-s kliens pl. a Net::EasyTCP használatával nagyon szépre megírható, nem kell hozzá semmi varázslat.
$trim =~ s/^\s+|\s+$//;
:)
Kovettem a tutorialokat, amiket talaltam. :)
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
Nekem a "Python" + "mindenre van kész libről" mindig a KDE Printer Applet jut eszembe...
----------------
Lvl86 Troll
Nekem meg az, hogy hivatalosan supportalt MySQL connector nincs hozza, csak 3rd party cuccok.
Egyszer talán lesz az is: http://geert.vanderkelen.org/post/817/
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.
Értem :)
=> Ubuntu User <=
Ez esetben fölösleges új nyelvet tanulnod, a PHP CLI tökéletesen megteszi.
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.
Asztali és/vagy webes alkalmazások készítésére valóban a legalkalmasabb...
Hol lácc te itt "Asztali és/vagy webes alkalmazások" címü kritériumot?
--
GPLv3-as hozzászólás.
Nézd meg 2. hozzászólást.
http://hup.hu/node/109311#comment-1381315
A parentben nem volt meg ez a kiírás. A threadet meg nem olvastam végig. :P
--
GPLv3-as hozzászólás.
/o\
--
NetBSD - Simplicity is prerequisite for reliability
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]
erlang :p
--
cythoon
Elsőre a hozzászólásod végére írt linket cython-nak olvastam. :)
http://cython.org - Python --> C --> GCC --> python alá töltődő .so fájl. Aranyos gyorsítása az interpretált nyelvnek.
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
Akkot terjunk vissza egy pillanatra ide:
"Jelenleg ismerem a következő[ programozasi nyelve]ket: HTML, PHP, MySQL, kicsi Bash"
----------------
Lvl86 Troll
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 HTML és az SQL nem programozási nyelv. Az egyik egy leíró, másik egy lekérdező nyelv.
A szögletes zárójeles megjegyzés annak tisztázására került, ha esetleg nem lenne egyértelmű.
----------------
Lvl86 Troll
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
Én meg leírom a beosztottamnak, hogy milyen programot kell készíteni, az hogyan nézzen ki.
Mindezt egy Word doksiban tesztem. Nagyon magas szinten programozok, a virtuális gép a programozó,
ő fordítja ezt le a gép számára érthető nyelvre.
---
http://szit.hu
saxusnak is: pontosan. Itt csak az absztrakció szintjében van különbség. A html egy fokkal magasabb szintű, mint a hagyományos prognyelvek, amiket ti mondotok, azok többel. Végső soron a mosógépet meg a videófelvevőt is programozod.
----
Hülye pelikán
Ezzel az erővel ez a hozzászólás is egy programozási nyelv, mert megmondja, hogy mi kerüljön a képernyődre...
----------------
Lvl86 Troll
HTML: Hyper Text Markup Language.
http://en.wikipedia.org/wiki/Markup_language :
"...markup languages, and more generally data description languages (not necessarily textual markup), are not programming languages ... "
Más kérdés?
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.
A HTML onmagaban nem Turing teljes, de HTML5+CSS3 mar igen: http://lambda-the-ultimate.org/node/4222
Szivesen.
--
|8]
subs
cserébe nem értem a html5 hype-ot – ugyanez a stylesheet valószínűleg működne html4-gyel is. :-)
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.
Akkor neked marhára másképp tanították a dolgokat... Anno fogtunk egy sima füzetet, egy folyamatábra-sablont, meg egy adatstruktúrák és algoritmusok témájú (tan)könyvet (Seymour Lipschutz: Adatszerkezetek), és megtanultuk az alapvető dolgokat előbb.
Ö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.
sub
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)
Nezd meg ezt: http://rosettacode.org/wiki/Rosetta_Code
Itt tobbszaz altalanos feladat van megoldva egy csomo nyelvben, arra tokeletesen alkalmas hogy osszehasonlitsd melyik nyelv stilusa szamodra atlathatobb/eszerubb/erthetobb.
Ez egy kiváló oldal!
2-3-4 nyelvre konctentráló sok van, de ezt még nem láttam.
Köszönet!
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
"C++ - GUI programokat írni legjobb (esetleg ehhez wxWidgets)"
Szvsz GUI-ra simán C# vagy Java.
----------------
Lvl86 Troll
+1
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.
Az, hogy te mit csinálsz Linux alatt, az konkrétan nem érdekel, először csináljanak egy normális, 2012-es desktop igényekhez tervezett grafikus alrendszert rá (X, broaf), aztán térjünk vissza a témára.
----------------
Lvl86 Troll
wpf.
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.
Szerencsere a 'keresztplatformossag' az esetek 99%-aban nem kovetelmeny.
----------------------
while (!sleep) sheep++;
Sajnos. Én a kormányzat helyében mindenegyes állam által finanszírozott projektnél megkövetelném.
Ha a kormányok eleve kizárnák a C#-ot eme problémák miatt, valószínűleg a Microsoft is lépne.
Kormanyzati kornyezetben, uj projektek eseten nehezen tudom elkepzelni, hogy miert ne webes klienset koveteljenek meg.
Szerver oldalon meg amugy is sok mindenre mar javat hasznalnak.
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)
az igaz, hogy nem hordozhato, nem lattam azt a hozzaszolasod. ritka esetnek szamit, hogy win/linux/mac tamogatas is kell, de abban egyet ertek, hogy erre a java alkalmasabb.
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.
Az, hogy ki hogyan hasznalja a platformot, nem mervado a platformra onmagara nezve. Kit erdekel, hogy XYZ szar telepitot csinal a javas progijahoz? Ez nem a Javat, hanem a fejlesztot minositi.
"Ha ugyanezt C++-ben csinalom, akkor az osszes platformra, ahol lefordulhat, forgathatom, ha a usereimnek binarist akarok adni."
A platform meg hagyjan, de szamit a fordito is, mivel nincs ABI.
A tömörséget én nem a whitespace hiányával tartom ekvivalensnek. Amikor Python kódot írok, akkor rosszul érzem magam, ha le kell írnom egy ciklust, és biztos vagyok benne, hogy ezt elegánsabban is meg lehetett volna oldani.
----
Hülye pelikán
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]
Biztos?
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
Milyen specialis celcuccokra gondolsz? A perl -pi opciojara? Vagy milyen egyeb rengetegre?
Egy nyelv egyebkent sem attol lesz eros, hogy tomor, inkabb attol, hogy sokat tud. Tudasban pedig a perl es a python nagyjabol megegyeznek, elobbihez viszont van CPAN, ami verhetetlen.
--
|8]
Olyanokra gondolok, hogy nyelvi szintre van emelve a regexp kezelés.
A sokat tud pedig értelmetlen. Ezek a nyelvek Turing-teljesek, tehát MINDENT tudnak. A kérdés az, hogy tudod kifejezni amit akarsz.
----
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]
A Python a whitespace-szel rokon, a Perl meg igaz, ami igaz, néha brainfck :-D
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.
Ha tudod, hogy akkora adathalmazt szeretnél vele kezelni, akkor csináld másképp, bár 25 millibájt (van a bájtnak tört része is?) nem sok :-D
A bit tuti tört része, és a nibble is.
Tudom, de az 10-3 bájt azért érdekesen néz ki :-D
Nem is tudtam, hogy a nyelvművelés ennyire érdekel titeket.
Mármint, hogy az mbyte-MByte közti különbségekből micsoda tudományos értekezés alakult.
:)
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.
A leginkább a feladat syntax ellenőrzéshez hasonlított, csak a bemenet túl nagy volt.
(megmértem és az idő 98.25%-a memcpy-ben töltődött, azóta ablakot használok és szupergyors)
Őőőőő.... 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.
> Perl alatt egy kis-nagybetűs összehasonlítás is regex-szel megy
Hol látod te ebből, hogy "csak regexppel megy"?
Regexp-pel szokták az esetek zömében megoldani.
die "sucks" if $var !~ /^hofekerke$/i;
Ez a tipikus mód.
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.
+1
"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
Miért kéne az alap C eszközeivel dolgoznom?
----
Hülye pelikán
Remek, aztán az egyik beemelt lib X, a másik Y, a harmadik Z módszerrel oldja meg a threadingot (vagy akármi mást, amire nincs szabvány megoldás) és máris kész a káosz ;)
----------------
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.
es a malloc is ugyanilyan hordozhato lesz? ;)
Nem ártana a kavinton, kedves NagyZ, öregszel. A mondatodnak helyesen így kellett volna elhangzani:
es a realloc is ugyanilyen hordozhato lesz? ;)
mea culpa, mea maxima culpa! :)
malloc? Használj láncolt listát!
----------------
Lvl86 Troll
Qt-vel is csak ott tartunk, hogy alapból szívás, de maszatolhatunk. Kérdés továbbra is adott: mivan, ha valami nem Qt-s cucc kell?
----------------
Lvl86 Troll
Mi van ha nem Java-s cucc kell?
Mi van ha nem digitalis cucc kell?
Mi van ha csak teheneink vannak?
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.
Ez nem teljesen igaz. A nyelv, es a nyelv implementacioja nem ugyanaz. - pl.: ott a google dalvik vm-je, .net-en futo ikvm, vagy a blu-rayben hasznalt bd-j...
Tok mindegy. Mindenkeppen kell hozza futtatokornyezet amit nem tudsz megirni Java-ban.
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;
}
Java fordítót is írhatsz Javaban, és Java futtatókörnyezetet is. Almát hasonlítasz körtével amikor C++ fordítót hasonlítasz össze JVM-mel.
C++ runtime-ot (libstdc++) tudsz írni alacsonyabb szintű runtime nélkül?
De.
--
|8]
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.
+1 erősen. Sokat magyaráztam embereknek, hogy az absztrakció fontos. Ha nem muszáj, ne menjünk le, és a C ebben nem segít. Én a Javaban sem értem a new kulcsszó szerepét. Gyakorlatilag elvették egy absztrakciós réteg lehetőségét.
----
Hülye pelikán
" Én a Javaban sem értem a new kulcsszó szerepét. Gyakorlatilag elvették egy absztrakciós réteg lehetőségét."
Mi van??? Egyebkent hogy a fenebe hoznal letre egy uj objektumot?
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...
Nem az a lényeg, hogy mikor kell nyúzni, hanem hogy ha úgyis nyúzni kell, akkor akár el is hagyhatjuk, és akkor mint lentebb is írtam, kicserélhető statikus metódusra bármikor, és a kód nem fog eltörni.
----
Hülye pelikán
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
----------------
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
Érdekelne, hogy mi a gyakorlati haszna, hogy elmaszatoljuk, hogy hol van függvényhívás és hol van példányosítás.
----------------
Lvl86 Troll
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.
Jól mondod: kevesebb az absztrakció. Ahogy néztem Javaban általában egy jó megoldása van egy feladatnak. Ezt lehet előnynek tekinteni (indiai programozók) vagy hátránynak (ha mégis egy másik megoldás lenne ideális).
----
Hülye pelikán
Adott feladatra, ha magas absztrakciós szinten nézzük, szerencsés esetben rá lehet húzni egy pattern-t. Hány factory pattern-t ismerünk?
Hát ha érdekel, akkor mondjuk olvasd el az írásomat. Ha ki akarod cserélni alatta, kódváltoztatás nélkül megteheted. Pythonban ez működik, használják is.
----
Hülye pelikán
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.
Apropó körülményes OOP (annyira egyébként nem is, igen, picit nagy a boilerplate egy osztályhoz, de C++-ban (pedig az meeeennnnyire OO!) se sokkal kisebb): manapság a Moose, Moo, Mo menő modulok. :)
Most meg fogsz lepődni, de a C++ nem OO.
----
Hülye pelikán
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.
Bizonyos hamis állítások szerint a Világmindenséget is abban programozták. :)
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... ;)
>> Röviden: Ne utasításként hanem definícióként olvasd, és mindjárt deklaratív lesz... ;)
Így fogom!
Köszönöm, hogy újat tanulhattam.
G.
============================================
"Share what you know. Learn what you don't."
Igaz, igaz, csak a funkcionálist kellett volna írnom.
Ó, 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
Perl !!!!!11111one
~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE
Ez meg egy jo kis osszehasonlitas lehet.
http://hyperpolyglot.org/scripting
Ez jó, köszi. Sajnos látszik belőle mennyire olvashatatlanná és feleslegesen bonyolúlttá tették Python-t v2-höz képest is - illetve szerintem az is lejön, hogy Ruby fényévekkel olvashatóbb nagyon sok helyen. Persze nem csak ez számít, de ez is fontos.
en egyre jobban szeretem a pythont, amit nagyon utalok, az az, hogy kulon meg kell mondanom, ha globalis valtozohoz nyulok, mert amugy a lokalis scope reszekent definialja.
Ez Ruby-nál annyi, hogy ha dollár jellel kezdődik a változó neve, akkor globális és minden függvényből, bárhonnét elérhető egyéb definíció nélkül.
2012 van. Mar eleve olyan programozasi nyelveket kellene hasznalnunk, ami szintaktikaban sem engedi a globalis valtozokat, de a minimum az, hogy azokban a nyelvekben amiben ez letezik, ott nem hasznaljuk.
A szkriptnyelvek mások, mint a fordítóval működő nyelvek.
Ha a bashban az "export" betiltásáért küzdenél, hát igencsak komoly frászokat kapnál itt a fórumon, tegyük hozzá jogosan is.
Vannak nyelvek, ahol a globális változók használata jogos.
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.
A Python annyira OO mint a C++ (és a C++ nem OO). Mindkettő támogatja az OO-t. A Python max object based.
----
Hülye pelikán
A bash-nél azért objektumorientáltabb. A globális változók témájához szóltam, így érdemes olvasni.
Az OO-nak nincs osszefuggese a globalis valtozokkal. Proceduralis nyelvben is lehet globalis valtozok nelkul programozni.
Lehet, csak bizonyos méret és komplexitás alatt nem érdemes. Mindig ésszerűen kell dolgozni, nem vakon követni ezeket az elveket.
----
Hülye pelikán
Amig kicsi lehet igenytelen?
Es ha megno mi az a pont, ahol at kell irni az egeszet, mert mostmar nem kicsi?
É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).
Thread-ek kozotti kommunikaciohoz pl. hasznosak a globalis valtozok. Illetve rovid programoknal celszerubb lehet valamit globalissa tenni. (pl. a fene akar egy mutex valtozora pointert atadni amikor ugyis csak egy van)
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...
Ez speciel pont az a terület, ahol nem biztos, hogy a globális változó a legtutibb ;)
----------------
Lvl86 Troll
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. :)
Egyáltalán nem garantált, hogy az int értékadás atomi művelet.
----
Hülye pelikán
Hogy tudna egy a=b hibazni? (mind a ketto int)
(raadasul az adott cuccon TUDOM, hogy egy muveletbol allt)
a = b LEGALÁBB két műveletből áll, ha mindkettő memóriacím, legalábbis amikor én utóljára assemblyztem.
A másik pedig, hogy az a = 2 is lehet több művelet, platformtól függően.
----
Hülye pelikán
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.
Képzelj el egy platformot, ahol ilyen-olyan okok miatt 64 bites az int a 32 bites platform C fordítóján is. Ekkor legalább két művelet lesz minden int művelet.
----
Hülye pelikán
Ilyen platformon NEM fogok ilyen kodot irni ;)
JLS 17.7 -et ajanlom figyelmedbe azzal kapcsolatban, hogy "a primitiv tipusok kezelese atomi".
Megkerdezhetem hogy az OO-nak melyik definiciojat hasznaltad?
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ó.
Senki nem mondta, hogy C-ben ne lehetne OOP-t programozni. Attól még a nyelv nem lesz az. Nem attól OOP a nyelv, hogy támogatja (a C egyébként nem támogatja), hanem hogy az az alap stílus, hozzáállás a nyelvben. OO pl a Java vagy a Smalltalk.
----
Hülye pelikán
A fejedben levo definiciohoz nem tudok hozzaszolni, de a wikipedia szerinti definicio alapjan a Python az OO.
Nem. Vígan tudok procedurális kódot írni Pythonban, nem az ojjektumok interakciója a lényeg (lehet úgy is).
----
Hülye pelikán
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
Szerintem nem ismered a Pythont. Mi az a Javaban megvalosithato pattern, amit nem lehet Pythonban OO alapokon megvalositani?
Mit is mondtál ezzel? Hogy a Python teljesen támogatja az OO-t. Ezt nem is vitattam soha.
----
Hülye pelikán
Erdekelne, hogy szerinted melyik nyelv OO, es a C++/Python miert nem az?
Akkor olvasd vissza a szálat.
----
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
Ez most globalizáció ellenes feltüntetés, :))
Szerintem nem véletlenül van így: így biztos, hogy szándékosan módosítasz globális változót. Ha nem ez a fő nyelved akkor könnyű megszokásból elnézni.
----
Hülye pelikán
En a comenius logot javasolnam!
Hátha logo, akkor inkább UCB Logo. :)
apt-get install ucblogo
---
http://szit.hu
Talaltam (veletlenul) masik osszehasonlitast is. :)
http://www.youtube.com/watch?v=mBmzFYSjfdE
Van meg mas nyelvek kozott is osszehasonlitas lejjebb.
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)