HOVD 2017 - Kedvenc fájlrendszer, fordított programozási nyelv, szkriptnyelv, HTTP szerver, kommunikációs megoldás

 ( trey | 2017. november 29., szerda - 14:43 )
Mostantól 24 órán keresztül lehet módosítási kérelmeket (ez még nem a szavazás) küldeni a címben említett kategóriák jelöltjeire, amelyek a következők:
Kedvenc fájlrendszer:

  • btrfs
  • ext2, ext3, ext4
  • f2fs
  • hfs, hfs+
  • jfs, jfs2
  • ntfs
  • reiserfs, reiser4
  • ufs, ufs2
  • xfs
  • zfs

Kedvenc fordított programozási nyelv:

  • assembly (bármely architektúra, bármely dialektus)
  • c
  • c#
  • c++
  • go
  • haskell, ocaml, f# (statikusan tipusos funkcionalis nyelvek)
  • java
  • objective-c, swift
  • pascal
  • scala

Kedvenc szkriptnyelv:

  • javascript
  • lua
  • *nix shell (bash, csh stb.)
  • perl
  • php
  • powershell
  • python
  • r
  • ruby
  • typescript, coffeescript (javascript jellegu nyelvek)

Kedvenc HTTP szerver:

  • apache
  • beépített http szerverek (simplehttpserver, webrick stb.)
  • h2o
  • hiawatha
  • java servlet container-ek (pl.: tomcat, jetty, ...)
  • lighttpd
  • litespeed
  • microsoft iis
  • nginx
  • thttpd

Kedvenc kommunikációs megoldás:

  • facebook messenger
  • facetime, imessage
  • google hangouts
  • irc
  • signal (vagy egyéb opensource, titkosított megoldások)
  • skype
  • slack
  • szabvány jabber / xmpp
  • viber
  • whatsapp

A módosítási kérésekre ugyanazok a szabályok vonatkoznak, mint a kategória szavazásra!

Példa:

Ha a go helyett izébigyó-t szeretnél, akkor:

- go
+ izébigyó

Ha a viber helyett foobar-t, akkor:

- viber
+ foobar

és így tovább.

Ahol "?" van, ott értelemszerűen lehet javasolni jelöltet az üres helyre.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"kedvenc fájlrendszer" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

+APFS
- nem tudom

-f2fs
+apfs

Mar tavaly is utolso volt es amugy is

"kedvenc fordított programozási nyelv" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

- scala
+ kotlin

Indoklás: tavaly a scala kapta a legkevesebb szavazatot, s JVM-es nyelvet cserélnénk így JVM-es nyelvre. A Kotlin idén jelent meg (stabilan), mostmár lehet JVM/JS/natív fordítani, amennyit én látok belőle, egyre inkább növekszik a népszerűsége.

(Nekem nincs kifogásom a váltás ellen, elvégre ez csak egy szavazás. :) )
Mi tetszik az embereknek a Kotlinon? (Viszonylag tapasztalt, Java-t/Scala-t ismerő vagyok, de a nyáron amikor IDEA kódot kellett olvasnom, eléggé kínszenvedés volt, persze könnyen lehet, hogy csak öregszem, vagy csak rossz stílusú kódot néztem.) Feltételezem a Ceylon az Eclipse kötelékében lassan elhal majd, megértem, hogy nem arra cserét ajánlasz.

  • Ami valószínűleg előkerül majd a felsorolásnál, az az improved null-safety lesz. Erre ha nem gond előre reagálok: iszonyú zavaró, inkább úgy tűnik, hogy a null-problémát kezelni próbálja, nem pedig megszüntetni. (Igen, nem vagyok Groovy-rajongó.)
  • az it néha tényleg olvashatóbb mint az _ (bár néhány helyen a Java is aláhúzást használ majd)
  • reified generics: ez érdekes lehet, use case-eket szívesen megismerek
  • a spéci return-ök nem könnyítik meg szerintem az olvasást
  • a coroutine szerintem egy jó érv mellette, van aki használja, esetleg másként gondolja?

1. az improved null-safety.
Megszünteni nem tudod szerintem ezt a problémát már sosem, hacsak nem törsz Java kompatibilitást visszafelé, de azt errefelé nem szokás. Ergo a cél a lehető legjobb kezelés lehet.
Esetleg hosszútávon becsoroghat a JVM-be egy ilyen improved null safety megoldás (a VM típusrendszerébe rakni ezt), de nem ez tűnik most az iránynak.

