HOVD 2015 - Kedvenc fordított programozási nyelv

HUP

assembly (bármely architektúra, bármely dialektus)
3% (26 szavazat)
c
23% (186 szavazat)
c#
11% (89 szavazat)
c++
20% (160 szavazat)
go
4% (35 szavazat)
java
24% (193 szavazat)
objective-c, swift
3% (23 szavazat)
pascal
8% (64 szavazat)
scala
2% (18 szavazat)
typescript, es6, coffeescript, scala.js (javascript-re fordított nyelvek)
2% (20 szavazat)
Összes szavazat: 814

( uid_17784 | 2015. 12. 14., h – 15:30 )

Aki pascalt jelolt, az ugye nem programozo.

Írok én neked Pascal wrappert még akár űrhajóhoz is :). Na jó, nem, mert gimiben láttam utoljára és szeretném is elfelejteni. Kb. az első programnyelvem volt, ha jól emlékszem.

Az a személyes véleményem, hogy eléggé szívás a Pascal, de akinek tetszik, vagy muszáj, az miért ne használná, nem attól lesz valaki jó vagy rossz programozó.

--

Mondjuk en is kivancsi lennek, hogy mostanaban hol jar a nyelv. Valamikor 2005 kornyeken lattam utoljara kozelrol Pascal kodot Deplhiben, azota nem. Nekem a C++ a kedvencem, de nem mondanam, hogy a Pascal unit rendszeret vagy forditasi sebesseget nem irigylem... Sot most igy el is ballagok, megnezem, hogy mire jutott a nyelv az utobbi par evben.

Ja, hamarosan már C/C++-ban is lesznek unitok (Pascalban kb. 1985 óta van, egyszer utánanéztem a pontos Turbo Pascal verziónak amiben megjelent), csak ott modulnak hívják majd... :) Meg Cx11-ben lett OS-független threading API, hát ez is bámulatos, 20 éve van ilyenünk. Ami még "modernebb" dolog és hiányzik a Pascalból az a lambda függvények, a Delphi már tudja, az FPC még nem, de készülőben van. Vicces, hogy egy ilyen feature, aminek nagy része csak parser work meg syntax sugar, mekkora hisztit tud kiváltani, ha nincs...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Azért khm. A Genericsszel, lambdaval és az Extension methodokkal (meg azzal, hogy minden gyűjtemény Enumerable és enumerable<T> igencsak kényelmes dolgokat lehet létrehozni, ld. LinQ.

Meg még sorolhatnék dolgokat, ami "csak" parser work és syntactic sugar (property, delegate, event, stb), mégis írtó hasznos dolog.

Sőt, valahol az exception, a class, a procedure, a function, a for, foreach (ha van, ezt épp nem tudom), repeat/until, while, is csak az.

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

Így van. Minden csak syntax sugar. Lassan 15 éve turkálok egy fordítóban hobbiból, kisebb-nagyobb megszakításokkal, az a többszázezer kódsor csak arról szól, hogy a lehető legtöbb objekt-trutymót meg transparencylayert meg syntax-sugart és eyecandyt kihajigálja, mert legalul úgyis minden csak, bit, byte, goto meg pointer. :) Ami megmaradt azt meg wrappolja valami library függvényre. És innentől úgyis csak azon vitatkozunk, hogy ki hány syntax sugarral szereti a kódkávét. :P

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Persze, de azt gondolom te sem vitatod, hogy ha egy nyelven egyszerűbben, gyorsabban, karbantarthatóbban meg lehet oldani egy problémát, az általában jobb, mint amin kevésbé.

És valahogy senki nem akar visszatérni a repeat/until helyett az if-gotohoz.

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

Nem vitatom. Nem azt mondtam, hogy a lambda rossz, csak azt hogy ezért sírnak újabban annyira (mint írtam Delphiben már van is), mintha nélküle már nem is lehetne semmit fejleszteni. És nyilván lesz FPC-ben is, tehát innentől mindegy is én mit gondolok róla, nem? :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Na ez egy messzebbre mutató vita, és ne menjünk bele. De csak röviden: az FPC egy open source projekt, amit ez esetben a tipikus opens ource betegség sújtott: mindenki rinyált egy feature-ért, de senki nem ült le, hogy belecsinálja, mert az sokba kerül és érteni kéne hozzá - egészen mostanáig, mikor is valaki végre beküldött egy patchet, ami most van review alatt. És ez általános jelenség: mindenki használ egy rakás toolt és komponenst hogy időt spóroljon, de hozzájárulni senki nem akar semmihez, hiszen mindenki csak a saját asztalán lévő X vagy X/10-ig lát. És mindegy, hogy lambda, vagy a kernel, vagy egy library, vagy akármi az.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Ha már a magyar szakirodalom C alapú és a C-re mint a programozási nyelvek angoljára hivatkozik, belinkelném az "angol nyelvű szakirodalmat" amely egy nagyon alap fordító írását tartalmazza, Pascalban, ráadásul 68k assembly kimenettel... :) Nem mai darab, de hasznos.

Tényleg, meg kéne nézni poénból lefordulnak-e a fejezetei FPC-vel... :P

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Ez a könyv már első beleolvasás után is szörnyű...

Angolul biztos rengeteg anyag van, de ha magyarul kell, akkor az itteni diák elég összeszedettnek tűnnek:
http://deva.web.elte.hu/fordprog.hu.html

(Nem ismerem sem az előadót, sem az előadást nem hallgattam, ez egy 10 mp-s google keresés eredménye.)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"szólni kéne a MEK-eseknek, hogy az informatikai témájú könyveit vegyék már le"

szerintem nem kene semmit sem levenni, csak azert, mert neked nem tetszik. Tudod, ezt nevezik cenzuranak...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Tudod, ezt nevezik cenzuranak...

Nem. Ezt véleménynek nevezik.
A cenzúra pedig azt jelenti, hogy hatóságilag betiltják egy mű terjesztését. Nem hiszem, hogy vilmos.nagy kolléga ezt egy kommenttel elérte.
Egyébként ha ekkora ferdítéseket bírsz kitalálni, akkor inkább tartsd meg magadnak az ostobaságodat (ez szintén egy vélemény volt).

hadd segitsek, mert szemmel lathatoan fingod nincs a dologrol.

- velemeny: valaminek a milyensegevel (minoseg, etc) kapcsolatos
- cenzura: egy nem kivanatos valami eltavolitasa

Namost vilmos baratunk mit is kommentelt?

"nagyon gáz" (-> velemeny)
"vegyék már le" (-> cenzura)

Szoval, ha csendben maradtal volna, okosabb maradtal volna. HTH...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

A cenzura nem egy nem kivanatos valami eltavolitasat jelenti: "A cenzúra információk hozzáférhetőségének és terjesztésének a felügyelete, elsősorban politikai és morális alapokon." (lasd Wikipedia)

Ha a cenzurat olyan tagan ertelmeznenk, mint egy nem kivanatos valami eltavolitasa, akkor a bugfix is cenzura lenne, mert egy nemkivanatos valamit - hibat - tavolitottunk el. Cenzura lenne a virusirats, az adblocker, es a spam szures is. Cenzura lenne kivenni a kovetkezo debianbol az XYZ csomagot, ilyen-olyan okokbol.

A cenzura nem ez. A cenzura felugyeletet is jelent. Az, hogy egy valamit, ami tobb kart okoz, mint amennyit hasznal, leszednek, nem cenzura. A szolas meg velemenyszabadsag senkit nem kotelez arra, hogy az ember velemenyet meghallgassa, vagy publikalja. Hasonlokepp a MEK sem koteles mindent szart elerhetove tenni, es ha levesznek valamit, az nem feltetlen cenzura.

--
|8]

+1
messze nem zavar Viola úr munkássága, olyanokat mond, amilyeneket szeretne.

