HOVD 2012 - Kedvenc kommunikációs program, audiólejátszó, BSD rendszer, böngésző, programnyelv jelöltek

HUP

Mostantól 24 órán keresztül lehet módosítási kérelmeket (ez még nem a szavazás) küldeni a címben említett kategóriák jelöltjeire, amelyek a következők:

Kedvenc kommunikációs program:

  • amsn
  • bitlbee
  • emesene
  • empathy
  • irssi
  • kopete
  • pidgin, adium
  • skype
  • windows live messenger
  • xchat

Kedvenc audiólejátszó:

  • amarok
  • audacious
  • banshee
  • clementine
  • console-os lejátszók (mpg321, mpg123, mplayer, ffplay stb.)
  • deadbeef
  • exaile
  • itunes
  • rhythmbox
  • xmms/xmms2

Kedvenc BSD rendszer:

  • dragonfly bsd
  • freebsd
  • freenas
  • freesbie
  • frenzy
  • ghostbsd
  • netbsd
  • openbsd
  • pc-bsd
  • pfsense

Kedvenc böngésző:

  • arora, midori, rekonq, uzbl
  • epiphany
  • google chrome, chromium és leszármazottaik
  • internet explorer
  • konqueror
  • links, lynx, elinks, w3m
  • mozilla firefox, swiftfox, iceweasel, icecat
  • mozilla suite, seamonkey, iceape
  • opera
  • safari

Kedvenc programnyelv:

  • c
  • c#
  • c++
  • haskell, erlang, caml, ... (funkcionális nyelvek)
  • java
  • perl
  • php
  • python
  • ruby
  • scala

A módosítási kérésekre ugyanazok a szabályok vonatkoznak, mint a kategória szavazásra!

Példa:

Ha az amsn helyett izébigyó-t szeretnél, akkor:

- amsn
+ izébigyó

Ha az amarok helyett foobar-t, akkor:

- amarok
+ foobar

és így tovább.

Ahol "?" van, ott értelemszerűen lehet javasolni jelöltet az üres helyre.

( trey | 2012. 12. 01., szo – 16:58 )

"kedvenc kommunikációs program" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

( trey | 2012. 12. 01., szo – 17:00 )

"kedvenc audiólejátszó" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

Nem érzem úgy, hogy a moc konzolos lenne. Ugyanis van UI-ja, még ha csak ncurses is. Az én felfogásom szerint az "konzolos" lejátszó, aminek kizárólag parancssoros kezelhetősége van. Szerintem a moc igenis megérdemel egy teljesen külön "kategóriát", úgy értem szavazási lehetőséget (menüpontot a szavazásban).
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Lehet hogy téged nem érdekel az én felfogásom, de engem legalább anmnyira hidegen hagy a te felfogásod. Mi az, hogy konzolosnak "számít"?! Ki definiálja azt, hogy mi konzolos és mi nem, ki határozza meg ennek a szempontjait? És ha ez valahol le is van írva, ki/mi tilthatja meg nekem, hogy másképp definiáljam a "konzolos" szót?! Számomra igenis az a konzolos program, aminek egyáltalán semmiféle UI-ja sincs, csak és kizárólag parancssorral paraméterezhető/vezérelhető. Ez szerintem egy egészen egyértelmű, félreértésektől mentes, korrekt, könnyen használható definíció. Már amiatt is, mert a legtöbb usernek arról a szóról hogy "konzol", rögvest a parancssor ugrik be. A moc nem felel meg ennek a definíciónak mert van UI-ja, azaz nem konzolos.

Persze neked is, másnak is jogod/joga van más definíciót adni a "konzolos" fogalomra, de attól az enyém még tökéletesen korrekt és érvényes marad. Igen, lehet úgy is definiálni, hogy az konzolos, amihez nem kell mondjuk xorg. De ez a definíció szerintem nem olyan jó mint amit korábban adtam, mert ergonómiailag tökmindegy hogy az UI grafikus felületű-e vagy sem, a lényeg hogy mennyire könnnyen kezelhető, milyen szolgáltatásgazdag. E szempontból a határ nyilvánvalóan ott húzódik, hogy egyáltalán van-e bármiféle UI is, vagy egyáltalán nincs.
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Az informatikára különösen jellemző, hogy bizonyos szabványok (ide értve akár a szakkifejezéseket, fájlformátumokat, kommunikációs protokollokat, stb.) de facto kerülnek elfogadásra és széles körben alkalmazásra. Bár használatuk nem kötelező, mégis illik ezeket követni, mert a világ többi része is ezt teszi, ezért ekkor van a legnagyobb esély az interoperabilitásra. Persze lehet próbálkozni új de facto szabvány kialakítására, ám ehhez megfelelő piaci részesedés kell az adott területen, és te sajnos nem vagy ebben a helyzetben. Arról már nem is szólva, hogy az ilyen magánakciók sokszor igen rosszul sülnek el, gondolj pl. a korábbi IE verziók egyedi HTML értelmezésére. (Igen, a szakkifejezésekről alkotott egyedi elképzeléseidet az Internet Explorerhez hasonlítottam.)

Sajnos amit írtál, teljesen mellékes és lényegtelen abból a szempontból, hogy egyetlen árva légypiszoknyi érvet sem hoztál fel, mellyel indokolhattad volna, hogy ugyan miért lenne az én "konzolos"-értelmezésem rosszabb mint bármi más. Sőt még csak azt az állításomat sem tudtad cáfolni, hogy az én értelmezésem messzemenően logikusabb. De ez még semmi, mert azt sem támasztottad alá semmivel, hogy lenne bármiféle értelemben is szabványa, akár csak "pszeudo-szabványa" a "konzolos" szó jelentésének. Még itt e topikban is található olyan hozzászólás az enyémen kívül, úgy emlékszem, ami inkább az én értelmezésemet támogatja, azaz az sem igaz hogy ez "de facto" szabvány volna s hogy ez magánakció a részemről, s pusztán egyéni értelmezés volna a részemről.

-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

A konzolosnak rem egyszeru a definicioja, maga a szo elmondja neked: minden ami konzolon fut. Az ncurses konzolon fut. Amihez pl. X kell, az nem fut konzolon, legalabbis onerejebol nem. Konzolos peldaul az irssi, a mutt, az mc - es a moc is.

Persze ettol neked jogod van mas definiciot adni a "konzolos" fogalomra, ettol maganak a szonak a jelentese, foleg a technologiai jelentese vajmi keveset valtozik. Ami valtozik, az az, hogy _te_ mire tekintesz konzoloskent.

Ez kicsit olyan dolog, mintha a "kilenclyuku" hidrol beszelgetnenk, hogy dehat azok nem is lyukak, hanem boltivek, es maga a hid amugy meg nem is lyukas. Ettol ennek meg ez marad a neve, akarmennyire is ugy erzed, hogy nem pontos, vagy nem fedi teljesen a valosagot. Mert masnak meg azok csak lyukak.

Nagyon remelem, hogy nem sertelek meg, de ebben az esetben sajnos ordit, hogy nincs igazad. Most okosabb lenne engedni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Definíció szerint az UI felhasználói felületet jelent, azaz az a felület, amely kommunikál a felhasználóval. Ebbe beletartozik a parancssorostól kezdve a grafikus felületig minden, ami a felhasználóval kommunikál.

A GUI grafikus felhasználói felületet jelent, ergo a kommunikáció egy grafika megjelenítésére alkalmas megjelenítési formát használ, azaz pixelekből rajzol ki mindent.

