keresek egy nyelvet

Fejlesztés

Keresek egy nyelvet ami az alábbiakat tudja:
- alapból futtatható a végeredmény linux és windows alatt
- elég egyszerű, könnyen tanulható
- rendszer programozásra alkalmas
- van hozzá gui kiegészítő ha kell(nem ez a legfontosabb)
- van lehetőség hálózati programozásra is
- lehetőleg normális dokumentáció van hozzá

------ SZERK: -------
Talán nem fogalmaztam elég érthetően mindenben, elnézést kérek.
- Rendszer(szintű) programozás alatt azt érteném (lehet rosszul), hogy egy futó process-t ki tudjak lőni ha kell, vagy lássam a futó folyamatokat, listázni tudjam a csatolt usb eszközöket, stb...
- az hogy linuxon és windowson is fusson az alatt azt érteném, hogy lehetőleg natívan. nyilván nem ugyanaz a program lenne win és linux alatt, de lehessen megírni ugyanabban a nyelvben és ne kelljen még 3rd party cuccokat is bevonni.
- hogy mi a feladat: nincs feladat. egyszerűen szeretnék pár saját tool-t írni bizonyos rendszer felügyeleti helyzetekre és nem szeretném ezt hol bash-ben, hol c-ben, hol x nyelvben megoldani.
- a python jellegű dolgokat szeretném elkerülni, nekem egyszerűen nem tetszik. ez van :)

( Mcsiv v | 2018. 12. 16., v – 21:52 )

" - rendszer programozásra alkalmas" ezt azért fejtsd ki
egyébként: c/c++/c#/nodejs/gyakorlatilagbármi

// Happy debugging, suckers
#define true (rand() > 10)

Ez még nem rendszerprogramozás.

C#/.NET-ben alapból van rá függvény a System.Diagnostics-ban. .NET Core-n is van, fut Linuxon meg Windowson is. (Process.GetProcesses())

Core esetén nyilván deploykor mellépakolja a szükséges részt a keretrendszerből, gondolom itt fog elhullani a dolog.

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

( nxu | 2018. 12. 16., v – 21:54 )

> alapból futtatható a végeredmény linux és windows alatt

Ez mit jelent?

Hát ez az...

Tipikusan .NET-re és Javára mondják, hogy van "végeredménye", vagyis bináris, de nem futtatható alapból, mert kell hozzá runtime. De szinte minden létező binárishoz kell valami runtime. Tudok neked olyan C programot írni, ami nem fog minden létező libc-vel futni, tehát ahhoz is telepíteni kell. A scriptek meg ugye le se fordulnak binárissá, ahhoz is telepíteni kell valamit. Nem tudni, mire gondolt a kérdező.

Java Runtime-ot nem feltétlenül kell telepíteni, odateheted a programod mellé, és úgy is tud működni Windowson és Linuxon is (bár Linuxon nem próbáltam még). Akár USB stickről is lehet futtatni. Ez jó kompromisszum lehet, mert más nyelveken sem egyszerű megoldani ezt a problémát, itt kevesebb mint 100MB-ről beszélünk.

Akkor is jó lehet hozzáadni a runtime-t, ha ügyfélhez megy, és nem akarsz azzal szívni, hogy telepít egy újat, vagy leszedi ezt, és hirtelen nem megy amit te adtál neki. Ha mellé van téve a JRE, akkor az pontosan ugyanúgy fog működni függetlenül attól, hogy mit garázdálkodik a rendszergazda.

Oké, de a lyukasság nem probléma, ha mondjuk egy netet nem használó programról beszélünk. Plusz, ha bugba belerongyolsz, az a program szállítójának a problémája, aki vagy workaroundot ad rá, vagy frissíti a JVM-et.

A lényeg, hogy ha a programmal adom a JVM-et, akkor az az én problémámmá válik, hogy a programmal együtt frissítsem azt is, ha kell, viszont nem az én problémámmá válik, hogy a rendszergazda miket telepít és mikor.

Ha abandonware-ré válik a szoftver, tehát nincs aki küldje a frissítéseket akár újabb JRE-vel, az probléma, de semmivel nem más jellegű probléma mintha akármiben írt program abandonware-ré válik, mert akkor ott sem lesz biztonsági frissítés. Sőt, ha egyébként normális Java programról van szó, akkor a felhasználó saját szakállra megpróbálhatja frissíteni a JRE-t, ha már úgyis abandonware, akkor a készítő nem fog beleszólni.

Semmivel nem különbözik a probléma attól, mintha bináris programot szállítanék például dll függőségekkel együtt.

Azért két probléma van:
-az egész rohadt jre-t arra találták ki, hogy ezt ne kelljen csinálni, ott legyen a gépen a jre, és a te programod gépfüggetlen legyen
-és ott lesz a jre összes dll-függősége.

Azért biztos sokan láttak olyan fizetős programot, amit szépen megvettél, jött vele a jre, majd újabb linuxon egy-két funkció nem ment. Olyat is láttam, ami alól kilőve a saját jre-jét, ezek megjavultak, így még évekig nem kellett megvenni az új verziót.

Igen, ha rosszul csinálják, akkor van vele probléma, de mivel nincs? Pláne Linuxon! Vannak egyáltalán olyan régi Linuxos programok jelentős függőségi hálóval, amit simán lehet mai Linuxra telepíteni?

Épp ez az oka, hogy sehol nem szeretnek általánosságban Linuxra release-elni, hanem 1-1 verzióra készül a release, aztán ha más Linuxon akarod futtatni, akkor így jártál.

Baj, hogy így van, de fejlesztőként baromi nehéz ezt a problémát jól megoldani.

Windowson ha minden függőséget visz a program, és egyébként csak Win32-re épít, akkor ott még működhet régi program sokáig. A JVM egyébként pont ilyen, nem nagyon van extra függősége - én legalábbis még nem láttam olyat, hogy Windowson nem működött volna az odamásolt JVM.

Pláne ha már nincs szupport a szoftver gyártója részéről, meg új verzió, akkor bárminek a régi verzióját nehéz készenlétben tartani.

Na meg szoftver fejlesztőként alapvetően arra az időszakra érdemes tervezni, ameddig szupportot is adunk, aztán meg a vevő dolga, hogy hogyan tartja életben a programot :-). Például lecserélheti a JVM-et újra, azzal is működni fog, csak arra nem tesztelünk, mert mindenre nem lehet tesztelni.

Felhasználói (vevői) oldalról: amit csak lehet, olyan szoftverrel kell megoldani, ami szabványkövető, és forrás is van hozzá. Azt le lehet fordítani az általam használt linuxon, ha valami megváltozott, ahhoz hozzá lehet igazítani.
Ha nincs forrás, akkor később, ha csak meg akarom nézni a saját régebbi dolgaimat, már ahhoz is lehet, hogy meg kell venni az új változatot, és lehet, hogy addigra már nincs is kitől.

Azt irta mar valaki, hogy JVM-en futo programot (nem csak Java-t, gyakorlatilag barmit) GraalVM-mel nativba fordithatsz?

http://www.graalvm.org/docs/reference-manual/aot-compilation/

Ez a GraalVM amugy is egy eros dolog, ettol fuggetlenul is erdemes nezegetni, nagyon popec cucc.

( Foltos | 2018. 12. 16., v – 22:04 )

Linux és windows között hordozható rendszer programot (ez kB a driver) még nem hordott a hátán a föld.
Amit arról sejtek, hogy mit szeretnél az alapján a Pythont keresed.

Kicsit kifejthetnéd mit szeretnél csinálni.

( bocs | 2018. 12. 16., v – 22:19 )

c# nagyszerű választás
- multiplatform
- a legtöbb feladatra nagyon jó teljesesítményű
- logikus, pont úgy működik, ahogy várod, nem kell ezres nagyságrendű szabálysereget észben tartani, hogy tudjad használni (mint c++)
- nagyszerű, igencsak teljes, szabványos osztálykönyvtár serege van
- FUN! öröm vele programozni a fentiek miatt + rendkívül produktív vele munka (átlagos fejlesztő c++ fejlesztéshez képest kb 3x produktívabb, jó fejlesztő 5x)

Vagy vannak, vagy van hozzá nuget. Már, ha a .NET Core-t érted és nem a Framework Class Libraryt.

De HTTP-re ott a Kestrel + ASP.NET Core (nuget packageban nyilván), JSON-ra meg ott a json.net (szintén nuget). De igazából .NET Core esetén feldaraboltak mindent nuget packagekra, hasonlóan, mint ahogy egy linux distro is összeáll. Még a System.Console is külön nugetbe került pl.

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

( kantal | 2018. 12. 16., v – 22:32 )

Akár a Python3 is lehetne:
- alapból futtatható a végeredmény linux és windows alatt igaz
- elég egyszerű, könnyen tanulható nagyon igaz
- rendszer programozásra alkalmas Mit kell ez alatt érteni?
- van hozzá gui kiegészítő ha kell(nem ez a legfontosabb) igaz, és multiplatformos
- van lehetőség hálózati programozásra is nagyon igaz
- lehetőleg normális dokumentáció van hozzá nagyon igaz

--
eutlantis

Mi ez e düh?
Én Pythonban is és C-ben is programozok, és mégsem mondom, hogy az egyik jobb mint a másik.

"vagy problémát oldunk meg..." Azt. A megoldandó problémának megfelelően választom a C-t vagy a Pythont. És nem félek az "űrtől", azaz a space-ktől, amiknek a kezelését egy rendes IDE vagy prog.szerkesztő leveszi a vállamról. :-)
--
eutlantis

Egyszer kollégával egy napig nyomoztunk egy integrációs teszt hibát. Úgy tűnt minden jó, kézzel kipróbálva a kód jónak tűnt, a teszt még sem ment.
Egy refactor reformat eredményeként egy sor egy tabbal kintebb került. Pythonban fejleszteni olyan mint aknamezőn sétálni.
===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Nekem a VIM is visit ha nem jol indentalom a python programot. Nem kell ide modern IDE. Mi a pacikukinak? :D

Amugy ha gyorsan kell tranulni programozast, akkor a python-t javaslom en is. Gyors sikerelmenyt lehet vele elreni. Vagy a masik a javascript/nodejs/stb. ami szinten gyors es lathato eredmenyt hoz (csicsas weboldalak osszerakasa). Aztan majd ha mar feszegetjuk a hatarokat johetnek a java/c/.net stb.

De tanulasra nem javaslom a "daily pointer arithmetic sentences in C" kurzust. :D

Altalaban veve a tanulas egyik legfontosabb resze az, hogy elvezetet es sikerelemnyt nyujtson, hogy tovabbra is erdekelje a tanulot a dolog. Erre pedig a python nagyon is alkalmas indentalasi hulyeseg ide vagy oda. :D

+1, Anno a kártyára lukasztott fortran programoknál volt nagyon nem mindegy, hogy hol kezdődött sor :-)

Arra, hogy valaki nem képes/nem akar szép, olvasható forráskódot kiadni a kezéből, nem az a megoldás, hogy akkor a nyelv elemévé tesszük a tördelést - jó régen kitalálták már a kódformázó eszközöket, amik csapatmunkánál is szép, egységes arculatot tudnak adni a forráskódnak.

A szép, áttekinthető kód csak igényesség kérdése - nekem van nem kevés Perl-ben írt dolgom, amiket évekkel később sem gond olvasni és értelmezni - attól függetlenül, hogy a nyelv lehetővé teszi a sorminta-szerű, helyesen működő Perl kód elkövetését, amit alapból hátrányként szoktak emlegetni vele kapcsolatban. Ilyen jellegű megoldásokat egyszerűen nem használok ott, ahol miniális esélye is felmerül annak, hogy később is használni kell az adott programot - plusz normálisan kommentezem, hogy mit, miért csináltam.