Az már zavar, hogy egy neves, ámde a témához nem értő helyre betolja a saját szemetét. És, ha a MEK-esek tisztában vannak vele, hogy ez egy szemét, s úgy hagyják fent - ám, legyen, nem zavar, a MEK-et fogja minősíteni. Csak van egy olyan erős érzésem, hogy nincsenek tisztában azzal, hogy a fent nevezett mű igencsak közröhej tárgya.
--
blogom

Reszlet a MEK oldalarol:

"A MEK a Nemzeti Információs Infrastruktúra Fejlesztési Program és az Országos Széchényi Könyvtár egyik projektje, és a magyar nyelvû vagy magyar vonatkozású, oktatási, tudományos, vagy kulturális célokra használható, szabadon terjeszthetõ elektronikus dokumentumok központi gyûjtõhelye kíván lenni."

Poliverzum muveinek szakmai szinvonalarol lehet vitazni, de belefer a MEK kuldetesebe. Ha xy kuld egy emailt, hogy vegyek mar le, az bizony cenzura(zasi kiserlet), meg a wikipedia alapjan is.

Ha a cenzurat olyan tagan ertelmeznenk, mint egy nem kivanatos valami eltavolitasa, akkor a bugfix is cenzura lenne

most a sajat cenzura fogalmaddal vitatkozol, nem az enyemmel.

Cenzura lenne a virusirats, az adblocker, es a spam szures is.

stop pulling my leg, plz! Bar az adblocker mar pikansabb teruletre vezet

A cenzura nem ez.

az biztos, de legalabb ezt en sem allitottam.

Az, hogy egy valamit, ami tobb kart okoz, mint amennyit hasznal, leszednek, nem cenzura.

erosen szubjektiv megallapitas. Ki vagy te, vagy vilmos.nagy, hogy ezt eldontsd?

A szolas meg velemenyszabadsag senkit nem kotelez arra, hogy az ember velemenyet meghallgassa, vagy publikalja.

mar megint terelsz

Hasonlokepp a MEK sem koteles mindent szart elerhetove tenni,

valoban nem, de ugy dontottek valamiert, hogy megis elerhetove teszik.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Ahogy ugy dontottek, kozze teszik, donthetnek ugy is, hogy eltavolitjak. Szivuk joga, es ha ezt megteszik, az nem lesz cenzura, megha esetleg az en keresemre is tettek, nem pedig maguktol. Mashol attol meg megjelenhet. A cenzura lenyege a felugyelet, a hozzaferes (globalis) korlatozasa. Ha ezt a reszt kivesszuk a definiciobol, az olyan tag lesz, hogy barmire ra lehet huzni, abbol pedig csak szomorusag lesz.

Lehet vitazni azon, hogy az emlitett mu kimeriti-e az oktatasi, tudomanyos vagy kulturalis celokra valo hasznalhatosag fogalmat. Mert ha nem, akkor nem feltetlenul felel meg a MEK celjainak sem, ergo akar el is tavolithato. Hogy mennyire felel ezeknek meg, vagy sem, nem mennek bele, ahhoz el kene olvasnom, amihez pedig semmi kedvem. Szerencsere nem is ezen vitazom veled, hanem a cenzura fogalman. :P

--
|8]

"oktatási, tudományos, vagy kulturális célokra használható"

Ezzel vannak itt a problemak.

"erosen szubjektiv megallapitas. Ki vagy te, vagy vilmos.nagy, hogy ezt eldontsd?"

Egyreszt vannak tamogatoi, masreszt tudod, van olyan, hogy a szakmai kozosseg megiteli, hogy egy munek - az iro szandekaival ellentetben - semmi koze nincs a szakmahoz.

"valoban nem, de ugy dontottek valamiert, hogy megis elerhetove teszik."

Igen, azonban a "valamiert ugy dontottek"-ben nem szerepeltek szakmai megfontolasok. Ez egesz addig nem is lenne problema, amig ezt a konyvet nem akarna a MEK szakkonyvkent eladni. Es ez az, ami a problema lenyege. Egy parodikus irasnak siman elmegy, szakkonyvnek nem, es mivel a MEK-tol nem elvarhato, hogy minden szakteruletrol legyen egy szakmai lektora, akik megiteljek egy konyv szakmaisagat, sajnos ezt a "manyeyeballs"-nak, masneven a szakmai kozossegnek kell megtennie. Itt es most ez tortenik, es ennek se a cenzurahoz, se mashoz nincs semmifele koze. A cenzurat te keverted ide, es senki mas.
--
Blog | @hron84
Üzemeltető macik

-1
Szerintem bőven belefér a cenzúra fogalmába.
Ebben az esetben "A cenzúra információk hozzáférhetőségének és terjesztésének a felügyelete", ebben az esetben szakmai alapon. Ki dönti el, hogy mi megfelelő szakmailag és mi nem?
Nem akarom védeni ezt a művet, mert nem olvastam, lehet, hogy tényleg nem sokat ér szakmailag, de mitől lesz káros?
Szakmailag sokak szerint az OOP az egyik legkárosabb programozási módszer. Most akkor az OOP műveket sem szabadna megjelentetni?
Gondolom sokak szerint meg az FP az.
Azt el tudom fogadni, hogy esetleg odaírják mellé, hogy XY neves szakértő szerint nem megfelelő szakmai színvonalú. Hasonlóan, mint filmeknél a 18 karika.

(Ui.: azzal sem tudok egyetérteni, amikor a művészetnél megmondják, hogy melyik színek harmonizálnak egymással. Pl., hogy a kék meg a zöld nem harmonizálnak. Ja, zöld táj kék égbolttal vagy kék tóval a közepén nagyon randa tud lenni.)

Nekem az ilyen dogmatikus "ez a legkárosabbról" mindig Churchill és a demokráciáról tett kijelentése jut eszembe. ("democracy is the worst form of Government except for all those other forms that have been tried from time to time.")

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

Egy cikk/mű szakmaiságának (érvekkel megtámogatott) megítélése viszont már nem szubjektív vélemény, hanem objektív ténymegállapítás. Azaz ha bárki a műben mutat X darab durva szakmai hibát (amihez nyilván végig kellene olvasni, amit az eddig hozzászólók szerintem nem tettek meg), amelyek akár még félrevezetőek is, és ez alapján távolítják el, szintén cenzúra. Viszont ilyen esetben ez a korlátozás szükséges, ha más nem, legalább azért, hogy az oldal és a szervezet megbízhatósága ne sérüljön.

Nem, ez sem cenzura. Az eltavolitas tette magaban meg nem az. Az, hogy egy helyrol eltavolitjak, esetleg be sem engedik, nem cenzura. Lasd a wikipedia cikket amit linkeltem, van benne jopar pelda arra, hogy mi a cenzura, es hogyan mukodott pl Magyarorszagon. Erdemes azt osszevetni azzal, amirol itt szo van.

cenzura != korlatozas. cenzura > korlatozas.

--
|8]

Ohm, most hirtelen nem tudom elobanyaszni neked azt a forumszalat, ahol ezt a konyvet mar kiveseztuk egyszer (sot, tobb is volt), de a Google toled is olyan messze van mint tolem.

De, ez a konyv egyszer mar szet lett szedve ezen oldal hasabjain, es megallapitast nyert, hogy tele van durva szakmai tevedesekkel es joindulattal is csak pontatlannak nevezheto megfogalmazasokkal. Az iro ebbe a beszelgetesbe erdemi modon bele nem folyt, a felmerult problemak javitasara hajlandosagot nem mutatott. Ezek utan en nem gondolom azt, hogy barmi hiba lenne abban, hogy a szakmai kozosseg a konyv eltavolitasa mellett ervel.
--
Blog | @hron84
Üzemeltető macik

Egyrészt: egyáltalán nem érdekel, hogy a mű ott marad-e a MEK-en vagy se (már rég lementettem :) ). Sőt, az a bizonyos fórumszál se igazán érdekel, így az időmet nem fogom erre pocsékolni.
Másrészt: ebben a fórumszálban nem láttam se érveket, se konkrétumokat.
Harmadrészt: akinek fontos, hogy a MEK-ből kikerüljön, megkeresi az általad emlegetett bejegyzést (vagy ő maga ír egy kritikát), és küld egy jelzést a MEK-nek. Ha úgy látod, hogy hiba, hogy fenn van, és fontosnak tartod, hogy ne legyen fenn, akkor meg is teheted ezt a (két) lépést.

Otleted sincs, mi az a cenzura, kar ezt a vonalat eroltetni.

Kulonben meg a keres teljesen jogos, a MEK nem egy hivatalos leveltari archivum, nem mulhatatlanul szukseges minden szemetet benne tarolni. Ennyi erovel fel lehetne tolteni a bash.hu egy kivonatat is, es az is pont olyan irodalmi mu lenne (es pont ugyanolyan ertekes) mint a fent emlitett muvek.

Esetleg, ha a torlest tul durvanak tartanank, akkor az is eleg lehetne, ha attennek a humoros irasok koze, vagy barhova, ami nem a szakkonyvek kategoriaja.
--
Blog | @hron84
Üzemeltető macik

azt hittem a __neked__-en van a hangsúly. így értem.

abban viszont nem vagyok biztos, hogy jó dolog, ha a Országos Széchényi Könyvtár neve alatt borzasztó minőségű könyvek jelennek meg. magasról teszek rá, hogy Viola Zoltán szépirodalmi művei ott vannak - ellenben, ha a MEK-en keresek egy szakmai könyvet, akkor megbízom az OSZK munkatársaiban abban, hogy nincs fent vitatható minőségű könyv.

de a fentebb linkelt mű messze a vitatható kategóriába esik. megértem azt is, hogy az OSZK munkatársainak nincs kompetenciája hozzá, hogy egy informatikai szakkönyvet elbíráljanak - de nem-e a mi felelősségünk akkor, hogy szakmailag ilyen vitatható minőségű könyvek, egy viszonylag neves intézmény neve alatt fent vannak?
--
blogom

Rövid megjegyzés, mert látom ezt többen nem tudják errefelé:
"A nemzeti könyvtári feladat ellátása a Széchényi Könyvtárat a magyarországi kiadványok vonatkozásában minden egyes kiadás gyűjtésére kötelezi."

Szóval ha az alatt, hogy "Országos Széchényi Könyvtár neve alatt borzasztó minőségű könyvek jelennek meg" azt érted, hogy ott valami válogatott gyűjtemény van, és gáz, ha valami silány anyag bekerül, akkor tévedsz. Valójában minden Magyarországon kiadott könyv egy példánya megtalálható ott (elvileg).

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

tehát ha írok valamit, ami arról szól, milyet sz*rtam az elmúlt egy év minden egyes napján (naponta), esetleg fényképpel dokumentálom, majd kiadom e-könyvben, akkor ezt nekik __kötelességük__ megőrizni?

ha tényleg így van (nem vitatom), akkor:
* írok egy ilyen könyvet
* és lehet, ezt felül kéne gondolni.
--
blogom

komolyra fordulva: egyébként semmi problémám nem lenne azzal, ha az OSZK-nál tényleg __mindent__ gyűjtenek, de (ahogy fent már említette valaki), az ilyen művek a vicc vagy a komolyan nem vehető, de valami vadbarom kiadta kategóriába kerülnének az informatika helyett.

de jelen esetben a mindent gyűjtés is aggályos szerintem - sok, fontos, magyar tartalom kimarad (például, ha írok egy szakmai blogot, kis valószínűséggel van ott), míg ha írok valami erősen kifogásolható minőségűt, s elküldöm nekik levélben, egyből megjelenik. jelen esetben, inkább a minőség lenne fontosabb, s ha minden minőségi, magyar tartalom felkerült, utána jöhetnek az ilyen trash-fun dolgok is.
--
blogom

Itt ketfele problema van, es ez allandoan atfedi egymast: az egyik, hogy minek gyujtik, ezt nagyjabol mar korabban is tisztaztuk, ennek ellenere ez hasznos pontositas.

A masik, hogy ha mar gyujtik (mert muszaj), akkor miert nem a megfelelo kategoriaba rakjak be?
--
Blog | @hron84
Üzemeltető macik

Én kettőt is fejlesztek hobbiból. Persze "kicsit" lassan haladok, mert kevés időm van, meg inkább csak KSP-zek.

Az egyik a BASIC interpreter, amit hasonló céllal csinálok, amivel a basic256-ot csinálták, csak annyi különbséggel, hogy teljesen konzolos felhasználói felületet álmodtam neki. Bekapcsolod a gépet és BASIC interpreterbe bootol. GUI, Internet nuku. Oktatási céllal készül. Van egy elméletem, hogy a gyerekeknek a grafikus GUI figyelemelterelő, és ezért konzolos gépen kellene programozást tanítani. (Lásd: http://www.salon.com/2006/09/14/basic_2/ )

A másik egy teljesen új C#-hoz és Java-oz hasonló nyelv néhány olyan feature-rel, amitől világmegváltó újdonság lesz, ha elkészül.

Már másodjára ajánljátok a JavaScript: The Good Parts könyvet, de ez valóban inkább elrettentő példának jó. Már csak azért is, mert a könyvben a Good Parts rész 4 oldalas, az Awful Parts 8 oldalas, a Bad Parts 6 oldalas.
Természetesen nem rossz könyv ez, de nem arra való, hogy meggyőzzünk valakit arról mennyire nem rossz nyelv, sőt kifejezetten jó (az ES6-tal és a remek könyvtárakkal) a JS.

Én pont fordítva látom. A DOM az aminek értelme van, és a JavaScript a kataszrófa. Ha valaki vette volna a fáradtságot és hozzádrótozza a DOM-ot (eseménykezelők, DOM és CSS manipuláció) egy normális programnyelvhez, akkor már rég elfelejthettük volna az egész JavaScript őrületet.

A DOM szerintem sem olyan rossz, leszámítva, hogy iszonyú rosszul van kitalálva :)
Nem véletlen, hogy egy rakat könyvtár bevezet virtuális DOM-ot, hogy hatékonyabb legyen a változtatás.
Bár már készülőben van a Shadow DOM, ami talán megoldja ezt a problémát.

A JS egy kifejezetten jó nyelv, leszámítva a dinamikus típusokból adódó hülyeségeit, ezekre figyelni kell, de ez más dinamikus típusúnál is hasonlóan van. A dinamikus típusosságnak is megvannak a maga előnyei.
Nagyon nagy előnye a nyelvnek, hogy könnyen tanulható, és mostanra, az ES6-tal minden olyan tudással rendelkezik, amellyel egy modern programnyelvnek rendelkeznie kell.

A virtual DOM nem erről szól: arról szól, hogy a DOM-ot batchekben módosítjuk, és nem egyenként késztetjük a rendering engine-t arra, hogy újra layoutoljon és painteljen.
A shadow DOM meg enkapszuláció.

A shadow DOM-ot használhatod virtual DOM-mal, nem kizáró vagy egyik vagy másik, mivel totál más dolgokról szólnak.

Van azert sok olyan dolog a nyelvekben, ami praktikusan nem okoz runtime-overhead-et, viszont a bolerplate-et komolyan csokkenti. Ez nagyon ertekes dolog szerintem. Hasonlokeppen a lambda nagyon jo dolog abbol a szempontbol, hogy egy pl. std::find_if hivasnal a predikatumot helyben lehet megadni. Ha valaki hasznal pl. boost::asio-t, akkor tudja, hogy mennyivel olvashatobb kodot lehet igy irni.

