- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Az opciók a legutóbbi HOVD-ról vannak.
- A hozzászóláshoz be kell jelentkezni
ez egy jó kérdés.
a c++-hoz sose értettem, indokolatlanul bonyolultnak tartom, de ez nyilván nem a nyelv hibája.
esélyes volt a perl az érthetetlensége miatt, de ez se a nyelv hibája.
végül a python nyert a szigorú kódolási megkötések (pl. behúzások) miatt. függetlenül attól, hogy bármire használható a nyelv.
- A hozzászóláshoz be kell jelentkezni
+1 a Python-ra (mar azok kozul amit ismerek)
Ez a behuzasos dolog nagyon bosszanto tud lenni, kulonosen amikor kap az ember egy kodot, amit valaki tab-okkal kezdett el, majd valaki mas space-ekkel folytatta...
/sza2
Szerk.: Meg a csak egysoros kommentezes. Vagy van tobbsoros is, csak nem tudok rola?
- A hozzászóláshoz be kell jelentkezni
Python többsoros komment:
#
#
#
#
:D
''' vagy erre
a fajta
kommentre
gondoltál?
'''
- A hozzászóláshoz be kell jelentkezni
Azt hittem ez csak docstring.
Sajnos ez viszont pl. nem mukodik vele:
#!/usr/bin/python
class Test:
def test1(self):
print "test1"
'''
def test2(self):
print 1
'''
def test3(self):
print "test3"
t = Test()
t.test1()
t.test3()
/sza2
- A hozzászóláshoz be kell jelentkezni
Végeredményben az. :)
De hogyhogy nem működik ezzel?
Lezárja az osztályt idő előtt? Vagy mi a gond vele?
Amivel kipróbáltam, azzal működött.
- A hozzászóláshoz be kell jelentkezni
Nekem ezt mondja az interpreter:
File "mlc.py", line 10
def test3(self):
^
IndentationError: unexpected indent
/sza2
- A hozzászóláshoz be kell jelentkezni
Jé... valóban.
(mondjuk csak poénnak szántam a '''-t, de eddig nem tűnt fel, hogy bármi, amit odaírok a nyitó és a záró aposztrófok közé, zavarná az interpretert)
- A hozzászóláshoz be kell jelentkezni
Tab-space sok más nyelvre is igaz. Sajnos. De normális editorok ezt lekezelik, tudnak a kettő között konvertálni.
"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."
- A hozzászóláshoz be kell jelentkezni
De mi koze ennek az editorhoz?
A Python ertelmezo a kerdes. A tobbi, nem indentalas alapjan stukturalo nyelvnel maximum csunya a kod, de a Python eseten nem azt fogja csinalni amit szerettel volna, mindossze azert, mert az egyik sorban 4 space van, a masikban meg egy tab.
Ha Python-t editalok, _mindig_ be van kapcsolva, hogy latszodjanak a whitespace karakterek, ez valamekkora segitseg.
/sza2
- A hozzászóláshoz be kell jelentkezni
Valahogy csak beírod azt a fránya kódot, nem? Itt érdekes az editor tudása.
"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."
- A hozzászóláshoz be kell jelentkezni
Persze, egy editor sokat tud segiteni, de ha eleve van egy kodod, amit tobben irtak, tobb kulonbozo editorban, mondjuk vannak tab-ok, space-ek vegyesen (mert sajnos kellet ma ilyet tovabbvinnem), akkor a tab/space konvertalo sokesetben tobb kart csinal mint hasznot, lehet, hogy az egesz kodot at kell nezned, megertened, mert nem tudod automatikusan konvertalni.
/sza2
- A hozzászóláshoz be kell jelentkezni
Csak egy kérdés, ez a kód eddig hogyan futott? Ha futott, akkor tudod a tab értékeket és át tudod konvertálni a forrásokat. Vagy ez csak leírva ilyen egyszerű? Őszinte leszek, ilyen kódot még nem láttam, nem tudom ilyen esetben két tab egyenlő két szóközzel?
"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."
- A hozzászóláshoz be kell jelentkezni
"nem tudom ilyen esetben két tab egyenlő két szóközzel"
Na ez az, arra sincs garancia, hogy ugyanolyan tab size-zal dolgoztok. Általában a 4 space az elfogadott, de ez nincs kőbe vésve. Olyan nyelveknél, ahol a szintaxisnak nem része a space, ott ez nem probléma, legfeljebb ha valami nem sor elején lett tabokkal egymás alá igazítva (de olyat meg miért tennél).
- A hozzászóláshoz be kell jelentkezni
Nem csípődött be, de ismét csak visszatérek az editorra. Van amibe bele tudod írni mekkora tabot használsz a forrásban, írsz scriptet alá, hogy jelezze ha tab van a forrásban, stb. Persze tudom, ha más nem használja, akkor ő szétcsesz(het)i. De legalább az editorod tud erre "figyelmeztetni".
"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."
- A hozzászóláshoz be kell jelentkezni
"de ha eleve van egy kodod, amit tobben irtak, tobb kulonbozo editorban, mondjuk vannak tab-ok, space-ek vegyesen"
Normális esetben nincs lespecifikálva a coding standard legalább egy projektszinten, hogy azt kövesse mindenki? Oké, hogy a python megköveteli a korrekt behúzásokat, de ahol nincs megkövetelve ott is elég zavaró tud lenni, ha vegyesen vannak.
- A hozzászóláshoz be kell jelentkezni
zavaro != mukodeskeptelen
- A hozzászóláshoz be kell jelentkezni
Le van speckózva, és komolyabb prozsék esetében van megfelelő forráskód-formázó tool, ami az esetleges trehányságokat helyreteszi, mielőtt a verziókezelőbe belezuttyanna a forráskód.
- A hozzászóláshoz be kell jelentkezni
+1
Nekem a Visual Studio már C# és SQL kódnál is elkezd vinnyogni, ha keverném a space-eket a tabokkal, vagy fordítva, pedig ott semmi jelentőségi nincs kódszinten. Azt már nem tudom, hogy ez alap feature, vagy plugin, mert extensionből elég sok van telepítve.
- A hozzászóláshoz be kell jelentkezni
Pythonban nem kell többsoros komment, a kód maga a komment! :D
- A hozzászóláshoz be kell jelentkezni
Ha követjük Robert C. Martint, akkor :D nélkül is igaz az állítás második része és nem csak pythonban.
Viszont a több soros komment, amint azt a korábbi példa is mutatja, arra is jó eszköz lenne, hogy ideiglenesen kiiktass kódrészleteket. Erre úgy tűnik, valóban nincs megoldás pythonban.
- A hozzászóláshoz be kell jelentkezni
Nincs, max. ki egysorozod :D
Armin Ronachernél is így néz ki egy többsoros komment.
- A hozzászóláshoz be kell jelentkezni
Miért kell kikommentezned sorokat a kódban? Töröld ki, ha nem kell. Aztán ha mégis kell, akkor a verziókezelőből előszeded. Egy normális IDE egyébként ki tud kommentezni akármennyi sort.
- A hozzászóláshoz be kell jelentkezni
"Erre úgy tűnik, valóban nincs megoldás pythonban."
Nem is kell, mert egyszerűen kijelölöd a blokkot, és szólsz az editorodnak, hogy kommentezze ki. Aztán meg vissza, ha kell. Azért ez nem űrtechnika. Jobb is, mint mondjuk a /* */, mert a kikommentezett blokkból akár egy kisebb részt is vissza tudsz engedni egyetlen gombnyomással (mivel soronként van jelölve).
- A hozzászóláshoz be kell jelentkezni
Tehát kell hozzá olyan editor, ami ezt tudja. Meg mást is.
- A hozzászóláshoz be kell jelentkezni
azert ez nem olyan nagy elvaras szerintem, ha egy editor nem kepes X darab egymas feletti sor ele beszurni a #-t vagy onnan kitorolni, akkor azt nem nagyon kene eroltetni :)
- A hozzászóláshoz be kell jelentkezni
Azaz megszámolom, hány sor, majd .,+Xs/^/# Rendben :-P
- A hozzászóláshoz be kell jelentkezni
VIM visual mód, számolni sem kell. :)
:'<,'>s!^!#!
- A hozzászóláshoz be kell jelentkezni
ti most komolyan azzal szorakoztok hogy a leheto legbonyolultabb megoldasokat keresitek? :D
(en Perlnel vagy shell scriptnel csak a sor elejere megyek, CTRL-V-vel le/felmegyek addig, ameddig a kommentet akarom, aztan SHIFT+I es # majd ESC es kesz :) )
- A hozzászóláshoz be kell jelentkezni
A SHIFT+I nekem nem jó, mert így végig kell szántanom azokat a sorokat, amit ki szeretnék kommentezni. :D
Szerk.
Nem sikerül így globálisan beszúrni a # jelet, tehát hogy csak egyszer keljen a # leütni.
Szerk.Szerk
Sikerült, az ESC-nél toltam el, pedig automatikusan duplán ütöm le, ha kell ha nem. Köszi! :)
- A hozzászóláshoz be kell jelentkezni
kevesbe gyoker editorban (emacs): ALT-;
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
es ez a "kevesbe gyoker editor" magatol kitalalja helyetted, hogy pontosan melyik sorokat akarod ki- illetve visszakommentelni?
- A hozzászóláshoz be kell jelentkezni
Nem mindegy? Aki tudja, már nem használja, mert túllépett rajta, aki nem tudja, az meg azért nem használja azt az editort...
- - - - - - -
A nagy tudású uraknak felhívnám a figyelmét arra, hogy a Windows ugyan sok mindenre nagyon jó, de Linuxnak speciel nagyon szar.
"http://hup.hu/node/111669#comment-1419622">csfeco
- A hozzászóláshoz be kell jelentkezni
Ehhez legalább tudsz neked kedvesen működő funkciót írni (elisp-ben) vagy más okosságát használni - ha az alap nem felel meg. :)
- A hozzászóláshoz be kell jelentkezni
ez sok mas szovegszerkesztore is igaz (pl. a szalban alapvetoen emlitett Vim-re is), de tenyleg nem ertem hogy ez most hogy jon ide...
- A hozzászóláshoz be kell jelentkezni
És írtak már normális szövegszerkesztőt az Emacs-hez, vagy arra még várni kell? :-D
- A hozzászóláshoz be kell jelentkezni
hat, ha mindenaron szopatni akarod magad, azt is lehet :D
- A hozzászóláshoz be kell jelentkezni
Jaj, de hát számítógép is kell a szoftverfejlesztéshez!
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Az identalason kivul milyen "szigoru kodolasi megkotesek" vannak?
Amugy en epp szeretem ezt, egyreszt nem kell zarojelezni (pontosabban zarojeleket vagy statemnteket lezarni), masreszt meg az identalast amugy is hasznaljuk, akkor miert ne hasznalja ki a nyelv is?
Igen, persze a masokkal valo egyuttmukodes problemas lehet, de ebben a szovegszerkeszto sokat segithet. Meg esetleg a kozos kodolasi szabalyok (amik amugy is hasznosak).
- A hozzászóláshoz be kell jelentkezni
Utolsó mondatra: http://legacy.python.org/dev/peps/pep-0008/
Ezt kell betartani és nincs több probléma. ;)
(egyébként nálam a Python inkább a kedvenc, mivel nem vagyok fejlesztő már nagyon rég)
- A hozzászóláshoz be kell jelentkezni
Azert az is tud szop@st generalni, amikor veletlenul kitorolsz egy-ket space-t (raadasul egy mas altal irt programban), es kesobb azt veszed eszre, hogy nem emlekszel, hogy az adott utasitast a program iroja egy cikluson belulre, vagy kivulre akarta tenni...
Tobb emberrel beszeltem mar akinek kellett Python-ban kodolni, de egyontetu velemeny volt, hogy az indentalassal valo strukturalas egy oriasi hatrany.
En C-ben is eleg kovetkezetesen betartom az indentalasi "szabalyokat", de egy ossze-vissza behuzott C programot is kivaloan meg tud szepiteni az autoformatter - ellenben Python eseten ez ugye ertelmezhetetlen.
Raadasul ha egy kodreszletet egy szinttel fentebb / lentebb akarsz tenni, az Python-ban mindenfelekeppen bonyolultabb, hiszen minden sort manualisan kell atrendezned.
/sza2
- A hozzászóláshoz be kell jelentkezni
"Raadasul ha egy kodreszletet egy szinttel fentebb / lentebb akarsz tenni, az Python-ban mindenfelekeppen bonyolultabb, hiszen minden sort manualisan kell atrendezned."
Nem használok Python-t, de ezt nem oldja meg a sok szerkesztőben meglévő kijelölöm, majd Tab (ill. Shift+Tab)?
- A hozzászóláshoz be kell jelentkezni
Ide, es artifex-nek is:
Arra gondolok, hogy pl. egy for ciklusnal, ha eggyel kulsobb szintre szeretnel tenni egy masik ciklust, inteligens editorok (tegyuk fel C, C++, akarmi eseten), kepesek atrendezni a kodot, hogy jo legyen az indentalas. Ugyanez Python-nal a zarojelezes hianya miatt nem oldhato meg, hiszen az autoformatter nem tudja, hogy az egyik ciklus a masikon belulre kerult. Egyebkent a normal auto indentalast sem lehet az editorra bizni, mert nem tudja, hogy a kozetkezo sort melyik szintre szeretned.
Eleg sok ram maradt Python kodot kell karbantartanom, es en ezt az behuzasos strukturalas az egyik rakfenejenek tartom, megha szamos mas elonye van is.
/sza2
- A hozzászóláshoz be kell jelentkezni
A cikluson belüli részt beljebb tolod és utána írod be az új ciklust?
De értem a dolgot, blokk eleje és vége jelzés nélkül nehezebb a forrás későbbi feldolgozása.
"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."
- A hozzászóláshoz be kell jelentkezni
"Ugyanez Python-nal a zarojelezes hianya miatt nem oldhato meg"
Én intellij idea-t használok, szépen megcsinálja.
- A hozzászóláshoz be kell jelentkezni
Én meg - ha nagyon szépre akarom pintyőzni a kódot, akkor perltigy vagy más hasonló motyót veszek elő, de általában nem sokat szokott módosítani a formázáson, mert eredendően szépen dolgozni kötelező identálás nélkül is lehet :-P
- A hozzászóláshoz be kell jelentkezni
Feltételezem arra gondolt, hogy míg a
if (a) {
p1
if (b) {
p2
}
p3
}
kódot szépen tudod identálni később, addig a
if a:
p1
if b:
p2
p3
gyakorlatilag megoldhatatlan python alatt, hiszen nem derül ki a p3 kihez tartozik.
Másrészről, az bizonyos lustaság (nem fikázás, én is csinálok ilyet, ha a nyelv megengedi), hogy nem a helyére teszed a kódot, hanem majd az autoformatter rendberakja utána.
"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."
- A hozzászóláshoz be kell jelentkezni
Pythonban ezért kell gondosan indentálni, nem mintha máshol nem kéne figyelni. :)
Én az osztályokat 2 üres sorral választom el, belül meg 1 üres sorral választok el mindent, még egy magányos változót is. Szellősen dolgozom, de legalább szemre egyből látszik, hogy ki/mi hova tartozik.
- A hozzászóláshoz be kell jelentkezni
Az identálást akkor is lehet jól csinálni, ha az elrontásától a programod hibásan működne. Egy blokkot _csak_ az identálás különböztet meg a rajta kívüli kódtól. Elég egy sornak elrontani a behúzását, és máris nem azt csinálja a kód, amit szeretnél.
Blokkhatárolókat használó nyelvekben ez két sor felcserélését jelenti, ami azért messziről látszik.
- A hozzászóláshoz be kell jelentkezni
Ez jogos, de ettől még számomra szimpatikus az alapötlet. Túl sok p.szőr hófúváskor kódot láttam már ahhoz, hogy a szép kódot értékelni tudjam. De jogos amit írsz, ha elcsúszik valami, akkor szopás.
"egy ossze-vissza behuzott C programot", lehet az a cél ilyen ne legyen.
A szintlépés problémát nem értem, megint editor kérdése, hogyan tudod a szintlépést megoldani.
"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."
- A hozzászóláshoz be kell jelentkezni
> "egy ossze-vissza behuzott C programot", lehet az a cél ilyen ne legyen.
Igen, a cel egyertelmuen ez, csak nem biztos, hogy sikerult a kerdesre a legjobb valaszt talalni.
Egyebkent a Python 3-nal azt hiszem csak space elfogadott az indentalasra, ami kicsit egyertelmubbe teszi a helyzetet (bar azon nem valtoztat, hogy pikk-pakk keresztbe lehet f0sni a kodot, ha veletlenul torol az ember par space-t, raadasul szintaktikailag helyes is marad, szoval ki tudja, mikor veszed eszre...)
/sza2
- A hozzászóláshoz be kell jelentkezni
Azért az értelmező elég jól kiírja hol az indent hiba. Tehát fel van erre készítve a python. Meg jó editor kell és kész.
- A hozzászóláshoz be kell jelentkezni
"Azert az is tud szop@st generalni, amikor veletlenul kitorolsz egy-ket space-t..."
Az egy viszonylag altalanos tulajdonsaga a programnyelveknek, hogy ha veletlenul kitorolsz egy-ket karaktert, akkor bazira mast fog csinalni mint addig.
- A hozzászóláshoz be kell jelentkezni
egy-ket space != egy-ket karakter
Azert keves olyan nyelv van, amiben ha whitespace-eket torolsz, akkor mast fog csinalni mint addig (termeszetesen nem arra gondolok, hogy int a; -> inta;).
De lehet, hogy en latom rosszul, esetleg mondhatnal meg par nyelvet ahol ez igy van.
/sza2
- A hozzászóláshoz be kell jelentkezni
Szerintem ebben a nyelvben például okozhat problémákat... :D
- A hozzászóláshoz be kell jelentkezni
Ha nem 2003-ban lett volna kiadva, meg azt hinnem toluk szarmazik a Python alapotlete:-)
/sza2
- A hozzászóláshoz be kell jelentkezni
Make
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Bizonyara azon is el lehetne filozofalni, hogy a make programozasi nyelv-e.
/sza2
- A hozzászóláshoz be kell jelentkezni
vegul is, egy erosen specializalt scriptnyelvnek tekintheto (bar en azert nem mernem programozasi nyelvnek hivni)
- A hozzászóláshoz be kell jelentkezni
igen, mert DSL
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Biztos ez is hozzaallas kerdese, de nekem a nyelv != programozasi nyelv.
Ennyi erovel akkor a HTML, PostScript, etc is ide tartozik, de szerintem nem (legalabbis ugy erzem ez a topic nem errol szol).
/sza2
- A hozzászóláshoz be kell jelentkezni
Imho amiben lehet írni http szervert, az programozási nyelv. ;)
- A hozzászóláshoz be kell jelentkezni
a socket kommunikációt nem is a PS végzi :(
~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack
- A hozzászóláshoz be kell jelentkezni
Irtam is gyorsan bash-ben egy http szervert:
#!/bin/bash
/etc/init.d/apache2 start
:-)
/sza2
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ok, akkor most ugyanezt make-ben. Koszi :-)
/sza2
- A hozzászóláshoz be kell jelentkezni
Nyilvan van kulonbseg az egy-ket karakter es az egy-ket space kozott, de azt is belathatod, hogy hasonlosag is van. Miutan veletlen torlesrol beszelunk igy kb mindegy.
Amugy shell-ben sem mindig mindegy hogy van-e space vagy sem, de az kicsit furmanyosabb (es sokkal inkabb bosszanto szerintem). Pl:
if [ $a = 3 ]
if [$a=3]
De asszem mindegy is, ez a python identalason lovaglas is hitvita, es ha meg nem derult volna ki: nekem semmi bajom vele, en birom a pythont. :)
- A hozzászóláshoz be kell jelentkezni
Igen, a "test" írható úgy is, hogy " [ " :-P
- A hozzászóláshoz be kell jelentkezni
Nem erzem hitvitanak, engem a gyakorlatban zavart / zavar. Van, amit en is Pythonban irok meg, mert epp az a legjobb ra, de engem mar bosszantott par tulajdonsaga.
Szerintem az Eclipse pl. eleg ugyesen tud banni a tab-okkal, space-ekkel, indentacioval, de volt mar hogy a sor elejen egy veletlenul nyomott tab miatt a program mast csinalt mint amit kellett volna.
Megprobalhatod megmagyarazni, hogy nem igy van, de azert mondjuk egy szintaktikai hibat elobb eszre vesz az ember mint egy whitespace elirast.
/sza2
- A hozzászóláshoz be kell jelentkezni
Én is szeretem a pythont, sőt szerintem első nyelvnek is kiválló, pontosan a behúzásos móka miatt, ami struktúrált gondolkozásra tanít. Ettől függetlenül jártam úgy, hogy egy egy hobby projektet az egyik IDE-ben elkezdtem, majd egy idő mulva elővettem a projektet egy másik IDE-ben, elvégeztem az eglsz refaktorálást, amit kigondoltam, és 1-2 óra fejlesztés után volt a kopp, amikor indítani akartam, hogy bizony szemre jók a blokkok, csak épp nem fut az egész. Persze "csak" 1-2 óra munkát kellett átnyálazni/rendbeszedni, de mondhatni pain in the @ss volt.
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
Egysorosokat nem igazán tudsz benne csinálni, "szépen" formázni a kódot meg nem így kéne megtanulni, ahogy az első osztályosoknak sem betűsablont adnak a kezébe, hogy tanuljanak meg szépen írni :-P
Normális editor szépen egységesen kezeli az identálást, jön a python-fanok kedvence, én meg azt mondom, hogy normális editor szépen tud például {}-es blokkokat formába önteni :-P
- A hozzászóláshoz be kell jelentkezni
Tud, ne:
a) nem kötelező
b) eltérő lehet editoronként
c) én nem a forráskód behúzásáról beszélek, hanem a struktúrált gondolkozás fejlesztéséről
De értem amit mondasz, én csak annyit mondtam, hogy tanulónyelvnek ezért (is) alkalmas, ahogy pl a Groovy-t 3-5 év Java tapasztalat híjján senkinek sem ajánlom, mert elfed egy csomó mindent, amivel aztán lehet szívni
- A hozzászóláshoz be kell jelentkezni
"de egyontetu velemeny volt, hogy az indentalassal valo strukturalas egy oriasi hatrany."
Ilyenkor mindig azt szoktam kérdezni, hogy "miért, hogy akarsz másképpen indentálni"?
:)
Ez egy hatalmas fícsör. Rákényszeríti a gányművészeket, hogy egyféleképp indentáljanak.
"Raadasul ha egy kodreszletet egy szinttel fentebb / lentebb akarsz tenni, az Python-ban mindenfelekeppen bonyolultabb, hiszen minden sort manualisan kell atrendezned."
Erre a megoldás egy IDE használata. Pl. http://pydev.org/ A vim/joe/stb fasza konfigszerkesztésre, viszont nagyobb projectre nem igazán...
- A hozzászóláshoz be kell jelentkezni
Sajnos nem. Nem kenyszeriti ra az egyforma indentalasra.
Lehet tab, 1, 2, 3, 4 space, N space, mittudomen, etc. Aztan jon a sz0pas, mert nem is latod, hogy epp melyik van hasznalva, mivel whitespace (persze, a legtobb editorban be lehet kapcsolni, hogy mutassa oket, de szerintem ez akkor sem normalis)
Raadasul, megcsak az sincs, hogy mindig ugyanannyi space kell hogy legyen, siman megy, hogy az egyik szinten 3 a masikon meg 5 space a behuzas.
4 space eseten szerintem mar eleg konnyu veletlenul 3-at vagy 5-ot rakni, aztan javitgathatsz amikor nem megy.
Ha neked ez feature, hat orulj neki, de ne vard, hogy mas is igy erezze.
/sza2
- A hozzászóláshoz be kell jelentkezni
4 space eseten szerintem mar eleg konnyu veletlenul 3-at vagy 5-ot rakni, aztan javitgathatsz amikor nem megy.
Én nem tabolok, csak spacet használok. A másik meg az, hogy egy idő után már szemre is meg tudod állapítani, hogy 4, 8 vagy éppen 16 space a behúzás, legalábbis én látom.
- A hozzászóláshoz be kell jelentkezni
Nem ertem, ez hol volt kerdes. En is meg tudom kulonboztetni, a 4, 8, 16 space-t.
Ugy tunik nem ertetted meg, en azt mondom, hogy mondjuk a 8 es a 7 vagy 9 megkulonboztetese tud gaz lenni. Pl.:
a = 0
for i in range(1)
if a == 0:
print "0"
else:
print "!0"
Eredmeny: IndentationError: unindent does not match any outer indentation level
/sza2
- A hozzászóláshoz be kell jelentkezni
Te nem értettél meg, nem voltam elég világos. :)
Én látom ha 7 vagy 9 a space. Ja és nincs kipontozva :P
- A hozzászóláshoz be kell jelentkezni
es azt is latod, ha a 8 space-es behuzasnal a harmadik szinten mondjuk 100 sorral lejjebb valahol 24 helyett csak 23 space van?
- A hozzászóláshoz be kell jelentkezni
Nem fogja látni :) de majd abba fog belekötni, hogy a 100 soros blokkot tovább lehet bontani ;)
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
100 soros blokkot tovább lehet bontani! :D
Eddig megúsztam az egymásba ágyazást a végtelenségig, pl. if -> if -> if már nálam sok(k). :)
- A hozzászóláshoz be kell jelentkezni
a kerdes nem ez volt, de akkor ezt egy NEMnek veszem :)
egyebkent mar csak ezert is erdemesebb TABot hasznalni, ott egybol eszreveszi az ember ha eggyel tobb vagy kevesebb van (legalabbis sokkal inkabb, mint a space-ek eseteben)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Csak ide néztem, meg rejtett up. De aszem mostanában enter. :)
Biztos, hogy nem én gonoszoltam le!
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ugye az tiszta, hogy itt a for végéről hiányzó kettőspont miatt írt egy "érdekes" hibaüzenetet az interpreter?
(nem tudom, mi volt az előzmény, mert a drupal threadeket nehezebb követni, mint a python indentálást. :D)
- A hozzászóláshoz be kell jelentkezni
Ugyanezt proporcionális fontokkal nyomtatott kód esetén is?
- A hozzászóláshoz be kell jelentkezni
Aki Python kódot proporcionális fonttal nyomtat, az menjen kapálni.
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
+1 (Meg ugy altalaban barmilyen kodot...)
- A hozzászóláshoz be kell jelentkezni
Apró de lényeges különbség, hogy a többi (nagyjából a whitespace kivételével) értelmes, használható marad, a python kód meg gyakorlatilag mehet a kukába...
- A hozzászóláshoz be kell jelentkezni
Az nem a nyelv hibája, ha valaki nem képes 1 lépést előre gondolkodni.
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Ja. A nyelv kitalálójának a hibája.
- A hozzászóláshoz be kell jelentkezni
lock
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Mitol is lesz nagyobb baja a pythonnak a tobbi nyelvhez kepest a proporcionalis betuktol?
- A hozzászóláshoz be kell jelentkezni
Valószínűleg arra célzott, a proporcionális betűk miatt romlik a kód olvashatósága.
- A hozzászóláshoz be kell jelentkezni
Stroustrup mehet kapálni... :)
- A hozzászóláshoz be kell jelentkezni
Ha egy nyelv kifejezőképességét befolyásolja a szintaxis, akkor az szerintem gáz. Márpedig pythonban pl azért nem lehet többsoros lambdát írni, mert nem lenne megfeleltethető az identálási szabályoknak.
- A hozzászóláshoz be kell jelentkezni
Ha többsoros, akkor azt nem illene egyébként is nevesített függvénybe pakolni? Vagy van olyan funkciója a lambda fv-eknek, ahol nem helyettesíthetőek normál függvénnyel? (ezt tényleg nem tudom, csak pythonban használtam ilyet)
- A hozzászóláshoz be kell jelentkezni
Nem azért anonymous egy függvény, mert egysoros, hanem mert nem akarom többször használni. Ha ilyenkor előtte nevesítenem kell, és úgy átadni egy függvények, az teljesen felesleges, ráadásul sokkal nehezebben olvasható.
Amúgy nálunk konkrét eset volt, amikor ez gondot okozott (és amúgy nem csak ez, sok más hasonló idegesítő aprósággal /vagy inkább baromsággal?/ meggyűlt a bajunk). Mégpedig egy xml alapú transzormációs logikából (kb xslt-hez, vagy mondjuk ant-hoz lehetne hasonlítani) python kódot kellett generálnunk, mert azok az emberek, akik ezt fejlesztik nem értenek máshoz. Ráadásul ők nem is programozók, hanem domain expertek, és nem a programozás a szakmájuk. Na most nekik egy soksoros lambdát meg tudok magyarázni, de azt nem, hogy mit jelent, ha definiálok egy függvényt egy másik közepén, és azt adom át egy másik függyvényhíváskor paraméterként.
Szóval ezzel a példával azt akartam mondani, hogy igen, legtöbbször ezek az apróságok nem jelentenek gondot, de ahhoz, hogy egy nyelv jó legyen, az ilyen speciális eseteknek sem lenne szabad problémát okozniuk. Sajnos a pythonnál ez nem így van.
- A hozzászóláshoz be kell jelentkezni
Hát látszik, hogy nem ugyanott tanultuk a kódolást. :)
Én valami olyat olvastam (talán Uncle Bobtól a Clean Code-ban? Erre nem mernék megesküdni), hogy nem csak olyasmit teszünk függvénybe/metódusba, amit többször akarunk hívni, hanem a zárt egységet alkotó részeket is. Többek közt azért, mert a nevük helyettesíthet pár sor kommentet is.
Például egy hosszabb kódot, amit te többsoros lambdaként írsz le, azt én pusztán azért, mert viszonylag nagyobb egységet képez, valószínűleg külön függvénybe tenném.
(azért azt nehezen tudom elképzelni, hogy valaki, aki python kódokat buzerál, ne értené meg, még ha nem is programozó az illető)
- A hozzászóláshoz be kell jelentkezni
Mindkettonek lehet letjogosultsaga.
Pythont nem ismerem ilyen szinten, de mashol mar tobbszor lattam olyat, hogy egy fuggveny meghiv valamit, es utana callbackkel kapja vissza aszinkron modon az eredmenyt. Ilyenkor ha a hivaskor egy lambda fv-t adsz callback fuggvenynek, akkor logikailag ott tudod folytatni a kodot, ahol akkor folytatodna, ha szinkron lenne a hivas. Egy ilyen lambda nyugodtan lehet tobbsoros.
--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.
- A hozzászóláshoz be kell jelentkezni
Na de azért ugye egy két soros kód még nem számít hosszúnak? Attól, hogy egy lambda többsoros, még nem feltétlenül lesz bonyolult, vagy hosszú.
Amúgy igen, a felvetésed teljesen jogos, magam is amikor coding style-t ismertetek az új kollégákkal mindig kitérek rá, hogy a jól körülhatárolt feladattal rendelkező pár soros kódot is érdemes külön függvénybe szervezni, viszont azért a többsoron lambdának is van létjogosultsága, például, hogy nem töri meg a kódot, és ott folytatódik, ahol az őt hívó függvény van.
És igen, nem teljesen egyértelmű, hogy mit jelent az, ha függvény közepén van függvény definiálva, ugyanis az emberek nincsenek hozzászokva, nem látnak ilyet nap mint nap. Ráadásul felmerül, hogy milyen változók láthatóak, de az sem feltétlenül egyértelmű mindenkinek, hogy az nem fut le ott, ahol definiálva van, stb.
- A hozzászóláshoz be kell jelentkezni
Azt legalább a margó szélén lásd be, hogy ez egy eléggé speciális eset (nem az egysoros lambda, hanem az egész szituáció). Minden koncepciónak megvannak az előnyei és a hátrányai, ettől még az egész koncepció nem kell, hogy szar legyen, csak egyszerűen lehetnek (szélsőséges) esetek, amire nem való az adott koncepció. És most %s/koncepció/programozási nyelv/g. Szerintem meg a PHP egy rakás sz@r, mert mindhárom állítás igaz: 0 == false, "0" == true, 0 == "0", aztán mégis millióan használják. Vagy pl Groovy-ban fordul, és fut az alábbi sor: List a = ['a'] (és nem vagyok tőle túl boldog).
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
"a PHP egy rakás sz@r, mert mindhárom állítás igaz: 0 == false, "0" == true, 0 == "0""
Ezt sokszor olvastam már, de ez mégis mikor jelent a gyakorlatban problémát? És hogy kéne jobban megoldani? Úgy persze lehetne, hogy az egyik operátor ne működjön, de ha nem tetszik, ne használd, probléma megoldva.
- A hozzászóláshoz be kell jelentkezni
"mégis mikor jelent a gyakorlatban problémát?" mármint az, hogy az egyenlőség vizsgálat nem szimmetrikus, az minden szinten problémát okoz.
"És hogy kéne jobban megoldani?" Hát ugye PHP-ban a csodás === való erre, de ugye a hanyag programozók azt sorra lefelejtik, és az ő teszteseteikben rendben mennek is a dolgok, aztán jön az R1 úser, és aztán értetlenkednek. Volt PHPs kolléga, aki mikor erről beszéltünk, akkor mondta, hogy ő pont ezért mindig ===-t használ. aztán rákerestem, és az egész projektben volt 2. Mert sajnos a szakmai hozzáértés pont annál a nyelvnél igen alacsony (úgy általában), amelyik a legrenyhébben kezeli ezeket a dolgokat, és ebből születik az a sok takony kód, ami a webes világot elárasztja (tisztelet a kivételnek). Érdekes más dinamikus típusos nyelveknél le tudták kezelni ezt a problémát.
"ha nem tetszik, ne használd" nem tetszik, nem használom
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
Szimmetrikusnak szimmetrikus, csak nem tranzitív.
Normális esetben, amikor beírsz egy kifejezést, tudod, hogy a változók milyen típusúak benne, akkor meg azt is, hogy mit fog csinálni az operátor. Ellenőrizve persze nincs, ez minden laza típusos nyelvnél probléma.
A "ne használd"-at az == operátorra értettem olyan esetben, amikor különbözőek a típusok, nem a nyelvre.
- A hozzászóláshoz be kell jelentkezni
"csak nem tranzitív" jogos!
- A hozzászóláshoz be kell jelentkezni
Azért arra kiváncsi lennék hogy ezt a C# mivel érdemelte ki egyesek szerint... :)
Üdv. bnv
- A hozzászóláshoz be kell jelentkezni
hasonló kérdés fogalmazódott meg bennem a javaval kapcsolatban.
- A hozzászóláshoz be kell jelentkezni
... nekem meg a C-vel kapcsolatban :]
- A hozzászóláshoz be kell jelentkezni
C: debugolni remalom, a SIGSEGV borzalom. Ha valamit nagyon C-ben kell megcsinalni, akkor a leheto legkevesebb koddal oldom meg, a tobbit valami scriptbol, amiben van ertelmes debugging, es nem felora ujraforgatni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
En oda ikszeltem. :) Nekem a platfromfuggetlenseg nem tetszik benne. Persze, persze, a nyelv nem fugg elvileg a platformoktol, de az MS-nek tulsagosan rajta van ezen a keze, a .Net meg mar erosen egy platfromos. (Letezik olyan, hogy valaki C#-ban dolgozik, de koze nincs a .Net-hez? Nem azt kerdezem, hogy elvileg lehet-e ilyet, hanem van-e aki tenyleg igy dolgozik.) En legalbbis meg sosem hallottam olyanrol, hogy valaki nekiallt egy projektnek aminek fontos a platformfuggetlenseg es azt C#-ban csinalta volna.
En azt nem ertem miert ixeltek sokkal tobben a Javara. A ket nyelv eleg hasonlo, de a fentiek miatt a C# -szerintem- rosszabb, szoval aki igazan gyuloli a Javat az ezt is, legfeljebb Javaval tobbszor lehet talalkozni.
- A hozzászóláshoz be kell jelentkezni
Én pl C#-ban álltam neki egy Linuxon futó szabályzó rendszer megírásának, mivel a Visual Studio-t nyüstölöm 6 éve, a Mono-ban meg kb mára minden megvan ami egy .NET 4.5-ben. Kivéve persze a Microsoft specifikus dolgokat, mint WPF...
A Java-t én pl nem szeretem, túl butuska a C# képességeihez képest, de nem ez a legrosszabb nyelv szerintem. A Java gyűlölet hátterében a lassúsága és az Oracle állhat (szerintem)
- A hozzászóláshoz be kell jelentkezni
Pl. unityben dolgozhatsz c#-ban.
Mondjuk azt én sem értem, hogy miért szavaztak annyian javara amikor a php sokkal rosszabb. ;) De mint nyelv, a c# sokkal gazdagabb a javanál. Lambda kifejezések (oké, java 8 óta van), linq, "var" kulcsszó, anonim típusok (nem összekeverendő a java anonim típusaival), yield return, reference passing, delegates és events nyelvi szinten, a c++-ból átvett dolgok (pl. default arguments, operator overloading). Aztán folytatható a sor a szerintem értelesebben megoldott dolgokkal, pl. a típusrendszerrel, a switch szerkezettel, a checked exceptionök hiányával, az értelmesebben megoldott láthatóságokkal.
Szerk: legfontosbbat kifelejtettem: properties!
Mindezt fejből soroltam fel úgy, hogy hónapok óta nem nyúltam c#-hoz, ellenben javahoz annál többet. :)
- A hozzászóláshoz be kell jelentkezni
Lefordítom: 99%-ban azok szavaznak, akik egy sort nem kódoltak benne (és nagyrészt más nyelvekben sem), de MS, szóval utálni kell.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Szerintem en nem anyaztam az MS-t, viszont amit te csinalsz az.... ;)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
A basic.
- A hozzászóláshoz be kell jelentkezni
Lássuk csak... (itt-ott nyilván enyhe csúsztatások és túlzások lelhetőek fel az írásomban :-) )
C --> nem szeretem, mert a hozzám eljutó problémák körében nincs olyan, amire egy C program megírása lenne a jó megoldás, ellenben van egy csomó olyan, amikor egy nem jól működő C programban kell hibát keresni, forráskód nélkül, a mocsár közepében.
C# --> nem szeretem, mert .NET futtatómotor kell hozzá, amivel régről kimondottan rossz tapasztalataim vannak két projekt kapcsán is (performancia-problémák - nem lassú, hanem nem egyenletes futási sebességű volt a kód, ami akkor tök zavaró volt).
C++ --> nem szeretem, mert a legokosabb programozó ismerőseim körében sincs olyan, aki tényleg értené, hogy miről is szól ez a nyelv a template-ekkel és társaikkal, így nem igazán várnám, hogy bárki is jól működő programot hozzon össze benne.
Haskell és társai --> nem szeretem őket, mert bár bizonyos célterületekre kimondottan nagyon jól használhatóak, sajnos sokan olyan helyeken is erőltetik a használatukat, ahol semmi keresnivalójuk, mert egy nem-funkcionális nyelven sokkal egyszerűbb, szebb, jobb megoldást lehetne adni a problémára.
Java --> nem szeretem, mert mindig védenem kell, hogy nem olyan lassú az, nem olyan rossz az stb., pedig nem hozzáértő kezekben olyan lassú az és olyan rossz az. Továbbá nem tetszik, hogy az 1.5-óta csak bonyolultabb lett a nyelv, sokkal használhatóbb nem.
JavaScript --> nem szeretem, mert az összes felsorolt közül ennek van legkevésbé egységesen és értelmezhetően definiálva és megvalósítva a szintaktikája és szemantikája, a nemfunkcionális tulajdonságairól meg ne is beszéljünk, böngésző-kisverziónként változik.
Perl --> nem szeretem, mert egy olyan eszközt ad egy csomó hozzánemértő kezébe, amellyel olyan kódokat tud létrehozni, amit nem tudok elolvasni. Egy program akkor jó, ha az elolvasásához és megértéséhez nem kell komolyabb energiabefektetés, ezt a Perl és a Perl programozók nem tudják nyújtani.
PHP --> nem szeretem, mert ennek talán a leginkább inkonzisztens az API-ja, nem elég tudni a függvény nevét nagyjából, azt is kell tudni, hogy hol van benne az aláhúzásjel. Nameg a mysql_real_escape_string()? Meh, hogy kell ilyen.
Python --> nem szeretem, mert az OO modellje éppen annyira tér el a többi OO nyelvétől, ami miatt már oda kell figyelni az eltérésekre tudatosan. Nem lenne ezzel baj, ha csak a Python létezne, de a sok Java meg C# között néha Python-ozni is nem egy élvezet.
Ruby --> nem szeretem, mert amit eddig leírtam, az lehetne akár Ruby kód is. A DSL-ek erőltetése miatt szerintem tökéletesen olvashatatlan a nyelv (egyébként pont emiatt nem lett a kedvencem a Puppet és a Chef sem, de ez más témakör).
egyéb --> igen, minden programozási nyelvet utálok. Ami tetszene, az egy olyan nyelv, amiben a C# nyelvi lehetőségeit használhatnám egy Java ökoszisztéma kiterjedt és konzisztens API-jára hasonlító valamivel, miközben lehetőséget kapok a párhuzamos programozásra Erlang-szerű stílusban, mindezt a Python szintaxis eleganciájával. Nyilván.
- A hozzászóláshoz be kell jelentkezni
Ez jo, :-)
- A hozzászóláshoz be kell jelentkezni
Ruby: szerintem a DSL-ek miatt pont, hogy olvashatobb kodok jonnek ki (a Perlhez viszonyitva feltetlenul, de egyebkent is), raadasul pont elegge hasonlit az OO modellje a tobbi nyelvhez (excluding Python). A new operator hianya kihivas, de szerintem konnyen megszokhato. Cserebe a vegletekig override-olhato benne minden, majdnem mint a C++-ban.
Egyebkent minden programozasi nyelvet lehet jol es rosszul is hasznalni - am ez elsosorban nem a programnyelven mulik. Lattam mar szep Perl kodot es csunya Java/Ruby kodot is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Egy DSL akkor olvasható jól, ha az adott DSL-t ismered, ennek a nyelv olvashatóságához igazából nincs köze. A "sima" Ruby kód szerintem nem gáz.
- A hozzászóláshoz be kell jelentkezni
A ruby alapu dsl-ek olvashatoak, ha ismered a ruby nyelv alapjait. raadasul egy rspec DSL-t peldaul konnyebb megerteni mint egy XML-t.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Elég jól összefoglaltad, kevés dologgal tudnék vitatkozni.
Én annyiban látom másként, hogy minden nyelvet szeretek, de azért mindnek vannak kisebb nagyobb hibái.
egyéb --> Pontosan ilyesmi nyelv a Scala, minden fő kívánalmadat hozzá.
- A hozzászóláshoz be kell jelentkezni
Scala-hoz közel sincs olyan kiterjedt natív ökoszisztéma, mint Javahoz... :-(
- A hozzászóláshoz be kell jelentkezni
Nem igazán értelek, a Scalahoz minden java könyvtár használható.
- A hozzászóláshoz be kell jelentkezni
A "natív" a kulcsszó, ami ront a dolgokon, de egyébként igazad van :-)
- A hozzászóláshoz be kell jelentkezni
Az tényleg jobb volna, ha minden Javas könyvtár meg lenne Scalasan is, de azért ne legyünk telhetetlenek. :)
- A hozzászóláshoz be kell jelentkezni
Nem vagyok expert a témában, de legutóbb mikor erről beszélgettem egy Scalással, azt mondta, hogy rengeteg wrapper cucc van, ami "scalásítja" a libraryt, és írni sem bonyolult (persze az írni != kész van)
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
"1.5-óta csak bonyolultabb lett a nyelv, sokkal használhatóbb nem" nekem szivem csücske a generikusok meg az @annotációk, hogy többet ne is mondjak. Persze több mindent kell tudni, de azért hasítja szét a fejemet a tudás, ráadásul mint EE fejlesztő meg még többet, hiszen a platform igazi inyencségei ott kezdődnek.
"böngésző-kisverziónként változik" hát ez k. nem a nyelv hibája ;)
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
A generikusok nem az 1.5-ben jöttek be?
- A hozzászóláshoz be kell jelentkezni
De, a szövegértés nem sikerült ;)
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
Néhányat nem ismerek, azokkal nincs bajom. Sokat szeretek és ismerek. Egyértelműen van egy, amit viszont nem szeretek, súgok: http://www.phpwtf.org/
- A hozzászóláshoz be kell jelentkezni
Objective-C
- A hozzászóláshoz be kell jelentkezni
Pedig az jo, de elsore tenyeg szokatlan. Ha siman a smalltalkot irtad volna at meg meg is ertenem.
- A hozzászóláshoz be kell jelentkezni
A szavazók közül hányan láttak már FORTH programot? :D
- A hozzászóláshoz be kell jelentkezni
Én írtam is! Szerettem...
--
Soli Deo Gloria
- A hozzászóláshoz be kell jelentkezni
Nem csak hogy Forth-ban volt szerencsém programozni, de még Forth-ot is írtam ASM/Forth-ban (Novell-alá is mint VAP vagy NLM, C-vel összegyógyítva ...). Én szerettem, de eljárt felette az idő.
- A hozzászóláshoz be kell jelentkezni
Mi baj van a FORTH-szal? A veremkezelést legalább egy életre megtaníttatta az emberrel. A Commodore Assembly-hez képest pedig gyakorlatilag ojjektumorientált teljesen ;)
- A hozzászóláshoz be kell jelentkezni
Hát abban próbálj webes alkalmazást írni! ;)
Vagy pláne: olvasható kódot (a'la Uncle Bob :) )
- A hozzászóláshoz be kell jelentkezni
Na jó, ezt visszavonom. A topik hatására belenéztem egy erlang tutorialba... A FORTH egy kedves, érthető, könnyen kezelhető nyelv! :)
- A hozzászóláshoz be kell jelentkezni
Anno erlangoztam kicsit, szerettem.
- A hozzászóláshoz be kell jelentkezni
Én csak a tutorialba olvastam bele és hazudnék, ha azt mondanám, hogy könnyen érthető amit olvastam. (most nem a nyelvi elemekre gondolok, hanem a logikájára - azt hiszem, ehhez kell némi matematikusi véna, ami belőlem sajnos hiányzik :( )
- A hozzászóláshoz be kell jelentkezni
Akkor ezután a prolognak ne nézz utána. Prolog után az erlang egy szép, könnyen megérthető, szerethető nyelv. :)
- A hozzászóláshoz be kell jelentkezni
Mintha lenne némi közük egymáshoz. ;)
- A hozzászóláshoz be kell jelentkezni
Mindkettő deklaratív, csak az egyik logikai, másik funkcionális.
- A hozzászóláshoz be kell jelentkezni
"The initial version of Erlang was implemented in Prolog"
Ezt láttam korábban. Csak én úgy emlékeztem, hogy a prolog ihlette az erlang kitalálóját.
- A hozzászóláshoz be kell jelentkezni
minden FreeBSD-s :)
_____________________________
Powered by 1,3,7-trimetilxantin
- A hozzászóláshoz be kell jelentkezni
Jelmagyarázat:
n/k ha nem ismerem annyira, hogy szakmai érvekkel alátámasztható véleményt alkothassak róla
n/a ha nem ismerem
C: Alapjában véve nem sok új kódsort írtam C-ben, de webservice interface-eket elég sokat gyártottam C-ben készült DLL-ekhez. Illetve néha bele kellett módosítanom. Ezek után: bizonyos feladatokra állati jó, amúgy generikus alkalmazást nem fejlesztenék vele. ++
C#: Abszolút kedvenc. Nagyon jól ki lett szerintem találva, MSFT vonalon maradva nagyon komoly dolgokat meg lehet vele valósítani nagyon alacsony költséggel. Amíg a .NET adott, addig heterogén rendszerben is nagyon szépen helyt áll, mondom ezt a PInvoke elég kreatív használata után. :)
C++: n/k, sosem foglalkoztam vele komolyabban, valamire biztosan jó, üzleti aspektusból csak akkor választanám, ha explicit jobb, mint az alternatíva. Tehát akárcsak a C-t, kliensoldali alkalmazásfejlesztésre megint nem annyira.
Haskell, Erlang, Caml, ... (funkcionális nyelvek): n/a
Java: Sok jó tulajdonságon osztozik a C#-pal. Pro, hogy ökoszisztémán belül k*rva sok mindenből lehet választani. Kontra: ugyanaz, k*rva sok mindent kell ismerni, hogy az adott részfeladathoz a lehető legjobb eszközt válaszd.
JavaScript: n/k, általában csak az "áldásos" hatásával találkozom, amikor pl. a pure JS-ben íródott "enterprise" vagy "webkettő" fos alatt izzad a gép. Pedig nem, nem tartozom kifejezetten azok közé, akiket zavar, hogy egyre több kraft kell a gépbe.
Perl: n/k, üzemeltető kollégák beszámolója szerint enélkül nem lenne élet, ha látom őket munka közben, hajlok arra, hogy ezt elhigyjem
PHP: Fuck that shit.
Python: n/a
Ruby: n/a
- A hozzászóláshoz be kell jelentkezni
Ez kb. annyira értelmes kérdés, mint ez lenne: "Melyik a számodra legkevésbé kedves fűszer? "
Attól függ, mit főzök.
-----------------
-activer
document.write(new Date().getFullYear()+1) will be the year of Linux on the desktop!
- A hozzászóláshoz be kell jelentkezni
+1
Hülye kérdés...
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Nem. Attol, mert valamit muszaj hasznalni, mert azzal lesz hatekony a megoldas, meg nem biztos, hogy szeretem is. Ha olyanoknak fozok, akik szeretik az erospaprikat, teszek bele, de nem vagyok koteles szeretni az ilyen fuszerezesu etelt.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Főleg ha grízes tésztát csinálsz, lekvárral. Akárhogy szeretik páran az erőspaprikát nem abba való. Azaz feladathoz az eszköz elvet illik követni, nem pedig epoxiból trabantfőtengelyt csinálni, ahogy ez anno a Fábry showban elhangzott...
- - - - - - -
A nagy tudású uraknak felhívnám a figyelmét arra, hogy a Windows ugyan sok mindenre nagyon jó, de Linuxnak speciel nagyon szar.
"http://hup.hu/node/111669#comment-1419622">csfeco
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
A köménymag, húú de nem szeretem, de hogy komolyan is válaszoljak, ez ugye ítlés dolga, és a kérdés is arra vonatkozott. Ha lehet kedvenc programozási nyelvem, akkor lehet -(kedvenc) is.
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
Hát igen. A fradi/ute/stb. köménymagot én se szeretem. ;)
- A hozzászóláshoz be kell jelentkezni
A köménymag az a szegedi B-közép :-D
- A hozzászóláshoz be kell jelentkezni
vagy nem. Pl.: nacionalista lehetsz, soviniszta nem. De tobbek kozt Jezus tanitasainak is ellentmond.
- A hozzászóláshoz be kell jelentkezni
Egyéb: Fortran. :D
- A hozzászóláshoz be kell jelentkezni
> Prolog
no
- A hozzászóláshoz be kell jelentkezni
Amelyikre a legkevesebb szavazat fog érkezni, meg fogom tanulni :)
- A hozzászóláshoz be kell jelentkezni
Gyanítom, abban benne van az is, hogy mennyien ismerik.
- A hozzászóláshoz be kell jelentkezni
Az se baj. Kell a kihívás :)
- A hozzászóláshoz be kell jelentkezni
PL/pgSQL
- A hozzászóláshoz be kell jelentkezni
-1 az nagyon is jo cucc es olvashato is
- A hozzászóláshoz be kell jelentkezni
PHP - a következetlenségei miatt, meg mert az összes többi nyelvre ki tudok találni valamit amiben az határozottan jobb mint a többi, egy niche-t. A php semibben sem jobb határozottan mint mondjuk a python/ruby/perl hármas.
A többire mondjuk, tényleg csak 1-2 dolog amiben vezetnek a többihez képest:
c - hardverközeli, könnyebben tanulható mint a c++
c++ - hardverközeli, de az összes létező zero vagy minimal overhead absztrakció rendelkezésre áll
c# - MS környezet
java - hordozhatóság (és azon belül közel natív sebesség)
funkc. nyelvek - parallel és konkurens programozás
Js - kliens oldali web
python - olvashatóság (de scientific computingban is versenyben van talán)
ruby - nagyon tömör, nagyon OO(következetesen), kifejezőkèpes de még jól olvasható
perl - amire eredetileg kitalálták (shell++, sed++ , awk++) ott még mindig talán a legkézenfekvőbb választás annak aki ért hozzá
- A hozzászóláshoz be kell jelentkezni
"c - hardverközeli, könnyebben tanulható mint a c++"
Az egész C++-nál könnyebben tanulható, de ha a C++-ból csak a string-et meg a vector-t használod, már jobban jársz, mint C-vel.
- A hozzászóláshoz be kell jelentkezni
"a vas maga vonja magához az embert" (Homérosz: Odüsszeia)
Azért nekem ezek némileg önkényes határoknak tűnnek, előbb utóbb minden fejlesztő belefut majd valamibe amit C++-os módon könnyebben megoldhatónak tűnik. És jönnek a viták: "Akkor már miért tilos más generikus adatszerkezet?", "Miért ne lehetne függvényt tenni egy structba ahelyett globális függvényt használsz ugyanarra?", "Akkor már miért ne hívjuk classnak?", "Miért ne írhatnál saját generikus adatszerkezetet?", "Miért ne használhatnál destruktorokat?", "Miért ne smart pointer?", stb...
Egy több fős fejlesztésben hogy képzelnél betartatni bármilyen ilyesmi korlátot?
Mondjuk te valamilyen coding guideline diktátor lennél - kellő hatalommal - hogy leverd a lázadó csoportokat?
Az ilyesmi vége a gyakorlatban egy valahogy magától fokozatosan kialakuló "stílus" (résztvevő emberek vitái, kvalitásai, meggyőződései, rendelkezésre álló eszközei alapján) hogy végül mit is használnak, de amit végül nem akarnak használni az is egyszer csak átcsúszik itt ott a code review-en, és már használják is. A végeredmény meg az egységesség hiánya.
Szóval végül egy c++ project lesz a végeredmény, amihez már c++ fejlesztőket kell majd alkalmazni - és még ők sem fogják tudni rendbe tenni azt, amit még a régi C fejlesztők kezdtek el, kiindulásként "de csak majd Vector-t használunk" mentalitással ;)
Szóval akkor már szerintem inkább "valódi" C++ projektet kell indtani, tapasztalt c++ fejlesztőkkel.
- A hozzászóláshoz be kell jelentkezni
Egyebre szavaztam a Visual Basic miatt, bar az obj-C es a C# is magasan van a listan.
Java nem tartozik a kedvenceim koze, de az Android SDK nagyon kenyelmes, ugyhogy kezdem megszeretni.
--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.
- A hozzászóláshoz be kell jelentkezni
Mi a baj a VB-vel? Pontosabban, melyik VB-vel van bajod, VBA, VB6 vagy VB.NET? Az elso ketto valoban kisse szerencsetlen volt, de az ujabb VB.NET-ekben dicseretesen sok fejlesztes van, egeszen hasznalhato szintet ut meg.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Hát ja, csak eddig nem igazán találkoztam olyan szituációval, ahol VB.NET-et kifizetődőbb lett volna használni, mint C#-ot. Ha már .NET.
- A hozzászóláshoz be kell jelentkezni
En VB.NET-ben jobban otthon vagyok, nekem kifizetodobb azt hasznalni, mint C#-ot, amit nem ismerek annyira.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
COBOL kód olvasásakor fizikai rosszullétet éreztem :)
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Csak azért nem említettem, mert amikor COBOL-lal dolgoztam, még szerettem a munkámat. ;)
- A hozzászóláshoz be kell jelentkezni
Azért a Cobol-t ne a mostani cuccokkal hasonlítsd össze - a többi korabeli nyelv sem szép mai szemmel nézve :-P
- A hozzászóláshoz be kell jelentkezni
Pythonra negativ velemenyt adni nem nagy gyakorlatra vall (Pythonban).
Kb. sokan programolnak (igy l-lel) mindenben, de attol meg nem ertenek semmilyen nyelvhez sem alapvetoen.
Stroustrup megmondta, hogy Python nelkul nincs _elet_, sokan masok meg azt, 5-10x gyorsabban lehet vele haladni.
Behuzassal kapcsolatos baromsagok meg olyanok, mint a monospace-ben lehet csak igazan jo programolni, kozben meg Stroustrup ota biztosan tudjuk, hogy proporcionalisan szep az elet.
De ez utobbi pont arrol szol, hogy legtobben beszopnak valamit az elejen, onnantol meg kb. nem tudjak kimosni a szajukat.
De kb. igy jo a vilag, mert mi lenne akkor, ha mindenki jol haladna?
- A hozzászóláshoz be kell jelentkezni
a Pythonban nem az elcseszett behuzasok a legnagyobb problema, hanem a kaosz, es az, hogy az egyebkent jo koncepciot agyonvagjak egy rakas idiotasaggal
- A hozzászóláshoz be kell jelentkezni
Milyen káosz, és idiótaságra gondolsz? Én pont azért szeretem a pythont, mert mindent a helyén érzek.
- A hozzászóláshoz be kell jelentkezni
pl ilyenek: https://lwn.net/Articles/590299/ (regebben olvastam egy hosszabb cikket rola, ahol rendesen le volt irva hogy hogyan hisztiznek egymassal a pythonos 'nagy emberek', folyamatosan keresztbe teve egymasnak)
amikor egy bugbol feature-t csinalnak, mert annyira broken az egesz hogy egyszerubb ugy hagyni mint megcsinalni :)
a 'helyen erzem' az, ami nalam mindig is hianyzott pythonnal, pont az ellenkezojet erzem
adott egy egyebkent jo otleteken alapulo modern nyelv, amit egy rakas rossz dontessel tonkrevagnak
pl. az is szimplan egy rossz dontes, hogy a space-t es tabot engedi keverni, emiatt kb. biztos hogy egy ilyen file sehol nem fog normalisan mukodni. Mindezt meg lehetett volna elozni azzal, ha kijelentik hogy egy file-on belul csak az egyik karaktert fogadja el behuzasra. Vagy akar nyelvszinten kikotni hogy az indentalas az csak tab (vagy csak space) es kesz...
vagy ott van pl. a hulye metodusdefinicio: a definicional kiirsz mondjuk 3 parametert, amit viszont csak kettovel hivsz meg, mert az elsot azt 'ki kell irni' de amugy a hivasnal mar nem hasznalod... ez is siman egy hulye dontes eredmenye, es aki mondjuk pythonnal ismerkedik eloszor, annal elkepzelem milyen zavart okoz hogy 'de hat miert 2 parameterrel hivom meg, mikor 3 van neki?'
vagy ott a kompatibilitas: elvileg remekul kompatibilis, a gyakorlatban nem egyszer fordult mar elo, hogy a python 2.4.X-re irt kod a python 2.4.Y-on nem mukodott (de gyakran meg a 2.4.X-en sem egy masik gepen), mindenfele rejtelyes syntax errorokra hivatkozva
es eleg sok hasonlo problemam van vele (mikor tobbet kodoltam pythonban, akkor naponta 4-5 hasonloba futottam bele, azota komoly munkaval sikerult ezeket elfelejtenem es nyugodtabb, bekesebb eletet elek :D)
Es ahogy mondtam, mindez nem is erdekelne ha a nyelv amugy szar lenne. A PHP-nal nem duhit hogy milyen, mert az ugy szar ahogy van es kesz... De a Pythonban rengeteg jo otlet es feature van, es lehetne egy baromi jo nyelv, ezert elkeserito hogy ilyen hulyesegekkel van tele :( persze aki megszokta, annak ez termeszetes, es mar fel sem tunik, de masik nyelvek felol erkezve ez tenyleg ki tudja verni az ember szemet (meg a biztositekot)
- A hozzászóláshoz be kell jelentkezni
Köszi a korrekt választ. A linket is köszönöm, lemaradtam róla.
az is szimplan egy rossz dontes, hogy a space-t es tabot engedi keverni
Én ezt egy választási lehetőségnek tekintem. Céges környezetben remélhetőleg mindenhol:D van valami policy, hogy milyen irányelveket kövessünk. Na meg egy nagyobb projekt mellé nem árt egy style guide csatolása. Viszont én azt vettem észre, hogy akik komolyabban pythonoznak, ott betartják a 4 spacet, mint általános ajánlást.
vagy ott van pl. a hulye metodusdefinicio: a definicional kiirsz mondjuk 3 parametert, amit viszont csak kettovel hivsz meg...es aki mondjuk pythonnal ismerkedik eloszor, annal elkepzelem milyen zavart okoz
Gondolom a self nevű változóra/paraméterre/objektumra gondolsz. Pythonnal ismerkedő olvasson utána. :)
- A hozzászóláshoz be kell jelentkezni
Igen, a ceges policy jo es szukseges, es ha mindenki betartja, akkor legalabb adott cegen belul nem merul fel a problema.
Viszont ha a nyelv egyik tervezesi alapelvet company policyvel kell workaroundolni, az szerintem rossz. Ezt meg lehetne (lehetett volna) annyival oldani, hogy nem azt mondjuk hogy "space es tab" hanem mondjuk "tab". Vagy space, aminel meg darabszamot sem kell kikotni. De meg az is jo lenne, ha azt mondana a fordito hogy lehet akar space akar tab, de egy adott forrasfile-on belul csak az egyik. Igy megmaradna a dontes a company policyben hogy melyik legyen, megsem allna elo az hogy az egyik gepen jo az indentalas, a masikon meg mar nem.
Par evvel ezelott mikor az akkori projectunkon is kellett kicsit Pythonozni, tobbszor elofordult hogy megszokasbol indentaltam (meg pl. vimben nem volt bekapcsolva hogy tab-bol space-t konvertaljon), es a szovegszerkesztoben szemre jol nezett ki, az en gepemen jol mukodott, de mikor masik gepen teszteltuk akkor meg elhasalt, mert ott eppen nem annyi space-bol allt a tab...
Meg most eszembe jutott egy masik erdekes vonas: elofordult parszor hogy mas nyelveknel kialakult reflexbol pontosvesszot raktam a sor vegere (ez nyilvan az en balfeksegem, ezt abszolut vallalom), es nem vettem eszre, mert tesztelesnel pont nem futottunk bele abba az agba, aztan egyszer napokkal kesobb mikor mashol meg igen, akkor dobalta a runtime errorokat... (bar ha jol emlekszem, lehet alapbol .pyc-t csinalni, ami a teljes file-t ellenorzi, igy az ilyenek kiszurhetok, eleg homalyosak mar az akkori emlekeim). Ez pl. Perl-nel ugy mukodik, hogy mikor elinditod a scriptet akkor az egeszen beparse-olja, ha valahol syntax error van akkor hibat dob es megall.
"Gondolom a self nevű változóra/paraméterre/objektumra gondolsz."
Arra bizony :) Ez is eleg ertelmetlennek tunik, mert ertem en hogy igy 'rugalmasabb' mint mondjuk a C++ -nal a fix 'this' pointer, de szerintem sokkal zavarobb is a kovetkezetlenseg.
Egyebkent kicsit visszaterve indentalas temakorre: en abszolut TAB-parti vagyok, azon egyszeru oknal fogva hogy az mindenkinel ugy nez ki, ahogy neki jobban tetszik. Ha valaki a suru kodot szereti akkor beallitja 2 space-nyire, aki a szellos, jol lathato behuzasokat az meg 4-re vagy akar 8-ra, es a kod maga ettol meg nem valtozik.
Nalunk a company policy pl. fixen 2 space, ami szerintem baromi ronda :D
- A hozzászóláshoz be kell jelentkezni
Nem lehet hogy a ruby felelne meg neked jobban?
Amúgy +1 a tab pártiságra az általad vázolt ok miatt.
- A hozzászóláshoz be kell jelentkezni
a pythonhoz kepest mindenkepp, kicsit feljebb irtam is a Rubyrol: http://hup.hu/szavazasok/20140504/melyik_a_szamodra_legkevesbe_kedves_p…
egyebkent en scriptnyelvek kozul a Perlt szeretem (nem tartom hibatlannak, es plane nem minden helyzetben mindenre jonak, sot sok vonasa nem tetszik, de bizonyos tipusu feladatokra baromi hatekony, )
- A hozzászóláshoz be kell jelentkezni
Kaosz a Pytonban, mi?
Oh man!
- A hozzászóláshoz be kell jelentkezni
Lehet doc huptárs PHP-t akart írni! :D
- A hozzászóláshoz be kell jelentkezni
Csak egy egyszerű példa: oop <-> len(lista).
- A hozzászóláshoz be kell jelentkezni
csak egy ecceru valasz:
- A hozzászóláshoz be kell jelentkezni
nekem annyira nem tetszett az indoklás. Rendszer api szinten konzekvensen kell(ene) tartani az elnevezéseket. Hogy most valami property (.length) vagy függvény (.length())
vagy size, vagy akármi, de legalább az alapkönyvtárban legyen már egységes. Hogy a felhasználó a saját kis könyvtárában hogyan nehezíti meg az életét, az szerintem
egy teljesen más tészta.
- A hozzászóláshoz be kell jelentkezni
Kar, hogy a Python tanulasi gorbeje meg tul meredek.
'''Rendszer api szinten konzekvensen kell(ene) tartani az elnevezéseket.'''
Oh man! (bocsanat!)
Szerintem meg minden a kompromisszumok korul dol el egy jo nyelv megalkotasakor; az ido (kor) meg ugyis majd kozbe szol (ez nem vers).
Akkor meg?
Olyan, hogy tokeletes nyelv nincs; tehat kinek van igaza?
- A hozzászóláshoz be kell jelentkezni
Szerintem a nyelvet
1, meg kell tervezni
2, a döntéseket indokolni kell
3, ezeknek rendszerben kell lenni
4, a verzióváltásnál (major) megoldani, hogy a korábbi komoly hibákat javítsuk, akár úgy is, hogy API-t törünk, max támogassuk a migrálást automatikusan
- A hozzászóláshoz be kell jelentkezni
most mirol beszelsz; melyik szalat nem talaltad el?
- A hozzászóláshoz be kell jelentkezni
A Python egyetlen nagy problemaja az, hogy nem teljesen OOP. Olyan, mintha eredetileg modularis szeretett volna lenni, aztan kesobb beleeroszakoltak az osztalyokat meg az oroklodest, kilognak a sorbol. Raadasul nem is kovetkezetesen OOP, a primitiv konstrukciok (tombok, stringek, szamok) nem objektumok, es ez nagyon meg tudja kavarni azt, aki egy normalis OOP vilagbol jon (Java, Ruby, you name it).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
'''primitiv konstrukciok (tombok, stringek, szamok) nem objektumok,'''
oh man!
- A hozzászóláshoz be kell jelentkezni
Ezt a marhaságot hogy sikerült leírnod?
- A hozzászóláshoz be kell jelentkezni
szerintem probaljunk mar megmaradni a kulturalt vitanal :)
ha ugy gondolod nincs igaza, akkor ird le hogy szerinted miben es miert, de ne intezzuk mar el annyival hogy "marhasag" meg "oh man", mert ez a "csak"-kal meg a "mert en azt mondtam"-mal egy szinten levo "erv"
legalabbis en kivancsi vagyok hogy a nyelvet nalam jobban ismerok milyen erveket sorakoztatnak fel egyik vagy masik oldalon
- A hozzászóláshoz be kell jelentkezni
Pythonban minden ojjektum.
Szóval így "kritizálni" valamit...
Nagyon finoman és kulturáltan fogalmaztam amikor marhaságnak neveztem.
- A hozzászóláshoz be kell jelentkezni
Szerintem meg az a kulturalt, ha valamihez nem ertek, akkor befogom a szamat.
A kollegad kurva okosnak gondolja magat pl. Pythonban, mikozben tudja magarol, hogy amit gondol, azt nem tudja, csak __elkepzelt__ (igy pythonosan) valamit; most pont nem jott be neki a mano vagyok, kb. ennyi tortent.
- A hozzászóláshoz be kell jelentkezni
> a primitiv konstrukciok (tombok, stringek, szamok) nem objektumok
most erre milyen kulturált érvet vársz válaszul?
_____________________________
Powered by 1,3,7-trimetilxantin
- A hozzászóláshoz be kell jelentkezni
pl azt hogy "de igen, azok, tessek itt egy PELDA"
vagy az hogy "valoban nem azok, es ez igy tenyleg nem jo"
vagy "valoban nem azok, DE ez igy szerintem jo, MERT"
gyanitom az utolso kettobol kene ebben az esetben valasztani
de ne kelljen mar azt is elmagyarazni hogy mit jelent a kulturalt, konstruktiv vita...
sajna a Python is olyan mint az Apple, sokan teljesen fanatikusok, semmifele ervelesre nem kepesek csak hisztiznek ha valaki rosszat mond a szerelmukre (es mielott meg megkopkodnetek: en is hasznalok Apple-termeket, teljes megelegedettseggel, de fanatizmus meg hiszti nelkul)
- A hozzászóláshoz be kell jelentkezni
Na a "sajna..." kezdetű sorodtól kezdve szimpla idióta vagy a szememben.
- A hozzászóláshoz be kell jelentkezni
ha szerinted ez a kulturalt stilus es a konstruktiv vita, akkor itt nyugodtan abba is hagyhatjuk :)
- A hozzászóláshoz be kell jelentkezni
Szerintem, ha valaki kinyilatkoztatás jelleggel leír egy kapitális ökörséget, az ne várjon kulturált választ. Ha meg valaki erre flame-et kezdeményez, ahogy azt tetted...
- A hozzászóláshoz be kell jelentkezni
"Ha meg valaki erre flame-et kezdeményez, ahogy azt tetted..."
Ezzel?
"ha ugy gondolod nincs igaza, akkor ird le hogy szerinted miben es miert, de ne intezzuk mar el annyival hogy "marhasag" meg "oh man", mert ez a "csak"-kal meg a "mert en azt mondtam"-mal egy szinten levo "erv""
- A hozzászóláshoz be kell jelentkezni
Ha már nem a vita kedvéért, de értünk, akik nem értenek a Pythonhoz túlságosan, nem lehetne picit tényleg konstruktívabban?:) Speciel én most tök nem tudom eldönteni, hogy kinek van igaza és miért.
Számomra azért is érdekes ez, mert sokat vaciláltam a Python és a Ruby közt általános script-nyelvnek megtanulni, és végülis a Ruby mellett kötöttem ki. Mondjuk itt csak az alap benyomások voltak mérvadóak számomra, nem tetszett a Pythonos szívás a 2-3 váltással, meg a pip install is nehézkes volt így picit, Ruby ennél picit felhasználóbarátabbnak tűnt elsőre.
- A hozzászóláshoz be kell jelentkezni
Rubyt nem ismerem (csak tudom hogy van), de ha jol tudom Pythont tobb helyen hasznaljak ill. tamogatjak. Nekem ez inkabb eldonti, hogy Python vagy Ruby.
Ha meg mar teccik alapon kellene donteni, akkor __Groovy__.
- A hozzászóláshoz be kell jelentkezni
hasonloan voltam a Rubyval en is :D (bar en nagyon kicsit belenezegettem, es kimondottan tetszett, de a konkluziom a tamogatottsagrol hasonlo volt)
http://hup.hu/szavazasok/20140504/melyik_a_szamodra_legkevesbe_kedves_p…
- A hozzászóláshoz be kell jelentkezni
Amiota Redmine-t hasznalunk a cegnel, azota utalom a Ruby-t. Ha egy ideig nem hasznaljuk (pl ejszaka), masnap az elso betoltodes kb. 15-20 sec. Hogy mire var, ne kerdezzetek.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Én is megsértődőm, ha "báncsák" a pythont! :) Pont mint egy gyerek, a kedvenc játékom az tabu. :D
Szerk.
Meg akkor is megsértődöm, ha HZ jó arcoknak szól be! :D
- A hozzászóláshoz be kell jelentkezni
És ki lenne a "jó arc"? :)
- A hozzászóláshoz be kell jelentkezni
doc. De szóltál már be olyannak itt, akit személyesen is ismerek, jó szaki, és nála önzetlenebb/nagyobb szívű fickó szinte nincs is. :)
- A hozzászóláshoz be kell jelentkezni
ooo... koszonom (blush) :D
de nem volt celom "jo arc"-nak lenni, pusztan remeltem hogy vegre kibontakozik elottem egy konstruktiv vita, amibol megertem a ket oldal allaspontjat, es netan meg tanulok is valami ujat es erdekeset
de eddig csak az jott a "Python-vedo" oldalrol hogy "baromsag" meg "idiota" meg "oh man" meg "kurva okosnak gondolja magat", ezzel meg nem nagyon lehet mit kezdeni...
- A hozzászóláshoz be kell jelentkezni
Ritkán szólok be olyannak aki nem szolgál rá. :D
- A hozzászóláshoz be kell jelentkezni
es azt, hogy ki "szolgal ra" termeszetesen te dontod el :)
vagyis csak annak szolsz be, akinek be akarsz szolni
- A hozzászóláshoz be kell jelentkezni
Gyurex: ennyit az emberismeretedről ;)
- A hozzászóláshoz be kell jelentkezni
Te kérted fel táncolni.:D Egyébként nem látok semmi kivetnivalót a hozzád fűzött szavaiban. Na meg én nem is elemzem docot, szeretve van itt mindenki, úgy ahogy van.
- A hozzászóláshoz be kell jelentkezni
''' szeretve van itt mindenki, úgy ahogy van'''
Ez jol esett; azt hittem, hogy a bunkokat csak a jo csajok szeretik.
- A hozzászóláshoz be kell jelentkezni
Nálam nem feltétlenül van olyan, hogy bunkó. Max. másképp szocializálódott. :D
- A hozzászóláshoz be kell jelentkezni
Provokálja a flame-et. Én úgy saccolom, szándékosan.
- A hozzászóláshoz be kell jelentkezni
Ezt már hányszor láttam hupon tőled... :) Kiharcolod, hogy visszaszóljanak, aztán letrollozod :D
- A hozzászóláshoz be kell jelentkezni
Aham. Mer azt ki kő harcóni... :D
- A hozzászóláshoz be kell jelentkezni
:D
- A hozzászóláshoz be kell jelentkezni
De igen, azok, tessék, még itt, a Ruby oldalán is írják, így a ruby-warrior-python-bashereknek sem kell égetniük magukat.
És nem vagyok Python-fan, egyszerűen a közmondásos, minden 0 skilles python tutorialban szereplő a "pythonban minden objektum" kinyilatkoztatással történő tagadása nem érvelő beszéd fogalmazására sarkallja az embert, hanem egy OMFG szintű beszólásra. (Egyébként a hozzászólás első része is elég zavaros, csak mindenki a már említett rész miatt bukott ki.)
_____________________________
Powered by 1,3,7-trimetilxantin
- A hozzászóláshoz be kell jelentkezni
na latod, ugye hogy lehet normalis valaszt adni, jelen esetben pl. azt hogy "de igen, objektumok azok is" :)
bar szerintem a linkelt cikkben nem irjak azt, hogy pl. a tomb vagy a string is objektum, az "everything is an object" ertheto siman alapelvnek is (lasd: "a Linuxban minden file" de pl. az ablak fejlece az nem file)
de akkor most mar tisztazzuk, mert tenyleg erdekel :)
szoval a pythonban pl. a string literal az egy object? mert Rubyban pl. igen, tehat ott mondhatod hogy "text".center(15), mert maga a string literal is egy object
(maga a valtozo amibe beleraksz egy tombot vagy stringet, mar nyilvan a Pythonban is objektum lesz, ez tiszta sor)
nem tudom hogy eredetileg hrgy84 erre gondolt-e, ha nem, akkor remeljuk jar meg erre es leirja hogy akkor mire :)
a hozzaszolas elso fele meg talan arra vonatkozik, hogy gyakran nem OOP modon kell/lehet kezelni az objektumokat (pl. a len es hasonlok esete)
- A hozzászóláshoz be kell jelentkezni
dir (0)
dir ("")
help (77)
help ("krixkrax")
Próbáld ki!
- A hozzászóláshoz be kell jelentkezni
>>> -4.__abs__()
File "", line 1
-4.__abs__()
^
SyntaxError: invalid syntax
>>> int(-4).__abs__()
4
>>> help ("krixkrax")
no Python documentation found for 'krixkrax'
vagyis ugy tunik, a literal az valoban nem object a pythonban (amivel mondjuk nekem szemely szerint nincs bajom, bar filozofiailag "szebb" a Ruby megoldasa, ahol az, es helyenkent kimondottan hasznos is tud lenni )
egyebkent ez a dupla alahuzogatas a masik amitol hulyet tudok kapni, hogy lehet osztalymetodusokat __nev__ modon kitalalni a standard libben? :S
illetve:
int(-4).__abs__() es nem int(-4).abs()
de
abs(4) es nem __abs__(-4)
vagy:
>>> str("abcdef").__contains__("d")
True
>>> str("abcdef").find("d")
3
tobbek kozott ezekre is gondoltam mikor kaoszrol meg logikatlansagokrol irtam...
- A hozzászóláshoz be kell jelentkezni
Igaz, a help nem működik mindennel, erre nem gondoltam, de ennek elég sok oka lehet, ennyire mélyen nem ismerem - pont a str egy olyan osztály, amivel sohasem próbáltam.
Ettől függetlenül a legtöbb tutorial úgy kezd, hogy a pythonban minden objektum.
Az ilyen: __név__ formátumú nevekkel kapcsolatban ajánlom figyelmedbe a python doksit!
- A hozzászóláshoz be kell jelentkezni
ok, a helpes resz nem annyira lenyeg, vegul is megtalaltam amit kerestem (talan a help(str) volt az)
a linkelt doksi meg baromi hosszu, vegigolvasni biztos nem fogom (gyorsan atfutottam, de nem talaltam benne meg a valaszt/indoklast, bar tippem van hogy mi lehet)
de ha esetleg megmondod hogy melyik fejezetben van, akkor azt elolvasom :)
- A hozzászóláshoz be kell jelentkezni
https://docs.python.org/3.4/library/stdtypes.html#text-sequence-type-str
>>> from string import Template
>>> s = Template('$who likes $what')
>>> s.substitute(who='doc', what='Perl')
'doc likes Perl'
>>> s.substitute(who='hrgy84', what='Ruby')
'hrgy84 likes Ruby'
_____________________________
Powered by 1,3,7-trimetilxantin
- A hozzászóláshoz be kell jelentkezni
ez ugyanaz amit en irtam, hogy a string (pontosabban 'str') tipusu valtozok objektumok
(es implicit benne van, hogy a string literal viszont nem)
szoval szerintem hrgy84 eredeti felveteset megvalaszoltnak tekinthetjuk, barhogyan is ertette :)
- A hozzászóláshoz be kell jelentkezni
a "példám" nem a kérdésedre válaszoló példa volt, bocsi :)
hogy a str.center() példánál maradjunk:
>>>'doc'.center(3)
'doc'
>>>'doc'.center(5)
' doc '
Rubyban is így megy nem?
_____________________________
Powered by 1,3,7-trimetilxantin
- A hozzászóláshoz be kell jelentkezni
ezaz, koszi :D
basszus az elobb pedig tutira probaltam igy kicsikarni belole valamit (bar lehet hogy csak a numeric literal-nal ragadtam le, kicsit szejjel vagyok mar igy hetfo delutan :-/)
szoval akkor a string literal is ojjektum, alakul :)
de ha az, akkor a szamok miert nem?
na rajottem, tulajdonkeppen azok is azok, csak 'nem annyira' mint Rubyban :D
>>> 6.__abs__()
File "", line 1
6.__abs__()
^
SyntaxError: invalid syntax
>>> (6).__abs__()
6
- A hozzászóláshoz be kell jelentkezni
nincs ezen semmi különös, ezen logika alapján a -6-ot nézve nem lenne egyértelmű, hogy -1×|-6|, vagy |-6|. Nem mintha bármikor így használnám, az abs(-6) egyszerűbb :)
_____________________________
Powered by 1,3,7-trimetilxantin
- A hozzászóláshoz be kell jelentkezni
na jo, de az sem mukodik hogy 4.__abs__()
de amugy ez tenyleg nagyon erosen reszletkerdes
- A hozzászóláshoz be kell jelentkezni
(-4).__abs__()
Így működik, de bevallom, ezt a részét már én sem értem.
A dir, a help, a type mind azt mondják, hogy int típusú objektum a numerikus konstans.
Viszont ha egy (numerikus) konstans osztályához tartozó metódusra hivatkozom, akkor máris syntax error az eredmény.
Ahogy azt sem értem, ha már itt tartunk, hogy miért tér el a dir((4)) és a dir((4,5)) kimenete.
Hiszen _elméletileg_ mindkettő lista.
- A hozzászóláshoz be kell jelentkezni
igen, pont ezt irtam kettovel feljebb :)
a tobbihez (a miertekhez) nem nagyon tudok hozzaszolni, en mar regota nem probalok logikat keresni abban hogy miert mukodik vagy nem mukodik a pythonban valami ugy ahogy... mivel kb. 2-3 evente egyszer kell pythonhoz nyulnom, ez nem okoz nagy problemat :D
de ha mar...
a dir((4)) az mitol lista? ilyen erovel a (-4).__abs__() -ben is lista kene hogy legyen a (-4), nem? gondolom az alapjan donti el hogy lista-e, hogy van-e benne felsorolas (ami eleg logikus, hiszen miert lenne lista mondjuk a 2 * (3 + 4) - ben a (3+4)? )
- A hozzászóláshoz be kell jelentkezni
Mitől lista?
A type(()) azt mondja, hogy 'tuple'.
A (4) ilyen alapon egyelemű lista (alias tuple) lenne.
Szintaktikailag.
A [4] már 'list' típusú.
Kezdem megutálni a pythont... pedig eddig szerettem. :D
- A hozzászóláshoz be kell jelentkezni
"Kezdem megutálni a pythont... pedig eddig szerettem. :D"
MISSION ACCOMPLISHED!
>:-D
- A hozzászóláshoz be kell jelentkezni
Úgy tudom a parsere ilyen (buta) vagyis a szintaxis úgy van definiálva hogy a pont utáni szöveg már nem befolyásolhatja lebegőpontos szám vagy metódushívás jön, azaz nem kell lookahead a parserba - mire a pont jön a dolog eldőlt.
szerk.: A zárójel meg egy aritmetikai kifejezés zárójele, semmi extra. (-4).__abs__() vagy pl. ((5 - 2) * (1 - 15)).__abs__(). Viszont lezárja a -4 parsolását ami így egyértelműen egy egész.
- A hozzászóláshoz be kell jelentkezni
Hogy neked milyen igazad van! Tizedespontként értelmezi a pontot...
- A hozzászóláshoz be kell jelentkezni
Ez emberi olvasáskor is hasznos lehet.
Bizonyára számtalanszor előfordult már minden ruby programozóval, hogy az intek felett definiált egy l415926 metódust és nem jó karakterkészletet választva a 3.l415926-ot lebegőpontosnak vélte a kódot később visszaolvasva. ;)
- A hozzászóláshoz be kell jelentkezni
Ezt a ruby-s poént valahogy nem tudom értelmezni, viszont azt sem, hogy ha pythonban is, az őt indító shellben is magyarra állítom a locale-t, akkor a tizedes miért marad meg pontnak a pythonban.
- A hozzászóláshoz be kell jelentkezni
Ok, a személyes információid alapján látom hogy miért nem: az 1 mint számjegy és az l mint László karakterekkel játszottam.
Ha a locale befolyásolná egy nyelv szintaxisát az szörnyű lenne: bad design. Az excelnél is összerezzenek tőle valahányszor szembe jön a jelenség.
- A hozzászóláshoz be kell jelentkezni
Félreértesz: a kiírt szövegben annyira feltűnő, hogy a pont után nem számjegy áll, hogy képtelenség nem észrevenni az eltérést. (no meg ki ad numerikus karakterrel kezdődő nevet egy metódusnak?)
Locale... hm. Excelék nem tudnak róla, mert ott még a függvények nevét is befolyásolja, ha jól tudom. ;)
(lehet, hogy hülyén fogalmaztam: a kiírt számokra gondoltam elsődlegesen. Ott sem használ vesszőt a tizedespont helyett)
- A hozzászóláshoz be kell jelentkezni
Mint írtam karakterkészlet függvénye. Microsoft (meg gondolom egyéb) termékkulcsokban sincs 1, l, O, 0, I stb.. bizonyos országokban rendszámban se.
A kiírtnál több a játéktér. De ott is mondhatja valaki, hogy a standard input függvényektől elvárja hogy locale-tól függetlenül - feltétel nélkül - mindig beparsoljon egy számot amit valaki a standard output függvénnyel írt ki - és az ezen felüli igényekre meg használható valami explicit pretty print könyvtár.
szerk: csak eszembe jutott erről - érdemes utánaolvasni a lebegőpontos számkiíró/beolvasó algoritmusoknak, ott pl. explicit követelmény általában hogy többszöri kiírás és visszaolvasási ciklus után minél kevésbé (vagy ne) divergáljon az érték, kb. ez az egyik fő fokmérője a algoritmusok "helyességének" (dragon4, grisu3, stb...)
- A hozzászóláshoz be kell jelentkezni
Ha valakinek van kedve flamelni a tizedespont\vessző témaköréről, akkor szóljon, vevő vagyok rá :)
_____________________________
Powered by 1,3,7-trimetilxantin
- A hozzászóláshoz be kell jelentkezni
Ez a megoldás (parser ilyentén segítése), meg a __név__ típusú metódus nevek meg a több soros komment hiánya mind szönyeg alá söprése a problémának. Nyilván semmi sem tökéletes, de ezek a gépet segítik a humán helyett, és ez nem jó írány szerintem.
Szerintem úgy működik, hogy attól függően hogy már alapból milyen jóra tervezték, ettől fog függeni hogy milyen későn siklik ki a vonat és kell elkezdeni hack-elni, mert már nem éri meg / lehet át tervezni, mert olyan mélységű kellene legyen az átalakítás.
- A hozzászóláshoz be kell jelentkezni
ugy sikerult neki, hogy -mint a tobbi Python anyazo- egyaltalan semmi fogalma a Pythonrol, de azt hiszi, hogy az a semmi ami van neki, mar valami.
- A hozzászóláshoz be kell jelentkezni
PL/1
Amikor utoljára használtam, akkor lyukkártyán lehetett leadni az operátornak futtatásra az R20-as gépen, és legkorábban is csak másnapra volt meg a batch eredménye :)
--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer
- A hozzászóláshoz be kell jelentkezni
Jurányi utca? :)
Vagy volt máshol is R20?
- A hozzászóláshoz be kell jelentkezni
Igen :)
Volt még egy R40-es is az Alkotás úton a MOM-ban is, a jelenlegi pláza helyén, ami már modern monochrome konzolokkal rendelkezett, nagyon király dolog volt :D
--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer
- A hozzászóláshoz be kell jelentkezni
Csak ha jól emlékszem, pár évvel öregebb vagy nálam. :)
R gépből volt sok az országban, de az R20 már akkor is öregnek számított, amikor a suli megkapta.
22-es, 35-ös, 40-es volt sok és én még láttam az ország utolsó R gépét, egy R57-est (??? a szám nem biztos) működgetni. :)
- A hozzászóláshoz be kell jelentkezni
Ermefeldobassal dontottem el hogy a Perlre vagy a haskell/funkcionalis nyelvekre menjen. Mindket write-only nyelv hanyingerkeltoen sok fejfajast tud okozni ha hozza kell nyulni, akik szeretik azok pedig szeretik elfelejteni, hogy nem eleg a programot sokszor csak ugy egyszer megirni. Meg mar onmagaban aki par karakternel hosszabb regexpet ir kommentben jelzett pelda es helyi gyors leiras nelkul, azt is 10 evre eltiltanam a szakmatol.
- A hozzászóláshoz be kell jelentkezni
Funkc. nyelvben ott lehet félremenni hogyha az ember nem nevez el elég sok dolgot, pl.. több soros függvényeket pakol össze let vagy where blokk nélkül ahol értelmes neveket ad a részeknek.
Amit viszont mindig a javára lehet írni a megértésnél, az az hogy garantáltan nincs állapot:
egy pure function önmagában egy megérthető, szeparált egység - nem kell közben az egész programot szem előtt tartani, nem kell az "idő"-re gondolni hogy mikor mi történhet, csak a konkrét transzformációt kell megérteni az adott függvény bemenete és kimenete között.
- A hozzászóláshoz be kell jelentkezni
Bármilyen nyelven lehet writeonly forrást "alkotni". Van, amiben egyszerűbb,és van, amiben nehezebb. Ez utóbbiakhoz kell a kevesebb programozási gyakorlat és szépérzék :-P
- A hozzászóláshoz be kell jelentkezni
FoxPro nincs a listában, se a jó öreg Fortran.
Mindkettővel volt kisebb dolgom.
- A hozzászóláshoz be kell jelentkezni
mau kimaradt.
--
http://www.micros~1
- A hozzászóláshoz be kell jelentkezni
Erősen torzítaná az eredményt :-D
- A hozzászóláshoz be kell jelentkezni
:DDDD
- A hozzászóláshoz be kell jelentkezni
PHP-ra szavaztam, mert egy átgondolatlan, össze-vissza tódozott-foltozott, önmagával is inkonzisztens, rossz szokásokat fejlesztő gányhalmaz. Jah és persze ez nem a nyelv hibája, de mégis elárúl valamit ;)
- A hozzászóláshoz be kell jelentkezni
Aki a Java -ra szavazott ide megindokolhatja, de légyszi szorítkozzunk a language levelre, ahogy a kiírás is szerepel (tehát a "lassú a java" című közmondás nem ér)
--
arch,xubuntu,debian,windows,android
dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C
- A hozzászóláshoz be kell jelentkezni
Elsutom, mert ugyis el fogjak: lassu a java!!!!4negy!
Nyelvi szinten ami nekem nagyon hianyzott eddig, az a kulturalt anonim fuggvenyek (ez most talan megoldodik a lambda kifejezesekkel), illetve nekem nagyon hianyzik a [] / []= operator a map-szeru objektumok eseteben, a get/put nem eleg vicces ehhez.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Nem hiszem hogy a Map kedvéért csinálnának ilyesmit. :)
--
arch,xubuntu,debian,windows,android
dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C
- A hozzászóláshoz be kell jelentkezni
A Map['string']-es résszel egyetértek, iszonyú rossz mindig leírni minden kilométer hosszú metódusnevet, ellenben az anonim függvények más nyelveken is a kárhozat útjai, fúj. Javascriptben pl. debuggoláskor jobb ha látsz egy függvénynevet, ennek ellenére sok barom inkább anonim függvényt csinál, mert a nyelv megengedi.
- A hozzászóláshoz be kell jelentkezni
Kétélű fegyever, mint minden kb a programozásban
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
csak nem jonnek az indokok, pedig kivancsi lennek ra...
en sem szeretem a Javat, de az meglep hogy meg a PHP-nal is tobb szavazatot kapott, ANNYIRA azert nem rossz :)
- A hozzászóláshoz be kell jelentkezni
Erről mi a véleményed? http://steve-yegge.blogspot.it/2006/03/execution-in-kingdom-of-nouns.html
- A hozzászóláshoz be kell jelentkezni
Az enyem az, hogy a linkelt blog egy eleg szubjektiv velemeny a Javarol es az OOP-rol. Ahogy a blog alcime is irja: "RANDOM WHINING AND STUFF."
- A hozzászóláshoz be kell jelentkezni
Úgy néz ki a "nem ér" kitétel sok kommentet kizárt.
-
groovy.lang.Tuple kicsit közelebbről
- A hozzászóláshoz be kell jelentkezni
Csak épp annak, hogy lassú, annak maga a nyelv is oka lehet. erről mi a véleményed?
- A hozzászóláshoz be kell jelentkezni
A linkelt oldalon azt allitja a szerzo, hogy "A Java benchmarkon lehet ugyanolyan gyors, mint a C++, de a valo eletben nem".
Ugyhogy akkor vegyunk egy peldat a valo eletbol: a Disruptor opensource java libet fejleszto ceg a kovetkezoket irja:
"LMAX aims to be the fastest trading platform in the world. Clearly, in order to achieve this we needed to do something special to achieve very low-latency and high-throughput with our Java platform. Performance testing showed that using queues to pass data between stages of the system was introducing latency, so we focused on optimising this area."
- A hozzászóláshoz be kell jelentkezni
Hm, lehet, hogy rosszul értem, de nem azt mondja, hogy speciálisan pöcsölniük kellett, hogy gyors legyen attól még, hogy Java?
- A hozzászóláshoz be kell jelentkezni
Hát az biztos, hogy másképp érted, mint én. Arra kívántam felhívni a figyelmedet, hogy a céljuk a leggyorsabb megírása és Javaban írják. Azt, hogy ehhez mérni kell és optimalizálni, az nem Java specifikus.
- A hozzászóláshoz be kell jelentkezni
Most komolyan egy tizenvalahány éves blogbejegyzéssel akarsz érvelni egy vitában, ahol egy Visual Basic fejlesztéssel nyitó C/C++ fejlesztő elmondja, hogy mit nem értett meg a Java-ból? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
fuggetlenul attol hogy mi a velemenyem a temarol, ez a komment odabasz, respect :D
- A hozzászóláshoz be kell jelentkezni
Nem minden haladt ám olyan sokat azóta, generics pl. már rég van de az 1. pontra (value types) még csak proposal született 1 hónapja: http://cr.openjdk.java.net/~jrose/values/values-0.html
" If, on the other hand, we could represent a Point in the same manner we do an int, we could store them in registers, push them on the stack, iterate through an array with locality, and use far less memory, with no loss of encapsulation."
- A hozzászóláshoz be kell jelentkezni
Nagyszerű... és? Kevés use-case az, ahol ez igazán nagy előnyt adna, ahol igen, ott meg DalvikVM van és Android. Nincs olyan nyelv, ami mindenben jobb, mint egy másik, pláne hogy itt összemosódik a nyelv és a platform fogalma.
Tehát például van-e értelme egy register-based VM-et összehasonlítani egy stack-based VM-el, miközben ugyanarról a forrásnyelvről beszélünk, amely bytecode-ra vagy dex-re fordulva teljesen más módon fut.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
"összemosódik a nyelv és a platform fogalma"
De hát erről szól az eredeti post, illetve a jdk proposal is, hogy maga a NYELV nem ad lehetőséget bizonyos platformszintű optimalizációkra.
Ha nehéz is megérteni egy Visual Basices arc cikkeit, köpködni még megy nemde? ;)
hint: A fikázás helyett, eleve írhattál volna ennyit: hogy Java magas szintű nyelv, szarunk a platformra, nem kell elcsúfítani mindennel mint a C++-t, pár ms nyereségért! ÉS kész. Ez egy értelmes komment lett volna.
- A hozzászóláshoz be kell jelentkezni
"De hát erről szól az eredeti post, illetve a jdk proposal is, hogy maga a NYELV nem ad lehetőséget bizonyos platformszintű optimalizációkra."
Attól függ, mit értesz platformon és azon, hogy a nyelv miért nem ad lehetőséget ilyesmire és hogy ezt hol olvastad egészen pontosan... a hivatkozott cikkben ugyanis csak JDK-ról van szó, és ott is a __ jel inkább egy hint a fordítónak, hogy más struktúrát készítsen, de ez eldönthető lehet hint nélkül is és akár futásidőben is...
Hozzátenném, hogy a DalvikVM az nem bytecode-ot kap, hanem dalvik executable formátumot, tehát egyáltalán nem érintett abban a megoldásban, ami le van írva.
"Ha nehéz is megérteni egy Visual Basices arc cikkeit, köpködni még megy nemde? ;)"
Megértettem, de látszólag Te nem érted a Java nyelvet, a platformot, az ecosystem-et és a futtatókörnyezetet, ahogy a VB-s arc se igazán.
"A fikázás helyett, eleve írhattál volna ennyit: hogy Java magas szintű nyelv, szarunk a platformra, nem kell elcsúfítani mindennel mint a C++-t, pár ms nyereségért! ÉS kész. Ez egy értelmes komment lett volna."
Megvan mindennek a helye és ideje. Lehet köpködni például a GC-t, hogy több memóriát igényel, mintha minden esetben a fejlesztő lekezelné a memória foglalást és felszabadítást, de cserébe csak igen erős ráutaló magatartással tudsz olyan hibát ejteni, mint a Heartbleed vagy a memóriaszivárgás...
...egyszerűen csak arra akartam rámutatni, hogy fura 2014-ben egy Java-val messziről találkozó blogszerző 2004 előtti írását lobogtatva egy IT megoldásról vitázni, ahol egy éven belül változnak a dolgok, nemhogy egy évtized távlatban...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
"de ez eldönthető lehet hint nélkül is és akár futásidőben is"
Erre írják Guy Steele-ék, hogy: "Despite significant attempts, JVMs are still poor at figuring out whether an object’s identity is significant to the program, and so must pessimistically support identity for many objects that don’t need it"
Tehát a gyakorlatban nem megy jól.
"nemhogy egy évtized távlatban"
Én meg pont azt írtam, hogy ez a value typeos felvetés nem változott semmit. Ma is érvényes.
"DalvikVM ... tehát egyáltalán nem érintett abban a megoldásban, ami le van írva"
Azaz ott tehát előfordulhat, hogy még tíz év benne lesz ebben az optimalizációban ha egyáltalán valaha megvalósul. Na, te tudsz ilyen időtálló rant-et írni? ;)
- A hozzászóláshoz be kell jelentkezni
"Tehát a gyakorlatban nem megy jól."
Most akkor proposal vagy proof-of-concept? Aztán meg a GC-ről is ezt mondták eleinte...
"Én meg pont azt írtam, hogy ez a value typeos felvetés nem változott semmit. Ma is érvényes."
Nagyszerű... leszámítva azt, hogy ez nem nyelvi sajátosság, hanem platform tulajdonság és egyetlen egy VM implementációról írsz, holott van néhány... tisztázzuk már a fogalmakat és azt is, hogy mi a bajod alapvetően. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
"és egyetlen egy VM implementációról írsz, holott van néhány"
Ok, akkor ha hozol példát arra (forrással) ahol ezt az optimalizációt jól megcsinálták, elhiszem hogy nem VB-s fickónak van igaza és a Java nyelv önmagában nem akadálya, hogy az egyszerű value typeokat 0 byte memory overheaddel kezeljék.
Ha maguk a Java nyelv közelében molyoló nagy nevek is azt mondják, hogy nyelvi kiegészítés nélkül nem megy ez jól automatikusan (VB-s csávóval együtt már négyen vannak), te meg hogy igen, akkor tényleg hozz már valami forrást rá kérlek!
- A hozzászóláshoz be kell jelentkezni
"Ok, akkor ha hozol példát arra (forrással) ahol ezt az optimalizációt jól megcsinálták, elhiszem hogy nem VB-s fickónak van igaza és a Java nyelv önmagában nem akadálya, hogy az egyszerű value typeokat 0 byte memory overheaddel kezeljék."
Nem hozok példát, mert (jelenleg) nincs. Se erős igény, se implementáció.
Leírva meg az van, hogy "JVMs are still poor at figuring out", ami az én szegényes és gyenge ismereteim szerint nem azt jelenti, hogy nem lehetséges, de majd felveszem így a szótáramba, mert ezek szerint rosszul értelmeztem.
"Ha maguk a Java nyelv közelében molyoló nagy nevek is azt mondják, hogy nyelvi kiegészítés nélkül nem megy ez jól automatikusan (VB-s csávóval együtt már négyen vannak), te meg hogy igen, akkor tényleg hozz már valami forrást rá kérlek!"
Hhh... tudod mit? Igazad van. Szar a Java, hagyjuk.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
"Hhh... tudod mit? Igazad van. Szar a Java, hagyjuk."
Nem, csak ebben a felvetésben pl. igaza volt az általad lesajnált cikknek.
Mondhatnánk, hogy nem lényeges az a felvetés és nincs rá igény, de a fő JVM implementáció körül dolgozó emberek is foglalkoznak a kérdéssel (erre hoztam egy friss cikket). Tehát van akiknek lényeges!
Csak arra akartam felhívni a figyelmed, hogy a nagy hangú fikázás mögött nincs is semmi. Persze tartalmi kritikát nem is írtál - de most hogy kikényszerítettem tartalmi vitát az egyik pontról, kiderült a VB-s srácnak tizenX éve igaza van. Csomó ilyen Java fanboy van, ha kritizálják a JAvat a válaszuk csak annyi, "áááá hülye vagy, nem értesz a Javahoz", aztán végül kiderül h. talán még a kritikát se értik, amikor elmagyarázzák nekik akkor jön a: "jaa de az számomra nem is lényeges" vonal - persze mert korábban még nem is halottak a problémáról nem is értették, hogyan bánthatná őket. Szépen illeszkedsz a típusba. ;)
- A hozzászóláshoz be kell jelentkezni
Évekkel ezelőtt megfogadtam, hogy nem kezdek bele parttalan vitákba, ahol órákon vagy napokon át rágódunk egy végtelenített szálon át nehézkesen szóról-szóra lépve előre (például abban, hogy mi a filozófiai különbség a "nem lehet" és a "are still poor at figuring out" kifejezések között), hogy aztán a végén mindenki azzal hagyja abba, hogy most aztán jó megmondta a másiknak, a közönség már rég nem olvassa, csak átlapozza, aztán másnap, egy hét múlva vagy egy hónap múlva másvalakivel lehet elölről kezdeni az egészet egy másik fórum másik hozzászólásában.
Ezért inkább azt mondom, hogy igazad van, ha (meg)érted, ha nem. Én meg szarok rá, és így sokkal jobb mindenkinek. Ezt a permalinket meg elteszem és legközelebb csak belinkelem, ha hasonló szituációba kerülök.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Ok. Értelek. Lehet, hogy elméletileg nincs lassú nyelv csak rossz fordító (mert gondoljunk pl egy okos emberi fordítóra - az akár a naív bubble sortot is kicserélheti ekvivalens heapsortra, vagy akár egy turing gép progtamot is átírhat ekvivalens eredményt adó regiszteres gépi kódra)
De gyakorlatban meg a vitatott esetben a javahoz nincs az elméleti optimumot megközelítő megoldás : és ez jelentheti azt hogy ez az optimális elméleti fordító mégiscsak túlmutat a jelenlegi képességeinken, és mondjuk más nyelvek ebben jobban állhatnak - ilyen gyakorlati értelmben mondhatjuk hogy egy nyelv lassú
- A hozzászóláshoz be kell jelentkezni
Csakhogy tudjárok van, aki olvassa ;) Abban igazad van, hogy a gyakorlatban nincs ilyen, abban pedig a Gábornak van igaza, hogy lehetséges lenne csak nincsen. De talán azért nincsen, mer tnincs is rá szükség. A JIT compiler finomhangolásával a teljesítménykritikus részeket szépen le lehet fordítani, és innentől az összehasonlítást is a natív kód, és a szignifikáns működésű másik kóddal kell elvégezni. A gyakorlat az, hogy vannak esetek, ahol mérhető gyorsulás van a C++al szemben, és vannak mások, ahol fordítva, az pedig még mindig igaz, hogy az esetek nagy százalékában az emberóra drágább mint a gépóra.
- A hozzászóláshoz be kell jelentkezni
"Lehet köpködni például a GC-t, hogy több memóriát igényel, mintha minden esetben a fejlesztő lekezelné a memória foglalást és felszabadítást, de cserébe csak igen erős ráutaló magatartással tudsz olyan hibát ejteni, mint a Heartbleed vagy a memóriaszivárgás..."
A Heartbleed nem inkább a range checking-en (ill. a hiányán) múlt? Az is optimális sebesség vs. biztonság kérdés, de nem ugyanaz, mint a gc.
- A hozzászóláshoz be kell jelentkezni
Igaz, bár a legtöbb nyelvben a kettő együtt jár, mivel a memory safety-hez bounds checking és automatikus memóriakezelés szükséges (explicit free dangling pointerhez vezethet), az automatikus memóriakezeléshez pedig GC kell.
- A hozzászóláshoz be kell jelentkezni
Egyébként 5.-ös pont High-Level Optimizations, kifejezetten érdekes felvetés.
Amilyen megvalósításról én mondjuk tudok, hogy Haskellben van rá okos pragma: https://www.haskell.org/ghc/docs/7.8.2/html/users_guide/rewrite-rules.h…
- A hozzászóláshoz be kell jelentkezni
"Egyébként 5.-ös pont High-Level Optimizations, kifejezetten érdekes felvetés."
De ez nyelvfüggetlen... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
Én nem érvelni akartam, hanem a véleményeteket kérdeztem.
- A hozzászóláshoz be kell jelentkezni
Erlang. Amilyen bénán kezeli a *NIX signal-okat. Meg úgy tűnik állandóan inkompatibilis módon változik.
- A hozzászóláshoz be kell jelentkezni
Perl, mert lavorba hanyok a regexektol.
- A hozzászóláshoz be kell jelentkezni
Lehet regexp nélkül is élni meg kódolni,csak néha nem érdemes :-P
- A hozzászóláshoz be kell jelentkezni
a regexpet nem a Perl talalta fel, csak azzal epitettek kore elsokent teljes erteku nyelvet :)
- A hozzászóláshoz be kell jelentkezni
Tudom :)
- A hozzászóláshoz be kell jelentkezni
Én a Perl-t nagyon szeretem, bizonyos feladatokat nagyon gyorsan és jól meg lehet benne oldani. Regex-elek benne ezerrel, hiszen ez az egyik oka, amiért használom. De attól még a hideg veríték kiver, akárhányszor el kell olvasnom egy regex-et, akár én írtam, akár nem.
Nyilván GUI-s progikat nem fogok Perlben írni, bár elvileg lehetne. OOP progikat is lehet elvileg Perlben írni, de köszönöm, abból sem kérek. A Perl egy strandpapucs, focipályára stoplis cipőt, erdőbe túracsukát veszek, de a Balcsi partra a strandpapucs a legtutkóbb.
- A hozzászóláshoz be kell jelentkezni
+1
Perlbel lehet akar Qt-t is hasznalni, de en sem vetemednek ilyenre, mindenre a megfelelo eszkozoket kell hasznalni :)
- A hozzászóláshoz be kell jelentkezni
Ha mar regexelni kell, en inkabb Rubyzok, mert van olyan powerful, mint a Perl, viszont a kornyezet sokkal kulturaltabb. Raadasul fel lehet venni mashol is, nem csak a strandon.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
a Ruby erdekes nyelv, regota neki akarok allni foglalkozni vele, de nincs ra idom :(
meg annyira nem nagy a motivacio sem, mert mig Perl kb. mindenhol van, rubynal ez lehet problemasabb
de nagyon tetszik a mogottes 'filozofia', az meg plane hogy meg egy numeric literal is object :D
- A hozzászóláshoz be kell jelentkezni
Sot, meg a null (nil) is az! :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Tudom, hogy sokszor nagyon hatekony a regex. Cserebe az olvashatosaga nem is nulla, hanem negativ. Az meg hagyjan, hogy a sajat regex-eidet nem erted 2 honap mulva, de maset... Szoval akinek ez megy, annak respect, de en nem tartozom ezek koze :D
- A hozzászóláshoz be kell jelentkezni
Mit használsz helyette?
- A hozzászóláshoz be kell jelentkezni
Nem nagyon szokott szuksegem lenni pattern-intenziv (ez ertelmes kifejezes egyaltalan?) dolgokra, ugyhogy a beepitett string-kezelo fuggvenyek elegek szoktak lenni.
- A hozzászóláshoz be kell jelentkezni
Nekem úgy tűnik, egy regex speciális karaktert gyakran >1 string-kezelő függvénnyé tudsz kifejteni. Így már nem biztos, hogy azt gyorsabb megérteni.
- A hozzászóláshoz be kell jelentkezni
Parsec
- A hozzászóláshoz be kell jelentkezni
Nalunk (reszben az en harcaimnak koszonhetoen) konvencionalisan meg van kotve hogy regexpet nagyon erosen kell kommentelni es peldakat is irni kell kore, hogy mit mive miert alakit (igy legalabb azt tudjuk, hogy mit kene annak a regex-el teli sornak csinalnia, mert sokszor az sem volt vilagos). Igy azert szerintem meg eppen van ertelme, de az ettol eltero modon hasznalt regexpekrol ugyanaz a velemenyunk Viktor ur. :)
- A hozzászóláshoz be kell jelentkezni
ez igy teljesen korrekt
en ennel azert lustabb szoktam lenni, rendszerint 2-3 szoban leirom hogy mire valo, aztan kesz (igaz, hogy agyonbonyolitott regexpeket nem szoktam irni, inkabb szetbontom ha lehet, ugy sokkal konnyebben karbantarthato)
- A hozzászóláshoz be kell jelentkezni
lájk
- A hozzászóláshoz be kell jelentkezni
Erre van egy válaszom, amit szerintem senki nem fog szeretni.
A unix-szerű rendszereken általában igaz, hogy kétféleképpen tudsz megoldani dolgokat:
- kevéssé hatékony, de jól átlátható elemi műveletekkel
- hatékony kriszkraszokkal.
Egy nagyon egyszerű példa:
cat patterns.txt |grep -v ^# |while read pattern
do
cat text.txt |grep $pattern
done |sort |uniq
vs.
grep -f <(grep -v ^# patterns.txt) text.txt |sort -u
Ha olvasni akarod őket, akkor így lehet olvasni őket. Első:
- kilistázom soronként a patterneket
- kiszedem közülük a kommenteket, csak a nem-kommentezett patternekkel foglalkozom tovább
- aztán mindegyik patternt egyesével megpróbálom megtalálni a szövegben
- a talált sorokat rendezem
- és végül mindegyik találatot csak egyszer kérem.
Második:
- WTF???
Cserébe az első O(n*m) futásidejű (lassú), a második meg O(m) futásidejű (gyorsabb).
Félreértés ne essék: nem azt mondom, hogy az első vagy a második helyesebb megoldása a problémának. Csak azt hiányolom, hogy az általam ismert rendszergazdák többsége nem próbálja tudatosan menedzselni ezt az olvashatóság vs. hatékonyság dolgot, hanem egyértelműen a hatékonyságot részesíti előnyben, gondolkodás nélkül. Van, amikor ez kell, de van, amikor összességében jobb lenne a másik...
- A hozzászóláshoz be kell jelentkezni
A helyes megoldás:
# Search for noncomment (not # line) patterns listed in patterns.txt and search for them
# one by one in text.txt and list matching lines alphabetically (and uniquely)
grep -f <(grep -v ^# patterns.txt) text.txt |sort -u
- A hozzászóláshoz be kell jelentkezni
Szerintem ez sem "A" helyes megoldása a problémának - a helyes megoldás, hogy a megfelelő esetre a három közül a megfelelő megoldást választjuk. (Ez a megoldás módosíthatóság tekintetében pl. rosszabb, mint az első, még a kommenttel együtt is.)
- A hozzászóláshoz be kell jelentkezni
Gondolom, $() akart lenni.
Ez a megoldás szerintem semmivel nem kevésbé olvasható, mint a ciklusos, ha az ember fejben tartja, az opciókat (-v, -f). Talán leginkább a ritkán használt opciókat érdemes kommentálni.
- A hozzászóláshoz be kell jelentkezni
Csak kopiztam a parentet, nem teszteltem, elhittem hirtelen. :)
- A hozzászóláshoz be kell jelentkezni
Ne csak hirtelen hidd el, nem kell oda a $, ha jól emlékszem.
- A hozzászóláshoz be kell jelentkezni
Valóban, <-vel egybeírva a zárójelet működik. Ezt nem ismertem.
- A hozzászóláshoz be kell jelentkezni
Látjátok, hogy mennyire nem olvasható? Nem is sikerült elolvasni, hogy mit írtam... :/ (Ez is cél volt, direkt akartam belerakni valami nem megszokott struktúrát, a <() pont ilyen.)
- A hozzászóláshoz be kell jelentkezni
De sikerült, csak sokunk számára ismeretlen ez a szerkezet, míg a $( ... ) a'la ` ... ` (backtick) ismerős.
Én is csak onnan tudom, hogy nem kell a $, hogy kipróbáltam. :)
- A hozzászóláshoz be kell jelentkezni
Na igen, viszont nem lett volna sokkal hosszabb a $() se (vagy a még ismertebb ``).
- A hozzászóláshoz be kell jelentkezni
Csak az mást csinál.
- A hozzászóláshoz be kell jelentkezni
Jogos, úgy a -f nem kéne. (És a $() idézőjelbe.)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Olvasgatva a hozzászólásokat, bennem felmerült a ruby is, mint egyike a "bottom ten"-nek. :)
Miért? Az általam látott doksik miatt. Valahol olvastam, hogy a fejlesztője szerint a forráskód a legjobb dokumentáció (hogy ez UL vagy tényleg mondott ilyet, azt nem tudom) és a kb. két éve nézegetett leírások finoman szólva hiányosak voltak.
Hogy azóta változtak-e a dolgok vagy sem, esetleg csak én kerestem rossz helyen... hát ezt nem tudom.
- A hozzászóláshoz be kell jelentkezni
Valóban hagy kívánni való maga után a doksi, de azért folyamatosan javul észrevehetően szerintem. Viszont ami plusz, hogy mindig sok példa kódot tartalmaz. Ez még MS doksiknál sem volt mindig így emlékeim szerint.
- A hozzászóláshoz be kell jelentkezni
Ha jól látom ez egy flame generátor poszt, úgyhogy beszállok. JavaScript fikkantás még nincsen :-).
Nekem az benne a halálom, hogy olyan matematikai konstrukció-szerű az alapnyelv (minden objektum egy map), mintha nem programozó tervezte volna. Nincsen semmi láthatóság, jogosultság, névterek vagy bármi ami segítené a komponensek együttműködését. Ha nem írom ki hogy var, akkor egy globálist vágok felül, ami csak debuggolás árán derül ki. Semmi gyakorlati megfontolást nem látni a tervezésében.
Ha háború lenne, akkor küldenék az ellenségnek egy beépített ügynököt, hogy terjessze el az iparukban. Ezzel évekre vissza lehetne vetni a fejlődést.
Nem a nyelv, hanem a standard könyvtárak hibája, de alig látszik rajta valami nevezéktani logika. Meg az objektum-orientáltság is teljesen esetleges. De legalább van 1000 féle könyvtár, ami egy rétegbe beburkolja az alapmechanizmusokat, hogy kicsit értelmesebb és lassabb legyen.
Külön öröm látni, hogy mekkora erőfeszítéseket tesz az iparág a JavaScript interpreterek optimalizálásába - ami fából vaskarika a nyelv alapvető szerkezete miatt :-). Amit a JS-be beleöltek a programozók, azzal az erővel 10 értelmes programnyelvet is be lehetett volna integrálni a böngészőbe.
Korunk kudarcra determináltságának csimborasszója, hogy egyesek megpróbálták szerver-oldalon is bevetni. Ez azért nagyon jó, mert így a káosz kiterjedése nem kell, hogy megálljon a kliensen, és a sötét erők még nagyobb hatalomra tehetnek szert.
Az egyetlen előnye az, hogy kizárja a valódi threadinget, és így legalább szálkezelési hibákat nem lehet csinálni benne.
- A hozzászóláshoz be kell jelentkezni
Ott van a TypeScript, az egészen szerethetővé varázsolja az egészet.
- A hozzászóláshoz be kell jelentkezni
Üdítő volt olvasni, köszi! :)
Vicces különben hogy milyenek vagyunk. Gondolom a node.js meg hasonlók is azért születtek, mert a fejlesztő beleölt időt a JS-be, és persze kényelmesebb a meglévő tudást tovább bővíteni mint egy radikálisan új irányt felvenni. Illetve a másik amely sok helyen fellelhető, hogy ugye mindig kifizetődőbb az e-pénisz eredmény, ha új dolgot hoz létre, mintha beállna sokadiknak a sorba egy meglévő projekt mögé.
Ilyenek vagyunk, ez motivál és fékez minket. Felkapaszkodunk a tudáshoz, majd hagyjanak minket már békén, tanultunk már eleget. És ez az örökös oda vissza szül érdekes dolgokat.
- A hozzászóláshoz be kell jelentkezni
Számomra megdöbbentő a jelenlegi sorrend igazából:
1. Java.
2. PHP
3. Funkcionális nyelvek
Komolyan, a Javával sok baj van, nade rosszabb mint a PHP!? Komolyan? Leesett az állam.
A funkcionális nyelvek meg aztán végképp nem értem, kinek ártottak. Ha valakinek nem inge, ne használja, de ettől még csak a vak nem látja, hogy érdemes ötleteket átvenni onnan és bármilyen nyelvben használni.
- A hozzászóláshoz be kell jelentkezni
"A funkcionális nyelvek meg aztán végképp nem értem, kinek ártottak."
Csupán annyival, hogy egyes funkcprogosok szeretik a szent grálnak beállítani és minden más - jellemzően OO - nyelveket leírni a francba. (Aztán kiderül, hogy életükben nem készítettek egy szál (G)UI-t.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Ööö, megírsz pár bajt? Magánban is jöhet.
- A hozzászóláshoz be kell jelentkezni
Hát igazából nem akarok most belemenni Java elemezgetésébe, lehet szeretni, lehet nem szeretni, nekem annyira speciel nem áll kézre, de úgy azért alapvetően "egész jónak" tartom.
Nem így a php -vel. Azt egyáltalán nem értem, hogy lehet szeretni, vagy jobban szeretni mint a Java-t. Ez lett volna a mondandóm lényege.
- A hozzászóláshoz be kell jelentkezni
Mármint miért nem kedvelem a PHP-t? Itt van egy egész jó összefoglalás:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
És itt egy igazán vicces dolog:
- A hozzászóláshoz be kell jelentkezni
+1
A fenti hozzászólásból azért sejteni, hogy nem a funkcionális nyelvekkel van a baj, hanem inkább valamilyen komplexusból fakadhat az ellenszenv. A fenti hozzászólásból az is látszik, hogy sokan azt hiszik, hogy vagy OO vagy FP, mintha ezek kizárnák egymást.
Pár példa, hogy mi lehet a háttérben:
- A "funkcprogosok szeretik a szent grálnak beállítani és minden más - jellemzően OO - nyelveket leírni a francba", ezért utálom a funkcionális nyelveket!
- Csak száraz algoritmusokat lehet vele kódolni (pl. fibonacci), GUI-ra teljes alkalmatlan, vesszen!
- Hú, ez nagyon bonyolult, tán egy kis matematika is kell hozzá, le vele!
- Nem tudom mi az, de sok rosszat hallottam róla, pusztuljon!
- Már a 60-as, 70-es években is használták, így nagyon elavult lehet, ne is lássak még csak szavazást se róla!
- FP-ben csak olvashatatlan és érthetetlen dolgokat lehet csinálni, miért nem törli el már végre valaki ezeket?
- A hozzászóláshoz be kell jelentkezni
+1
Én mondjuk az állítólag öntökönlövésvilágbajnok C++ helyét sem értem.
Válogatott egy közönség ez. :)
A funkcionálisakkal szembeni sztereotípiák meg talán enyhülni fognak, ha felnő egy "harmadik generációs" lisp, meg "első/második generációs" haskell nemzedék. :)
- A hozzászóláshoz be kell jelentkezni
Még mindig kicsit össze vagyok zavarodva a funkcionális paradigmától a saját munkakörömben. Milyen előnyt ad egy átlagos webapp fejlesztéséhez a funkcionális szemlélet, amit mondjuk nem kényszerít ki pl. a Clean Code?
- A hozzászóláshoz be kell jelentkezni
Nem tudom mi van a CC-ben.
Ennek fényében a funkcionális szemlélet hozzájárul a következők javításához/megoldásához: skálázhatóság, újrafelhasználhatóság, biztonság, tesztelhetőség, kevesebb programhiba, átláthatóbb, jobban strukturált kód.
- A hozzászóláshoz be kell jelentkezni
+1
Annyival egészíteném ki, hogy a CC az FP-nél is alapvető követelmény.
A CC ilyesmi:
- Minél több kis függvény (osztály), egy nagy helyett.
- Minél kevesebb paraméter egy függvénynél (metódusnál)
- DRY (Ne ismételd magad)
- Jól érthető elnevezések
- Egy függvény (metódus) egy dolgot végezzen
- A hozzászóláshoz be kell jelentkezni
Az SRP nem függvényre/metódusra vonatkozik, hanem az osztályokra. Igaz, ez eredendően OOP téma.
- A hozzászóláshoz be kell jelentkezni
Szerintem osztályokra is és függvényre/metódusra is, de ezen nem veszünk össze.
- A hozzászóláshoz be kell jelentkezni
Úgy értem: nagyobb egységekre találták ki, a kisebb egységre ezért már alapértelmezett.
- A hozzászóláshoz be kell jelentkezni
A megfejtés nyilvánvalóan az, hogy a szavazás nem a nyelvek minőségéről(rosszaságáról) szól, hanem a nyelvekkel kapcsolatos (un)szimpátiáról. Nem autós hasonlattal: vannak itt a hup-un néhányan, akik számomra unszimpatikusak, pedig nagy valószínűséggel igen jó szakemberek/programozók.
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
antipátia, antipatikus
- A hozzászóláshoz be kell jelentkezni
Ellengyógyszerész. :)
- A hozzászóláshoz be kell jelentkezni
legyszi ne irjal mar le olyat hogy "unszimpatikus"...
MOD: latom megeloztek :)
- A hozzászóláshoz be kell jelentkezni
Miután a kedves antipatikus Hevi beszólt, sajnos ez már örökre így marad :)
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Azt kell megjegyezni, hogy Antal foglalkozását tekintve gyógyszerész.
- A hozzászóláshoz be kell jelentkezni
Nem könnyű ezzel megbarátkozni, de azt hiszem menni fog :)
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
mi a baj a szokepzessel?
- A hozzászóláshoz be kell jelentkezni
Tképp semmi: http://www.gyakorikerdesek.hu/tudomanyok__helyesiras__505981-unszimpati…
Bár nem tartom hiteles forrásnak az oldalt, amit az első pár hozzászólásban leírtak, az legalábbis érdekes.
- A hozzászóláshoz be kell jelentkezni
Pedig németben teljesen oké a szó.
- A hozzászóláshoz be kell jelentkezni
Értem én, de annyira mégsem. Pl. a python számomra nem szimpatikus, de elhiszem hogy lehet benne jó, áttekinthető kódot írni, elismerem hogy "jó szakember" az analógiával élve.
A php minden elképzelhető szempontból egyszerűen rossz.
- A hozzászóláshoz be kell jelentkezni
Én spec a funkcionálisokra szavaztam, meg is magyarázom, ha gondolod. Nem vagyok programozó, leginkább rendszertervezek meg sysadminkodok, ha kódot kell írni az leginkább valami párszáz sor perl ami a wd40-szigszalag szerepét tölti be valami olyan részen, amire a rendes programozó urak nem gondoltak (vagy nem jól, vagy "jól" nagyon drága lett volna). Meg persze tanultam azért programozni, csak mondjuk c-t, javat, ilyesmit rég nem kellett magamnak írni.
De ha szembe jön valami, amibe valamiért bele kell nézni, modjuk hogy az ember kitalálja mi a baja, akkor egy random funkcionális / oop nyelven írt izét általában megértek komolyabb erőfeszítés nélkül, látom kb mit csinál, tudok szólni, hogy hol néz ki marhaságnak, esetleg meg tudom patkolni magam. A haskellre mondjuk meg nézek mint borjú az újkapura, hogy ez mi a tököm akar lenni. Na, nekem ezért legkevésbé kedves :)
- A hozzászóláshoz be kell jelentkezni
A 2013-as "Kedvenc programnyelv" HOVD-n első lett a PHP, második a java. Itt a második a php, első a java.
Az első két helyezett ugyanaz a kedvencben és az antikedvencben is, érdekes. És persze felveti azt a kérdést is, hogy a HOVD-n ez a szavazás mennyire mutatja helyesen egy nyelv kedveltségét a HUP olvasói között.
- A hozzászóláshoz be kell jelentkezni
Mindenféle szavazási rendszer mást mutat meg. Ezek szerint számodra valamilyen Concordet módszer lenne beszédes (pl. Schulze method) ott valószínűleg olyanok nyernének amik kevésbbé megosztók.
- A hozzászóláshoz be kell jelentkezni
Fene tudja. Esetleg egy egyszerű rangsorolás, mondjuk az első háromra kellene szavazni, és kapnának 3-2-1 pontokat. Szerintem érdekes lenne így is a szavazás, mert ebből (megfelelő lekérdezéssel) a klasszikus HOVD eredménye is kijönne ("ki kapta a legtöbb három pontot").
Hasonlóan szavaztattam az osztályomat még novemberben, hogy a szalag milyen színű legyen - ami lett végül, kevesen mondták első helyen, de mindenkinek tetszett, sőt, még a párhuzamos osztályfőnökök szerint is talán a legjobb lett :)
- A hozzászóláshoz be kell jelentkezni
Szerintem itt inkább arról lehet szó, hogy a többség ezt a két nyelvet ismeri a megfelelő mélységében, ezért ezekről tud véleményt mondani. Ezért szerintem az is egy jó módszer lenne, ha minden nyelvről külön lehetne véleményt nyilvánítani, elég lenne a tetszik/nem tetszik/nem ismerem opciók közül választani. Csakhogy ez 10 nyelv esetén 10 szavazás vagy 10^3 szavazati opció lenne...
- A hozzászóláshoz be kell jelentkezni
Egy szavazásban is lehetne (bár nem tudom, mennyire van drupal-hoz lehetőség), mindegyikre meg lehetne jelölni, a tetszik/nem tetszik/nem ismerem lehetőséget. Persze ezzel meg az az információ veszik el, hogy melyik tetszik a legjobban.
Szerk.: nem 3^10 szavazási opció? :)
- A hozzászóláshoz be kell jelentkezni
De.
--
blogom
- A hozzászóláshoz be kell jelentkezni
+1 :)
- A hozzászóláshoz be kell jelentkezni
Igen talán ez a konszenzust leginkább támogató módszer, jól döntöttél ha ez volt a célod:
http://en.wikipedia.org/w/index.php?title=Borda_count#As_a_consensual_m…
- A hozzászóláshoz be kell jelentkezni
Jaja. A végeredményt ismerve is úgy gondolom, jó, hogy nem szimpla többséges szavazósdit játszottunk.
- A hozzászóláshoz be kell jelentkezni
Twitter-en lévő álláshirdetések által generált sorrend az elmúlt egy évre: http://www.sitepoint.com/best-programming-language-learn-2014/
Lentebb van olyan lista is, mely nyelvet mennyien szerették volna megtanulni az egyik weboldal segítségével.
- A hozzászóláshoz be kell jelentkezni
Hat, a C betuvel kezdodo nyelveknek van meg hova fejlodniuk... :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni