HOVD 2016 - Kedvenc fordított programozási nyelv

HUP

assembly (bármely architektúra, bármely dialektus)
3% (18 szavazat)
c
22% (147 szavazat)
c#
13% (89 szavazat)
c++
19% (125 szavazat)
go
6% (38 szavazat)
haskell, ocaml, f# (statikusan tipusos funkcionalis nyelvek)
3% (17 szavazat)
java
23% (155 szavazat)
objective-c, swift
2% (16 szavazat)
pascal
7% (46 szavazat)
scala
1% (9 szavazat)
Összes szavazat: 660

A mostani rendszer megtartásával:

1. A 24 óra egy ilyen eldöntésére nagyon kevés, legalább egy hetet adnék rá.
2. Időben szét kellene választani a javaslatokat és a rájuk való szavazatot, hogy ne lehessen olyan, mint amit fent is írtam, hogy a vége előtt egy kicsivel le lehet váltani akár melyiket.

Új rendszer:

Mondjuk az utolsó három legkevesebb szavazatot kapó versenyző verseng a bármikor felvetett új versenyzőkkel.
Az összes közül a három legtöbb szavazatot kapó kerül be a szavazásba az utolsó három helyére.
A legalább egy hét szavazás azért itt is kellene.

( NevemTeve | 2016. 12. 13., k – 06:32 )

Azért a C, mert az már eleve egyben fordított is, szemben pl a 'lacsaP' és 'loboC' nyelvekkel.

( taurus | 2016. 12. 13., k – 07:51 )

Az assembly biztosan forditott nyelv? Ugy tudom (meglehet tevesen), hogy az assembler kb csak linkelget. Szoval fordito nelkul, mikent lesz forditott nyelv?

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

Szoval van egy altalanos assembly nyelv es minden processzor csaladnak van sajat assemlere? Vagy az assembly olyan alacson szintu programozasi nyelv ami processzor specifikus utasitaskeszlettel rendelkezik szemben a magas szintu programozasi nyelvekkel melyeket hordozhatoak es kulonbozo processzorokon futtathato binaris allomanyokra lehet forditani.

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

És akkor a compiler feladata az, hogy processzor specifikus kódot állítson elő, lehetővé téve a magas szintű nyelvek hordozhatóságát? Vagy az, hogy futtatható állományt hozzon létre?

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

A fordító egy valamilyen - gépi kódnál magasabb szintű - nyelven (ez lehet assembly, C, Pascal, Ada, Prolog, Fortran, stb) írt kódot fordít (kompilál) általában gépi kódú objekt fájl formába. Amit aztán egy következő lépésben a linker (kb "összeszerkesztő") - hoz futtatható állapotúvá. Természetesen vannak kivételek, ha jól tudom pl. az LLVM alapú fordítók előbb előállítanak egy "virtuális processzorra" való kódot, amit aztán egy következő lépésben fordítanak fizikai processzorokon futó kóddá. Vagy ott a Java, ahol a JVM nevű virtuális gép utasításait állítja elő a javac, és ezt fogja aztán a Java futtatókörnyezet értelmezni/futtatni.

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