Nyilvan ezek a nyelvi kepessegek meg nem teszik a lehetetlent lehetsegesse, inkabb mondjuk azt, hogy a bonyolultsagot teszik kezelhetove. Nyilvan minden nyelvnel a tervezo donti el, hogy milyen koltseget (portability, runtime, compile-time, ...) hajlando bevallalni adott feature-ok miatt. A C++ ebbol a szempontbol viszonylag radikalis, tehat ahol csak lehet, minimalizalja az absztrakciok futasi ideju koltsegeit.

A szalkezeles szerintem annal bonyolultabb kerdes. A boost-nak volt ugye a jelenlegi C++ szalkezelo konyvtarhoz hasonlo cucca. Igazabol nem az a kerdes, hogy tudunk-e platformfuggetlenul elinditani egy szalat. A kerdes az, hogy milyen magasabb szintu primitivekkel tamogatjuk meg a szalkezelest. Ez c++11-ben jelenti most a future/promise/mutex/condition_variable/atomic vonalat. Ez azert meg csak alapja annak, ami egy robosztus tobbszalu program megirasahoz kell. Egyenlore az imperativ nyelvek ebben le vannak maradva (nem veletlenul divatos most az Elixir/Erlang vagy a Haskell vagy a Scala). Majd meglatjuk, hogy mit hoz a holnap. A C++17 jobb lesz ebben (pl. asio integracio), es akkor majd meglatjuk, hogy merre elore...

Ezen a hozzászóláson azért röhögök, mert nagyon fikázni akar, de igazából pont fordítva van. :) Egy Object Pascal kód (csakúgy mint a C++) a magasabb szintű funkcionalitás miatt rengeteg implicit háttérben működést és buktatót hoz magával (pl. refcounted stringek és objektumok, dynamic arrays, generics, RTTI, stb), amiről néha sokkal nehezebb megérteni hogy mit miért csinál és miért nem, vagy miért úgy működik ahogy, mint egy pure C kódról, ahol szinte minden eléd van rakva és nem sok minden történik "elrejtve", de pont ezért rengeteg mindent kézzel kell a fordító szájába rágni. De pont ezért a Pascal - a magasabb szintű funkcióknak hála - egy csomó mindenre jobban (mellékszál, de mit is jelent az, hogy "jobban"?) használható. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Na, most csigaztal fel igazan. Van valami olyan Pascal tutorial, ami nem total nullarol magyaraz, hanem mondjuk egy Java-C++-barmihez kepest magyarazza el a nyelvet, es foleg az objekt-orientalt reszet? Gondolom a Record-on tul is van elet, de elso harom korben en csak ilyesmit talalok.
--
Blog | @hron84
Üzemeltető macik

Nem olvasgatni akarok, kiprobalni. Viszont, mivel nem ertek hozza, nem tudom, hogy mi mukodik FP alatt es mi nem. Ezert lenne jo tudni, hogy mi az, amivel erdemes probalkozni FP alatt is, mert annak nincs ertelme, hogy orakat szopjak valamivel, amirol aztan kiderul, hogy az FP nem is tamogatja.
--
Blog | @hron84
Üzemeltető macik

"Ezert lenne jo tudni, hogy mi az, amivel erdemes probalkozni FP alatt is, mert annak nincs ertelme, hogy orakat szopjak valamivel, amirol aztan kiderul, hogy az FP nem is tamogatja. "
vs
"Nem olvasgatni akarok, kiprobalni."

A jó lenne tudni részt úgy lehet csak megoldani, hogy olvasol. Ha csak próbálghatsz, akkor jön az órás szopás. Ellentmondásban vagy.

Nem igazán értelek. Amit a Pascal tud, de a C nem az hasznos és jó, amit más nyelv tud, de a Pascal nem, az meg felesleges?
Ha konzekvens lennél, akkor Assmebly vagy még inkább gépi kód, hiszen a többi "snytax-sugar", " mintha nélküle már nem is lehetne semmit fejleszteni."

Na ez az a mellékszál, amit írtam. Mi az h. "jó" vagy jobban használható? :) Minden ilyen extra funkció egy tradeoff, csak kérdés, mi a cél. Ha kódsebesség vagy kis méret, akkor nem biztos hogy a nagyon high level a célravezető. Ha fejlesztési idő meg karbantarthatóság, akkor meg ezek az előnyösek.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Szerintem inkabb arra gondolt a kolto (aztan ha nem, akkor majd idejon es elmondja mire gondolt igazabol :) ....), hogy igen gyakran fikazzak a Pascalt, amikor bizonyos kepessegeket igazan ellophatna pl. a C/C++ belole (a unit rendszer az egyik legnyilvanvalobb bizonyitek).

A C++ szegyene, hogy 2017-ig kell erre varni. Pont. Sot felkialtojel ;). (Mondom ezt ugy, hogy a C++-ra szavaztam).

"a unit rendszer az egyik legnyilvanvalobb bizonyitek"

hat. nemtom, annak az unitnak az utodairol van szo, ami a turbo pascal 4.0 -ban jelent meg 1987 korul ?
30 ev alatt csak kiforrott a koncepcio, ha atveszik.
de azert lassuk be, anno az exe formatum es a 64k szegmenshatarok miatt (is) talaltak fel ezt.

a szerveroldali

FPC CGI support. Amúgy. És igen, ismerek embert, aki használja. Én csak azért nem, mert ahol dolgozom (lásd lent), ott saját webszerver is van, Pascalban írva...

meg az embedded pascalról nem is beszélve.. ;)

Én abból élek (külföldön) 2,5 éve, hogy Object Pascal kódot írok embedded Linuxra... De egyébként az FPC-nek van egy kezdetleges ATmel/AVR backendje, valamint tud "bare iron" kódot fordítani ARM-ra (incl. Thumb), MIPS-re és x86-ra, minimum. Mármint ezek a teszteltek is.

Az is közismert, hogy ha megjelenik egy új proceszor, akkor az első dolog, hogy megírják rá a Pascal compilert... :)

Well, a közelmúltból: amikor az IBM nemrég bevezette a PPC64LE Linuxot, akkor egyébként felvették az FPC team-mel a kapcsolatot és megcsináltatták a little endian PPC supportot a compilerben (mert korábban csak BE volt)... AArch64-en is futunk már, más olyan nagyon hű de újdonság nem nem volt mostanában, CPU téren.

Egyébként meg készül az LLVM backend, vagyis ha nagyon valami olyasmire akarsz fordítani, ami még nem létezik, akkor az FPC tudni fog LLVM frontendként működni...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Én még általánosban kezdtem a Pascalt, egész középiskola végééig programoztam benne.
Mikor elkezdtem az egyetemet, azonnal megfogott a C egyszerűsége és átláthatósága, meg az a szabadság, amivel kezelheted a gépet.
Azóta már 10 év eltelt, és nem tudom sem megunni, sem letenni :)
De ettől még a Pascalt sem tartom rossz nyelvnek, az biztos, hogy a java-nál több szavazatot érdemelne :D

Mindenesetre nagyon kíváncsi leszek, hogy a HOVD 2025-ön hogyan alakulnak majd az arányok?
Gyanítom hogy a C akkor is ott lesz majd az élmezőnyben, a C++-ban, java-ban annyira nem vagyok biztos.

"It has nothing to do with dinosaurs. Good taste doesn't go out of style..."

"C egyszerűsége és átláthatósága"

Javaslom keress rá a C szabványban, hogy hány dologra írják, hogy "undefined". Ha annyira szép, egyszerű és átlátható lenne, akkor nem lennének ilyen szabvány, mint a MISRA C, ami több száz szabályt tartalmaz csak azért, hogy hogyan írj olyan C kódot, hogy ne haljanak meg emberek. Magyarán a sok undefined dolog helyett hogyan működjön a programod nagyjából kiszámítható módon ;)