( uid_952 | 2018. 12. 17., h – 00:17 )

Ha már a python ennyiszer elhangzott, akkor groovy (Ami gyakorlatilag java, csak scrit nyelvben). Idea ismeri, Eclipse kevésbé.

( riverman | 2018. 12. 17., h – 00:21 )

Hat igy elso blikkre talan a go(golang) a megfejtes.

- alapból futtatható a végeredmény linux és windows alatt --> true; kb. mindenre lefordul azonos kodbazisbol
- elég egyszerű, könnyen tanulható --> true
- rendszer programozásra alkalmas --> true
- van hozzá gui kiegészítő ha kell(nem ez a legfontosabb) --> electronnal megoldhato. true?
- van lehetőség hálózati programozásra is --> true
- lehetőleg normális dokumentáció van hozzá --> true

-------------------------
Roses are red
Violets are blue
Unexpected '}' on line 32

+1

Zero (0, semmi, nix, nyista) Go ismerettel a nullarol egy nap alatt osszetakoltam egy olyan programot magamnak (teszteleshez), ami egy MQ-rol leszedte az uzeneteket, es egy bizonyos modon atformazva kirakta oket stdout-ra. Ebben benne volt a "fejlesztokornyezet" installalasa, teszteles, stb. Eszmeletlenul gyorsan produktiv lehetsz benne. Viszont a UI-t felejtsd el - nem arra valo. A unix-tipusu programok irasara valo (kis program -> egy dolgot csinal, de azt jol), nativra fordul, es van hozza mindenfele lib.

Az igazan erdekes reszet meg nem probaltam (a channeleket), bar az MQ-hoz kellet az is, de az inkabb csak copy-paste volt, megertes nelkul. Viszont ugy tunik, a konkurrencia kezeles is benne van a nyelvben, mint elsodlegesen tamogatott feature, ez a mai vilagban igencsak elonyos :)

( Oregon | 2018. 12. 17., h – 06:57 )

"- alapból futtatható a végeredmény linux és windows alatt"
"- rendszer programozásra alkalmas"

Lehet azt a frameworkot, akkor neked kell elkészíteni.
....vagy define(rendszer)?

Szerintem ott akad el a 3rd part, hogy a különböző oprendszerek különböző filozófiájúak. Egy unix fájl jogosultsági rendszer pl nagyon különbözik a win-től. Persze lehet emulálni a dolgot, de akkor NEM alacsony szinten férsz hozzá a rendszerhez. Az X is eléggé különbözik a win felülettől programozástechnikailag, bár itt vannak mindkét rendszeren hasonlóan működő grafikus fejlesztő-környezetek.

Vagy ott van pl az rtc programozás. Azzal, hogy a unix alatt MINDEN fájl, eléggé más technikát igényel, mint a win. Persze vissza lehet nyúlni port szintig. (Apropó, win alatt van ioperm()?)

Persze azt meg lehet csinálni, hogy

#ifdef win31
// valami_win.c
#elif
// valami_unx.c
#endif

de gondolom ez nem az, amire a költő gondolt.

Alapvetően az a gond, hogy az operációs rendszerekhez való alacsonyszintű hozzáférés NINCS szabványosítva (ha nem veszem ide mondjuk a C standard könyvtárat).

> Sol omnibus lucet.

( enpassant v | 2018. 12. 17., h – 07:19 )

Scala native,
Kotlin native,
Rust,
D

( meditor | 2018. 12. 17., h – 09:13 )