A második. Nyilván eza az alacsony meg magas kategorizálás erősen szubjektív, pl. az operátori panelen kézzel bevitt gépi kódú utasításokhoz képest minden magas, még az assembly is. De ha már, akkor inkább alacsony szintűnek kéne hívni. Jellemzően a hatékony programok írásához nem baj ha valaki látott már ilyet, és főleg körülbelül sejti, hogy a kód amit egy magas szintű nyelven megírt, az mennyire illeszkedik a végeredményt futtató processzorhoz. (Sok esetben ez utóbbit egy jó optimalizáló elég jól elfedi a programozó elől.) Anno volt egy cikk a Dr. Dobbs Journalban - ez se tegnap volt - amiben egy teljesen szimpla, sok számolgatást igénylő feladatot - mátrixszorzás, vagy invertálás, vagy ilyesmi - megírtak, talán C-ben. Lefordították az akkortájt újdonságnak számító MIPS R4000-t használó valamelyik SGI gépre, és valamilyen x86-ra, talán Pentiumra. Bődületes teljesítménykülönbség volt. (4-5 nagyságrend?) Utána elkezdték a jól olvasható, természetes kódot a "magas-szintű" C-nyelv mindenféle eszközeit kihasználva a Pentiumra optimalizálni - közben általában egyre jobban keresztbe tettek a MIPS-nek. Ezt több lépésben iterálva végezték, a végeredmény az volt, hogy lett egy rohadtul átláthatatlan, de erősen Pentium-specifikus kód, amivel sikerült mondjuk 1-2 nagyságrendre megközelíteni az x86-os géppel a Silicon Graphics csodamasináját. És máris kijött, hogy mivel a két gép között árban nem 2 nagyságrend a különbség, matematikai számításokhoz érdemesebb Pentiumot venni, mint MIPS-et - hisz épp csak egy "kicsit" kell optimalizálni. (Az már más kérdés, hogy ha nem ismeri az ember a gép belső működését, akkor kb esélytelen az átlátható kódot átláthatatlanra optimalizálni.)

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

Nem semmi tortenet. Szoval az assembly egy olyan alacsony szintu nyelv amit forditani kell? Bar ettol a "forditastol" nem lesz processzorfuggetlen mivel a kodot alapvetoen processzor specifikus utasitasokbol allitottak ossze. Tovabba, ha az assembly kodban mar definialtunk minden egyes utasitast miert szukseges, mit lehet rajta forditani? Nem azert kell forditani a magas szintu nyelveken irt kodot, mert tartalmaznak olyan utasitasokat melyek nem processzor szintu utasitasok, igy alacsony szinten nem ertelmezhetoek/megfeleltethetoek egyeb utasitassal?

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

Az tulzas. :) A cikk jol leirja hogy mi az assembly. De hogy hogyan mukodik a gyakorlatban, es foleg manapsag, amikor mar nem nagyon irunk kezzel assemblyt, ellenben a generalt assembly fontosabb mint valaha, arra nem nagyon vilagit ra...

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

Komoly forras - "... a gépi kódhoz (a számítógép „anyanyelvéhez”) ...". Hallottam valami magasszinvonalu felsooktatasi intezmenyrol mely jegyzete szerint a processzor orajele meg a szamitogep "szivverese". Nem gyozott meg egyik sem. Amugy a magyar nyelvu wiki oldalak kozt nincs olyan ami a linker-rol szolna. Tartok ez a tobbi hasonlo temaju oldalt is minositi. Viszont itt egy egesz jo konyv.
Szinten wikin talaltam a forrasok kozott.

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

Az assembler nem is igazan az utasitasok megfeleltetese miatt kell. Van egy csomo dolog alacsonyi szintu programozaskor is, amit emberi aggyal nehez lekepezni, es az assembler megcsinalja neked, foleg bonyolultabb architekturakon.

Pl. egy 6502 (8 bites processzor) eseten meg lattam elo embert gepi kodban progamozni, mivel a gepi kodja baromi egyszeru, 1, 2 v. 3 byteos utasitasok vannak, ahol az elso az opkod, a masodik es harmadik pedig altalaban egy cim, semmi cico. Ott viszonylag atlagos kepessegu humanoidok (mint en) is fel tudjak fogni hogy melyik szam mit jelent a processzornak, es ha nagyon akarod el lehet lenni assembler nelkul is.

Ellenben egy bonyolultabb architekturan, az utasitasok bitfieldekkel vannak encode-olva, szoval ha megvaltoztatod hogy az utasitas egy melyik regisztert hasznalja, akkor egy 32bites szam kozepen kell modositani egy 4 bites, neha hatulrol-elore encodeolt bitfieldet. Hat koszi. Vagy pl. az assembler szinten az utasitasok egysegesek, mindig azt irhatod le, hogy add reg1,reg2, de a gepi kodban tobbfele add utasitas van, attol fuggoen hogy melyik regisztereket adod ossze. Ezt is megcsinalja neked az assembler, kivalasztja h. melyik add kell neked a tobbfelebol. Nyilvan a gepi kod ugy van megcsinalva, hogy a processzort konnyu legyen implementalni, es/vagy kompatibilis legyen, az assembly pedig egy vekony reteg rajta, ami szoftveres aggyal is ertelmezhetove teszi a rengeteg bitet es szamot amivel dolgozik.