http://www.slideshare.net/olvemaudal/deep-c/23-What_will_happen_if_you

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

Van egy nyelv, ami pascal alapokon indult, annak a szintaktikai alapjait követi és vannak helyek (pl. hadipari beszállításoknál), ahol csak abban a nyelvben írt programokat fogadnak el. Szóval azért valahol úgy gondolták (úgy a 80-as években), hogy az a pascal annyira nem rossz. Ja, az ADA-ról van szó.

Lepődj meg, de tengerentúlon rengeteg a VB.Net kóder, szóval...

Mellesleg, ha a syntax lett volna a fő probléma a Pascal/Delphi párossal, akkor nem készült volna olyan istenverte sok program TP-ben DOS-ra vagy Delphiben Windowsra a 90-es években/2000-res évek elején.

Arról nem tehetek, hogy a Borland volt olyan hülye, hogy miután egyszer már kihalt alóla a platform (DOS), úgy gondolta, jó buli lesz a .NET kedvéért elhanyagolni a Win32/Win64-es fordítót (sokáig ezért nem volt pl. Total Commanderből 64 bites) és teljesen dobni a keresztplatformos törekvéseit. Arról nem beszélve, hogy .NET fronton is egy döglött csiga tempójával kullogott a Microsoft után.

Nem is értem, hogy hogyan gondolta a Borland ezt.

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

Nem is értem, hogy hogyan gondolta a Borland ezt.

Sehogy. Miután Anders Hejlsberg, a TP/Delphi atyja meglépett a Microsofthoz szísárpot fejleszteni, utána csak pingvineztek h. mi legyen és próbálkoztak mindennel... Aztán eladták az egészet a CodeGearnek, majd az Embarcaderonak, végül most az Embarcadero-t megvette valami befektető cég, hogy gatyába rázzák. De a Borland óta mindegyik tulajdonosnál voltak technológiai és sales elkúrások, meg alig volt 1-2 compiler fejlesztőjük, és láthatóan senki olyan aki Pascal fejlesztő, szóval az FPC csapatnak néha a hajuk égnek áll, hogy miket tolnak be a nyelvbe, néha véletlenszerűen... (Szerencsére az FPC többféle dialektust is támogat, így nem kell mindenben a Delphit majmolni.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Egyébként a C#-os WinForms leginkább olyan volt nekem, mint egy letakarított Delphi VCL, ahol direkt átneveztek mindent, hogy semmi se legyen teljesen ugyanolyan, mint amit megszokott az ember korábban. Más kérdés, hogy a WPF mellett a WinForms és a VCL... Nos, hát... Szép volt, jó volt, de haladjunk kérem.

Egyébként mik azok a hajmeresztő dolgok?

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

Pl. Zero Based Strings. Ennek pl. semmi értelme sincs, azon kívül h. eltöri az összes stringet használó Pascal kódot, ever, hiszen minden stringtípust 1-től indexelünk, hagyományosan. Ráadásul platformfüggő(!) az újabb Delphikben, hogy mi a default. De valahol valaki jó ötletnek gondolta, mert gondolom akkor 1:1-ben tudott wrapolni valami mobil OS helper hívásra, és leszarta következményeket. Hiszen ki akarna bármilyen meglévő kódot lefordítani iOS-re! Marhaság!

Ez most csak egy, ami hirtelen eszembe jutott, biztos tudnék még kiásni... Szerencsére ritkán interaktálok Delphivel... FPC forever... :P

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Nem, mert a nyelv definíciója nem engedi azt meg.
Ajánlom elolvasni ezt:
http://www.pascal-central.com/iso7185.html
Vonatkozó fejezetek: Pointer-types, Compatible types és Assignment-compatibility.
Azaz az a fordító, ami ezt lefordítja, nem Pascal-fordító, csak valami Pascal-ra hasonlító nyelv fordítója. A nyelv nem csak szintakszis ám :)

( uid_194 | 2015. 12. 14., h – 19:46 )

Sajnos kedvenc nyelveim (Clojure es ClojureScript) direktbe sehol nem szerepelnek. Gondolkodtam Javan (igazabol JVM miatt, es igy indirekte Clojure), meg a JS-re forditottakon. Vegul utobbi lett, mert bar ugyan nincs konkretan felsorolva, de CLJS megiscsak JS-re forditott nyelv, igy azt a tabort erositem.

--
|8]

A Scala nálam már a fájdalomküszöb. Az SBT és a Play meggyőzött arról, hogy a Scala nagyon is rossz irány. Ha egy Java kódhoz kell hozzányúlni, akkor hozzá tudunk nyúlni, mert pl. egy függvénynél, változónál stb ott van a típus. Amikor pl. egy Play filtert kell írni, akkor megy a hajtépés, mert egyszerűen nem tudod kideríteni, hogy az adott függvény milyen típussal tér vissza, a ScalaDoc oldalak átláthatatlanok (szinte használhatatlan), hacsak nincs komoly Scala programozási tapasztalatod. A típus kitalálással a Scala csak azt érte el, hogy csak az tud hozzányúlni egy programkódhoz, akinek a fejében ott van a program egész architektúrája és fejből ismeri az összes függvényt, metódust. Az SBT meg az élő bizonyíték arra, hogy tökéletes nyelv arra, hogy karbantarthatatlan és érthetetlen kódot lehessen vele fejleszteni.
Persze ezek a gondok nem a Pistike BT 5 fájlból álló programjánál jönnek elő, hanem vállalati környezetben, ahol pl. szempont az, hogy hozzá tudj nyúlni egy olyan kódrészlethez, amit előtte nem láttál. Vagyis emberi időn belül átlásd a kód környezetét, megértsd, hogy mit csinál és ha csak egy lépést kéne hozzáadni, akkor ne 2 napig a hajadat tépd és valami nagy kerülő megoldással állj elő.

Minden nyelven lehet érthetetlen, karbantarthatatlan kódot írni, a Scala sem kivétel.
Ha valaki a kódolás legelemibb szabályait sem ismeri, akkor tényleg nagyon csúnya dolgokat lehet vele csinálni csakúgy, mint a legtöbb nyelven.
A programozzunk Scala nyelven, de fingom sincs se a programozásról, se a Scala-ról, akkor nyilván ilyen kódok fognak születni.
Megnyugtatlak, hogy ha X programnyelvet (képzeld ide a legszarabb nyelvet, amit csak ismersz) ismerő programozóknak rövid időn belül Y programnyelven (képzeld ide a legjobb nyelvet, amit csak ismersz) kell programozniuk, úgy, hogy nincs kód review (a páros programozásról már nem is merek beszélni), és nincs egy-két az adott nyelven tapasztalt programozó, akkor ugyanilyen projekt fog születni és azoknak a programozóknak is meg lesz a véleményük az Y programnyelvről.

Mondod ezt egy statikusan típusos nyelvre. :) IDE támogatás nélkül valóban nehéz, bár ha nagyon akarod mindenhová kiírhatod a konkrét statikus típust. Egyedül az implicitekre tudnám azt mondani, hogy azok tényleg rendesen be tudnak kavarni, ha rosszul használják őket, azokkal vigyázni kell.

A vicc az, hogy más fp nyelveknek (pl. F#) még jobb a type resolutionje, még kevésbé látod a kódból a típusokat. :)

Amikor elkezdtem Scalazni durván másfél éve, előtte programoztam már Erlangban, illetve JS, valamint C# funkcionális elemeit is használtam már. Akinek nincs ilyen háttere annak nem ajánlanám, első fp nyelvnek kicsit tényleg erős.

( horvatha | 2015. 12. 15., k – 08:35 )

Igaziból: Python.
De a C sem rossz, azt jelöltem.

( NevemTeve | 2015. 12. 15., k – 10:47 )

<troll>
Kedvenc nyelvem a <randomword>: híres arról, hogy még soha semmilyen kritikus alkamazásban sem okozott hibát <randomword> nyelven írt program. (Ja, hogy használták-e már kritikus (vagy bármilyen) alkalmazásban? Hát még nem, de már lelkes közössége van a usenet-en.)
</troll>

( janu v | 2015. 12. 15., k – 11:23 )

Azt hiszem, akik ekézik a Pascalt, nem igazán tanulták a programozást, csak úgy „belenőttek” (hogy udvariasan fogalmazzak). Oktatási célokra ma is tökéletesen megfelelő és egészen jó alkalmazásokat lehet benne írni.

Az a baj, hogy a programozók nem célorientáltan választanak nyelvet, hanem divat szerint. Így aztán rendszerszintű programokat írnak C++-ban és csodálkoznak, hogy nincs az a memória, ami elegendő lenne – mert senki nem szólt, hogy nem arra való. Mint ahogy meg lehet írni assemblerben is egy adatfeldolgozót, csak éppen...

Azt meg már félve jegyzem meg, hogy a basic hová tűnt? Már csak Kemény János miatt is... Arról nem is beszélve, hogy komolyabb irodai csomagok makró nyelvének az alapja,
----------
Registered Linux user #46079

Nem vagyok programozó, de felkeltetted az érdeklődésemet. Tudnál valami olyan írást linkelni, ahol átnézik, hogy milyen típusú feladatokra milyen (típusú) nyelvet kell/érdemes/ajánlott választani? Lehetőleg valami magyarázat félével megtámogatva.

Köszi előre is.

--
Csaba

( prion | 2015. 12. 15., k – 12:20 )

nem tudom mennyi értelme ennek a szavazásnak. szerintem inkább azt méri, hogy ki melyik nyelvet ismeri igazán mélyen, melyikkel dolgozik, így melyikben tud a legkönnyebben megoldani problémákat.

Nem, nekem erről az jut eszembe, hogy binárist írunk úgy, hogy abból valami értelmes forrás kijöjjön.
Anno 96-97 környékén, amikor az első gépemet megkaptam, akkor azt hittem az a programozás (és ezt próbáltam is művelni), hogy ncedit-be megnyitunk egy command.com-ot (vagy más tetszőleges binárist), és írogatunk bele valamit... Akkoriban járt egy párszor "a szerelő" nálunk. :)
Aztán pl. arra rájöttem, hogy az olvasható üzeneteket másra át lehet írni, csak a hosszának kell ugyanannak maradni.
De ugyanebben az időben volt az is, hogy a config.sys-be rendőrvicceket írtam, utána nem annyira bootolt a rendszer... De rég volt már. :)
--
The Community ENTerprise Operating System

( Tomito | 2015. 12. 16., sze – 10:25 )

Pascal helyett mondjuk lehetne Ada, vagy is-is ...
(by the way, a lisp-et is lehet compilálni ;) )
--
Avoid hangovers, Stay Drunk!

( Soultrane | 2015. 12. 16., sze – 14:47 )

Kiváncsi vagyok hány emberre igaz a Pascal-t jelölők közül hogy "basztam továbbképezni magam az iparba kikerülésem után".

Persze, azonban egészen elenyésző százalék használ C-t rendszerprogramozásra és az alkalmazásfejlesztésben nagyon durván túlreprezentált az aránya, holott arra sok-sok alkalmasabb (sok esetben még egy ObjectPascal!) nyelv elérhető.

Egyébként jobban belegondolva, a (Turbo) Pascal és a Delphi volt az a két nyelv, amit leginkább arra használtak csak, amire kitaláltak.

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

Kb. hét év Java (három különböző mobil platformon + SE), másfél év embedded C, 2 év Objective C, négyféle különböző assembly, és egy rakás egyéb nyelv érintése rövidebb feladatokra az továbbképzésnek minősül vagy nem? ...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( NevemTeve | 2015. 12. 17., cs – 05:58 )

(Azért kíváncsi vagyok, hogy akik itt a leglelkesebben szólnak le programozási nyelveket (és az azokat használó fejlesztőket), voltak-e már benne a hobbizáson túlmutató valódi programozási munkában... Ahol eleve adott számtalan hardver+szoftver peremfeltétel, és nem kérdezik meg a programozót, hogy 'Kedves fiam, nem akarod esetleg Commodore Amiga hobbigépen SmallTalk-ban vagy BrainFuck-ban csinálni ugyanezt? Azt ugyan nem tudnánk beilleszteni a projektbe, amin még tizenkét ember dolgozik, de a te személyes preferenciáid mégiscsak fontosabbak, mint a közös munka!')

Rengeteg C es pythont kodot irtam. Elobbiek kozott van olyan ami egy atomeromu rendszerein is fut. Mindket nyelvet szivbol gyulolom. A python raadasul meg szar is.

Csak a pelda kedveert, hogy lehet ugy leszolni es utalni nyelveket, hogy melyen ismered es komoly tapasztalatod van veluk.

--
|8]

+1

Nyelvet még csak-csak lehet szidni bizonyos objektív jellemzők alapján, de inkább szubjektív az egész. A programozót meg főleg nem érdemes leszólni, már csak emberileg se.

Én például Pascal és C kezdés után kötöttem ki C#-nál és majdnem 10 évig toltam. Láttam közben párszor Javát, de sose tetszett. Aztán úgy hozta a sors, hogy Javás fejlesztő lett belőlem. Egy hónap volt megtanulni, és mondjuk negyed-fél év igazán kiismerni és elfogadni (odáig nem mennék, hogy meg is szerettem). Még mindig jobban tetszik a C# (és ez már határozottan objektív okokból, lévén jól ismerem mindkettőt). Végső soron elég hasonó mindkettő, a nyelvi feature-ökön kívül rengeteget számítanak a mellé adott eszközök (IDE, libraryk), de még ezekkel együtt is amit meg lehet csinálni egyikben, azt kb. ugyanannyiból meg lehet csinálni a másikban is. Ugyanolyan embert kíván mindegyik, és egy idő után már nem azt mondja az ember, hogy én C# programozó vagyok, vagy Java programozó vagyok, hanem úgy általában programozó.