A karakteres felület (amit te konzolosnak hívsz) csak karaktereket használ a megjelenítésre, maga a VGA kártyába is csak ezek kerülnek átadásra (attól most tekintsünk el, hogy ez manapság valamilyen virtuális dolgon kerül megjelenítésre, legyen az framebuffer vagy egy X11-en keresztüli terminál), csak ezeket tudja felhasználni a megjelenítésre.

Persze, régen itt is trükköztek rengeteget és van néhány alap karakter, amely keretek és egyéb apró szimbólumok, amivel lehet trükközni.* Az ncurses is ilyen trükk, a felületeit csak karakterekből rakja össze egy karakteres felületen. Innen kezdve definíció szerint a "konzolos" programokhoz tartozik, mégha neked ellenkezik azzal a mércéddel, hogy ami CLI az menő, minden más nem menő.

(Egyébként ezeknek a karaktereknek a képének felüldefiniálásával egyesek régen egész meglepő dolgokat hoztak ki, mikor még közvetlen lehetett túrni a VGA-t, pl. DOS alatt.)

Szóval ezeket az informatika _szakma_ definiálta így, az, hogy neked nem tetszik, az mindenkit hidegen hagy. Ez olyan, mintha odaállnál egy villanyvadász elé, hogy akkor holnaptól változtassuk meg a feszültség vagy az áram fogalmát.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ismerem a moc-ot, egy időben használtam is.
Értelmezésem szerint a konzolos lejátszó az az, amely futásához nem szükséges x(org). Amire gondolsz, én arra azt mondanám, hogy "parancssoros".
Szerintem hogy a káposzta is, meg a kecske is, meg a róka is megmaradjon, ki lehetne bővíteni a konzolos listát a moc-cal (ha már a nevében is benne van a "console" szó, akkor csak oda illik :) ).

+1 a moc szerepeltetesere. Ha mar ilyen nepszeru lejatszo, hatha ettol a konzolosok tobb szavazatot kapnak :-) En nekik is szurkolok, mert az mpg123 az nekem is rajta van a "kedvelem" listamon, bar en rhythmbox-szavazo vagyok (vessetek mokusok koze).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( trey | 2012. 12. 01., szo – 17:01 )

"kedvenc BSD rendszer" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

( trey | 2012. 12. 01., szo – 17:01 )

"kedvenc böngésző" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

Akkor módosítok: a luakit-tel sikerült jól böngésznem, minden külső program nélkül. Pont ugyanúgy működött, mint pl. a chromium, firefox, opera, stb. (egy kicsit más billentyűkombókkal), mindenféle hekkelés, beállítás és hasonló nélkül. A wget ezért nem jó példa, mert (csak) azzal nem tudsz böngészni, csak mindenféle tartalmat tudsz a gépedre fájl formájában letölteni, amivel aztán azt csinálsz, amit akarsz (illetve amit tudsz :) ).

Az, hogy jobban lehet bővíteni, testreszabni, a böngészés "élményéből" szerintem semmit nem von le. Szóval nem értek egyet azzal, hogy nem kerülhet be azért, mert "framework" - bár szavazni nem arra fogok.

Szerk.: egy építő javaslat: "arora, midori, rekonq, uzbl"-vonalba, mivel az uzbl-hez eléggé hasonlatos, nyugodtan oda lehetne rakni a luakit-et is, de akkor a dwb és a jumanji is.

-1
Ezert a mac userek borzasztoan megsertodnenek, ami nem szerencses az almoskonyvek szerint. Akkor mar az elso lehetoseget dobjuk ki, bar egyebkent a luakit inkabb csak webkit binding nem? Persze, a QtWebkithez adott alap kis brozerrel is lehet bongeszni, de ettol a QtWebkit meg nem lesz brozer.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( trey | 2012. 12. 01., szo – 17:02 )

"kedvenc programnyelv" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

errol ez jutott eszembe: http://hup.hu/cikkek/20121123/nem_negy_hanem_tobb_mint_tizmillio_eurot_…