Ez a nyelv a 'C' (-::
> Sol omnibus lucet.

( saxus | 2018. 12. 17., h – 09:41 )

Egyáltalán mi a feladat?

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

( NevemTeve | 2018. 12. 17., h – 10:26 )

A 'rendszer programozás' az valamilyen politikai dolog? Vagy csak azt jelenti, hogy fájlműveletek is vannak a dologban?

Szerk: most látom: https://hup.hu/node/162141#comment-2297217

Hát, már maga az hogy 'process' egy eléggé OS-specifikus dolog...

( saxus | 2018. 12. 17., h – 10:30 )

Hogy ezt mennyire lehet rendszerprogramozásnak hívni... Ez azért nem annyira alacsony szinten van.

Na, ha olyan szoftvert akarsz írni, ami Linuxon és Windowson is megy szívás nélkül, akkor vagy azzal fogsz szívni, hogy mindkét rendszeren külön oldod meg, vagy keresel olyan libeket, amiket ez megoldja. Mindenre úgy sem fogsz (USB eszközökben szinte biztos vagyok).

Amivel tudod egyszerűsíteni az életed az az, hogy elindulsz valami platformfüggetlen nyelvel (Java, .NET Core), aztán maximum lesznek platformfüggő részei. Nem fogod tudni teljesen megúszni és azt sem, hogy teljesen vegyes librarykat húzzál be. Még Windowson is lesz majd, hogy be kell húzni Win32-es DLL-eket. .NET FW alatt ezt könnyű, .NET Core és Java alatt nem próbáltam.

Ha igazából csak programozást akarsz tanulni, akkor lehet egyszerűbb lenne elengedned a platformfüggő részeket.

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

( sigellef | 2018. 12. 17., h – 11:02 )

c
elvileg linuxon, windowson bármit meg lehet vele csinálni, ha pedig csak az alapvető függvénytárakat használod, akkor pedig semmit nem kell telepíteni sem a fejlesztői gépre, sem a felhasználó gépére. (ha csak az stdio.h-t használod, elvileg még DOS-on is lefordítható)
Ha egyéb függvénytárakat is használsz: Ha statikusan linkelve fordítod, akkor csak a fejlesztői gépre kellenek a plussz függvénytárak.
Amire még ügyelni kell: ha 64 bites rendszeren fordítod, akkor 64 bites lesz a binárisod, 32 bites rendszeren nem fog futni.
Linux esetén az alapvető függvénytáraknak úgy tudsz utánanézni, hogy letöltöd a glibc csomagfájlját, és megnézed, hogy mi van a csomagfájl/usr/include mappában.
Ha nagyon mélyen a rendszerhez akarsz nyúlni, akkor a linux-headers csomagból is használhatsz függvénytárakat, de azok csak linux esetén használhatóak.
c++: Ugyanaz mint a c, csak a felhasználónak telepítenie kell a libstdc++ függvénytárat. (legalábbis némely disztribúcióknál). Valamivel nehezebben tanulható mint a c.

Mindkettőre igaz:
-Hálózati programozáshoz mindkettőnek rengeteg függvénytára van.
-Nem egyszerű, de könnyen tanulható
-Ha csak az alapvető függvénytárakat használod, akkor Linuxon és Windowson is lefordul.
-Rengeteg dokumentációt és segédanyagot lehet találni.
-GUI nincs hozzájuk, de sok szövegfájlszerkesztő tudja szintaktikailag szinezni a programkódot. (gedit, pluma, mcedit, stb...)

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( Chain-Q v | 2018. 12. 17., h – 11:25 )

Amit keresel Pascalnak hívják. Az utolsó praktikus, kezdőknek is jól használható, de profiknak sem korlátozó alkalmazásfejlesztő nyelv, aminek nem kapsz agyrákot a szintaktisától (hello C++) és GUI fejesztésre is erősen alkalmas, de valahol, valakik eldöntötték, hogy uncool, és erről azóta sem lehet a világot lebeszélni. Natív binárisba fordul lóméretű futtatókörnyezet nélkül (Linuxon még libc nélkül is működik), van platformfüggetlen API egy rakás dologra, de a teljes low level C ill. Win API elérhető ha kell, és könnyedén linkelsz C könyvtárakat. Még inline asm is van. A Free Pascal az instantfpc nevű kiegészítővel kvázi shell scriptelésre is alkalmas. GUI és adatbázis fejlesztésre a multiplatform Lazarus nevű RAD IDE elérhető végtelen számú ezt segítő csomaggal.

Én megnézném, hogy megfelel-e a céljaidra.

(Megjegyzés: a szerző a Free Pascal projektben aktív hozzájáruló.)

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

Pascallal kezdtem a programozást, sokáig programoztam benne, turbo/borlad pascal, delphi/lazarus cuccokkal, de nem ajánlanám, hogy valaki ebben kezdjen. Arra jó volt, hogy a programozás alapvető elemeit megtanuljam, változók, adatszerkezetek, utasítások, függvények, stb...
Aki pascal-ban kezd, aztán belemegy a c-be, annak eleinte valóban agyrákot okoz a c szintaxisa (meg minden másegyéb nyelv szintaxisa), és nehéz lesz megszokni a c-t... márpedig a linux+a rajta futó cuccok 95%-a c/c++ -ban van megcsinálva.
Ha valaki megtanulja a c-t, előbb-utóbb kezd értelmessé válni a linux forrása, a GNU cuccok forrása, függvénytárak forrása, és ha mélyen a rendszerbe akar nyúlni, akár elemezheti is őket, mielőtt programot ír rá, vagy használ belőle valamit. Nem egyszerű, és nem néhány hónap alatt kitanulható dolog, de ha pascal-t (vagy más egyebet) tanul, akkor esélytelen.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Remek, hogy C-ben megértheted a GNU könyvtárak forrását (én leginkább azt értettem meg belőle, hogy senki nem tud C-ben programozni rendesen, a legtöbb kód írtózatos JÁJ), de nem az volt a feladat, hogy az ajánlott nyelv platformfüggetlen is legyen? Szóval kezdjen a kérdező szopni MingW-vel és valami féllábas kevert POSIX vs. WinAPI kódot ajánlassz, esetleg Visual C és direkt Windows API, vagy a Windows verzió majd WSL-lel fut? :P

Ennél még a valaki által lentebb ajánlott C++ + QT-nek is több értelme van, bár szerintem kezdésnek az is elég erős, és minden csak nem userfriendly.

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

A WindowsXP+mingw+gcc -vel fordítottam már, és működik a végeredmény más windowsokon is, 7,8,10-en is. Megoldható, hogy Windowson lefordított cucc alapból, "natívan" futtatható lesz a többi Windowson, a Linuxon lefordított cucc meg a többi Linuxon. Olyan meg nem létezik, hogy egy adott bináris program mindkettőn alapból, natívan fusson.
Rendszerprogramozás + hálózati programozás bizonyos részei soha nem lesz platformfüggetlen.
Elvileg a microsoft is gyártott valami c fordítót, azt hiszem cl a neve, azt is lehet próbálgatni.
A kérdező programozni akar megtanulni, a legjobb ha kipróbál több dolgot. Hogy mi platformfüggő, és mi nem, azt úgy is csak idővel fogja megtanulni/megérteni.
QT, egyéb grafikus felület programozása: amíg nincs meg a libacomb, fölösleges azon agyalni, hogy milyen színű tepsibe süssük meg.
QT/GTK alapú cuccnál meg vagy statikusan linkel, és egy egyszerű kis program bazi nagy méretű lesz, vagy külön vonszolni kell a programmal a QT/GTK libeket.
A natívan futó programhoz még a pascal (fpc/gpc) is elég közel van.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Hát... Régen én is szerettem a Pascalt meg a Delphit, mert egy olyan eszköz volt, amit kivételesen arra is használtak, amire kitaláltak (alkalmazások fejlesztése).

Viszont ma már új projektet nem kezdenék benne.

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

Miért is nem kezdenél új projektet? Mármint, ha friss teamet kell hozzá verbuválni, akkor megértem, mert kevesen hajlandóak megtanulni (de így lesz ez a Java-val is hamarosan, ahogy kinéz), de saját kis munka-könnyítő projekteket miért nem?

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

Nem csak az, hogy teamet keresni. Az, hogy egy nyelv körül mekkora az userbase, az erősen befolyásolja azt is, hogy mennyi anyag érhető el hozzá: dokumentáció, leírások, kitaposott best-practiclek, libraryk, szopásokra (mert mindig van valami) kész megoldás, stb. Ha magamnak cisnálok valamit ÉS nem kifejezetten valami tanulás/kipróbálás célú dolgot, akkor általában a hatékonyságra törekedek és azt a megoldást választom, ami a legkevesebb időt igényli.

Másrészt, ha oda kell adnom valakinek, akkor tudom, hogy hozzá se fog szagolni, mert "jaj, fúj pascal".

Ezen kívül meg leginkább az, hogy C#-ban vagyok jelenleg a leghatékonyabb és azt érzem legkényelmesebbnek. Látom, hogy egy csomó minden megvan már Pascalban is a nyelvi dolgok közül, de ha csak magamnak írnék valamit, akkor nem vesződnék azzal, hogy még akkor nekiálljak felfedezni, hogy mik a különbségek. Gondolom, hogy valaohgy minden megoldható ott is, viszont a C# letisztultabb. (Még úgy is, hogy egy csomó featuret vitatható módon toltak be - pl. async - és igazából ráférne már egy takarítás a nyelvre).

GUI: WPF <3. *Minden* hibája ellenére is (van neki bőven). Fényévekkel előrébb jár, mint a VCL vagy akár a WinForms. Bevallom, wx-el, GTK-val meg Qt-vel keveset foglalkoztam, azt is régen, hacsak valamelyiknél nem történt valami radikális változás, amiből kimaradtam, akkor azokhoz képest is. (Talán a Qt-nél történtek, de azzal tényleg nem foglalkoztam kb. 9-10 éve.)

De ugyanígy, pl. egy webservice létrehozására az asp.net meglehetősen egyszerűen használható eszköz. És amióta van Core, a platformfüggetlenség is egyre kevésbé kérdés. (Főleg, ha még a WPF-et is portolja egyszer valaki)

Másrészt meg... Van egy csomó olyan design döntés a Pascalban, ami nagyon előremutató volt a maga korában (pl. unit rendszer a C-s header izéhez képest), de ma már erősen eljárt felette az idő.

És akkor még nem beszéltünk olyanokról, mint az elérhető toolok, IDE-k, stb.

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

Ez az uncool dolog eredete:

Kezdetben volt a Turbo Pascal, népszerű volt. Leálltak a fejlesztésével, de sokan tovább használták több évtizedig. A Turbo Pascal uncool lett, hiszen olyan valamit használtak, amit több évtizede nem fejlesztettek. Az emberek elfelejtették közben a "Turbo" szót is. De megmaradt: Pascal = uncool. Jött a FreePascal, de a fejekben már megragadt: Pascal = uncool.

Ui:
Ha legelterjedtebb operációs rendszereket C nyelven írják, és te megtanulod a C nyelvet, akkor gondolhatod, hogy te aztán menő vagy. Gondolhatod, azért is menőnek magad, mert a C nehezebb mint például a Pascal, és te C nyelvet ismered. Ezek után megértem, hogy beállasz azok táborába akik fikázzák a Pascal nyelvet.

A Pascal nyelv ettől függetlenül remek nyelv. Nehéz ez után mást meg tanulni? Kit érdekel. Nem ettől lesz egy nyelv rossz vagy jó. Egyébként meg: egy idő után már mindegy hogyan néz ki egy nyelv szintaktikája.

Jaj, ez nagyon vicces, különösen a szöveg megírása óta történtek tükrében, mert ugye "senki nem bízna egy ilyen pontosságú navigációt egy Pascal programozóra" és hogy mekkora igazi programozók dolgoznak a pályaadatokon NASA-nal, vs. Mars Climate Orbiter, ugye. :P

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

A Turbo Pascalt miben írták? C, assembly
Java futtató/fejlesztő keretrendszert miben írták? C
A DOS-Windows-t, miben kezdték írni? C
A C# fejlesztőrendszert miben írták? C
Perl, Python, Tcl/Tk miben írták? C, C++
PHP értelmezőt miben írták? C
Lua, wxLua miben írták? C, C++

Most akkor melyik a legjobb? :D

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

"A Turbo Pascalt miben írták? C, assembly"

Nem akarlak elkeseríteni, de Pascal előbb volt, mint C. Másrészt az első fordítókat ASM-ben írták, utána az egészet újraírták Turbo Pascalban. FreePascal szintén self-hosted.

"A C# fejlesztőrendszert miben írták? C"

Miről beszélsz? Visual Studioról? Fordítóról? Ha igen, melyikről? C#, C++ mellett még egy halom egyéb nyelv van. Másrészt a mostani compiler szintén self-hosted, tehát C# a 2/3-a, VB.NET az 1/3-a. C nem igazán van benne.

"A DOS-Windows-t, miben kezdték írni? C"

Ja, meg egy jó adag C++ van mellette, DOS-t meg egyenesen Assemblyben kezdték írni. Másrészt meg ismételten, melyik részét? KErnelt? Annak nagy része valóban C, C++. Userlandet? Egyre nagyobb része .NET vagy más.

"Perl, Python, Tcl/Tk miben írták? C, C++"

Egyébként mi az, hogy "x _NYELVET_ miben írtak"? És konkrétan melyik implementációról van szó? Pl. Python esetén a CPython mellett egy halom más implementációja létezik a nyelvnek, pl. Jython (JVM) vagy az IronPython (.NET).

"Java futtató/fejlesztő keretrendszert miben írták? C"

Legtöbb Java IDE Javaban íródott. Tehát akkor miről beszélünk? Eclipse Java-s, JetBrains cuccok Java/Kotlin, utóbbi szintén JVM felett fut, szóval megint miről beszélünk?

Szóval, ha már trollkodni akarsz, legalább csináld jól.

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

Szerintem egy alap JVM-et megírni nem egy nagy kaland, persze a JIT meg ilyesmi már kicsit macerásabb, de egy sima bytecode interpreter nem olyan nehéz. (Függetlenül attól, hogy miben írod.) Amúgy a Free Pascal tud Java bytecode-ot fordítani, szóval még a tesztprogramokat is megírhadnád hozzá Pascalban. :P

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

A Turbo Pascalt miben írták? C, assembly

C? Nem hát. A Turbo Pascal fordítót magát assemblyben írták, először amúgy Z80 processzorra és CP/M operációs rendszerre. A 3.0-s verzió nekem megvan lemezen és futtattam a Commodore 128-amon. Később portolták x86-ra és DOS-ra, de továbbra is assemblyben maradt. A keretrendszer maga pedig Pascalban van, ill. Pascal és assembly keverékében, csakúgy mint a hozzácsapott runtime library. A Free Pascalt teljesen Pascalban fejlesztik, a.k.a. önmagában (az első verzió pedig TP-ben készült), akár csak a hozzá való Lazarus IDE-t is. A Delphit is önmagában írták jó sokáig, a mostani verziókat nem tudom.

A DOS-Windows-t, miben kezdték írni? C

Na ez is rohadtnagy mellé, mivel a DOS maga teljesen assemblyben volt, a Windows kernel alapjait is abban írták, a nyolcvanas évek végéig pedig a Microsoftnak saját Pascal fordítója is volt, amit vicces módon pont a későbbi Turbo Pascal verziók elsöprő sikere nyírt ki (pedig a Microsoft QuickPascal néven még egy TP-kompatibilis verziót is kiadott!). Windowsok (és pl. az OS/2) korai ABI calling conventionjét konkrétan "pascal" calling conventionek hívják, és Borland származék. Persze a későbbi fejlesztések C-ben jöttek a tetejére, és megszületett az stdcall calling convention.

A C# fejlesztőrendszert miben írták? C

A natív részeket (Common Language Runtime) amúgy szerintem inkább C++-ban, de a fene se tudja. A C# Lead Architektjét amúgy úgy hívják hogy Anders Hejlsberg. A dán úr a Typescript mellett többek között a "Turbo Pascal" és a "Delphi" megalkotójaként is ismert. Amúgy a Java, és a Java-ripoffnak induló C# is a szintaxison kívül rengeteg mindent kölcsönzött a Pascaltól. Többek között a bytecode-ra fordítunk koncepciót is (lásd p-code és UCSD Pascal, ami a koncepció első komolyan vehető implementációja volt), de ezen kívül is, a C-szerű kapcsos zárójel-szintaxis mögött sokkal kevésbé C-szerűen működnek ezek a nyelvek mint azt a legtöbben gondolják.

Szóval ennyit erről.

Mellékesen megjegyzem, a Pascal mint nyelv időrendben megelőzte a C-t. Csak mielőtt kitalálod, hogy az egész Pascal dolog amúgy is egy C ripoff, mert ugye az ismert világ úgy kezdődött, hogy megalkották a C nyelvet, nyilván, a semmiből. Ezért miután Niklaus Wirth megalkotta a Pascal nyelvet, a kritikusok egyből leszólták, hogy a furcsa ALGOL-szerű x := y + z; szintaxist használta, az ismert és megszokott C-szerű x = y + z; helyett, és ebben az a tény sem zavarta őket, hogy a C nyelv mint olyan még meg sem született. (Forrás)

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

Ráadásul egy kicsit matematikusabb fejjel az x=x+1 szintaxis őrület, az x:=x+1 pont ezerszer logikusabb, kifejezi, hogy miről van szó.

Nem mintha a szintaxis annyit számítana, pár nap után már nem a szintaxis az ami számít, bármit meg tud szokni egy programozó.

Azt nem tudom, hogy nemdefiniált működésből mennyi van Pascalban, de a C-nek az a halála, hogy a típusok méretétől kezdve minden fordítóspecifikus, aztán írjál benne cross-platform kódot, egészségedre!

Bevallom én sem vagyok egy Pascal fan - valószínűleg mert gyerekkoromban rossz társaságba keveredtem :-) - de elismerem, hogy rengeteg erénye van. Pláne a C-vel hasonlítgatni, hogy az mennyivel jobb volna, hatalmas öngól.