De ezeknel sokkal jelentosebb, hogy az assember, architekturaktol teljesen fuggetlenul:

- Valtozo <-> Cim megfeleltetest csinalni. Nem kell emlekezned, hogy a $8534 offset az vezetek_nev, valtozo, hanem forditaskor az assember behelyettesiti a valtozot a cimevel.

- Cimkeket hasznalni, a belepesi pontokhoz, az ugro utasitasokhoz. Ha ez nem lenne minden ugro utasitashoz neked kene kiszamolni kezzel, hogy az vagy milyen messze van a jelenlegi cimtol, vagy fix offsetre bedrotozni a kododban. Ha modositod a kodot, az osszes cimet az osszes ugro utasitasban at kene irnod kezzel... Ez mar csak azert is fontos, mert pl. rengeteg architakturan attol fuggoen hogy az ugras celpontja milyen messze van a jelenlegi poziciotol, masfele ugro utasitast hasznalhatsz, ami adott esetben rovidebb (optimalisabb) opkodra fordulhat. Ezt is jo, ha nem neked kell kezzel kiszamolni a cim tavolsagat, majd kezzel kivalasztani az utasitast (opkodot).

- Alignment. Bizonyos architekturak megkovetelik, hogy byte-nal nagyobb ertekek igazitva legyenek paros, neggyel oszthato stb. cimekre. Vagy optimalizacional sokszor elkerulethetetlen, hogy a kodot is igazitsd, pl. cache-line merettel oszthato cimre (pl. ciklusoknal, amik sokszor vegrehajtodnak). Az assemblerek tartalmaznak direktivakat es makrokat, amikkel elkerulheto, hogy ezt neked kelljen kezzel megtenni, es utana karbantartani a megfelelo mennyisegu NOP utasitassal, stb.

- Ezek fentiek annyira fontos muveletek, hogy egy rakas magas szintu fordito szimplan az alatta levo assemblerre bizza, es egyaltalan nem foglalkozik a magas szintu kod forditasakor ilyesmivel! Ergo assemblyre forditanak, nem gepi kodra! (A legtobb fordito ezt az assembly kodot le is tudja neked menteni, pl. a GCC a -save-temps parameterrel, Free Pascal -al parameterrel, stb...)

- Szintaxis ellenorzest vegezni. Ennek az elonye egyertelmu, meg a gepi kod, a szamok szintjen is van olyan hogy hibas utasitas, vagy az adott processzor altal nem tamogatott utasitas. Ha megmondod egy assemblernek mi a celprocesszor, megmondja hogy a kod amit irtal, fog-e rajta futni.

- Makrozni. Kezi programozaskor nem kell magyarazni a hasznukat, a sokszor ismetelt utasitas-mintakat makrokba rakhatod, amiket az assembly fordito megismetel neked. Sokszor meg magasabb szintu nyelvek is hasznalnak assembly makrokat. Bizonyos processzorokon (pl. PowerPC) az utasitasok egy resze szimplan "makro" vagy egyeb syntax sugar, amelyek csak egyszerusitett parameterezesei valamely joval bonyolultabb utasitasnak.

- Binary encapsulation. Az assembler ismeri a kimeneti formatumokat amiket a linker vagy az operacios rendszered linkere elvar. Ergo nem kell neked kezzel irni objektum es exe fejlecet.

Es meg tudnek egy rakas dolgot ideirni, amit az assembler csinal. A legtobb ember ugy kepzeli a forditas muveletet, hogy megirom X magas szintu nyelven -> kod es exe file, kesz.

