HOVD 2019 - Kedvenc fordított programozási nyelv

HUP

Szavazz az alábbi kategóriákban! Kedvenc ...

assembly (bármely architektúra, bármely dialektus)
4% (53 szavazat)
c
19% (274 szavazat)
c#
13% (182 szavazat)
c++
17% (246 szavazat)
go
8% (119 szavazat)
haskell, ocaml, f#, scala (statikusan tipusos funkcionalis nyelvek)
2% (35 szavazat)
java
20% (281 szavazat)
kotlin
3% (45 szavazat)
pascal
7% (97 szavazat)
rust
8% (109 szavazat)
Összes szavazat: 1441

( hrgy84 | 2019. 12. 19., cs – 15:19 )

[X] Java / Groovy

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nagyon hasonlit a Rubyhoz, ezert ha valami JVM-eset kell irni, es nem vagyok a Java nyelvhez kotve, akkor azt hasznalom inkabb. A JRuby nem teljesen nativ JVM-es nyelv, a Groovy ilyen szempontbol jobb.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( novalis65 | 2019. 12. 20., p – 13:42 )

Szerkesztve: 2019. 12. 20., p – 13:56

Úgy látom a D-re és a Crystal-ra szavazni sem lehet. De még csak Egyéb kategória sincs. Én azért megemlítem őket, mert ígéretes mindkettő. De még a modern Fortran is tetszik.

Egy időben javasolgattam a D nyelvet, de talán soha nem került be, így aztán eluntam. A tiobe szerint globális érdeklődésben előrébb tart több itteni versenyzőnél is (pl. haskell, ocaml, f#, scala, kotlin, rust), de az is csak egy mérés.

A Haskell, Ocaml, f#, Scala egy komplett csoport, nagyon-nagyon meglepne ha a D elobbre tartana mint ezek egyuttveve, vagy akar a Scala onmagaban.

Bar legfokepp emellett a csoport mellett szeretnek ervelni, de... Kotlin, really??

Amugy a Tiobe valoszinuleg / a kozvelekes szerint a legrosszabb language ranking, ha mar akkor inkabb redmonk, de a fentebbi igy is all. Gondolom ez is a problemak fo forrasa a hsz-eddel

Ha elmondod melyik reszt nem erted szivesen segitek, addig is ertelmezeskent alljon itt annyi hogy amit irtal az egy tobb mint megkerdojelezheto metodikaval keszulo ranking alapjan osszehozott lazalom. Semmi bajom a D-vel, de abban elni, hogy elorebb tart elterjedtsegben a Kotlinnal (hogy csak a legkirivobb peldadat emlitsem) olyan szintu elszakadas a realitastol, hogy a helyedben leellenoriznem nincs-e nalatok CO szivargas, ami felelos lehet ezert a velemenyert ;)

Mondjuk ahogy a szavazas allasat elnezem, a HUP-on nem igazan kozkedvelt, bar erdekes volt latni hogy alakul a javahoz kepest, jovore jogos igeny lesz osszevonni a kettot, hogy valami masnak helyet adjon.

Én nem tudom, hogy te hol olvastál ilyet, hogy én abban élek, hogy előrébb tart elterjedtségben x-nél vagyy-nál. Összesen azt írtam, hogy a tiobe mérése szerint sok itteni versenyzőnél nagyobb érdeklődésre tart számot (ezért akár nyugodtan helye lehetett volna a szvazásban), de: "ez is csak egy mérés". Tehát semmi, de semmi jelentősége nincs sem számomra, sem más módon, pont ugyanúgy, mint ahogy ennek a szavazásnak sincs. Csak egy érdkes adat, játék. Az értő olvsás elsajátításának azonban bizonyosan lenne értelme. Pl. nem kevernéd az "egy mérést" (aminek nincs jelentősége) valamely "tényállítással", nem kevernéd az "érdeklődésre tart számot" az "előrébb tart elterjedtségben" foglamakkal, stb.

"de az is csak egy mérés"