Az Optional lehetne hosszútávon erre egy jó kerülőút, a Project Valhallával egyetemben, de:
- se abban nem vagyok biztos, hogy a végén tényleg value type lesz az Optional, bármennyire is hangoztatják most (hány emberhez nem jut el, hány kód törik ketté)
- se a paraméterként kapott null-t, fieldben tárolt null-t, non-null problémát nem oldja meg (nem arra van szánva), nem ad rá kényelmes kezelhetőséget.

2. java-interop
A Scala tökjó nyelv, de azért a Javahoz képest nagy ugrás, több szempontból is.
- mindenből kitalálják a saját megoldásukat
- eléggé látszik rajta, hogy egy akadémiai projekt (mindent _is_ rakjunk bele)
Nekem nem sikerült a cégnél a Scala-t átverni (bár mikor jöttem ide, a Scala már nem volt új), míg a Kotlint igen. A Kotlinnal a megszokott keretek között (Spring/EE, Maven/Gradle, etc.) dolgozhatok, könnyen mappelhető minden Stackoverflows megoldás Javara, etc.

3. Android
Ez engem kevésbé érint, de a Makery-ben (ők szervezik a hazai Kotlinos gárdát nagyrészt) mondták, hogy a Scala-t egy halál volt anno Androidra reszelni. (Azóta mintha meg nem is tudnád, a JDK8-as kód miatt).

neked reagálva:
- reified generics: annyira azért nem reified, minden csak az inlineolt dolgoknál megy. Részben menő, egészen cool DSL-t lehet vele összebarkácsolni, meg hasonlók - de hoszzútávon azért ennek is megvannak a buktatói.
- spéci returnök: ebben teljes mértékben egyetértünk, de Scala-ban nem mégtöbb van ebből? (kérdés, annyit azért nem Scalaztam)

Köszi a részletes választ.

Spéci returnök: Scala-ban is vannak, részben nyelvi szinten (return), részben library (breakable,continue,break), de kevésbé díszesek (nincsenek labelök) és nagyon nem ajánlott a használatuk.

Android - Scalaval nem használtam, de 2.11.12-ig támogatott a JDK6 és van egy Scala on Android projekt. Elvileg az Android már szintén 8-as JDK-t használ, szóval a 2.12-es Scalaval sem kellene, hogy gond legyen.

Kíváncsi vagyok mikor kezditek el használni majd a Kategory libet. Ott kell egy picit igazítani a nyelven (@higherkind).

1 és 2 pontoddal egyetértek, bár nálunk egész jól elboldogulunk a Scalaval is (használunk Java libeket is természetesen), csak nem érzem jó megoldásnak a kotlini utat (az IDEA kódban inkább embrace nullness volt a jellemző az explicitebb Optional helyett; Scala esetén a tooling valóban van hová fejlődjön).

Azért nem ajánlott a használatuk, mert ezek mind mellékhatással járnak. Ráadásul a return megváltoztatja a program működését.

A Scala-s Option-ben az a pláne, hogy ugyanúgy tudod használni mint bármilyen collectiont. Btw. bár elvileg lehetséges, gyakorlatilag évek óta nem találkoztam null értékekkel Scalaban, Scalas libraryk tipikusan soha nem adnak vissza nullt, hacsak explicit erre nem adsz utasítást (pl. Option.orNull). Szerintem ez sokkal előremutatóbb, mint engedni a null értéket, majd minden használati helyen körbebástyázni (még akkor is, ha Kotlinban ez jóval egyszerűbb).

Ezzel egyetértek, de a Scala Option helyett a Java8-as Optional is vállalható lenne a Kotlin esetében. Mindenesetre nálunk azért viszonylag ritkán (amit látok ~havonta 1-szer) fordul elő NullPointerException (többnyire traitbeli valok miatt) és azok is viszonylag könnyen javíthatók.

(Ha az Optional (funkcionális) használata elterjedtebb lett volna a Kotlin kódban, valószínű sokkal kevesebb early return-t kellett volna kibogoznom. Szerintem ez valószínű egy pragmatikusnak gondolt választás volt a fejlesztők részéről, engem azonban eltántorított. Természetesen egy fejletlenebb null-támogatás meg van Scalaban is, azonban ott a kulturális szokások miatt csak az interopnál használjuk. Ha jól sejtem ez is lehetett az egyik oka a Scala elvetésének a Kotlinéval szemben.)

> Ezzel egyetértek, de a Scala Option helyett a Java8-as Optional is vállalható lenne a Kotlin esetében.

Szerintem azért nem, mert:

