Továbbra is a JavaScript a legnépszerűbb nyelv a GitHub szerint

Továbbra is a JavaScript a legnépszerűbb nyelv a GitHub szerint
2018-11-22T19:55:55+01:00
2018-11-28T20:33:37+01:00
2022-10-18T12:55:33+02:00
  • "Virágozzon száz virág!'

    Nem az a cél, hogy átvegye bárminek is a helyét a dotnet.
    Az eddig eléggé fajsúlyos windows kliens rendszerek (ez igen sok és igen komoly üzleti alkalmazást jelent) előtt megnyílik az út, hogy sokkal könnyebben beintegrálódjanak a mobil, webszerver és webkliens alkalmazásokba.
    Vagyis míg a konzolos GUI teret veszít, a régi bevált technologiának megtalálták a hatékony utat a feltörekvő platformokra.

    Ennyi.
    Mutasd a teljes hozzászólást!
  • Az általad "hiányolt" multiplatform, na az a Core... úgy tűnik le vagy maradva a technologia ismeretében.

    Nem vagyok lemaradva, csak erre írtam, hogy a Java már elvitte ezt a piacot rendesen. Nem igazán látom, miért kezdene a piac tömegesen áttérni a Microsoft technológiájára, amikor köszöni szépen, teljesen jól megvan a Java technológiával. Persze mindig lesznek Microsoft-fanok, nálunk is van két senior architect akik mindenáron az Azure-on meg C#-ban akarnak fejleszteni, és valahogy az összes értékelésükben az jön ki, hogy valahogy az Azure mindig, mindenben jobb, mint az AWS vagy a GCP, a .NET meg jobb, mint a JVM stb. De szerintem a Microsoft tartani fogja, esetleg enyhén növeli a piaci részesedését a jövőben, de nagy tarolást ne várj.

    Hanem hogy azt a kódot (librarykat és tudást, know-how-t) veheted munkába a böngészőben, amit a Win-es GUI alkalmazásba tettél, a Xamarinos mobilappban és a webszerveren is kihasználtál, egyszerűen (nemhogy forrás szinten, de assemblyben) átvettél és a webkliensen az eddig megszokottnál lényegesen nagyobb szintten kódolhatsz.

    Erre is az vonatkozik, ami fentebb, hogy ez remek technológia lesz annak a rétegnek, aki eddig is C#-ban kódolt, de kizárt, hogy ez híveket toborozzon, vagy szélesebb körben elterjedjen.
    Mutasd a teljes hozzászólást!
  • Személy szerintem nem hiszek abban, hogy a C# most kezdene "kifutni" (max. a divatból), az Azure megerősödése adhat neki egy lökést, de a C#/.NET vonal továbbra is a MS lock-in, platformfüggőség szinonimája, és -- bár kétségtelenül megszólítja a fejlesztők egy részét -- emiatt nagy növekedést nem várok tőle. Még ha teljesen multiplatformossá tennék is a .NET-et, ez a hajó már elúszott a JVM képében.

    A DotNetCore összetételre vonatkoztattam a "kifutni" szót. a C# már nagyon erősen betagozódott a szakmában, ez nem kérdés.
    Az általad "hiányolt" multiplatform, na az a Core... úgy tűnik le vagy maradva a technologia ismeretében.

    Miért gondolod, hogy a Blazor megmozgatná a böngésző-oldali programozást?

    Mert egy hatalmas ugrás a C# mint nyelv is a JS-hez képest. De nem ez a nagy dobás. Hanem hogy azt a kódot (librarykat és tudást, know-how-t) veheted munkába a böngészőben, amit a Win-es GUI alkalmazásba tettél, a Xamarinos mobilappban és a webszerveren is kihasználtál, egyszerűen (nemhogy forrás szinten, de assemblyben) átvettél és a webkliensen az eddig megszokottnál lényegesen nagyobb szintten kódolhatsz.  

    Már maga az is szép, ha a Razor szintaxis levihető a kliens oldali templétezésre, de hogy egy az egyben átveheted a kliensre az eddig csak szerver oldalon igazán meglévő komplexitású kódokat, komplett osztálykönyvtárakat, az éles üzleti és adatkezelési osztályokat, na az minőségi ugrás.
    Mutasd a teljes hozzászólást!
  • Azért a C#/DotNetCore még érdekes lehet, most kezd kifutni, akármi is lehet belőle.

    Igazad van, a C#-ot a Javával együtt kellett volna említenem, mint egy iparági megoldást. Személy szerintem nem hiszek abban, hogy a C# most kezdene "kifutni" (max. a divatból), az Azure megerősödése adhat neki egy lökést, de a C#/.NET vonal továbbra is a MS lock-in, platformfüggőség szinonimája, és -- bár kétségtelenül megszólítja a fejlesztők egy részét -- emiatt nagy növekedést nem várok tőle. Még ha teljesen multiplatformossá tennék is a .NET-et, ez a hajó már elúszott a JVM képében.

    Miért gondolod, hogy a Blazor megmozgatná a böngésző-oldali programozást?
    Mutasd a teljes hozzászólást!
  • A xamarin forms kb. a WPF egyszerûsített változata, és elég sok platformot támogat. A Blazor tényleg elég ígéretesnek tûnik.
    Mutasd a teljes hozzászólást!
  • Tényleg. Lehet, hogy csak túl rég néztem, most kapásból jött a találat az 1 gigás hely- és forgalom-kvótáról (GitHub, ingyenes eset).
    Mutasd a teljes hozzászólást!
  • Annyiban tévedsz, hogy a python tutorialokat hamarabb végig lehet nézni és hamarabb hiheti valaki, hogy ő egy komoly szakemberré vált

    Ez valamennyire igy is van. A python sokkal egyszerubb nyelv mint a c++, ha ismer mar valaki 10 masikat, a python-t 1 het alatt meg lehet tanulni hasznalhato szinten. A tobbi ugyis jon majd a dokumentaciobol.
    Mutasd a teljes hozzászólást!
  • Hmmm… akkor nem ment át a mondanivalóm.

    Annyiban tévedsz, hogy a python tutorialokat hamarabb végig lehet nézni és hamarabb hiheti valaki, hogy ő egy komoly szakemberré vált a for dummies elolvasása után, mintha C++ tutorialikat nézett volna :)

    De tény sok olyan van, aki a 24 óra alatt könyveket olvasva azonnal zseninek érzi magát, bármilyen témában, csak a programozásban engedik szóhoz jutni, míg az Építsünk atomerőműveket 24 óra alatt kötet olvasóit a szakmájukban nem veszik komolyan.
    Mutasd a teljes hozzászólást!
  • Azért a C#/DotNetCore még érdekes lehet, most kezd kifutni, akármi is lehet belőle.

    A Blazor nagyon érdekes vonal, a böngészó oldali programozást teljesen megmozdíthatja.
    Remélem a MS komolyan veszi és beletesz sokat illetve nem hátrál ki.

    Get started with Blazor

    A xamarin/razor/blazor/környezetfüggetlenség (talán egyszer a wpf egy egyszerüsített változata multiplatform lehet) még érdekességet hozhat. Még a Java sem fed le akkora területet, mint amire a C# igéret és ahogy nézem a MS részvényérték növekedését, eltrafálták a piac által preferált utakat.
    Mutasd a teljes hozzászólást!
  • Nem kell magadnak installalni az lfs storet a nepszerubb git hostok tamogatjak alapbol. A github, gitlab biztosan.
    Mutasd a teljes hozzászólást!
  • Javíts ki, ha tévedek, de az LFS (a vicces magyar áthalláson felül) nekem mindig olybá tűnt, hogy te magadnak installálsz egy ilyen szervert, ahova majd automatikusan kerülnek a GitHubra nem való fájlok. A GitHubra meg gyakorlatilag linkek mennek.
    Mutasd a teljes hozzászólást!
  • Hmm, na ma is megismertem valami újat, köszi a választ! ;) Mondjuk ez gondolom nem túl tárhely barát, mert ha egy 20 megás PSD-ben cserélnek egy logót, akkor annak az új verziója újabb 20 mega. De jó tudni, hogy ilyen is van. Jobb, mint a 2 FINAL 2. ;)
    Mutasd a teljes hozzászólást!
  • Kelleni nem kell, de verziokovetoben szoktak, mostanaban git-ben. Tobbek kozott ezzel: Git Large File Storage
    Mutasd a teljes hozzászólást!
  • Csatolom, én így szoktam látni grafikusoknál.

    Troll off, amúgy jó kérdés, semmilyen grafikai munkával nem foglalkozok, így nem tudom, de arra tippelek, hogy nem Github-on kell képeket, videókat verziókezelni. :)
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • A Python erősen túlhype-olt, boldog boldogtalan Pythont tanul, de ipari környezetben elhanyagolható a valós részesedése, és pl. a web backend oldalon sehol sincs a PHP-hez képest

    En pont forditva latom. A php-t foleg ott hasznaljak ahol minden mindegy csak olcso legyen es legyen hozza havi 500 ft-ert hosting. Komolyabb projekteknel java, python, .net-van es mostanaban go-is sok van.
    Mutasd a teljes hozzászólást!
  • Optimális esetben képeket és videókat sem rakunk Github-ra, de azért megnéznék egy olyan statisztikát, hogy ezekből mennyi lehet ott. :)

    Miert, te hogy oldod meg a kepeknek es videoknak a verziokezeleset? Vannak ugyanis akik kepekkel es videokkal dolgoznak.
    Mutasd a teljes hozzászólást!
  • Ebben is lehet igazság, meg sokan vannak, akik az említett jQuery-t, Bootstrap-et stb. a saját oldalaikról töltik be, így ezek sincsenek ott a commitban, ez tény. Viszont egyrészt én szeretem nálam tudni pl. a jQuery-t, hogy ha bármi miatt nem, vagy lassan érhető el a szerverük, akkor az ne lassítsa le az én oldalamat is. Emellett viszont nem rakok fel és tárolok ész nélkül minden szemetet, ha használnom kell egy libet, kiegészítőt, plugint stb., akkor mindig átnézem, hogy egyáltalán kell-e minden belőle. Kinek hogy. :) Másrészt amit írsz, az a szép megoldás lehet, az pedig sok fejlesztőre sajnos nem jellemző. Optimális esetben képeket és videókat sem rakunk Github-ra, de azért megnéznék egy olyan statisztikát, hogy ezekből mennyi lehet ott. :)
    Mutasd a teljes hozzászólást!
  • Annyit azért érdemes tudni a mai világról, hogy GitHub-ra nem szokás a függőségeidet feltenni, csak az összeszedésükhöz használt leírókat. Így lesz a pár kilobyte-os checkoutból 20+ megás rém, mire tényleg futni kezd. De a statisztikában csak a pár kilobyte-os rész szerepel csak.
    Mutasd a teljes hozzászólást!
  • Nem tartom túl reprezentatívnak ezeket a Github népszerűségi statisztikákat, mert attól még, hogy ezekből van a legtöbb náluk, nem biztos, hogy ezekben kódolnak ténylegesen a legtöbbet.

    Én webes vonalon mozgok, így onnan hoztam két konkrét példát:

    Nagyon egyszerű WP oldal, képek nélkül a template mappa 486KB, melyből
    - jQuery 85,6KB (szerintem ma már ez alap)
    - BX slider JS 67,6KB (egy egyszerű, nem túlcsicsázott slider)
    - less.min.js 155,5KB (LESS compiler)

    Ez a három pedig majdnem 2/3-a az egésznek, a többi elosztva PHP/HTML/JS/CSS, amit tényleg én írtam.

    Másik, egy közepes méretű és összetettségű MVC oldalnál a teljes models, views, controllers mappa együtt 367KB. Ha ehhez hozzáadjuk a a fenti 3 JS-t, akkor az együtt méretben majdnem annyi, mint a PHP alapú framework PHP file-jainak nagy része (nyilván ez csak az app, a system nem, mielőtt belekötnek).

    Ha csinálok egy index.html-t, benne egy div, ami mondjuk jQuery segítségével valami egyszerű animációval mozog, akkor kb. <1KB lesz a HTML/CSS/saját JS és 85KB a jQuery.

    Ha commitolunk egy üres WP-t, akkor abban eleve benne van pl. a jQuery, a jQuery UI, szerintem még a Bootstrap is, és még fene tudja mi, pedig lehet, hogy egyik sincs használva, csak jár a WP-vel együtt.

    Tehát az, hogy a JS vezet nem véletlen, nagyon sok weboldalon nagyon sok (felesleges) JS van, amit nyilván commitolnak a repóba, így megemeli a Github statisztikáját is. Megnézném ezt a statisztikát pl. csak úgy, hogy --exclude jquery*.js, vagy --exclude bootstrap*.js . :)
    Mutasd a teljes hozzászólást!
  • Hmmm… akkor nem ment át a mondanivalóm. 

    Mutasd a teljes hozzászólást!
  • Hali!

    Ez csak addig vicces, amíg távolról nézed.

    Hmmm… akkor nem ment át a mondanivalóm. 

    Abban a pillanatban, hogy bedolgozol egy cégnek - ahol ott ül az illető úriember és az Ő szava a döntő - már nem annyira megmosolyogtató

    Az én szerencsém, hogy soha életemben nem kerültem ilyen helyzetbe (munkahely tekintetében) – illetőleg két alkalommal direkt kerültem el (nem vállaltam az együttműködést).

    Mutasd a teljes hozzászólást!
  • Ez csak addig vicces, amíg távolról nézed.

    Abban a pillanatban, hogy bedolgozol egy cégnek - ahol ott ül az illető úriember és az Ő szava a döntő - már nem annyira megmosolyogtató   
    Mutasd a teljes hozzászólást!
  • Hali!

    a tippentőm kivan a sok hiperidiótával akik végignéztek egy keras tutorialt és innentől pájton programozok és Ai developerek

    Tökéletesen megértelek. Én is megmosolygom azokat, akik végignéznek egy XZY-tutoriált és mindjárt XYZ-programozónak hiszik magukat. 

    Mutasd a teljes hozzászólást!
  • A Python erősen túlhype-olt, boldog boldogtalan Pythont tanul, de ipari környezetben elhanyagolható a valós részesedése

    megaLike :) 
    a tippentőm kivan a sok hiperidiótával akik végignéztek egy keras tutorialt és innentől pájton programozok és Ai developerek
    Mutasd a teljes hozzászólást!
  • A poén az ebben az anekdotában, hogy a tudósnak igaza van, csak nem a megfelelő úton
    jutott el hozzá, mivel a bolhák hallószerve az első pár lábukon van.
    Mutasd a teljes hozzászólást!
  • A JavaScript azért van ennyire fent, mert a web frontendek ezt használják. A backend oldalon a node.js-nek van pár százalék részesedése, de a hype már lecsengett. Ami újdonság volt a node.js-ben (non-blocking I/O stb.) azt a többiek már lekopizták, a node.js semmit se tud, amit a többiek ne tudnának ugyanúgy vagy sokkal jobban. Maga az alapító is elhagyta már a node.js-t és másik projekten dolgozik "tanulva a node.js hibáiból".

    A Java nem az Android miatt van ennyire fent, hanem mert a fejlesztések nagyon nagy része ténylegesen Javában zajlik, elég rápillantani egy indeed statisztikára.

    A Python erősen túlhype-olt, boldog boldogtalan Pythont tanul, de ipari környezetben elhanyagolható a valós részesedése, és pl. a web backend oldalon sehol sincs a PHP-hez képest. És mivel a PHP7 már egy egészen jó nyelv, így a Pythonnak kevés esélye van, hogy itt is megerősödjék.

    A Kotlin valóban egy jó nyelv, de ahogy hallom, nem állnak tömegek sorban az áttérésre. A modern IDE-k (főleg az IntelliJ pl. az emmet pluginnal) olyan sok segítséget nyújtanak a Java boilerplate kitöltéséhez, hogy egy gyakorlott Java programozó gyakorlatilag úgy ír kódot Javában (emmettel, live template-tel stb.) mint más Pythonban. Java programozó ismerőseim szerint "majd egyszer kipróbáljuk" a Kotlint, de nem igazán rohannak.

    A TypeScript csak egy erős típusos overlay a JavaScript felett, még ha meg is erősödik a GitHubon, akkor azért, mert a frontendeket (React stb.) ezzel kezdik el írni. Kevés esélye van a backend oldalon.

    Szóval magyarul backend oldalon marad a PHP dominancia, legalábbis itt Európában, lassan fejlődik a Python, elüzemelget a Ruby, helyenként van egy-két Node.js, az iparban meg marad a Java.

    Machine learning stb. témában meg nyilván nyomul a Python és az R, mellette lassan jön föl talán a Julia, remélem fejlődnek a JVM nyelvek (Scala és Clojure), nagy csodák nincsenek.
    Mutasd a teljes hozzászólást!
  • A statisztika elég kétélű fegyver. Nagyon könnyű rosszul használni vagy rossz következtetést levonni, akkor is ha nem szándékosan akarsz hamisítani.

    A régi anekdotának nagy igazsága van:
    A tudós vizsgálta a bolhát. Azt mondta neki, hogy ugorj, a bolha pedig ugrott. Aztán levágta az egyik lábát. Megismételte a kísérletet, a bolha megint ugrott. Aztán a másodikat, harmadikat.. míg az utolsót is, de ekkor már a bolha nem ugrott. Mire a tudós levonta a következtetést: ha a bolha összes lábát leváguk, megsüketül.
    Mutasd a teljes hozzászólást!
  • A statisztika az egzakt tudomány.
    A statisztikai adatfelvétel (mődja, tartalma, súlyozása), az eredmények és értékelések már szubjektív döntések.
    Mutasd a teljes hozzászólást!
  • “Csak abban a statisztikában hiszek, amit én magam hamisítok”

    Csak aki nem érti azt, hogy hogyan működik a statisztika, gondolhatja azt, hogy azokat kell vagy érdemes hamisítani. Aki meg érti, az tudja, hogy ez teljességgel értelmetlen és szükségtelen. Szintén csak az, aki nem érti a statisztika működését gondolja azt, hogy a tény, hogy két látszólag hasonló statisztika alapvetően eltérő számokat hoz, valamiféle hamisítást vagy manipulációt implikál. Nem teszi.

    Az meg, hogy egy statisztika nem azt hozza, mint amit valaki szívesen látna vagy helyesnek gondol, végképp' nem jelenti azt, hogy az a statisztika manipulált vagy téves, és hogy az a statisztika meg, ami az úgymond várt számokat hozza, viszont helyesebb vagy mérvadóbb lenne. Ez csakis azt jelenti, hogy az illető vágyszerű gondolkodásban szenved.
    Mutasd a teljes hozzászólást!
  • Nyilván kivégezné a security guy azt, aki túl sokat githubol ki a céges codebaseből.... Illetve a manager guy is sokat panaszkodna talán a know-how miatt...

    Viszont szerintem a legtöbb cég megtehetné, hogy mindent open sourceol teljesen kivéve a security faktort... Ez tök érdekes, de szerintem simán működhetne így egy-egy cég!
    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