De hogy ne csak vele peldalozzak, o kezdte a sort: http://hup.hu/cikkek/20121123/nem_negy_hanem_tobb_mint_tizmillio_eurot_…

Btw. en birom a JS-t, bar egyszer nagyon jol jott, hogy talaltam hozza egy asszociativ tomb (aka hash)(-szeru) fuggvenyt, ami nelkul azert elegge meg lettem volna love...

Diktatorok kezikonyve

-1
Erdemes megnezni a korabbi eredmenyeket. A perl lehet, hogy "retegnyelv" vagy kihaloban van vagy barmi, ennek ellenere tavaly 8%-kal, 6. lett, megelozve pl a C#-ot. Szoval a HUP-on nepszeru, akarhogy is van. (Nyilvan a HUP olvasok/szavazok nem adnak objektiv kepet az egesz informatikara/rol, de talan nem is ez a lenyeg.)

Azért van kihalóban, mert minden jóérzésű ember heveny hányingert kap, ha egyáltalán eszébe jut. Ugyanolyan jajjdeckockavagyoknézdgusztustalantíroknemértedmi?XD rétegnyelv lett, mint a C (ezzel most sok embernek a lelkébe gázoltam, de mindjárt kifejtem). Vannak normális használati esetei, de ezek legfőképp abból adódnak, hogy baromira elterjedt, és nem abból, hogy jó lenne. A Perl egyetlen előnye, hogy iszonyatosan sok lib van hozzá, C-nek meg, hogy mindenre fordul, és sok alapdolgot (kernelek, nagyobb libek) abban írtak, így azzal bindol a legjobban. Ezektől eltekintve mindkettő nem optimális eszköz, aminél már van jobb egy jóideje.
----
India delenda est.
Hülye pelikán

Pont ez az, van egy nagyon nagy előnyük, ami miatt érdemes őket használni normális embernek is. De rajongója, szeretője csak az lesz, aki szeret a szarban turkálni, illetve ha frissen kezdett dologról van szó, akkor már nem nagyon indokolhatóak.

De hogy kifejtsem.
- Perl: Pythonnak már szinte megvan a Perl penetrációja, rengeteg lib van hozzá (no sajnos nem annyi, mint Perlhez, ezt írtam ugye fentebb is), és nagyjából mindenben jobb. De kb bármelyik népszerű scriptnyelvet vehetjük, szinte mindegyik következetesebb, olvashatóbb és emberbarátabb, mint a Perl.
- C: C++ mindent tud, amit a C, csak jobban. Egyszerű.
----
India delenda est.
Hülye pelikán

"- C: C++ mindent tud, amit a C, csak jobban. Egyszerű."
A C++-t állati nehéz C-től független nyelvként kezelni, mivel örököl mindent amit a C tud. Ráadásul rengeteg helyen használhatatlan (pl. kernelben) így nem váltja ki a C-t.
A C előnye pont az, hogy maga a nyelv egyszerű mint egy kilincs, de bármit meg lehet benne csinálni. A C++ ezzel szemben egy gusztustalan hatalmas izé ami csak magasabb szintű programokban bontakozhat ki.
Akkor már inkább ott a D nyelv amihez sajnos még a fordítók nem elég kiforrottak.

"A C++-t állati nehéz C-től független nyelvként kezelni, mivel örököl mindent amit a C tud."

Azért általában sikerül. Mármint nem függetlenként, mert nyílván nem független, kitűzött cél volt az ésszerűség határain belül de maximális kompatibilitás.

"Ráadásul rengeteg helyen használhatatlan (pl. kernelben) így nem váltja ki a C-t."

Erről beszéltem fentebb, a meglévő kódbázis miatt a C-nek van létjogosultsága. De azt nem állíthatod, hogy C++-ban rosszabb kernelt lehetne írni, mint C-ben.

"A C előnye pont az, hogy maga a nyelv egyszerű mint egy kilincs, de bármit meg lehet benne csinálni. A C++ ezzel szemben egy gusztustalan hatalmas izé ami csak magasabb szintű programokban bontakozhat ki."