Ehelyett altalaban az van, meg forditott (nem VM/interpretalt/JIT) nyelveknel is hogy:

- megirod a magas szintu kodot, OOP, funkcionalis, whatever...
- a magas szintu fordito kihajigalja az OOP, funkcionalis egyeb dolgokat es sima proceduralis/strukturalt kodot csinal belole, mert azt lehet megfeleltetni aztan legegyszerubben a kesobbi assembly kodnak. Kiszorjak a syntax sugart, a bonyolultabb nyelvi strukturak kezelesehez tablazatokat es segedfuggvenyhivasokat (a runtime library-ba (pl. libc)) generalnak.
- a proceduralis/strukturalis kod, vagy annak valamely belso reprezentacioja vegul assemblyre fordul.
- az assembler leforditja az assemblyt gepi kodda es objektum fajlokka (.o fajlok). Altalaban ezen a szinten meg megfelel, hogy 1db. .c, .cpp, .pas, .m, akarmi fajlbol 1db .o fajl lesz a vegen.
- es ezutan jon a linkelesi szakasz, amikor a linker a rengeteg forrasfajlod leforditasa vegen nyert rengeteg .o fajlbol gyart egy futtathato allomanyt (vagy .dll-t, vagy .so-t vagy akarmit), olyan allomanyt, amit aztan egy oprendszer is ertelmezni tud.

Nagyon nagy vonalakban, es pongyolan... :)

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

Szoval cimkek, valtozok, makrok, mnenomikok ezek kb mind aliasok. Az assemblyre forditott C kod mar processzor specifikus. Ok, elhiszem biztos van olyan assembler ami optimalizal, meg odafigyel dolgokra, de ettol szerintem meg nem fordito mert mar nincs mit forditani. Assembly es gepikod kozott nincsenek mar olyan feloldando ertelmezesi problemak mint C es assembly kozott. Mar alacsony szinten vagyunk, az utasitasok teljes mertekben definialtak. Lehet rosszult ertelmezem a forditas fogalmat, de en ugy latom azert van szukseg forditasra, mert bizonyos magasszintu kifejezesek nem egyertelmuen azonosithatoak alacsonyszintu megfelelokkel. Amennyiben lenne egyertelmu megfelelo, elegendo lenne ezeket strukturaltan megfeleltetni es linkelni, hivatkozni rajuk.

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

Megtaláltam ami mellett érvelsz a wikipédián, a Low-level programming language címen:

Low-level languages can convert to machine code without a compiler or interpreter— second-generation programming languages use a simpler processor called an assembler— and the resulting code runs directly on the processor.

Eszerint az assembler nem compiler, de fordit? Nyilvan eleg gyokernek tunok, hogy ezen lovagolok, pedig csak szeretnem javitani ismereteimet anelkul, hogy megalapozatlannak velt informaciokat fogadjak be.

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

Ha fordito = compiler

The name "compiler" is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language or machine code).
Wiki

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

Assembly language is converted into executable machine code by a utility program referred to as an assembler. The conversion process is referred to as assembly, or assembling the source code. Assembly time is the computational step where an assembler is run.

Egyébként benne van a nevében mit csinál ezért hívják assemblernek. :D

Szerintem ez az igaz:

With respect to "compile" vs. "assemble" pedantry: The distinction between assembling and compiling becomes blurred when macros (in assembly language) or blocks of inline assembly language (in a language that is not primarily assembly language) come into play. Besides, we use "compile" because among words meaning "translate source code into object code", I assume it will be understood by the largest number of readers. What better word encompasses both "compile" and "assemble" and means "perform a translation of source code, in either assembly language or a language that is not assembly language, into object code"?

Innen van.

Ha az általad linkelt bejegyzésen kicsit tovább mész, akkor ezt találod:

Before the development of FORTRAN, the first high-level language, in the 1950s,[5] machine-dependent assembly language was widely used.

Összefoglalva:
1. Fordítónak azt nevezzük, ami magas szintű program nyelvet alacsonyabb szintűre transzformál (pl. assembly vagy gépi kód).
2. Az Assembly volt az első magas szintű program nyelv.

Tehát az assembler az egy fordító, ami a magas szintű Assembly-t fordítja alacsonyabb szintű gépi kódra.

/ A szegedi egyetemen is fordításnak hívják, két jegyzetben is ezt láttam. Valamint a magyar wikipédián is ez a nézet uralkodik. /

Szóval van sok érv és link mellette és van ellene is.

"Before the development of FORTRAN, the first high-level language, in the 1950s,[5] machine-dependent assembly language was widely used."
"2. Az Assembly volt az első magas szintű program nyelv."

Nem ellentmondas ez a ket mondat? Az assembly meg ismet magas szintu nyelv lett?!

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

Valóban félreértettem, én így értettem elsőre (a pontosvesszőt kell figyelni):
Before the development of FORTRAN; the first high-level language, in the 1950s,[5] machine-dependent assembly language was widely used
ehelyett:
Before the development of FORTRAN, the first high-level language, in the 1950s;[5] machine-dependent assembly language was widely used

Te minek nevezel egy teljesen binaris, szamokbol allo es egy emberek szamara konnyen ertelmezheto reprezentacio kozotti forditast ha nem forditasnak? Amugy valoszinuleg a magyar es az angol nyelv kozotti terminologiai kulonbsegen akarsz vitatkozni.

Angolul a "compile" szo definicioja - "produce (a list or book) by assembling information collected from other sources." Ennek megfeleloen az assembler egy compiler, az assembly pedig "compiled" nyelv. De magyarul ezt az eljarast "forditasnak" nevezzuk. Te csak a "fordito" szo hagyomanyos jelentese miatt (ami angolul translator lenne) akarod ezt beleeroltetni.

Amugy meg, elmagyaraztam hogy sokszor nem feleltetheto meg 1:1-ben, hogy mit akarsz, mert belenyulsz a kododba tok mashol, elcsusznak az offsetek, es maris masik utasitasokra fordul amit leirtal (pl. masik ugro utasitasra).

De akkor ilyen alapon a C fordito sem fordito, mert a korai C forditok 1:1-ben forditottak C kodot valamely assembly mintara, ami pont az altalad feszegetett 1:1-ben megfeleltetes... Sot, pl. a fejlettebb disassemblerek visszafele is tudjak ugyanezt, mai napig felismerik a forditok altal generalt mintakat, es visszaforditjak az egeszet C-be. Na ilyenkor mi van? Akkor a C az forditott nyelv vagy nem? (Nyilvan az, de ezert nem kell hulyesegeket forszirozni.)

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

Rendben, valoban ertelmezesi problemarol van szo. En a forditas alatt a compiler-rel torteno feldolgozast ertettem, de itt egy jo kis wiki page ami kifejti reszletesen, hogy ez sokkal tagabb tema mint gondoltam. Csak ebben a terminologiaban az interpreter is fordito es minden forditott nyelv ami nem gepi kod. Mindennek ellenere az assembler nem compiler. Tovabba szamomra egyertelmunek tunt, hogy a cimbeli fordito a compiler-re utal.

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

ha az assembly kodban mar definialtunk minden egyes utasitast miert szukseges, mit lehet rajta forditani?

Assembly = le van írva szövegszerkesztőben, betűkkel, számokkal.

Pl. C64-esen ki akartam tenni egy A betűt a képernyő bal felső sarkába, akkor assembly-ben ezt írtam le (ha jól emlékszem):

LDA #65
STA 1024

Ezt az assembler lefordította gépi kóddá:

A9 41 8D 00 04

Ha az assembly programocskámat betöltöm a memóriába, akkor ki tudom mondjuk listázni, de nem nagyon jó semmi másra.
A fordítás után készült gépi kód, ha bent van a memóriában, el tudom indítani, és valamit majd csinál.