be kell vallanom, a hozzaszolasod vege folott tenyleg elsiklottam, ujraolvasva meg is lepett, es igy mashogy is hangzik az egesz, valoszinuleg mashogy valaszoltam volna ra ha figyelmesebben olvasok.

"globális érdeklődésben előrébb tart" vs. "előrébb tart elterjedtségben"

Ezeket szerintem annak kontextusaban, mit mutat egy language ranking, akar egymas szinonimajakent is nezhetjuk, az adott kontextusban nem latok kulonbseget (ami nem azt jelenti, hogy onmagaban veve a ketto ugyanazt jelentene)

Most akkor eltekintek attol is, hogy a Tiobe mennyire ilyen vagy olyan, csak ismetelnem amit mar leirtam, en barmilyen konnyed gondolatkiserlethez mas ranking-et valasztanek.

Igy is ertelmetlennek tartom egyenkent osszehasonlitani a D-t olyan nyelvekkel, amik egyertelmuen azert vannak csoportban, mert onmagukban nem elnenek tul a listan. Ez igy nekem nagyon szalmabab erveles szagu, ha nem is ez a kifejezett cel.

"ezért akár nyugodtan helye lehetett volna a szavazásban"

A Tiobe es a fenti ellenerv miatt nem ertek veled egyet. Mas miatt felkerulhet a D (vagy mas), mondjuk mert osszessegeben 3 ember szavaz majd a Kotlinra es osszevonjuk a Javaval, vagy mert jovore hirtelen tele lesz D-vel a hacker news ami miatt erdekes lehet megnezni a HUP-on hogy alakul a nepszerusege. 

A Crystal tenyleg igeretes valamennyire, a D sajnos nem. Na nem azert mert baj lenne vele, csak nem uj, es az emberek egyszeruen nem fognak elkezdeni olyan technologiat hasznalni, ami regi es eddig kb. semmire se vitte, akkor sem ha amugy technologiai szempontbol jobb mint a jelenlegi helyzet. Nem a D-t akarom tamadni, csak ugy latom van ez a bias ami miatt nagyon keves jo de nem kozkedvelt/kozismert kezdemenyezes kap masodik eselyt.

Masreszt, a D-nek manapsag a C/C++-on kivul a Rust-tal is meg kel kuzdenie a szegmenseben, es bar sok siket kivanok neki, en mind technologiai mind mindshare szempontbol a Rust-ot reszesitenem elonyben.

Nyilván majd az idő fogja eldönteni, mennyire terjed el a D. Egyre több új programozási nyelv lesz és mindenkinek szinte mindenkivel meg kell küzdeni a piacért. Mainstream nyelv biztosan nem lesz a D, de sok mindenre használható, praktikus nyelv. Garbage collected, ezért rendszer programozásban nem versenyezhet a C-vel, C++-al, Rust-tal. Sok más nyelvből csipegetett (Pascal, Python, Ruby, C, C++, C#, Java, stb.), elég gazdag feature set-tel rendelkezik, de mégsem olyan horribilisen nagy , mint a C++. Én fő vetélytársának inkább a Go-t látom, ami szintén egy C-szerű nyelv és garbage collected.
Ami a Crystal-t illeti: Jópár éve létezik már, de még gyerekcipőben jár. Window-on tudtommal még nem működik, a compiler a unix-szerű op. rendszereken lassú. Szinte teljesen Ruby szintaxisa van, ami sok embernek tetszik, soknak nyilván nem. Mivel én most ismerkedem a Rubyval, úgy gondoltam érdemes egy pillantást vetni a compiler-es testvérre. Ígéretesnek tartom, itt is majd az idő dönt. Nekem hobby célra mindkettő megfelel.

A Fortrant egyrészt nosztalgiából említettem (mégis csak az volt az első magasszintű elterjedt nyelv), másrészt még most is sokan használják tudományos számításokhoz, mérnöki munkához, párhuzamos feldolgozásban, tömbkezelésben erős. És persze a modern Fortrannak már annyi új feature van, hogy John Backus rá se ismerne. :)