Fentebb beszéltük meg, hogy a C++ mindent tud, amit a C (kivéve persze a futási idejű méretű automatikus tömböket), akkor most miről is beszélünk? A C++-ban semmit nem kötelező használni, többek között pont erről szól a 0 overhead principle.

"Akkor már inkább ott a D nyelv amihez sajnos még a fordítók nem elég kiforrottak."

A D nyelv nekem kicsit olyan hatású, mint a tisztán funkcionális nyelvek. Nyomatnak valami egyetemen jól hangzó ötletet, aminek semmi praktikus hatása nincs. Aztán lehet tévedek, de az ipar ráharap a jó dolgokra.
----
India delenda est.
Hülye pelikán

"kitűzött cél volt az ésszerűség határain belül de maximális kompatibilitás."
Minden C program egyben C++ program is. Ha valami C++-ként fordítva másképp viselkedik, akkor ott baj van.

"Erről beszéltem fentebb, a meglévő kódbázis miatt a C-nek van létjogosultsága. De azt nem állíthatod, hogy C++-ban rosszabb kernelt lehetne írni, mint C-ben."
Pedig nem véletlenül nem használják a C++-t kernelek fejlesztésére. Pl. az egész "new"-"delete" dolog elég szépen fregmentálná a memóriát. Persze, lehetne jól lebutítva használni a nyelvet, de igazából a tiszta C előnyösebb.

"A D nyelv nekem kicsit olyan hatású, mint a tisztán funkcionális nyelvek."
Eleinte nekem is ilyen érzésem volt vele, de ahogy kezdtem megismerni elmúlt. Nekem egyedül az vele a bajom, hogy rendes eszközök nincsenek még hozzá így nem használnám hobbin kívül másra.

"Minden C program egyben C++ program is. Ha valami C++-ként fordítva másképp viselkedik, akkor ott baj van."

Az eleje nagyon erős túlzásokkal igaz, sok minden miatt nem fordul le egyből egy C program. A szemantikában is vannak (nem túl jelentős) eltérések, erről van egy külön fejezete is a nagykönyvnek :)

"Pedig nem véletlenül nem használják a C++-t kernelek fejlesztésére. Pl. az egész "new"-"delete" dolog elég szépen fregmentálná a memóriát. Persze, lehetne jól lebutítva használni a nyelvet, de igazából a tiszta C előnyösebb."

Ugye nem kötelező mindent használni a nyelvből, semmi sem indokolja, hogy a new/delete rosszabbul viselkedjen, mint a malloc/free.
Az meg, hogy a tiszta C előnyösebb, eléggé hasraütésszerű állításnak érzem. Miben előnyösebb? Gyengébb a fordító ellenőrzőképessége? Nehezebb kifejezni komplexebb dolgokat? Vagy miben jobb?
----
India delenda est.
Hülye pelikán

"Ugye nem kötelező mindent használni a nyelvből"
Ok, elfogadom.

"semmi sem indokolja, hogy a new/delete rosszabbul viselkedjen, mint a malloc/free."
Azonban kernelen belül ennél picit összetettebb a memória kezelés. A malloc() és free() jellegű hívások használata viszonylag ritkán indokolt. Az azonos méretű memóriablokkok foglalásához (amilyenek pont az objektumok lennének) inkább slab allokátort (vagy ami éppen az adott kernelben elérhető) érdemes használni, hogy csökkenjen a fregmentáció.

"Az meg, hogy a tiszta C előnyösebb, eléggé hasraütésszerű állításnak érzem. Miben előnyösebb?"
A C kevesebb dolgot rejt el a programozó elől mint a C++. Teljes C++ támogatást amúgy is nehéz lenne elérni egy kernelben, így a C++ előnyeinek nagyrésze elveszne.
Mindenesetre nem látom, hogy olyan sok kernelt írnának C++-ban.
(Haiku kernel egy érdekes kivétel, de itt is nagyrészt javított C-ként használják a C++-t.)