Én csak azt nem értem, kit akarsz meggyőzni? *Én* pl. fordítónak tekintem az assemblert, és különösképp nem zavar, ha te, vagy más nem. *Én* úgy gondolom, hogy egy fordító és egy interpreter között van egy lényeges különbség: mikor történik a fordítás. Pl. az egyik elterjedt vélekedés szerint ha elkülönül a fordítás ideje a futtatástól - azaz ha *előbb* minden le van fordítva valamely gép által érthető formába (egyszer), és csak utána történik a futtatás, akkor fordítom a kódot. Ha pedig minden futtatás magával hoz fordítási műveletet, akkor interpretálás - azaz értelmezés történik. (Másként mondva: ha nem módosul a kód két futtatás között, és ugyanazon környezetben történő futtatáshoz nem kell újra fordítani semennyit, akkor ez fordító és nem értelmező.) Noha egyértelmű, hogy interpretálás *közben* is történik fordítás, ennek ellenére sokan azt mondják, hogy az interpreter nem fordító. Hasonlóan, pl. az *én* véleményem szerint a fordítás során áll elő egy olyan kód, amely egy valamilyen (valós, vagy akár virtuális) processzor számára már érthető, ezért az assemblálás művelete fordításnak számít, míg a disassemblálás pont nem, mert nem a gép, hanem az ember számára emészthetőbb formátum előállítása zajlik ilyenkor.

De szerintem vannak itt páran, akik úgy gondolják, mint én: te kérdeztél kvázi definiciókat, megkaptad, ha ezek után másként akarod ezeket *értelmezni* (pun intended), az a te dolgod.

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

"a fordítás során áll elő egy olyan kód, amely egy valamilyen (valós, vagy akár virtuális) processzor számára már érthető"

Akkor a compiler nem fordito mivel object fajlokat allit elo?

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

Hát pedig az object fájlokban már pontosan a processzor számára ehető műveletek vannak. Az, hogy jellemzően van egy plusz linkelési művelet, az nem nem kötelező. (Egy semmiféle külső libet nem használó, önmagában is működőképes kód fordítása simán állíthat elő már a processzor számára emészthető kódot. Csak épp jellemzően van külső hivatkozás, van "gyári" inicializáló rész, stb - ezért aztán van egy plusz linkelés.)

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

+ mint azt fentebb is irtak: bar ritka megallni a ketto kozt, de rendszerint a compiler a nagyon magas (pl. c) nyelvu kodbol csinal egy alacsonyabb szintut (assembly), es evvel egy lepesben elvegzi az assemblalast is (assmbly -> object)

Anno meg SZTE-n Devenyi bacsinak a jegyzeteben volt egy egesz remek ascii art a folyamatokrol, amit aztan kesobb egy sajat jegyzetben tex-esitettem:
http://linux.gyakg.u-szeged.hu/~pasztor/gnue/gnue.pdf
9. oldal: 1.2 abra.

1101011010010101100101110101001110101001110001010010011010100111110101010010010101001100100111

Text fájlból ezt is fordítani kell, hogy bináris legyen :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

( ggabo | 2016. 12. 13., k – 09:34 )

+Python; Valamiért nem fordított nyelvként tartják számon, mert a default implementáció automatikusan fordít. Megvalósításban kb. Javahoz hasonlóan interpretált nyelv. Cython fordítóval meg kombinálható akár C kóddal is.

( NevemTeve | 2016. 12. 13., k – 10:47 )

Meta: Zahy olvtárs, kérlek tegyél be egy [/b] taget valahová...

( sigellef | 2016. 12. 13., k – 12:34 )

A java-ból gépi kódú bináris lesz, vagy csak a java keretrendszer által értelmezhető bináris?

-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