Hát 'C'-ben 32 bitről átvinni egy kódot 64 bitre elég nagy odafigyelést kíván, az már szentigaz. Minél inkább támaszkodsz a nyelv erejére, annál inkább! Én úgy látom, hogy míg a 'C'-nél előny az architektúra ismerete, a Pascal esetében ez periférikus kérdés.

> Sol omnibus lucet.

Azt nem tudom, hogy nemdefiniált működésből mennyi van Pascalban, de a C-nek az a halála, hogy a típusok méretétől kezdve minden fordítóspecifikus, aztán írjál benne cross-platform kódot, egészségedre!

Pascalban általánosságban véve kevesebb a nem definiált működés, de őszintén, nehéz összehasonlítani, mert a C-ben elég sok "nemdefiniált működés" az a fordítók eltéréséből fakad, úgy értem a nyelv specifikáció valamit nem definiál, és aztán két fordító két különböző módon implementálja, és onnantól mindenki köti az ebet a karóhoz. Itt a Pascalnak szerencséje van, mert az utóbbi kb. harminc-harmincöt évben a "Borland" a.k.a. "Delphi" dialektus az irányadó, sokszor compiler-viselkedés szinten ha valami "nem definiált" és nincs túl sok alternatív fordító. A Delphi nyilván a saját szekerét tolja, a Free Pascal pedig kiemelten kezeli a Delphi kompatibilitás kérdését (bár komolyan felmerült, hogy az utóbbi néhány "fejlesztést" amit belehánynak a nyelvbe, szimplán sohasem fogunk támogatni, mert akkora clusterfuck), amellett, hogy vagy egy tucat különbözö dialektust vagy azok alváltozatait támogatja.