"A D nyelv nekem kicsit olyan hatású, mint a tisztán funkcionális nyelvek. Nyomatnak valami egyetemen jól hangzó ötletet, aminek semmi praktikus hatása nincs. Aztán lehet tévedek, de az ipar ráharap a jó dolgokra."

Tavaly ezt mar jol kitargyaltuk. :-) A D-nek nincs kello marketingje, mert nincs mogotte tokeeros ceg. Az iparban pedig az van, amit a tokeeros cegek a nagy fejlesztocegeknek eladnak. Eladni pedig nem feltetlenul a szakmailag jo dolgot lehet, hanem olyat, amivel a managementet lehet parasztvakitani.

Azt hiszem mindannyian tudunk pledakat hozni borzaszto rossz eszkozok hatlamas elterjedtsegere. A sajat peldaimtol a flame elkerulese vegett eltekintek.

A D kifejezetten nagy hianyt potolna olyan kornyezetben, ahol egy modern programnyelv native forditott kodjara van szukseg. Tehat az osszes olyan helyen, ahol ma kenyszerbol C-t vagy C++-t vagy Adat hasznalnak, mert nincs jobb (erstd: nincs mashoz fordito). Ez nagyon is ervenyes beagyazott rendszerekre (elsosroban firmwarekre, mert megint jonnek majd itt a mikro managelt kornyeztekkel, amit maris portolhatok majd magamnak, stb. de ugye ez azert a legtobb esetben meg viccnek is rossz), real-time fejlesztesekhez, nagybiztonsagu (safety) rendszerekhez, stb.

Tehat letezne ipari igeny, de 2 evvel ezelott mi sem D-vel, hanem C++-szal indultunk neki rendszer teljesen uj alapokra helyezesenek. Ez teljesen vilagos kenyszerek menten tortent, es nem azert mert nincs a D-re (vagy hasonlo nyelvre) ipari igeny. Kenyzseritve vagyunk a sok tizeves elavult szarokat hasznalni.

C++ mögött sem volt nagy cég (legalábbis hivatalosan), C mögött sem. Persze, mindkettő az AT&T-ből került ki, de egy Java vagy C#-hoz képest egyértelmű, hogy nincs neki egy nagy céges támogatása, olyan, mint a Linux, sokan beledolgoznak.
Még mindig úgy érzem, hogy a D nem ad, vagy nem úgy ad plusz dolgot, ahogy arra az iparnak szüksége van. C++ (egyébként C is) friss, 2011-es szabvánnyal rendelkezik, szóval elavultnak nem nevezném, és mindkettőben vannak olyan fícsörök, amiket nem használ senki. Szerintem az ipar jól el tudja dönteni, mit használjon. Nyílván a meglévő kód- és tudásbázis behatárolja a lehetőségeket, de lett volna már ideje elterjedni. Nem tette.
----
India delenda est.
Hülye pelikán

Lehet használni a C++-t egy jobb C-ként is, nem tart senki a fejedhez pisztolyt, hogy használj osztályokat, sablonokat, operátor overloading-ot, stb.

Nem elég kiforrott D fordítok téma: Ha real time vagy ahhoz közeli igényekre programozol, akkor lehet, hogy a viszonylag fejletlen GC-vel gondod lesz. Ha erősen függ a programod teljesítménye bizonyos fordítói optimalizációktól, akkor lehet, hogy a viszonylag fejletlen optimalizációval gondod lesz. Más esetekben igen igen ritkán fogsz belefutni komoly gondba.

Igazából a Perl előbb volt az életemben, de azóta is néztem más nyelveket (Ruby, PHP), de egyelőre a Python fogott meg. De nem a Python a hangsúlyos, azon lehet vitatkozni, a lényeg, hogy Perl szar, tákolt, gusztustalan (hasonlít a PHP-ra).
----
India delenda est.
Hülye pelikán