Nem arra gondolt. Utólag belegondolva valószínűleg jobb lenne egy Statikusan típusos programozási nyelv / Dinamikusan típusos programozási nyelv elválasztás, de így legalább rá lehet mondani a TypeScriptre, hogy az nem fordított csak transpileolt, így be lehet rakni a scriptnyelvek közé.

"jobb lenne egy Statikusan típusos programozási nyelv / Dinamikusan típusos programozási nyelv elválasztás"

Ezt mondom mar vagy 3-4 eve, csak sajnos sosem idoben :)

 

Mondjuk szerintem mindket kategoria neve ele oda kene tenni, hogy "elsosorban", es ugy a Typescript mehetne a Javascript melle, tekintve hogy ott a statikus tipusossag teljesen opcionalis (hasonloan mint ahogy Python-ban is vannak type hintek vagy mi a szosz manapsag, meg ha nem is ugyanaz a ketto)

( taurus | 2019. 12. 24., k – 08:08 )

"A compiler is a computer program that translates computer code written in one programming language (the source language) into another language (the target language). 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, object code, or machine code) to create an executable program."
https://en.wikipedia.org/wiki/Compiler

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

Működik bárkinek ez a micsoda? Bármelyik listának, bármelyik fülére kattintok, bármilyen böngészőben, nem mutatja meg az utált meg keresett listákat, hanem össze vissza ugrál az oldalon. Opera 12, PaleMoon, IceWeasel-UXP, Chromium, Midori, Otter, QupZilla; egyikben sem működött.

Oldschool Computer - http://oscomp.hu

( blalo | 2019. 12. 25., sze – 11:45 )

Ezeknél a szavazásoknál én mindig eltalálom a keki színű oszlopot. XD

( NevemTeve | 2019. 12. 26., cs – 07:21 )

A 'ratfor', bár helyesen 'nartrof' lenne, mint fordított programozási nyelv.

Off: a Groovy is jó, továbbfejlődése a Growlithe (National Pokédex #58)

( zsalab | 2019. 12. 26., cs – 11:15 )

Szerkesztve: 2019. 12. 26., cs – 11:47

Mindenfel trollkodas nelkul szeretnem megtudni hogy aki a Kotlin-ra szavazott az milyen mas nyelveket hasznal illetve mi az ami miatt kedvenc?

 

Szemelyes tapasztalat; fejlesztek mar egy ideje tobb programozasi nyelvet is hasznalok neha egyidejuleg. Egy uj projektet kezdtunk kb fel eve, felmerult a Kotlin es en lelkesen bolintottan ra mert hallottam mar tobb szep beszedet rola.

Most fel ev utan az en szemelyes velemenyem az hogy soha semmikor nem dolgoztam meg egy ekkora kalap sz.rr.l (na jo perl talan odaver neki)

- a fordito botranyosab lassu (ezt allitolag megoldjak 1.4ben), valamint kepes teljesen invalid kodot forditani (ha esetleg valaki ugy erzi hogy gyors az IDEben annak legyen itt a trukk: nem forditjak le a kodot csak az API-t)

- a kompatibilitas java-van csak alom, van jopar helyzet amikor workaroundot kell alkalmazni, eleg csunyat csak hogy az ember tudjon java libet hasznalni (talan ezen a ticketen van a legtobb szavazat de a fejlesztok annyit mondanak hogy, hat ja ezzel nem tudunk mit kezdeni)

 

- a generics egyszeruen csak hibas, teljesen... had ne menjek bele a reszletekbe itt mert hosszu lenne, majd irok rola egy blog postot ha lesz idom

 

Nagyon nagyon sok egyeb problema van meg vele amit nem sorolnek fel ido hianyaban, rovided az eye candy feature-ken kivul semmi nem mukodik vagy nem ugy ahogy igerik.

 

Eloszor azt hittuk mi vagyunk tudatlanok tomenytelen mennyisegu orat toltunk tanulasba es debugolasba es most ott tartunk hogy en szenely szerint gyulolok a projekten dolgozni es ki fogjuk dobni a Kotlint mert egyszeruen nem eri meg a kuzdelem. Amit megsporolsz az eyecandy feature-on azt tizszeresen elgeted a Kotlin problemain.

 

Kivancsi vagyok masok tapasztalatara

>had ne menjek bele a reszletekbe itt mert hosszu lenne, majd irok rola egy blog postot ha lesz idom

Engem mindenképp érdekelne. Nagy dirrel-durral lett bejelentve és hájpolva, szemeztem vele, hogy kipróbálom valamikor üresjáratban. Minden valós tapasztalat érdekel, akár a többi pontot is jobban kifejthetnéd, ha lesz kedved.

nagyon roviden a generics problema, adott ket generikus oszaly egymasba illeszthetoek azaz

Valami<Super1<Super2>> ugye van a kotlinban az out ami "hasonlo" mint a <? extends Something> viszont ha kotlinban definialsz egy tipust

Valami<out Super1<out Super2> es ennek megprobalsz pattintani egy Valami<Child1<Child2>> erteket akkor csak force cast johet szoba mikozben ugye Child1 a Super1-bol szarmazik a Child2 pedig a Super2bol... 

de ugye mar az out-al is baj van mivel nekem ex bizony van hogy "in" kellene vagyis pont leszarja a metodus hogy mi a subtype mert mac az upper boundary-val dolgozik...

 

Valahogy az sem mindig igaz hogy ha definialsz egy ilyen fuggvenyt:

<T> fun blabal(v: T)

akkor <T> <T:Any?> jelent ugyan a dokumentacio ezt mondja de valahogy neha csak <T:Any> lesz belole pedig ezt senki sem kerte

 

a kodunk tele van szarva force generics cast-l es ugye a hozza tartozo supress annotaciokkal. 

En nagy hive vagyok a genericsnek es nagyon sokat hasznalom ha a programnyelv tamogatja de a Kotline eszerintem teljesen hibas (szerintem, most eppen azon vagyunk hogy keresunk egy Kotlin szakertot - valoszinuleg direktbe a Jetbrains-tol) aki majd megvilagosit minket.... de ha megnezed a bug reportokat a nyelvvel kapcsolatban akkor latni fogod hogy nagyon sok es komoly problema van az egesszel

 

Meg egy a KAP (eg kotlin annotation processor) is egy darab szemet, csak a bajunk van vele

 

AspectJ (vagy nevezzuk AspectK-nak nem letezik) DceVM nem megy vele azaz restartolnom kell nincs rendes hotcode replacement.....

 

A hires null safety is sokszor okoz problemat de szeerintem tobb KotlinNullPointerException latok mint Javaban NPE-t, raadasul sok helyen ez az oroklest is megbolygatja foleg ha java-libeket is hasznal az ember.

 

Talan a szemelyes kedvencem amikor van egy N soros kotlink fajl es megjelenik egy szep exception az N+30 soron es talald ki hogy mi is ment felre
 

Talan a data classokat is erdemes megemliteni, a dokumentacioban ugyan jol mutat valos eletben annal kevesbe hasznalhato

 

A repetable annotacio nem letezik csak forditasi idoben szoval felejtos minden (pl java validation api es validation groups) ahol futas ideju repetable annotacio kellene

Minden tisztelettel en nagyra ertekelek sok jo otletet a Kotlinban es boldog lennek a hatekonyabba tenne minket... de sajnos nem

Én kotlinra szavaztam. A projekt javaban van írva (libGDX framework-el), a tesztek vannak kotlinnal. Anno újra lettek írva a tesztek és kotlin és groovy között vaciláltam, végül kotlin lett. Egyelőre úgy érzem, hogy nem bántam meg. Ami tetszik benne, hogy nem bőbeszédű, de még olvasható a kód (számomra legalábbis).
 

Invalid kódfordítással én nem találkoztam, de a fordítása tényleg lassabb, mint java, de annyira nem vészes.

 

Ha újra választani kéne, szerintem újra kotlin mellett döntenék.

Oszt jónapot!