De a clang/LLVM vs. GCC világ is csak azért átjárható, mert a clang támogat egy rakás GCC-izmust, lévén direkt arra mentek rá, hogy egy rakás GCC-vel írt kódot is le lehessen vele fordítani, szóval ez már csak ilyen.

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

A C (meg egy csomó más nyelv, C++, Fortran...) esetében van szabvány, amit frissítenek. A Pascal esetében (már) nincs ehhez elegendő userbase (nincs ezzel egyedül, így jár a PL/1 is). Ha van szabvány, és használsz ellenőrzést (-Wall -pedantic, vagy lint, ftncheck), akkor azért mennie kellene annak a kódnak másik fordítóval is.

Ettől még nem lesz az egyik nyelv maga jobb, mint a másik, de a compilerek minőségét, ill. azt, hogy mennyire számíthatsz rá, hogy lesz jövőre, egy új architektúrára is compiler, már befolyásolja. Azért ha van egy elég jó open source implementáció (gcc, clang, free pascal), akkor nem nagyon aggódnék. Inkább az a kérdés, hogy mi a célod. Programozgatni otthon az ember választhatja a saját szempontjai szerint "jobb" nyelvet. Ha együtt akarsz dolgozni másokkal, akkor sajnos a nyelv népszerűsége is számíthat (különben nem lenne még mindig annyi tudományos cucc fortranban).