- a javas Optional __lehet__ null.
Igen, nem szokás, nem illik, code quality, fordítás utáni dolgok. Ezzel az a bajom, hogyha egyszer beemeled a nyelvbe, mint elvi lehetőség, az egy olyan technical debt, amit sosem tudsz majd levetkőzni. Most is megvan a Kotlinban, részben, a platform typeok mentén ez. A tooling/nem szokással meg az a bajom, hogy a C/C++ vonalon is megvan ez a tooling/best practices egy ideje, mégsem C/C++-ban írunk ilyeneket, mert könnyű lábonlőni magad.

- a javas Optional nem ajánlott:
* fieldként
* paraméterként
Hogyan jelölöd, ha egy paraméter opcionálisan megadható a függvényhívásban?

"- a javas Optional nem ajánlott:
* fieldként
* paraméterként"

Mert erre aztán a null tényleg sokkal jobb! ;)

"Hogyan jelölöd, ha egy paraméter opcionálisan megadható a függvényhívásban?"

Default paraméterrel, overloadinggal, vagy mondjuk így.

> Default paraméterrel, overloadinggal,
ez nem oldja meg azt, hogyha én segg vagyok, és nem olvasom el a doksit/a libfejlesztő segg, s nem ír doksit.

Megjegyzés: Scala-ban sem túl gyakran látok Option[A with NotNull] with NotNull kifejezést (mivel deprecated, így nem csodálom; igen, Option[A] lehet null, Some(null) is), mégis szinte sosem ellenőrzök nullságot.

Semmi gondot nem látok az Optional használatával fieldként, vagy paraméterként (bár kétségtelen, hogy ahol dolgozok már a null, var, return keyword-ök használatát nagyon-nagyon nehezen fogadnák el/meg kell indokolni egy-egy code review alkalmával, szóval valószínű nem feltétlen reprezentatív a tapasztalatom).

Ami nagyon hiányzik a Kotlinből azok a persistent adatszerkezetek.
Bár 0.1-es verziószámmal valami nagyon gyenge próbálkozás elindult, de másodlagos szerepet szánnának eleve neki.

+1, én is pont ezt akartam javasolni

+1
A Kotlin-ra én is kíváncsi lennék.
---------------------------
Oszt jónapot!

-1

Én a Scala kivétele helyett inkább átraknám a Haskell-es csoportba. Lásd lentebb.

+ Rust

-go
+rust

Indoklás: hasonló problémák megoldását célozzák, de az utóbbi többet nyújt és sokan a nem-kezdőbarátabb* nyelvet tartja kedvesebbnek. (Igazi tapasztalatom egyikkel sincs, de mindkettőről olvastam 1-1 könyvet. Túl sok limitációt érzek a go esetében amit a gorutinok nem kompenzálnak szerintem eléggé. Inkább átmeneti nyelvnek tekinteném, míg a rust egész átgondoltnak tűnik.)

*: nem tudom mi a helyes írásmódja az új szabályok szerint.

Azért a Go-t elég sokan használják jelenleg. Szerintem ha valamit ki akarunk dobatni a Rust miatt akkor a Pascal legyen az, teljesen irreleváns nyelv így 2017-ben.

(A kérdés nem a használatról szól, hanem a kedvencségről.) Szerintem viszonylag sok olvasónak a Pascal kedvenc, ha más nem, nosztalgia miatt. De nyugodtan módosítsd a fentebbi hozzászólásod, hogy ne csak +Rust legyen, hanem
-pascal
+Rust

Én nem vagyok ilyen bátor. ;) Nem hiszem, hogy azok közül akiknek használnia kell a go-t olyan soknak kedvence is az lenne, de persze simán tévedhetek.

Szerintem Pascalt leginkább az olyanok favorizálják, akik nem igazán ismernek más nyelveket, pl. akik tanulmányaik után nem sokat programoztak, mert inkább az üzemeltetői vonalra sodorta őket az élet. Amivel persze semmi baj sincs, csak kérdéses, hogy mennyire releváns az ő "véleményük" a témában.

Persze, tudom, eleve ne keressek mélyebb konklúziókat a HOVD szavazás eredményeiben, de azért akkor is. :)

Én nem vagyok ilyen bátor. ;)

Én sem, de carlcolt barátunk volt, és bár valaha nekem is volt a kedvencem a Pascal, de valóban eljárt felette az idő, így arra már volt bátorságom, hogy azt a szavazást meg +1-ezzem. ;-)

+1 a Rustra. Go-hoz nem volt szerencsém, de amennyi rálátásom van, nincs akkora momentuma a közösségnek.