Is.
A javac vagy eclipsec vagy egyéb Java fordítók .java fájlokból .class bájtkódot (platformfüggetlen) állítanak elő. Futtatás során kezdetben interpretált módban fut, de a gyakran hívott kódrészleteket több lépésben (gyors fordító, nem túl optimalizált kód - "C1", majd erősen optimalizált változat, lassabb fordítóval - "C2") lefordítja natív gépi kódra. Shipilëv elég sokat ír a témában (https://shipilev.net/), és Nitsan Wakart blogja is jó (http://psy-lob-saw.blogspot.com/).

( kl3on v | 2016. 12. 13., k – 15:31 )

aki pascalra szavazott az mit csinál vele?

Pár éve még én is a pascal-ra szavaztam. Most már a c jobban tetszik.
Ugyanazt meg lehet csinálni pascalban, mint c-ben. Csakhogy: az /usr/include függvényei az c/c++ -ban van elkészítve, ha Linux-ra akarok írni valamit, jobb megtanulni a c/c++ -t.

Ha valami számítást kell csinálnom sebtiben, akkor még mindig pascalozok (fpc). De erről a rossz szokásról remélem mihamarább leszokok.
A pascalozóknak is lehetne miakedvenc szavazást csinálni :D (tpc/bpc/fpc/dpc/dcc/dcc32/gpc/delphi/kylix/lazarus)

-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 Free Pascalon es a haromevente mas kiado alatt feltamado Delphi-n kivul nincs mar mas epkezlab fordito. A GPC projekt halott, a Lazarus meg csak egy - a legnagyobb es a "hivatalos", abban az ertelemben hogy vannak atfedesek a fejlesztocsapatban - IDE Free Pascalhoz. A tobbi emlitett fordito meg csak a Delphi ill. korabban a Borland Pascal valamifele inkarnacioja. (A Kylix is, de az is reg halott/unsupported.)

Amugy multkor pont errol tarsalogtunk a melohelyen, egy Rust fan kollega felhozta a csomagkezelot, mint plusz ervet, hogy miert kell Rustozni, erre azt talaltam mondani, hogy a C/C++-hoz is van csomagkezelo, csak azt a kedvenc Linux disztrodnak es az abban levo csomagkezelonek hivjak. Mire o "Hubaz, tenyleg. Erre nem gondoltam." Te is ezt irtad le, csak mashogy... De ettol meg nem lesz rossz szokas Pascalozni, mert az OS ossze van nove a nyelvvel amiben irtak.

Sajnos minden mas nyelvnek a C/C++-on kivul szembe kell neznie azzal, hogy valamifele bindinget kell biztositania a C-ben irt OS fele. Free Pascalhoz amugy keszul egy csomagkezelo, es hasonlot akarnak vele mint az npm/pip/crates toolok a kulonfele egyeb nyelvekben, hogy egy kozponti repobol lehessen csomagokat lehuzni es karbantartani.

(Ha mar itt tartunk, a minap tortenelmi erdeklodes okan kezembe akadt egy korai Mac Internals konyv a nyolcvanas evekbol. Az OS fuggvenyekhez ketfele binding volt megadva: assembly es Pascal. Valamint az osszes struktura leirasa es a peldakod is Pascalban volt. :) Szoval ez is olyan, hogy nem lesz itt gond, csak irni kene (ujra) egy OS-t Pascalban... :D)

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

Régen, még a DOS6.x/Windows 3.x idején pascal-ban nekiálltam összeütni olyan grafikus szarságot, mint a Windows. Multitask ugyan nem volt, de különféle programok futásidőben tudtak változók, meg rekordok értékeit átvenni egymástól... nomeg statikus ablakban jelentek meg. Akartam még neki pascalt értő shellt is csinálni.
Csakhát jött a Windows NT4, az meg véget vetett a megszakításokkal, meg rezidens programrészekkel való játszadozásnak, a Linux megismerése után meg felhagytam minden DOS specifikus dologgal.

-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

Akkoriban mindenki OS-t irt, meg grafikus shellt DOS-ra. Nekem is volt sajat, bar nyilvan igen kezdetleges, kesobb csak egy GUI "librarybe" torkollt, amit par hazi barkacs programom hasznalt. :) Amugy van egy elvetemult bolgar, aki megcsinalta az i8086 kodgeneratort FPC-hez, o most jelenleg egy homebrew i8086 alapu szamitogepen, es hozza valo DOS szeru OS-en dolgozik. Mondtam neki, hogy teljesen hulye es eltevesztette az evezredet (mondjuk en beszelek a 68000 maniammal), masreszt meg gigarespect. :) Csak rohogott, es mondta h. boknak vette. :) (Es eloben egy normalis, jo szakembernek tuno faszi, nem kelti futobolond benyomasat...)

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