Ja, volt közben még PHP is, talán nekem szubjektíven az a leges-legszörnyűbb (lásd még http://phpwtf.org, de ilyen WTF-ek vannak még pár nyelven, asszem Pythonra meg JS-re is gyűjti valaki).

--

off: de azért az feltűnt, ugye, hogy az előbbi hsz nem általában a szavazásra és a topikra vonatkozott, hanem kifejezetten a 'ex cathedra kijelentem, hogy szar az X' és 'hülyéknek való az Y; tudom, mert egyszer már próbáltam' stílusú beszólásokra -- fenntartom, hogy ezek tipikusan hobbiprogramozóktól származnak.

( Tomi87 v | 2015. 12. 21., h – 12:45 )

Aki Scalat jelolt, az reagalhatna egy masik (altalam inditott) topicban irt hozzaszolasomra, vagy itt erre. Nekem eddig ugy tunik, nem az a helyes irany a funkcionalis programmozas fele vezeto uton, de szivesen olvasnek tobb HUP-os reakciot a linkelt videokra.

"Nekem eddig ugy tunik, nem az a helyes irany a funkcionalis programmozas fele vezeto uton".

Nem igazán értem, hogy ezzel mit akarsz mondani. Funkcionális programozást szeretnél tanulni és szerinted nem alkalmas erre a Scala, (hanem inkább a Haskell)?
Ha erre gondolsz, akkor szerintem jó bármely funkcionális programozási nyelven tanulni, mert nem a nyelv a lényeg, hanem a módszer. A nyelvet könnyű megtanulni, de a módszert nagyon nehéz.
Elkezdeni bármelyik nyelv jó lehet (Lisp, Scheme, Scala, Haskell, Clojure, F#, ...).
A megismert módszereket viszont sok nyelvnél lehet alkalmazni, nem kell, hogy (pure) funkcionális nyelv legyen, pl. akár Java-ban is.

Nem, nem ezt szerettem volna mondani. Igazabol most inkabb kerdeztem, es az sem a tanulasra vonatkozott. Inkabb arra, hogy ha manapsag egy ceg ma a funkcionalis programozas fele nyitni szeretne, akkor az legtobbszor Scala-t jelent, holott ott az a sok alternativa amit te is felsorolsz. Ok, Scala mellett szolhat, ha mar van meglevo JVM-en futo kodbazis, de...

...okke, azt hiszem ezt most megvalaszoltam magamnak iras kozben. Scala mogott ott van a TypeSafe, ami masik nyelvrol nem mondhato el. Jo, F# mogott meg az MS, de az irrelevans ha csak a JVM-re fejleszto ceg nem akar platformot valtani.

Szerk.: ja es hallani szerettem volna, hogy a (foleg az elso) videoban emlitettek mennyire vannak jelen egy Scala fejleszto mindennapjaiban, illetve, hogy hogy kezelik ezeket a problemakat, ha kezelik, vagy hogy mi ezekrol a velemenye annak, hasznalja.

Ugyanazért, amiert nagyjabol az osszes OO nyelv vesz at elemeket az FP-ből: vannak problémák, amiket FP-vel nagyon kényelmes megoldani és vannak, amit imperatív módon.

Nem véletlen használunk SQL-t is és nem véletlen, hogy idővel ahhoz is megjelentek az imperatív elemek, pl. tárolt eljárások.

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

Nem olvastam vegig, de az OP megertese nem okozott problemat, pedig a matek tudasom eleg silany. Monadokat szeretik matekkal magyarazni, persze. Olvastam N+1 ertekezest roluk, felet sem ertettem. De szerencsemre akadt par praktikus "monad tutorial" is, ami halandok szamara is emesztheto. Igy megintcsak sikerult kikerulni a melyebb matematikai ismereteket!

Nomeg vagyok annyira bator - es botor -, hogy siman hasznalok olyan dolgokat amiket nem teljesen ertek. ;)

--
|8]

Mi egy webes projecthez használunk Scalat, Scalatra a HTTP-hez, Scalikejdbc a db kapcsolathoz, meg még pár lib ami épp kellett, de Akka nincs. Én úgy látom, hogy az OOP és a funcprog szépen ki tudják egészíteni egymást, OOP-vel szervezed a projectet, szeparálod és absztraktálod a rétegeket, míg funkcionálisan implementálod a funkcionalitást (pun not intended). Persze keveredik is a kettő, simán lehet egy absztrakt típusod egy függvény, amiket aztán különböző módokon implementálsz (pl. különböző sort stratégiák).

( kleinie | 2016. 01. 07., cs – 15:46 )

Nem programozok, de ha programoznék az biztosan C lenne.

Felhasználói programok írására pl. pont nem jól használható. Oprendszer írására is igazából nagyon határeset.

De a legnagyobb kedvencem, mikor valaki megpróbálja az OOP-t újrafeltalálni a C-ben (meglepődnél, hányan teszik), ahelyett, hogy inkább valami OO nyelvben teszik, ahol legalább átlátható kód fog születni.

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

Nezd, az, hogy egy kisebb részénél valóban a C kell, nem jelenti azt, hogy mindent C-ben kell megírni. Eleve érthetetlen, hogy amikor egy struct+fv pointer kupaccal újra feltalaljak az OOP-s nyelvekből ismert interfaceket, miért nem egyből választanak egy olyan nyelvet, ami támogatja azt alapból.

Nem véletlen, hogy annyi kutatási vagy hobbiprojekt van, ahol C++-ban, vagy akár valami managelt nyelven írnak oprendszert, legyen az Java vagy Singularity. Ugyan utóbbinál sem lehetett teljesen megúszni a C-t, de meg lehet nézni, mennyivel tisztább a kódja, mint egy C-ben írt OS-nek.

Hja és oprendszer != kernel.

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

> Nem véletlen, hogy annyi kutatási vagy hobbiprojekt van,

Használhatót mondj egyet is :-)

> Hja és oprendszer != kernel.

Így is van, és ott már miben is fejlesztenek? Mindenfélében. A faék egyszerűségűeket/low level cuccokat többnyire C-ben, de a bonyolultabbakat másban.

Egyébként - a régi vita - megnézném mire jutnátok erőforrásban szűkös embedded környezetben C nélkül. IMHO megint egy másik szemszögből, másik szemüveggel nézed a dolgokat.

Egy fokkal. Sajnos túl sokat enged meg. Egyébként attól, hogy valamit valamiben írtak meg, még nem lesz igazolt, hogy az a legjobb megoldás, csak az, hogy megoldható. Mi nem is azt firtattuk, hogy nem lehet megoldani, csak azt, hogy lehetne jobb is.

És még mindig nem csak C meg C++ van a világon.

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

"Egyébként - a régi vita - megnézném mire jutnátok erőforrásban szűkös embedded környezetben C nélkül. IMHO megint egy másik szemszögből, másik szemüveggel nézed a dolgokat."

Nem csak erőforrásokban szűkös embedded környezet van. Bár kérdés, hogy egy iPhone minek számít.

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

Szerinted az miért nem megoldható (vagy lenne megoldható), hogy létezzen olyan programozási nyelv, amelynek kétféle szemantikája van:
1. Alacsonyszintű, runtime ellenőrzéseket nem végző szemantika, itt minden a programozó felelősségi köre. Itt például nem szól senki semmit, ha túlcímzel egy tömböt.
2. Magasszintű, runtime ellenőrzéseket is végző szemantika, itt a runtime szól, ha túlcímzel egy tömböt.
Maga a nyelvtan (szintakszis) ugyanaz, de a szemantikája más a két kódnak, és a fordító feladata, hogy milyen binárist generál.

Persze a két szemantika szerint elkészült binárisoknak más a runtime-követelménye és szemantikája is, ezért nem keverhetők.
Az első használható embedded rendszerekben, ahol nincs semmiféle runtime type-checker, bounds checker és társaik, cserébe sokkal pontosabban kell programozni míg a másik meg jó a nem embedded-környezetben is, cserébe produktívabb a programozás.

Vagy hogy egy más megközelítést adjak: utasítod a compilert, hogy fordítson be, vagy ne fordítson be minden tömb hozzáférés, vagy memóriacímzés elé egy határellenőrzést, amely assertation failed hibát ad, amennyiben az ellenőrzés sikertelen.

Azért nem praktikus, mert a két nyelv esetén eltérő forráskódot is ír az ember.

Az 1-es típusú nyelvben neked kellene "if (xyz == null)" ellenőrzéseket a kódba tenni (különben sechole), a 2-esben nem (legalábbis sok esetben fölösleges, redundáns).

Az 1-es típusú nyelvben a runtime-nak nem lenne muszáj eltárolnia a tömbök méretét, ergo neked kell olyan adatstruktúrát definiálnod, ami tudja a saját hosszát (különben sechole), a 2-esben a gyűjtemények tudják a maguk hosszát (illetve te is tárolhatod, de teljesen fölösleges).

Egész más forrást ír az ember, ha van GC, mint ha nincs.