Rust fejlődését (ha csak fél szemmel is) kb. a 0.4 verzió óta követem, hobbi projektekhez használtam/használom is. Még mindig van 1-2 dolog ami néha rettentően hiányzik (impl trait pl.), de már most is bőven használható komolyabb dolgokra, lásd FF Quantum CSS motorja. A fejlesztők masszívan gyúrják, max 1-2 év és eltűnnek ezek a hiányosságok is.

A közösség nyüzsgése, a szépen növekedő ökoszisztéma pedig bámulatos, számomra nem kérdés, hogy ez idővel bőven túlnövi magát az egzotikus hobbinyelv státuszon, felnő a C/C++ mellé.

-pascal
+rust

Inkabb a pascal-t dobjuk ki, mint a Go-t. (Igen b+ odatettem ket nyelvtanilag helytelen kotojelet, es? ;) )

-1
A Pascal tavaly ötödik lett. Szerintem vannak még sokan, akik használják és szeretik. Igen, én is.

-1

-1

én szeretem a pascalt, és használom is, sőt még a VBA-t is :D

+1

+1

- scala
+ kotlin
- haskell, ocaml, f# (statikusan tipusos funkcionalis nyelvek)
+ haskell, ocaml, f#, scala (statikusan tipusos funkcionalis nyelvek)

Indoklás: én is szívesen megnézném a Kotlint, de a Scala-t sem dobnám ki teljesen. Ha a Haskell-esek nem tartják rangon alulinak, akkor szerintem abban a csoportban megférne. (A Haskell-en kívül a többi sem pure FP)

(Azért is lenne jó ez a csoport, mert kb. ez a 4 legkedvencebb nyelvem ;-)

+1

+1

Nekem a scala is FP :)

+1

+1 (esetleg a Kotlin mellé beférhet még a Ceylon is)

"kedvenc szkriptnyelv" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

"kedvenc HTTP szerver" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

"kedvenc kommunikációs megoldás" módosításokat ebbe a szálba (a válasz linkre kattintva). Egy válasz egy javaslatot tartalmazzon!

Ebből a szálból a kiírásnak meg nem felelő javaslatok és egyéb hozzászólások törlésre kerülnek!

--
trey @ gépház

+ Telegram
--
:wq

+Telegram

+Telegram

És nem is csak privát üzenetküldésre jó, utóbbi időben azt vettem észre, hogy csomó közösségi projekt Telegram groupot használ inkább IRC csati helyett, főleg a frissen indulók (pl. blockchain vonalon elég elterjedt).

^-- Edes Istenem! olvassatok mar el a szabalyokat, hogy hogy kell javasolni. Mindharom ervenytelen javaslat jelenleg.

Vagy megszoktatok hogy a Telegramban nem kell uzenetet torolni, mert torlodik a beallitott timeouttal, igy majd itt se kell minuszolni? ;)

Igazad van.

+Telegram
-szabvány jabber / xmpp

Előbbit írtam miért, utóbbival rég találkoztam.

+1

Erre mar +1

Jabber / Xmpp-t raadasul a rossz skalazodasa miatt dobta az osszes multi (Facebook, Google, etc.)

Raadasul a Singal vagy egyeb open source-ba ha nagyon akarom beleeroltethetem fejben :)

Most már csak rossz helyen van ez a bejegyzés, így is érvénytelen.

+ Telegram
- facetime, imessage

Valamilyen szinten mindegyikkel találkoztam, kivéve a mínuszos jelöltet, ezért került be ez, csak hogy érvényes legyen a változtatási javaslat.

Telegram: kb. három éve használom napi szinten, Androidon is meg asztali gépen (XP) alapvetően csak chatre, teljesen korrekt, szeretem. A hanghívást egyszer próbáltam miután elindították, működött (nincs rá szükség, akikkel használnám, azokat egyszerűbb telefon hívni). Lehet, hogy a Signal mellé passzolna? Bár kíváncsi volnék, önállóan indulva hányan választják.

Erre viszont -1

Factime/iMessage -et hasznalom a legtobbszor (azert nem lattad, mert csak Apple es Apple kozt mukodik)

(Keresem meghallgattatott, koszonom Trey :) )

+1

Jövőre javasolni kell:
Kedvenc programozási nyelv (fordított)
Kedvenc programozási nyelv (szkript)
És akkor még a fengshui se romlik el :)

Persze amire figyelni kell, hogy ne épp a kettő között legyen az ötös csoportok határa :)

Vagy lehetne "Kedvenc vleyn isázomargorp" inkább.

De akkor ABC-sorrendben nem egymás után lesznek (fengshui).

Kellögem.

--
GPLv3-as hozzászólás.

nemide, elnézést