Nnnnajó, de tudod milyenek ezek a szabványok... Egy csomó helyen csak leírja, hogy ez "implementation specific detail", vagy valaminek az implementációja "optional" aztán szevasz. Ami általában csak azt jelenti, hogy már volt kétféle különböző verzió a piacon és a szabvány nem tudott köztük igazságot tenni, és-vagy valamelyik a vendornak addig sírt a szája valami miatt, amig kivették az adott X dolgot a szabványból mint kötelező elemet. Onnantól meg baszhatod, mert az egyik fordítóval lefordul minden, a másikkal meg nem, hiába "szabványos" a kódod. Arról nem is beszélve, ha egy amúgy elterjedt (és/vagy nagyon elterjedt platformon alapértelmezett) fordító nem halad a korral. Lásd Visual Studio, aminek mindig ötször annyi ideig tart teljes mértékben támogatni egy elvileg-szabványt mint mindenki másnak.

Szóval értem én, hogy szabvány, de a clang/llvm elterjedéséhez se a szabványok támogatása kellett, hanem hogy lefordítsa a legtöbb GCCism mocskot és ugyanazt az eredményt adja vissza a mindenféle "implementation detail" kódokon. :)

Szerk: amúgy van ISO meg Extended Pascal szabvány, de szerintem néhány niche-fordítón és a Free Pascalon kívül soha semmise támogatta, ergó megírt kód is alig van benne, szóval mindenkit csak az érdekel, hogy a Delphiben (vagy a korábbi FPC-kben) összetákolt cucc lefordul-e.

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

Azért C-ben és Fortran-ban elég sok időtálló és szabványkövető programot láttam már (a mai C-fordítók többsége simán elfogadja a K&R és az ANSI C kódokat is, a Fortran 77 is elég jól támogatott, a Fortran esetében elég kevés dolgot hagy meg implementációfüggő részként, itt inkább az van, hogy különböző compilerek különböző kiterjesztéseket adtak hozzá).

A Pascal esetében inkább az a helyzet, hogy eleve kellettek a kiterjesztések egy csomó feladat megoldásához (mondjuk egy mátrixinvertálást úgy megírni, hogy ne foglalja le mindig a maximális mátrix-méretnek megfelelő helyet), csak szerencsére a kiterjesztések közül csak a HP és a Turbo terjedt el.

Múltkor valaki előásott valami hetvenes évek végén valami "nagygépre" Pascalban megírt időjáráselőrejelző kódot, és kb. öt sor átírásával (a writeln() szintaxisa változott, IIRC, floatokra, kismértékben) lefordította FPC-vel x86_64-re és berakta egy Docker containerbe. Szóval az időtállóság tényleg nem a szabványokon múlik, hanem hogy egy adott stack mennyire ügyel a saját visszafele, előre és kereszt-kompatibilitására.

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

Ráadásul egy kicsit matematikusabb fejjel az x=x+1 szintaxis őrület, az x:=x+1 pont ezerszer logikusabb, kifejezi, hogy miről van szó.

Dehogy. A matematikus attól matematikus, hogy tud precízen és absztraktan gondolkodni. Nem zavarhatja meg egy szokatlan jelölés, pl. ha a matematikában szokásos '=' helyett az '==' operátort kell használni az egyenlőségre, és a ':=' helyett az '=' jelet az értékadásra.

"A legtöbb fordító"

Egy új nyelv fordítóját elég nehéz az új nyelven megírni létező fordító nélkül, utána meg persze átállni nehézkes.