Ha mindent meg tud csinálni vele, amit szükséges csinálnia, akkor nem is olyan bolond. Ha meg olyan problémába ütközik, amit nem tud a rendszer, akkor azt hozzáírja. Szerintem ezért jó, ha van valakinek teljesen saját OS-e.
Ha idegen forrású az OS, akkor meg ha találunk is egy adott problémára szoftvert, néha már a fordítása is rengeteg vesződséget igényel, merthát a figgőségeket, a függőségek függőségeit is le kell fordítani, ha meg a rendszeren is megvannak az adott lib-ek, csak más verzióban, akkor jöhet(nek) még az uj libdir(ek), includedir(ek), stb.
A grafikus felület programozása meg... ott tovább tart a progit összehozni a felulettel, mint magát a problémát leprogramozni.

-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

"Ha idegen forrású az OS, akkor meg ha találunk is egy adott problémára szoftvert, néha már a fordítása is rengeteg vesződséget igényel, merthát a figgőségeket, a függőségek függőségeit is le kell fordítani, ha meg a rendszeren is megvannak az adott lib-ek, csak más verzióban, akkor jöhet(nek) még az uj libdir(ek), includedir(ek), stb."

Mig ha sajat OS-eden mondjuk ki akarsz nyomtatni egy PDF-et csak szimplan 0-rol kifejleszted a nyomtatodrivert meg a PDF nezegetot/konvertert, es mar kesz is. Semmi szivas nincs vele, par perces melo. Nem kell holmi idegen kod forditasaval meg libekkel vacakolni.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

/me morfondír: hogyan is kezdődött ez az egész GNU-marhaság? Csak nem valami nyomtatódriverrel? (Szóval ha mázlid van, az eredeti hozzászóló lesz az új RMS. De az is lehet, hogy már az. Persze lehet, hogy még csak a csírái vannak meg, pl. fehér zokni)

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

En korabban router firmware-t es kapcsolodo toolokat irtam benne (penzert, meloilag). :) Amugy meg a Free Pascal forditot magat hackelem, sosevolt szamitogepekre, mert az is Pascalban van. Leginkabb azert, mert szeretem a nyelvet es sokat tanulok belole. (Jelenleg C++ fejlesztesert fizetnek napi 8-ban, es hmm... nem gyozott meg. Es C-ben is tudok. De voltam 7 evig Java-s is korabban. Ez van.)

Amugy a kovetkezo amin gondolkodok, hogy csinalok egy WebAssembly backendet Free Pascalhoz. Aztan akkor futtathato lesz a browserben a Pascal kod. :P (In fact mar elkezdtem, de egyelore nagyon gyermekcipoben csoszog, idohiany, energiahiany...)

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

Nekem '81-ben tanították, a korábbi évfolyamoknak még Fortrant nyomtak, mi voltunk az első Pascalosok. Franciakockás lapon írtuk a programot, lyukkártyákon ment be az R20-asba :)
Kicsit később ZX Spectrumra sikerült szerezni Pascal compilert, majd PC-re (6MHz-es 286-os, turbo módban ment az 10MHz-cel is) Turbo Pascalt. Mellette saját fejlesztésű paneleken (Z80, i8085, MCS51) assembly, később azokhoz is lett Pascal, jelenleg is abban írogatok AVR-re, ha kell valami (kivéve, ha Arduino kerül az ember kezébe, de a C-t nem csípem annyira, nekem a Pascal való).

Mit hasznalsz AVR-re? Csak mert az FPC-nek is van AVR backendje manapsag (azaz tud AVR-re kodot forditani), de en sosem probaltam hogy mennyire jo. (Amugy '81, joeg, nem vagyok benne biztos, hogy akkor mar szobatiszta voltam. :D)

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