Más megközelítés. A sok pointer mágia miatt nem hiszem, hogy egy C-szerű nyelvet lehetne biztonságosra fordítani. Viszont egy C#-szerűt lehetne nem biztonságosra, ha eltávolítod belőle az ellenőrzéseket. Szerintem nem lesz sokkal gyorsabb, viszont nem lesz értelme. Nem lesz gyorsabb, mert pl. a C# szintaxisa és VM-je elég magas szintű dolgokat is enged neked, ami egy gyenge rendszeren mindenképp lassabb lesz, mintha tök nyersen implementálnád optimalizálva ugyanazt. És nem lesz értelme, mert egy magas szintű nyelvben az embernek direkt nem kell csomó mindenre odafigyelnie, és az overhead nélkül nem tudna működni. Nem csak ellenőrzésekről van szó, hanem pl. osztályok közötti öröklődésről, reflection, stb.

--

"megnézném mire jutnátok erőforrásban szűkös embedded környezetben C nélkül"

https://www.youtube.com/watch?v=o5m0m_ZG9e8

https://github.com/JinShil/stm32f42_discovery_demo/blob/master/README.md

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."
Instant Coelho

Külön szép a bad meg az ugly rész -> ilyenek miatt komoly munkában nem használnám. Különben ha már ilyet keresel, a .NET Micro Framework jobb ellenérv lett volna (bár eddig nem tudok róla, hogy bármi komoly helyen használnák)

Értem amúgy, hogy szőrszálhasogatunk, de amennyire látom, saxusnak úgy en bloc a C/C++/D-vonal nem tetszik, egyszerűen ő szerintem a hardvertől távoli vonalon van (ami nem bűn), ahol ezeknek a nyelveknek a lazasága tényleg problémás (másutt is az, csak az előnyei nagyobbak).

C-ről beszéltem és csak is a C-ről. C++-ról is csak annyit említettem meg, hogy nem arról beszéltem. D-ről még csak említést sem tettem. (Sajnos nem ismerem annyira a nyelvet, hogy tudjak róla nyilatkozni érdemben.)

C++-al nincs egyébként különösen bajom, leszámítva, hogy hordoz magában egy csomó olyan dolgot, amit nem kellett volna (jellemzően C-s ökörségek, legalább azokat megfixálhatták volna), illetve nagyon kellett már a C++11/14. De talán most jobban megindul a fejlődésben.

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

Hja és oprendszer != kernel.

ez vilagos, de a userland tool-ok zome is c-ben van megirva

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Kétoldalú kérdés ez. Ugyanis az nyelvi hiba, ha te a runtime-tól egy 50 méretű tömböt kérsz, és túl tudod címezni. Egy 50 méretű tömböt nem lehet túlcímezni elméletben. Így a nyelvnek sem kéne megengednie szemantikailag azt, ami gyakorlatban runtime ellenőrzést jelent.
Az egy dolog, hogy mivel a C alacsonyszintű nyelv, megenged mindenféle memória-manipulálást, és a tömb adatstruktúra nem valójában tömb, csak egy syntax sugar egy pointerre.

ez igaz, de meg mindig tartom, hogy a programozo nemtorodomsege, ha az 51. elemet is ki akarja olvasni.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Így is fel lehet fogni, de attól még nem lesznek jobbak a szoftverek. Az egésznek pedig erről kellene szólnia.

Picit olyan, mintha volna egy megfelelő csavarkulcs készleted, de te mindent egy kombinált fogóval akarnál megoldani, aztán ha sérül a csavar, mert nem egyenletes az erők elosztása a programozót hibáztatnád, hogy rosszul tartja...

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

Ezért mondom, hogy ez részben igaz. De például az a nyelv hiányossága C-ben, hogy van egy adatstruktúrád (tömb), aminek nem tudod lekérdezni a méretét, így ezért a függvényekben szépen át kell adogatni a méret paramétert. Ez gányolás. Ahelyett, hogy a tömböt be tudnád járni rendesen.
Ne feledd: a tömb az nem egymás utáni memóriacímek halmaza (persze így könnyű implementálni), hanem egy indexelhető adatstruktúra. Van mérete és egy indexelés operátor. Nos, C-ben nem csak tömböt tudsz indexelni, hanem tetszőleges pointert, és tömb méretet nem tudsz lekérdezni. Persze működik a stacken lefoglalt tömböknél a sizeof(array) / sizeof(element type), de ez a heapen lefoglalt tömböknél már nem működik.

Plusz, külön extra, amikor ez sem számít. Pl. itt van ez a függvény: 

size_t PQescapeStringConn (PGconn *conn,
                           char *to, const char *from, size_t length,
                           int *error);

Aztán meg:

"A terminating zero byte is not required, and should not be counted in length. (If a terminating zero byte is found before length bytes are processed, PQescapeStringConn stops at the zero; the behavior is thus rather like strncpy.) "

Ez így nekem egy rák.

(Különösen muris, hogy az egészre úgy derült fény, hogy PHP-ben megpróbáltam egy serializált objektumot text-ként eltárolni, ami tökéletesen működhetne, ha nem lennének retardok a PHP fejlesztői és az addig csak sima karaketerek mellé nem használtak volna egy \0-t is. Mondanom sem kell, mikor felfedeztük, már akkor évek óta több bugreport készült erre, hogy ez így szar.)

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

Mi még 2000-es évek előtt is remek felhasználói programokat írtunk C++-ban.
Azóta a nyelv rengeteget fejlődött, lásd C++11, C++14.
Ha meg az olyan rendszerekre gondolunk, mint a Qt, akkor sok hiány érzetünk sem lehet.
Én magam sem tartom a legjobb nyelvnek a C++ -t, de azt azért elismerem, hogy általános célú programnyelvnek elég jó!

Nem értetted: újrafeltalálni az OOP-t C-ben = valamilyen kódolási konvenciót és library supportot kitalálni arra (újrafeltalálni), hogy OOP-ben programozz.
És de, újrafeltalálod, ha mondjuk nem meglévő eszközkészletet használsz, pl Glib.
De a legjobb megoldás még mindig egy OOP nyelv. Ne te találd ki, hogy hogyan nézzen ki a programozási nyelved, mert az minden lesz, csak nem hatékony programozás.

gobject mesehez az is hozza tartozik, hogy nem csak kozvetlenul C -bol lehet hasznalni,
Van binding minden fele nyelvhez, for ex. GTKSharp ahol nem is nez ki hulyen a hasznalata (nincs sok explicit cast ill. typus megjeloles).

C-libek ujra hasznosithatosaga igen magas, `write once use everywhere` nevu bohockodas-rol is beszlhetnek.

Mar a C++ ban irt libek mindutt valo hasznositisa sem olyan egyszeru,
gyakran azzal kezdodik, hogy butisd le C -re az interfacet.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

pl.: http://commons.apache.org/proper/commons-jelly/

Eleg sok XML alapu technologia helyett, jobb/egyszerubb volna valami
script nyelvet hasznalni engendni.

Alltalanosagban, nem akarom elitelni egyik technikat sem, enterspajz teruleten
eleg fura use casek szoktak szuletni a ceg szervezodese miatt.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Lua ill. python .. tcl .. hasznalta nem ujdonsag C/C++ kodbol sem."
Nem errol van szó, hanem mondjuk C++ classok hívása Lua kódból. Persze köszönhetően a nem definiált, ezért fordítóspecifikus name-manglingnek, orbitális szopás az egész. Javanal ilyen nincs, a bináris formátuma jóldefiniált.

... Java is currently number one in the enterprise back-end market and number one in the still growing mobile application development market (Android). Moreover, Java has become a language that integrates modern language features such as lambda expressions and streams. The future looks bright for Java.

( mrceeka v | 2016. 04. 10., v – 17:57 )

Az én kedvencem ez:

ʌlǝʎu ᴉsɐzoɯɐɹƃoɹd

Elnézést. :D

Üdv,
Marci