De egyébként meg meglehetősen sok fordító íródik C++-ban, szóval ne legyél már annyira biztos a C totális dominanciájában. Plusz, előbb-utóbb a legtöbb nyelvnél igény, hogy self-hosted legyen. (C#, FreePascal, Rust, Java fordító pl. mind a saját nyelvében van írva, Python-hoz is van Java meg C# implementáció a CPythonon kívül.) Szóval eléggé mellélőttél ezzel.

Nyilván, interpretált nyelveknél (pl. PHP, Perl) nem nagyon tudsz mit csinálni, valamiben meg kell írni a runtimet (az sem feltétlen C, sok helyen C++ - ld. HHVM is C++, pedig az eredeti PHP runtime C-ben van írva). De elméletben senki nem akadályoz meg abban, hogy PHP-ben írjál egy PHP runtimet, csak épp értelme kevés.

"oprendszer 'C'-ben készül legjobb tudásom szerint."

De melyik része? Kernel? Van azért ott időnként más nyelv is, nem csak C. Userland? Egyre kevésbé. És egyébként is, most OS fejlesztésről van szó vagy alkalmazás-fejlesztésről? Nem igazán releváns az, hogy más feladatra milyen nyelvet használtak.

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

A Rust szvsz elég laza értelmezéssel kezelt self-hosted-ságán mindig felvonom a szemöldököm. Nem kell neki a C++-ban írt LLVM IR backend? Lehet hogy van alternatív backend, de a(z egyetlen production ready és mainline) implementáció az az LLVM IR-ra épül. Azért elég jelentős különbség van aközött, hogy ha a fordítómat egy másik architektúrára akarom portolni, akkor egy tök más nyelvben írt fordító-backend portolásával kell kezdenem, vagy tényleg fogom és keresztfordítom önmagát önmagával, miután leimplementáltam a szükséges backendet, aztán helló.

Arról nem is beszélve, hogy az LLVM IR mennyi mindent diktál egy nyelvnek és fordítónak, amit a legtöbb programozó nem is ért, mert sosem megy bele ilyen mélységben a nyelvbe és a rendszer működésébe. A saját backendek mellett az FPC-nek is lett LLVM backendje, de nem tud 100% kompatibilis lenni pl. x86-on, mert egy rakás dolgot az exception handling és a paraméterátadások kapcsán másként csinál mint amit az azonos procin futó Pascal fordító csinálna...

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

Ez a mi minek a ripoffja szinte teljesen értelmetlen. Egyrészt szinte minden nyelv vagy Algol vagy Fortran, vagy LISP ripoff, másrészt nem ezen múlik, hogy jó lesz-e.

"A C egy egyszerűsített Algol-ripoff", mégis baromira bevált az eredeti céljára.

A Pascal egy "oktatási célra kiherélt Algol 68", mégis jobban elterjedt.

A BASIC egy kezdők számára "egyszerűsített Fortran-ripoff", ...

...
stb., stb.,

Valóban, a Pascal előbbi, mint a C. De csak 2 évvel előzte meg dizájnügyileg. Ha ehhez hozzávesszük, hogy később jelentek meg Pascalhoz értelmes fordítók (használható implementáció), akkor az jön ki, hogy lényegében kb. egy idősek, egyszerre indultak terjedésnek.

Persze azt enélkül is mindenki tudja, hogy a Pascal nem a C ripoffja, hanem az ALGOL-é.

No keyboard detected... Press F1 to run the SETUP

( mgabor v | 2018. 12. 17., h – 12:43 )

Most nézegetem a Lua-t. Tudna valaki a valós életből merített tapasztalatot megosztani?

A Lua szvsz erre nem való, amit akarsz tőle. A Lua-t arra találták ki, hogy scriptelhetővé tegyél egy-egy programot, a kisméretű Lua interpreter programokba való beépítésével. Lehet erőltetni persze független, teljes értékű programozási nyelvként is, és majdnem jó is rá, csak minek.

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

Mi csináltunk desktop alkalmazást win/linux környezetben wxWidget-tel. Embedded rendszereken is használjuk, készült vele pénztárgép, bankterminál. File feldolgozásra is remekül használható, sokkal átláthatóbb kódot lehet vele készíteni, mint pl perl, awk, bash és társaikkal.

Az a nagyszerű benne, hogy kicsi, hamar tanulható. Könnyű bármibe beépíteni, illetve könnyű bármivel kibővíteni. Hátránya a típustalanság, emiatt egy kicsit jobban kell figyelni.

Bocs, ez nekem nem világos - ezt Lua-ban tettétek? (Csak mert mintha a wxWidget C++-hoz adna bindingot.)
Jav: találtam egy wxLua-t, de a 2012-es utolsó hír kicsit elbizonytalanított.

Kieg: a FreeBSD bootjának X-edik lépése eddig egy Forth-ban írt loader volt. 12.0-tól lett (mellé) egy Lua-ban írt. De egyébként még az életben nem láttam Lua-t, csak tudom, hogy pl. a NodeMCU-kat gyárilag abban lehet programozni.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( Raynes | 2018. 12. 18., k – 05:56 )

A topikindító leírás még átszerkesztés után is elég homályos, túl általános. Konkrétan írd le, hogy milyen programot akarsz fejleszteni, ahhoz kell keresni a nyelvet. Mindig az adott feladathoz választani.

Az is elég relatív, hogy kinek mi a könnyen tanulható nyelv. Erősen függ a programozói előélettől, hogy milyen nyelveket ismersz már eleve.

Egyelőre csak annyi jön le, hogy interpretált nyelvek nem lesznek neked alkalmasnak.

Amit én ajánlok így általánosságban, az a C++. Azért, mert jó sok mindenre, van minden platformra. De ha pl. GUI-s programot akarsz írni, annál nem fogod megúszni, hogy valami grafikus keretrendszert, vagy a win32 API-t, esetleg a .NET-et, vagy hasonlót (pl. Qt) ismerj pluszban még az adott nyelven felül.

No keyboard detected... Press F1 to run the SETUP

GTK GUI cuccot lehet csinálni, simán c-ben is, néhány példát átnézve elég könnyen tanulható, viszont nem ajánlanám, hogy valaki bármilyen GUI programozásával kezdjen el programozni tanulni.
A hordozhatóságot illetően viszont vigyázni kell vele, mert ha egy adott disztribúción lefordítod, nem biztos, hogy egy másikon működni fog, esetleg talán ha statikusan linkelsz. Windows-ban nem próbáltam még ilyet, de elméletileg Windows-ra is rá lehet erőszakolni valahogy. pl. a GIMP egy GTK alapú cucc, és van windows-ra is, sőt bármelyik windowson fut.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( vilmos.nagy | 2018. 12. 19., sze – 01:28 )

A szerkesztés alapján én egyébként powershell irányba mennék, s megnézném, mennyire kóser Linuxon most.

( neuron | 2018. 12. 20., cs – 21:35 )

https://dlang.org/

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