az lenne a legjobb ha nem kellene semmit eltávolítani. audiolejátszónál pl. azért választottam mínuszosnak a rhythmboxot, mert azt ismertem kb. a legjobban a konzolos kategóriát kivéve, azt meg nem akartam mondani, mert mp3blaster-t használtam elég hosszú időn keresztül.

? sztem volt értelme annak, amit írtam.

bírom egyébként, ahogy mindenki felhördül, ha nagy ritkán berobbanok közétek... hát igen, a szám nem lett kisebb, csak időm nincs már annyi, mint régen.

ami azt illeti, szívesen beszélgetnék az itteni emberekkel ennél kicsit többet és kicsit kevésbé kiteregetve a világ elé, de ha bemegyek irc csatira akkor a társaság addig hallgat, amíg meg nem unom és ki nem lépek, nehogy véletlenül kiderüljön, hogy jó fej is tudok lenni, mert akkor el kéne fogadni a jelenlétemet, az meg olyan "kamu és buzis"

:)

szerk.: közben gondolkodtam hogy mennyire esne rosszul, ha több szavazatot kapna mint perl, de aztán rájöttem, hogy én ettől még nem szeretném jobban, szóval mindegy is. de ez egy egészen értelmes hozzászólás volt, egy pillanatra elgondolkodtam rajta.

Obj-C engem is érdekelne, de nem tudom, mit lehetne kidobni. A perl, python, ruby olyan hármas, aminek együtt van értelme, nem vonhatod össze, mert fontos a sorrend. Ugyanez a C#/Java és C/C++ esetén.
Ha valamit ki KELL dobni, akkor inkább a scala-t kéne, az olyan magányosan álldogál.
----
India delenda est.
Hülye pelikán

Funkcionális nyelvek közé a Haskell, Erlang, Caml mellé fel lehetne írni a Clojure-t, ami mostanság emelkedő népszerűségnek örvend, hazánkban is. (Konkrétan több magyar Clojure felhasználót ismerek, mint amennyi ember tavaly a Scala-ra szavazott :D)

Szóval:

- haskell, erlang, caml, ... (funkcionális nyelvek)
+ haskell, erlang, caml, clojure, ... (funkcionális nyelvek)

--
|8]

Szerintem akkor már inkább JS, ha a Perlfanok ennyire ragaszkodnak hozzá. (És nem azért, mert annyira kedvencem lenne az a nyelv - sőt! - , hanem a jelentősége miatt.)

D-t használ egyébként valaki aktívan?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Vanni vannak (gondolom), de ha bekerul, lehet meg a tavalyi Scala szavazatszamnal is kevesebbet kap. Meg talan a "programnyelv" kategoriaba bele se fer, ezek inkabb a "hardverleiro nyelv" kategoriaba illenenek. (Cserebe ott meg en nem tudnek 10-et felsorolni... :) )

Szoval csak ezert -1.

A verilog/vhdl nyelvet nem csak hardverleíró nyelvként lehet ám alkalmazni. Igaz, ritkán hall az ember ilyet, de gondold el, nyelvi szinten valósul meg a párhuzamos és eseményvezérelt programozás. Azért ez nem lenne rossz dolog (persze a szimulátorok nem erre vannak kihegyezve).

Hardver/rendszerleíró/verifikáló nyelvnek (csak a móka kedvéért, nem komolyan veendő :-) ):
Verilog
VHDL
SystemVerilog
MyHDL
SystemC
e
AHDL
(idáig fejből)
VERA
ABEL
M
(ezek Wikipédia, bár a VERA és ABEL így utólag megvannak)

( CrushTestDummy | 2012. 12. 01., szo – 22:10 )

- haskell, erlang, caml, ... (funkcionális nyelvek)
+ groovy