Kiderült: JavaScripttel működik a James Webb űrteleszkóp is

Kiderült: JavaScripttel működik a James Webb űrteleszkóp is
2022-08-19T07:26:33+02:00
2022-09-05T15:25:32+02:00
2022-10-17T02:55:48+02:00
  • ...és egy ekkora blama typo-t betolni, ó, kis Jézus a mennyben, borogass!
    Mutasd a teljes hozzászólást!
  • ...és nem történik semmi, mert az univerzumnak csak "blackHoleCollapse" eseménye van, "blackHoleCollape" soha nem történik. Ilyen árnyoldala is van, ha stringly typed a rendszerünk

    (Tudom, tudom, írni kell rá unit tesztet és akkor kibukik a hiba még az élesbe kerülés előtt...)
    Mutasd a teljes hozzászólást!
  • universe.addEventListener('blackHoleCollape', function(e) { e.preventDefault(); });
    Mutasd a teljes hozzászólást!
  • Biztos, hogy nem minden javulás abból származik. Ugyanis önmagában az, hogy egyik nyelvet lecseréled a másikra egyértelműen nem teszi sem "hatékonyabbá a szállítást", sem lehetővé azt "kevesebb üzemanyag"-ból.

    Ahhoz az útvonaltervezés végeredményében, a szállítás szervezésében kell változás, ami viszont a nyelvcseréből nem, csak az algoritmus és/vagy a használt adathalmaz változásaiból következik. Ha viszont ilyen történik, onnantól kezdve a futásidőben, cloud költségben bekövetkezett változások is kérdőjelessé válnak, hogy nem -e ennek eredményei.

    Szóval ezek a kijelentések, még ha igaznak is fogadjuk el őket, nem alkalmasak annak a konklúziónak még csak a valószínűsítésére sem, hogy az említett poiztív változások egyes sajátosságokban (amik mellett ráadásul más, nem említett sajátosságai is vannak a megoldásoknak) a Python->Java váltás eredményei.
    Mutasd a teljes hozzászólást!
  • // HWSW hirdetés-cikk:

    Újraírta áruszállításhoz használt útvonaltervező motorjának egy részét a Tesco Technology magyar fejlesztőcsapata. A korábbi Python alapokat Java váltotta, az eredmény pedig tizenhatodára csökkent futásidő, hatékonyabb szállítások, félmillió font megspórolt cloud költség és kevesebb üzemanyag.

    Persze nem biztos hogy minden javulás a Python -> Java cseréből származik, a második verzió gyakran jobb, mert elkerüli az első hibáit... de talán mégis van hozzá köze.
    Mutasd a teljes hozzászólást!
  • Nem teljesen értem miért Javat írod közbenső rétegnek. Java-(JNI)->C++->JS, és JS->C++-(JNI)->Java lennének az irányok. Igazából a Java<->C++, amit meg kellett volna írni, a többi adott.

    De mindegy is, mert nem így csinálták.
    Mutasd a teljes hozzászólást!
  • De lehet JS->C++->Java bindingot csinálni, ha elég perverz az ember, és valamiért nagyon kell. 

    Lehet. Csak ha wrappelni kell valamit egyszer JS<->Java, aztán még Java<->C++ irány(ok)ba is, akkor semmi értelme a Java réteg közbeiktatásának. Akkor a C++ változatot kell beágyazni, annak kell kompletten a szkriptet átadni, és annak a Java-ba visszahívását kell csak lehetővé tenni, mert az csak egy wrap réteget igényel.
    Mutasd a teljes hozzászólást!
  • Érteni értem, csak nem láttam, mert figyelmetlen voltam. De alaposabban megnézve én is azt látom, hogy van Java implementáció is. Azért azt megnézném, hogy a C-s és a Javas implementáció közt sebességben, memóriahasználatban mekkora különbség lehet.
    Mutasd a teljes hozzászólást!
  • oda-vissza transzparens módon és korlátok nélkül kellene tudnia hívnia a Java kódba ahhoz, hogy integrálni lehessen abba, mint egy, a Java alkalmazás szkriptelését lehetővé tevő eszközt.

    Ennek éppenséggel nincs technikai akadálya, JNI-on keresztül tudsz Java kódot hívni, Java objektumokat példányosítani, kivételt dobni stb. Hogy mennyire törik le tőle az ember keze, és mennyi idő után vág eret, az egy másik kérdés. De lehet JS->C++->Java bindingot csinálni, ha elég perverz az ember, és valamiért nagyon kell. 

    Ugyanakkor úgy tűnik nem ezt csinálták:

    SE:ISDK/Java is written in and works with any Pure Java application.

    Forrás

    Gondolom többek között azért is, mert J2ME-hez is lehetett használni.
    Mutasd a teljes hozzászólást!
  • Ezt nem értem, miért kellene valamit Javaban is megírni ahhoz, hogy használható legyen Javaból. Javaból lehet hívni natív kódot.

    Te már azt sem érted, hogy mit írtam. És ami az volt, hogy egyrészt nem csak hívásról, hanem fordításról van szó. (A dokumentáció legalábbis erről beszél Java esetén is, ti. hogy a felhasználó fejlesztő maga fordíthat .jar-t a ScriptEase Java változatából, és azt használhatja majd a saját Java kódjából.) Másrészt, hogy itt egy hordozható megoldásról van szó, nem JNI-s "varázslásról". Legalábbis ez a kifejezés vagy bármi utalás arra, hogy itt csak egy Java wrapperről lenne szó, ami natív kódot hív, sehol nem merül fel a ScriptEase Java változatának dokumentációjában.

    Nem is lenne sok értelme, illetve kb. megoldhatatlan lenne az integrációja a Java gazdaalkalmazással, hiszen itt egy szkriptértelmezőről beszélünk, amibe nem csak bele kellene tudni hívni a Java kódból, de aminek oda-vissza transzparens módon és korlátok nélkül kellene tudnia hívnia a Java kódba ahhoz, hogy integrálni lehessen abba, mint egy, a Java alkalmazás szkriptelését lehetővé tevő eszközt.
    Mutasd a teljes hozzászólást!
  • Ezt nem értem, miért kellene valamit Javaban is megírni ahhoz, hogy használható legyen Javaból. Javaból lehet hívni natív kódot.
    Mutasd a teljes hozzászólást!
  • A vezérlés működtetésére kiváló lehet a JS. Szerintem jó döntést hoztak, én is mindenféleképp egy interpretált nyelvet választottam volna erre a feladatra.

    Ha ma csinálnák az egészet, a TypeScript-et is megfontolnám a helyükben, mert egy bizonyos bonyolultság felett, a programozás közbeni időveszteség megtérül, mert kevesebb hiba keletkezik. Persze itt csak az erős típusosságra gondolok és véletlenül sem az OOP-re, amit rendre az összes általam ismert programozási nyelv pocsékul implementált.

    Mondjuk az OOP semmilyen formája nem alkalmas véleményem szerint kritikus területekre (repülőgép/atomerőmű/autó vezérlés stb.), de szerintem a legtöbb esetben sem abban kéne írni a programok jelentős részét. De ez már egy másik téma és messzire vezet. :)
    Mutasd a teljes hozzászólást!
  • Több, mint valószínű hogy C-ben írták az engine-t.

    Meg Java-ban. (Vagy egy közös harmadik nyelvben, amiből mindkét nyelvű változatot generálták - főleg, hogy a cég ami csinálta, kifejezetten új nyelvek kidolgozásával és nyelvi értelmezőkkel, fejlesztőeszközökkel látszott foglalkozni.) Mert, hogy egyébként nem lehetett volna hordozható, fordítható Java csomag (is) belőle.

    Teljesen irreleváns, mennyire vannak távol egymástól,

    Nem. Most írtam le miért. Azért, mert ez egyértelművé teszi, hogy szinte bármilyen nyelvben meg lehetett volna írni a motort. És, hogy ezzel összefüggésben tök mindegy, hogy konkrétan miben írták meg a motort, mert az nem az adott nyelv a feladatra kiválóságának jelzője (hanem mondjuk azé, hogy a piacon milyen nyelvet használó projektek, fejlesztők, iparágak részéről volt a legnagyobb befogadóigény rá).

    Ettől függetlenül nem mindegy, hogy mondjuk C-ben vagy Java-ban írták, mert a kettőnek teljesen mások az erősségei.

    És látod, mégis mind a kettőben megírták. Ezért mondtam, hogy ez egyértelművé teszi, hogy nem a nyelv kiválósága vagy kivételes alkalmassága a feladatra volt a döntő. Mert két, egymással szinte minden szempontból ellentétes nyelv nem lehet egyszerre ugyanolyan alkalmas ugyanazon feladat megoldására. Vagy ha az, akkor minden más  nyelv is kb. ugyanolyan alkalmas rá.

    Eredetileg a Pythont szerették volna, de állítólag túl nagy volt az interpreter meg a libraryk

    Egyrészt ilyet egyik itt felmerült forrásanyagban sem írtak. Így el nem tudom képzelni, hogy ezt honnan vetted. (Amit találtam random internet-júzer kijelentését random weboldalon ezzel kapcsolatban az az volt, hogy a lebegőpontos számok miatt döntöttek a JS mellett a Pythonnal szemben. De ez is olyan, hogy vagy igaz vagy nem.) Másrészt ha ez így is volt vagy lett volna, akkor is csak azt bizonyítja, hogy lám, a JavaScript még ebből a szempontból is hatékonyabb és jobb választás tud lenni.

    Illetve szóba jött még a Lua is, de azt elvetették, mert akkoriban még túl fejletlennek találták.

    A 15-20 évvel ezelőtti JavaScript-hez képest? Viccelsz? Ráadásul a Lua 3 évvel idősebb nyelv, mint a JS. 

    Mutasd a teljes hozzászólást!
  • Egy érdekesnek tűnő adalék, hogy (egyebek mellett) miért a JS-re (illetve inkább egy lebutított JS-re) esett a választás:

    I got to visit the control centre while it was under construction back in 2016 (I think: I was one of the guests at an SF convention, hence the special group tour). One factoid that stuck with me was they also considered micro-Python, but Javascript won because it supported floats. They were looking for an embeddable scripting language that astronomers could reasonably be expected to learn or already use for directing observations, so it had to be compact, very popular or ubiquitous, expected to remain so throughout the working life of the telescope, and easy to learn. (It was to be used not by CS grads but by astronomers.)

    It's a cut-down subset of the language and bolted down to prevent idiots installing random packages off the internet on an irreplaceable $10Bn instrument.

    (HN comment)

    Mindazonáltal ez se arra nem bizonyíték, hogy a JS nem igazi programozóknak való, se arra, hogy a JS (vagy úgy általában egy runtime validált és fordított nyelv, dinamikus típusrendszer stb) pont annyit nyújt, mint egy statikus, fordítási időben validált nyelv. Itt azért eléggé le van limitálva a JS képessége, szerepe, és a dinamikus típusrendszer kihasználása is lényegében csak egy elméleti lehetőség, mert a feladat jellegéből (és az egyéb vezérelt programok okán) a típusok valójában kötöttek. 

    A tény, hogy JS mellett döntöttek, illetve hogy miért mellette az arra nagyon jó példa, hogy hogy kell szakmailag megalapozottan tech stacket választani, hogy hogy kell a döntési feltételrendszert megalkotni. Kimondottan, hogy az elvárásoktól kell kiindulni, és majd az adja ki a tech választást. Az xy nyelv/eszköz a legjobb/gagyi nem egy feltételrendszer, hanem fanboyság/haterség, és pont a professzionalizmust veszi ki az egészből.
    Mutasd a teljes hozzászólást!
  • Több, mint valószínű hogy C-ben írták az engine-t.

    Ami - és az, hogy pont a C-ről és a Java-ról van szó, mint két nyelv, amiben elkészült, és amik távolabb nagyon nem is nagyon lehetnének egymástól sajátosságait illetően

    Teljesen irreleváns, mennyire vannak távol egymástól, amíg van SDK C-hez/C++-hoz és Java-hoz, addig teljesen érdektelen, hogy miben készült maga az engine. Ettől függetlenül nem mindegy, hogy mondjuk C-ben vagy Java-ban írták, mert a kettőnek teljesen mások az erősségei.

    Az egyetlen nyelv pedig, ami valóban jelen van a teleszkóp működésében a fedélzetén, az a JavaScript.

    Eredetileg a Pythont szerették volna, de állítólag túl nagy volt az interpreter meg a libraryk. Illetve szóba jött még a Lua is, de azt elvetették, mert akkoriban még túl fejletlennek találták.
    Mutasd a teljes hozzászólást!
  • Az engine C vagy C++ nyelven íródott, erre vonatkozólag nem találtam pontosabb infókat.

    Az nem derült ki, hogy C vagy C++-ban íródott, csak az, hogy volt belőle C/C++-hoz szánt változat. Ahogy volt Java változat is belőle. Tehát abban is íródott. Illetve igazából semelyikben akkor. Hiszen azt jelenti, hogy egy nyelvfüggetlen, illetve több nyelven is implementált valami volt.

    Ami - és az, hogy pont a C-ről és a Java-ról van szó, mint két nyelv, amiben elkészült, és amik távolabb nagyon nem is nagyon lehetnének egymástól sajátosságait illetően - mindjárt jól példázza azt is, hogy mennyire tök mindegy is, hogy milyen nyelvben készült (és hogy jó eséllyel bármilyen másik nyelvben is éppen úgy megvalósítható lett volna - akár még JavaScript-ben is). Mármint azon túl is, hogy - ahogy leírtam már - mivel bináris formában terjesztették, ezért is tök mindegy, illetve lényegét tekintve megállapíthatatlan, hogy miben készült.

    Az egyetlen nyelv pedig, ami valóban jelen van a teleszkóp működésében a fedélzetén, az a JavaScript.
    Mutasd a teljes hozzászólást!
  • A ScriptEase nevű JavaScript engine futtja a teleszkópon a JS-t. Ezt az engine-t Brent Norda cége, a Nombas fejlesztette ki ( Nombas ), a kezdetei a '90-es évek elejére nyúlnak vissza. Az engine C vagy C++ nyelven íródott, erre vonatkozólag nem találtam pontosabb infókat.
     
    Itt a 3.1-es pontban azt írják: "The script interpreter is run by the flight software, which is written in C++. The flight software operates the spacecraft and the science instruments."
    Azt nem tudom, hogy ez a script interpreter megegyezik-e a ScriptEase enginnel, vagy annak egy részhalmaza, vagy hogy pontosan hogyan kapcsolódik.
    Mutasd a teljes hozzászólást!
  • Nem érted mi szúrja a kritikusok szemét

    De, értem. Az, hogy a JS egy olyan eszközön és egy olyan szerepben is feltűnik, ami végleg és megkérdőjelezhetetlenül cáfol és megsemmisít minden olyan - mellesleg eddig is hamis - vélekedést és állítást, ami szerint a JS-t csak amatőrök és csak bohóckodásra használják, olyan helyeken, ahol a megbízhatóság nem fontos, ahol nem számít ha valami rosszul működik, ahol nincs tétje semminek. Ami nyilván abszolút nem igaz az JWT-re - mi több, nála kritikusabb és a fenti szempontokból magasabb elvárásokat megfogalmazó alkalmazási területet nehéz lenne mondani.

    Ezért a JS-fóbiások kényszeresen próbálnak olyan dolgokat iderángatni, amivel legalább maguk számára be tudják mesélni, fenn tudják annak hamis látszatát tartani, hogy "háhá... nem is igazán a JS-t használják, meg nem is igazán a JS amit használnak"; vagy hogy ugyan a JS-t komoly helyen és komoly emberek használják, de az igazán komoly helyeken azért ezen belül sem JS működik, és az igazán komoly feladatokat nem rá bízzák. Lásd még: A te érvelési hibád: Nem igazi skót

    Nem, nem a JS működteti. Hanem az alatta levő rengeteg kód.

    Ami nem igaz. A JS éppen úgy működteti, mint "az alatta lévő rengeteg kód". Ami ráadásul nincs semmilyen nyelvben, mert bináris formában van rajta. Így azt mondani, hogy mondjuk C vagy C++ működteti, adott helyzetben elég értelmetlen. Szemben a JS-tel és a JS kódokkal, amik tényleg JavaScript-ként vannak jelen a teleszkóp vezérlőberendezésén.

    Ehhez képest azt, hogy a "működteti" egy általad használt kifejezés, és a címben nem az szerepel, hogy az "a JS működteti", hanem az, hogy azzal "működik" (ami jelentéstartalmában is egy teljesen más dolog), már csak ráadás. Ezt kritizálni így, ahogy fent olvashatjuk, kb. annyira értelmes, mint azzal jönni, hogy az autó nem benzinnel működik, hanem a motorral. Vagy, hogy a hűtő nem hűtőgázzal működik, hanem kompresszorral. Stb.
    Mutasd a teljes hozzászólást!
  • Nem érted mi szúrja a kritikusok szemét

    Nem írták semmiben a NASA-nál, csak felhasználták és beépítették, bináris formában.

    és

    JavaScripttel működik a James Webb űrteleszkóp



    Nem, nem a JS működteti. Hanem az alatta levő rengeteg kód.
    A JS-el irányítják a működését. Ez a legfelső réteg. Amivel semmi gond, csak logikailag más.

    Valóban jó példa egy játékmotor, és egy scriptnyelvel irányítása.
    Ahol egy nagyon komoly kódbázis dolgozik a megjelenítésen, de egy scriptnyelvvel (annak célszerűbb használata miatt) határozzuk meg, hogy mi is jelenjen meg.

    Mutasd a teljes hozzászólást!
  • Miben írták a javascript futtatót ?

    Nem írták semmiben a NASA-nál, csak felhasználták és beépítették, bináris formában. És nem azért választották, mert egy adott nyelvben volt írva (ami a bináris forma miatt irreleváns is volt, de ráadásul a jelek szerint több nyelvben is meg volt írva), hanem azért, mert több évtizedes volt és mert különösen robosztusnak és hibamentesnek számított.

    Az alacsony szintű műveleteket ?

    Nem tudjuk. Valószínűleg gépi kódban és valami hardverközeli nyelvben.

    Miért pont javascript, miért nem egy olyan script nyelv amiben megadjuk a típusokat ?

    Ezt a NASA-tól kellene megkérdezned. De valószínűleg pont azért, mert ők tudják és értik, 1. hogy a típusok rögzítésének hátrányai nem állnak arányban az előnyeikkel, 2. hogy ha funkcionálisan teszteled a kódod (márpedig ők ezt teszik), akkor a típuskikötések használata értelmetlen pazarlást jelentenek.

    statikus pl.  typescript ?

    A TypeScript még nem is létezett, amikor az alapvető technológiai döntéseket meghozták az űrteleszkóppal kapcsolatban. De ha létezett volna sem tudjuk, hogy azt választották -e volna.
    Mutasd a teljes hozzászólást!
  • Miben írták a javascript futtatót ?
    Az alacsony szintű műveleteket ?
    Miért pont javascript, miért nem egy olyan script nyelv amiben megadjuk a típusokat ? statikus pl.  typescript ?
    Mutasd a teljes hozzászólást!
  • Na jó, de az is ott van hogy az igazi programozó, ha szükséges, bármilyen nyelven tud FORTRAN kódot írni. Tehát: a modern igazi programozó JavaScriptben, esetleg Pythonban ír FORTRAN kódot
    Mutasd a teljes hozzászólást!
  • Ennyi beszélgetés a témában, és senki nem említi meg, hogy az igazi programozó FORTRAN-t használ? Hígul a szakma
    Mutasd a teljes hozzászólást!
  • Az egyszerűségen felül az is fontos, hogy míg a C++ nál egy hosszadalmas fordítási és optimalizálási folyamat fut le, addig scriptnyelvnél akár futás közben is módosítható a program, mivel itt nincs komoly fordítás/optimalizáció. 

    Tévedsz. És nem is kicsit. Egyrészt abban, hogy a mai szkriptnyelvek, illetve "értelmezőik" ne fordítanák le a forráskódot (akár gépi kóddá is), vagy ne optimalizálnák esetleg rommá azt, különösen annak sebességkritikus és nem változó részeit. A mainstream böngészőkbe épített JavaScript-értelmezők esetében pl. teljesen hamis az állítás, hogy ne így lenne, de más szkriptnyelvek esetében is részben vagy teljesen, a használt eszköz, futtatóplatform függvényében.

    Másrészt - részben előbbivel összefüggésben - a futás közbeni módosításnak semmi köze nincs az optimalizáláshoz. Utóbbi megléte vagy hiánya se ki nem zárja, se feltétlenül lehetővé nem teszi (és pláne nem implikálja) a futás közbeni módosítást.

    Mellesleg pl. C++-hoz is léteznek interpreterek, és szkriptnyelvekhez is léteznek fordítók. Tehát ez is egy olyan dolog - ti. hogy fordítás, illetve milyen fordítás előzi -e meg egy adott nyelven készült program végrehajtását -, ami nem szükségszerűen következik a nyelvből és annak használatából. És ami miatt az ezek mentén történő valamiféle kettéosztása is értelmetlen a nyelveknek, szkriptnyelvekre meg többiekre.

    Nyílván egy jól átgondolt architektúrát az ember nem futás közben szokot módosítgatni, de egy scripttel összerakott valamit annál inkább.

    Itt megint két, egymástól tök független dolgot próbálsz összekötni, összemosni. Mert hogy egyetlen architektúra sem lesz átgondolt attól, hogy nem módosítják, és attól sem lesz átgondolatlan, hogy módosítják, ha és amikor szükséges. Továbbá semmivel sem inkább szokás az architektúrát magát módosítani "futás közben" egy szkriptnyelvben sem, mint egy nem szkriptnyelvben írt programban.

    A kettőt általában kombinálni szokták, vagyis a komoly architektúrát megírják a komoly célokra szánt nyelvvel a szakemberek, a hozzá bindolt script rendszerrel meg gyorsan összeütik a magasabb szintű logikai részt jellemzően azok, akik nem az architektúra és az alacsonyszintű programozás mesterei, mint inkább valamilyen más szakterülettel foglalkozó a programozáshoz csak minimálisan értő emberek (designer, tester, webfejlesztő, orvos, csillagász stb.). 

    Ilyesmit általában azok szoktak mondani, akik nem az architektúra, az alacsony szintű programozás és úgy általában a komoly fejlesztés szakemberei, hanem inkább csak törik, "kutyaütik" a programozást. A valódi szakemberek ugyanis 1. tudják, hogy a fent felvázolt összefüggés a valóságban nem létezik, 2. tudják, hogy nem egyes nyelvek komolyak és komolytalanok, hanem a programozók, akik használják azokat vagy nyilatkoznak róluk, 3. mindent "szkriptben" írnak meg, amit abban érdemes, teljesen függetlenül attól, hogy - pláne az előbb említett, nem éppen toppon lévő szakemberek szerint - mennyire komoly az adott feladat vagy az architektúra mely részén helyezkedik el.
    Mutasd a teljes hozzászólást!
  • A program összetettsége is meghatározza, hogy melyik nyelv a hatékonyabb. Kis programot összeütni, vagy egy engine-hez egy játéklogikát összerakni, esetleg a legfelső réteget egy scriptnyelvvel lehetséges, míg több millió soros több rétegű architektúrát viszont jellemzően nem scriptnyelven írnak. Az egyszerűségen felül az is fontos, hogy míg a C++ nál egy hosszadalmas fordítási és optimalizálási folyamat fut le, addig scriptnyelvnél akár futás közben is módosítható a program, mivel itt nincs komoly fordítás/optimalizáció. Nyílván egy jól átgondolt architektúrát az ember nem futás közben szokot módosítgatni, de egy scripttel összerakott valamit annál inkább.

    A kettőt általában kombinálni szokták, vagyis a komoly architektúrát megírják a komoly célokra szánt nyelvvel a szakemberek, a hozzá bindolt script rendszerrel meg gyorsan összeütik a magasabb szintű logikai részt jellemzően azok, akik nem az architektúra és az alacsonyszintű programozás mesterei, mint inkább valamilyen más szakterülettel foglalkozó a programozáshoz csak minimálisan értő emberek (designer, tester, webfejlesztő, orvos, csillagász stb.). Ehhez mérten a script egy gyengített egyszerű szintaxisú, magasszintű és futás közben módosítható megoldásokat tartalmaz. A példádban szereplő Qt is ilyen éppenséggel, ahol a frontedet QML-el tudja scriptelni a designer, míg maga a rendszer többi komolyabb részének fejlesztése már a komoly C++ szal zajlik.
    Mutasd a teljes hozzászólást!
  • A C++-hoz képest sokkal hamarabb végzel, több időd lesz egyéb funkciókra, egyéb optimalizálásokra

    Ezzel mondjuk nem feltétlenül értek egyet. A modern C++ elég jó nyelvi támogatottságot nyújt tömör programok írására, valamint ugyanúgy elérhető kismillió könyvtár, melyek az adott probléma specifikus magas szintű használatot biztosítanak.

    és bárhol is futtatod minden probléma/nehézség nélkül.


    Ez mondjuk a C++-ra is igaz. Elég könnyű cross-platform kódot írni pl QT segítségével. De a core algoritmusokat semmiből nem áll lefordítani egy arm-ra, vagy 8-bites uC-re.



    Problémához választunk eszközt, mint már sokan írták.
    Mutasd a teljes hozzászólást!
  • Megragadtad a lenyeget.
    Mutasd a teljes hozzászólást!

  • Kulcsmondat: "Az altalam ismert vilagban..."
    Mutasd a teljes hozzászólást!
  • Az altalam ismert vilagban, az esetek 99%-ban a scriptnyelv a megfelelo valasztas. Kivetelt kepeznenek az embeded megoldasok, te tobb microkontrollerben is mar JS fut egy ideje, es mivel ugy is IoT, ezert ott is van letjogosultsaga mostmar.
    Mutasd a teljes hozzászólást!
  • Ha úgy akarnád érteni, hogy komolyabb háttértudás és nagyobb tervezés/tapasztalat kell a nem script nyelvek használatához, az sokat segítene. :)

    Ettől még a legprofibb (értsd hivatásos kibővítve a hozzáértő, szakmabeli, tapasztalt fogalmakkal) programozók is használnak script nyelvet, HA a feladathoz az a megfelelőbb.

    De sajnos a vllág elment abba az irányba, hogy akkor is script nyelveket használ (sokféle kényszerből, ez megint egy új téma), amikor nem az lenne az indokolt ill. célravezető.

    ui:

    Nyitottam is neki önálló szálat:

    Scriptnyelvek kényszer
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd