Használnál kínai Integrált fejlesztői környezetet? (kérdés részletes leírása az első hozzászólásban)

Programozás

Igen
10% (17 szavazat)
Nem
53% (89 szavazat)
Csak angolra fordított forkját, még akkor is ha le van maradva a kínai eredeti kiadás mögött
17% (29 szavazat)
Csak a válaszok érdekelnek
20% (34 szavazat)
Összes szavazat: 169

( Ritter | 2018. 05. 08., k – 13:01 )

TFH Kínában fejlesztenek egy minden eddiginél hatékonyabb Integrált fejlesztői környezet, Javanál és C#-nál is jobb/fejlettebb programnyelvvel. De minden kínai benne még a programnyelv elemei is. Viszont roppant hatékonyan lehet vele dolgozni, legalább fele annyi idő alatt el lehet készülni egy projekttel mint például Java-ban fejlesztve.
Megtanulnád ezért kínai nyelvet?

Ott van a hiba, hogy mindenkinek más a hatékonyabb. Lehet, hogy egy kínainak hatékonyabb a kínai nyelvre épülő programnyelvet használnia, de ha te nem beszélsz kínaiul akkor neked egyáltalán nem lesz hatékony. Ha csak ezért kezdesz kínaiul tanulni, amíg fel nem hozod magad arra a szintre amin angolból vagy, addig egy angolra épülő nyelvvel hatékonyabb leszel. Ehhez hozzájön, hogy a kódot embereknek írjuk elsősorban, vagyis akkor lesz csak igazán hatékony ebben a nyelvben dolgozni, ha mindenki legalább olyan szinten beszél kínaiul, mint angolul.

Ha szeretnél tehetsz egy próbát, itt egy szép hosszú lista.

De ugyanez a szabály igaz a tradicionális programnyelvekre is. Hiába vagy te hatékonyabb Pythonban, ha a projekten mindenki más Java programozó.

Maga a kínai nyelv nem egy nagy wasistdas, de írni ők se szeretik (ezért látod az összes messengerben olyan hangsúlyosan a hangüzenet küldése funkciót), szóval nem teljesen látom, hogy lennék roppant hatékony kínai nyelven.

Igaz, a vim-et se tanultam meg soha rendesen, pedig 15 évet fejlesztettem benne, de pl pluginezni sose volt energiám.

( covix v | 2018. 05. 11., p – 21:16 )

Flame on

gondolom egy “házikóval” ki tud fejezni egy komplett ciklust, nem csoda hogy gyorsabban lehet vele haladni :D

KoviX

( asch v | 2018. 05. 11., p – 21:30 )

Persze. Ha tényleg annyira király lenne, akkor megtanulnék érte akár kínaiul is.

( sigellef | 2018. 05. 11., p – 23:04 )

Attól, hogy nem sikerült megtanulnom angolul, elég jól tudok programnyelveket tanulni. Ha a kínaival is így működne, akkor miért ne?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( hajbazer v | 2018. 05. 11., p – 23:47 )

Ha összehoznak egy olyat, ami van olyan gyors és erőforrástakarékos, mint a Dev-Cpp, akkor igen. Remélem, hamarosan lesz valami, mert az Eclipse, a NetBeans, meg a JetBrains IntelliJ bloatware-ei egymásra licitálnak CPU- és memóriazabálásban, valamint a totál feleslegesen több giga merevlemez foglalásban. Éppen itt lenne már az ideje, hogy utóbbiak örökre eltűnjenek a süllyesztőbe.

A mai napig tele vagyunk 32-bites Linuxokkal, a Windows 7 és a 10 is támogatott 32-biten. Értem én, hogy nem látsz ki a fősodorból, de attól még nem kéne ilyen következtetéseket és egyetemes igazságként beállítani. Ha pedig egy alkalmazást multi-platformra írsz, azt könnyedén build-eled 32-bitre, lévén, hogy az ehhez szükséges eszközök jócskán rendelkezésre állnak.

Pedig le kellett volna már húzni a 32 bitet a retyón. Az oka, hogy még mindig kerülgetjük, mint egy gőzölgő x@rt, mert a fejlesztők lusták 64 bites binárisokat kiadni (és emiatt nem csak a szoftver marad 32 bites, de a 32 bites függőségeket is külön fel kell rakni, meg a memóriába is betölteni a 64 bitesek mellé, ami bloatságot okoz, ahogy mondanád). Plusz egy csomó idióta összevett egészen a legutóbbi időkig ilyen 1-2 giga RAM-os gépeket, amelyeken ráforrasztott a memória (kezét vágnám le az ilyennek) vagy a hulladék chipset nem támogat többet, így meg hiába a 64 bites CPU, 2 GB RAM és azalatt meg a memóriafogyasztás miatt a 32 bites megoldásokat szokták kényszerhelyzetben bevetni.

Linuxon mindig is lesz támogatva a 32 bit, ha a disztrók dobják is a támogatását lemezkép és csomagszinten, ott olyan architektúrára fordítod le a kódot, amilyenre akarod. A mai napig lehet 386-osra meg 486-osra fordítani a kódot, mikor a disztrók már a 686-os támogatást is dobják el, van, aki csak lemezkép szintjén (Ubuntu), van, amelyik csomagok szintjén is (Arch Linux). Viszont lesz egy pont, ahonnan majd a kernel nem fogja támogatni, akkor meg bőghetnek a Harminckétbit von i686 Henrikek, hogy az MS magára hagyott 400 millió embert, brühühű, pedig 3-3,8 GB RAM + 2 GB user/application space ought to be enough for anybody. Ja. tudom PAE, mert az megoldott valaha bármit is, ha a fekáliát pofoztuk az érdemi fejlődésre törekedés helyett.

Akinek meg 32 bites legacy szutyok kell, az bezárja emulátorba, virtuális gépbe.

No keyboard detected... Press F1 to run the SETUP

... hogy egy processzor 64 vagy 32 bites, annak nem sok köze van ahoz, hogy a BIOS/OS/Felhasználóiprogram hogy oldja meg a dátumkezelést. Mondjuk röhely, hogy pont a dátumkezelésen kell biteket spórolni, mikor már egy bool is 64 bitet foglal :D

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

elvileg 8 bit is sok egy bool-nak. Mondjuk, ha a legkisebb címezhető egység 8 bit, akkor mindenképp ez az optimális.
A C#-nál úgy tudom 16 bit. Javítsatok ki, ha tévedek.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Szerintem elsősorban nem biteket spórolnak, hanem dátumaritmetikánál időt. (Adj össze két 64 bites előjeles egészt 32, illetve 64 bites CPU-val...)
A spórolás az az Y2K esetén volt irgalmatlanul észlelhető - az egyik gond ott ugyanis a két jegyen tárolt évszámokból adódott, persze a szökőév kezelése sem volt mindenütt rendben, de a röviden tárolt év is elég sok sz0pórollert hozott az érintetteknek...

A Cobol programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.
When he asked why he was unfrozen, he was told: "It's the year 9999 - and you know Cobol".
-stackoverflow

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

Egyszer, ha nyerek a lottón, szervezek egy nyilvános vitát az 5 legnagyobb kereskedelmi bank rendszermérnökei és az 5 legaktívabb, legfejlődésmániásabb, legidealistább fősodratú mérnök úr között. A moderátor én leszek, vagy ha nem nagyon kell moderáció behívjuk trey-t. :D

Kíváncsi leszek, hogyan védik majd a fejlődési mantrát a C#-on, Java-n, Scala-n, Python-on szocializálódott kényelmeskedők a régi, ósdi, ótvar, elavult (de még mindig megbízhatóan működő és sokkal kevesebb bloat-tal rendelkező) COBOL-lal szemben.

A bankok a legjobb példái annak, hogy azoknak a rendszereknek a koncepciójába, melyeknél elsődleges követelmény a stabilitás és az integritás, nem fér bele a folyamatos fejlesztgetés, frissítgetés idealizmusa, mint ahogy azt próbálják egyesek konepcionálisan vagy kompromisszumcsapdákkal erőltetni. Sokkal nagyobb kockázat (= sokkal több pénz) egy új rendszer adoptálása, mint a régi, jól bevált megtartása. Persze, nem csoda, ha ez csak bankéknál van kimondva, ha a többiek szemét kiszúrják a marketinggel és a "fejlődj, különben lemaradsz, meg nem leszel biztonságban" hazugsággyárral.

Pedig le kellett volna már húzni a 32 bitet a retyón.

Nem kellett volna lehúzni. Nagyon sok 32-bites gép van és nagyon sok mindenre jók. Az, hogy van 64-bit, nem azt jelenti, hogy át is kell rá állni, amennyiben a 32-bit is teljesíti ugyanazokat az elvárásokat. Ráadásul, 32-bitre jóval kiforrottabb kódbázis áll rendelkezésre mind library-kból, mind fordítókból, sokkal több tapasztalat van mögötte, ezáltal definíció szerint stabilabb programok készíthetőek.

mert a fejlesztők lusták 64 bites binárisokat kiadni

Na, most akkor mégis lusták azok a fejlesztők? :P

Plusz egy csomó idióta összevett egészen a legutóbbi időkig ilyen 1-2 giga RAM-os gépeket, amelyeken ráforrasztott a memória (kezét vágnám le az ilyennek) vagy a hulladék chipset nem támogat többet

Amik bőven jók lennének mindenféle átlagfelhasználásra, ha szoftverfejlesztőék nem bloatware-eket írnának, hanem mondjuk egy Windows 98, 2000, XP ökoszisztémájának erőforrásigényével beérnék a programok. Nagyjából ugyanarra lehetne használni, mint amire most a Media Markt-ból utánad dobott csililaptopot, leszámítva néhány extrém igényt (pl. 4K videólejátszás).

Viszont lesz egy pont, ahonnan majd a kernel nem fogja támogatni, akkor meg bőghetnek a Harminckétbit von i686 Henrikek

Hasonlóképpen igaz itt is, hogy vissza lehet bele húzni olyan patch-eket, amik támogatják a 32-bitet. Persze, ez az álomvilágod nem mostanában fog eljönni. A 32-bites processzorok jó sokáig támogatva lesznek még, megjegyzem, nagyon helyesen.

Akinek meg 32 bites legacy szutyok kell, az bezárja emulátorba, virtuális gépbe.

32-biten maradni még mindig fenntarthatóbb. Kevesebb memória kell a programoknak, kevesebb új gépet kell venni.

Ajanlom, mert latszik, hogy meg mindig nem erted:
https://www.youtube.com/watch?v=zkPGfTEZ_r4

Lehet, hogy a fejleszto lusta, lehet, hogy nem az. Ha lusta, ha nem, fizetesert dolgozik. Ha az o ideje dragabb, mint HW-rel megoldani a problemat, akkor az utobbi a jobb megoldas. Persze azt is bele kell szamolni, hogy adott esetben sok felhasznalo van - de sok fejleszo is lehet, es sok sok kod gyult ossze az evek alatt.

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

Egy olyan világrendben, ahol bizonyos ember munkája nagyságrendekkel többet ér, mint másé, ráadásul ez még a földrajzi elhelyezkedéstől függ, nem szabad és nem is etikus mindent pénzben mérni. Ha a hardver legyártásához használt emberi munkaerő igazságosan lenne megfizetve (közel annyit keresne minden, benne szereplő emberi tényező, mint a bloated szoftvert tákoló fősodratú mérnök úr), akkor nem lehetne a hardveres megoldás olcsóbb. Már azzal, hogy a hardvereket nem a munkaerőt szándékosan olcsón tartó és azt kizsigerelő kommunista diktatúrákban és egyéb más lemaradott országokban gyártanánk, olcsóbb lenne szoftveresen optimalizálni. Ahogy egyébként a józan ész diktálná is.

Arról pedig még nem is beszéltünk, mi van ha adott szoftveres megoldás nem belsős vagy szűk körű használatra készül, hanem másnap százmilliók használják majd. Ők is vegyenek többszázmillió új hardvert az emelkedett szoftveres igények miatt, igaz? Csak azért, mert a szoftverfejlesztő "fizetésért dolgozik". Csakhogy, amennyi pluszba ez a felhasználóknak kerül, annyiból számtalanszor ki lehetne fizetni az optimalizációt. Nem érzel aránytalanságot abban, hogy néhány száz fejlesztő lustálkodása, kényelmeskedése, néhány tíz menedzser üzleti idealizmusa milliószoros hátrányokat okoz a fogadó oldalon?

Ha szerinted ez az "értékelosztás" így igazságtalan, akkor el lehet menni:
- pici pénzért fejleszteni szoftvert,
- ugyanolyan sebességgel tartva persze a mérföldköveket, mintha nem lenne optimalizálva

De ahogy látom, jobban szeretsz bennragadni ebben a képmutató szerepben, hogy csak a pálya széléről megmondod, hogy hogy kellene, evvel is tovább erősítve a 11 millió magyar szövetségi kapitány országa prekoncepciót.

Az meg, hogy aktívan nem járulsz hozzá a fejlődés általad helyesnek vélt irányához, csak folyamatosan itt beugatsz mindenkinek, az meg már a más f..szával verni a csalánt minősített esete.

Nem neked, cserébe mindenki másnak szóló kérdés:
Kérdezném itt a hup többi olvasóját, hogy csak nekem veri ki a biztosítékot ennek az embernek, ez a gyomorforgató képmutatása és megmondóemberkedése gyakorlati tapasztalat és hozzáértés nélkül, ahogy itt folyamatosan osztja az észt?
Természetesen a troll érvek nélküli stílusa csak tetézi a helyzetet :'(

Nem kell sehova se elmennem.

Kell védővámokat és tilalmakat bevezetni a Kínából érkező olcsó elektronikai cikkekre, és előírni, hogy az EU-n belül eladott számítógépeket az EU-n belül kell gyártani.

Máris értékesebbek lesznek a hardverek és háromszor meggondolják idealistáék, hol lustálkodtassák a fejlesztőiket.

Csak úgy nagyjából, megközelítőleg van-e sejtésed arról, hogy mennyi processzort/memóriát/nagy bonyolultságú integrált áramkört gyártó kapacitással rendelkezik Európa? Na ha a pécék, mobilok, autóelektronika, ipari automaitzálás, meg úgy mindenestől az elektronikai berendezések forgalma erre a gyártókapacitásra épülne... Mondjuk úgy, nem igazán lenne mit eladni. Ez nagyjából azonnal versenyképtelenné tenné az európai ipart, de sebaj, hájblézertámogatta XP-vel meg elektronikai hulladékból kukázott pécékkel is lehet nagy dolgokat alkotni... Olyan nagyokat, mint amilyet a szomszéd falu bikája alkotott pottyanátssal egy jól sikerült legelőlátogatás végén...

Majd hajbazer az XP-n megtervezi az új chipeket, a hosszú élettartamú lámpa (amit szintén ő gyártott) fénye mellett egykristályt húz. A konyhapulton szeleteli, így egyből biztosított lesz a szennyezés is… A végén pedig összeszereli a Hajbazer PC-t, ami természetesen képes lesz az XP-t döccenés nélkül futtatni.

Az oroszok már kb. 20 éve dolgoznak egy ilyen terven. Bár nekik még az XP sem kell. :-) Még a kínaiaknak sem sikerült kiváltani a x86-os architektúrát, pedig nekik ehhez megvan minden eszközük.

Volt mar hasonlo, a vasfuggony idejen nem lehetett/nehez volt szamitogepeket behozni kintrol (mondjuk akkor a kelethez tartoztunk, Kina meg pont velunk volt). Maradjunk annyiban, hogy ha ezt meglepnek, az EU lenullazna magat, mi meg remelhetoleg kilepnenk.

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

Ezt az angol ugy hivja, hogy: "whishful thinking". Egy ilyen lepesnek (ami kimeriti a kereskedelmi haduzenet fogalmat) belathatatlan kovetkezmenyei lennenek.

Amugy nem vagyok meggyozodve arrol, hogy a kinaiaknak tenyleg olyan rosz ezeknel a HW gyaraknal dolgozani mint ahogy beallitod ("kinai rabszolgak").
Nem astam magam bele a temaba de tudtommal az iparosodottabb teruleteken a munkaberek es az eletszinvonal rohamosan emelkedik, annyira, hogy egyes cegek mar meg keletebbre koltoznek (Vietnam).

Ami szereny velemenyem szerint esetleg valtoztatna a helyzeten az a kornyezetben tett karok megfizettetese es/vagy a karok kotelezo jelleggel valo csokkentese, koltsegeket nem kimelve.
Jelenleg ezt az egyaltalan nem elhanyagolhato "koltseget" senki nem veszi figyelembe de meg vagyok gyozodve, hogy ha ez be lenne epitve az arba nagyon mas lenne a helyzet.
Szerintem lassan rajon Kina is, hogy ezt nem lehet a vegtelensegig csinalni mert megmergezik magukat (azt nyilvan leszarjak, hogy masokkal mi van), lasd a villanyauto kvota.
--
:wq

Ez az ára annak, hogy a projektben lévő összes osztály összes metódusát beindexeli (és azt az esetleg több száz jar függőséget is),
így frankón működik a kódkiegészítés, javadoc-kal, meg minden varázslattal együtt. Meg van olyan funkció, hogy végigkeresi a projekt/
workspace-ben az összes olyan helyet, ami egy adott osztálynévre, metódusra, változóra, stb. hivatkozik. Na, ezt fizetjük meg RAM-ban.
(amikor 8GB ram mondjuk egy napi/fél napi fizetés, addig meg nem igazán érdekel...)

így frankón működik a kódkiegészítés, javadoc-kal, meg minden varázslattal együtt. Meg van olyan funkció, hogy végigkeresi a projekt/
workspace-ben az összes olyan helyet, ami egy adott osztálynévre, metódusra, változóra, stb. hivatkozik. Na, ezt fizetjük meg RAM-ban.

Ennél szélsőségesebb idealizmust nem is írhattál volna. Egy Dev-Cpp, és egy Visual Studio 2005 is megcsinálja neked ugyanezeket, töredék RAM-ból úgy, hogy a Java-specifikus javadoc kivételével minden van. Elmondom mit fizetsz meg. Szoftverfejlesztőék lustaságát, kényelmeskedését, menedzserék üzleti idealizmusát, Java = multi-platform mániáját, és úgyszintén szoftverfejlesztőék azon nemtörődömségét, hogy magasról szarnak azokra, akik a nálukénál gyengébb gépet használnak, mivel menedzserék alájuk tolták a legújabb csiligépet.

( Raynes v | 2018. 05. 12., szo – 05:48 )

Nem használnék ilyet. Nem a kínaiakkal van bajom, de olyan prognyelvet, fejlesztőkörnyezetet nem használnék, ami nem érhető el angolul. Két ok miatt is. Egyrészt ha nem tud angolul, akkor nem fog elterjedni, nem lesz mellé elég támogatás, és nem érdemes rá építeni. Másrészt meg komolytalan, szakmaiatlan, ha nem lehet angolra átállítani úgy, hogy teljes értékűen használható maradjon, magyarán valami összegányolt trehányság, amibe a nem angol nyelv fixen bele van drótozva. Ezért még forkját sem használnám. Tudom, angolsznobság, genyaság, más kultúrák lenézése, nem vagyok PC, de ez van.

No keyboard detected... Press F1 to run the SETUP

( b | 2018. 05. 12., szo – 05:58 )

csak ha szabad szoftver.

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

( GerzSonka | 2018. 05. 12., szo – 07:57 )

Rendesen beállítva a VIM sokkal hatékonyabb mindennél bármilyen programnyelven, és az azért hamarabb tanulható, mint a kínai nyelv.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Azért egy publikus változó/metódus/stb. átnevezése egy nagyságrenddel egyszerűbb normális IDE-t használva.
A jetbrains eszközeinek egyéb tudásáról már nem is beszélve. Pl. kódolási szabványokra figyelmeztetés, automatikus javítás az új kedvencem.
És gyanítom, van még sok olyan eszköz ezekben, amik jelentősen megkönnyítik egy fejlesztő életét.

( sz332 v | 2018. 05. 12., szo – 08:11 )

Kb. 1.5 éve tanulok kínait, a válasz: nem, nem, soha :D (beszélni nem annyira nehéz, olvasni megoldható, de baromi melós, kézzel írni pedig sohanapján)

( blalo | 2018. 05. 12., szo – 10:03 )

A kérdés elég pongyola. Mire vonatkozik? A kínai nyelvre, vagy hogy az IDE kínai fejlesztésű legyen?
Ott van például a Coocox ARM mikrokontrollerhez, amit a kínaiak fejlesztettek, ingyenes és angol nyelven elérhető. A régebbi verziója elég jó volt, a 2-estől már nem annyira. Közben az ST-től szintén ingyenesen elérhető lett a System Workbench is, így inkább áttértem arra. Az valószínűleg nem továbbítja a fejlesztett forráskódot se a kínaiaknak, de ki tudja...

( ironcat | 2018. 05. 12., szo – 11:23 )

Korábban a var'aq nyelvet akartam megtanulni, de nem találtam hozzá jó fejlesztő környezetet, így egyelőre elnapoltam a dolgot. Ha a var'aq már készségszinten megy, akkor egy kínai származású programozási nyelvvel fogom folytatni.

Off: Keresek anyanyelvi latintanárt.

<off>
Philip Newton:
I'm impressed that they got the Klingon right.
(Except for the missing initial apostrophe in {'arlogh Qoylu'pu'}.)

Anon:
Great, now we have Klingon grammar Nazis

-WTF comment, http://thedailywtf.com/Comments/A-Statistical-Anomaly.aspx
</off>

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

( blackberry | 2018. 05. 12., szo – 11:57 )

Nem vagyok fejlesztő, de nemet nyomtam.
Van bőven tapasztalatom a szorgos kis elvtársak szoftvereivel, valószínűleg ez a fejlesztő környezet is valami "hiba" folytán real-time mentené a leütött billentyűket valami kínai szerverre.
Aztán néhány hét után a fejlesztett szoftvernek megjelenne a kínai verziója is (max. a logó lenne lecserélve).

--

( uid_952 | 2018. 05. 12., szo – 19:22 )

Ez most olyan kérdés, mint hogy bevezetné az unió az arab számokat?

( dejo v | 2018. 05. 13., v – 08:33 )

Ha jól tudnék kínaiul akkor igen.
Főleg ha lenne egy jól fizető munkám kínai nyelvű szoftverek fejlesztésére, mert gondolom ezzel nem túl kézenfekvő angol vagy magyar nyelvű szoftverek fejlesztése.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( sigellef | 2018. 05. 14., h – 20:56 )

nem kell félni tőle, szovjet assembly már létezett.
https://github.com/besm6/simh/blob/master/BESM6/test_pprog05.b6

Valamikor olvastam egy könyvet, 1980 táján készült, az volt a címe hogy "Többprocesszoros szovjet számítógépek párhuzamos programozása"

Az nem a БЕСМ volt, hanem újabb, ott még cifrább utasítások voltak oroszbetűs mnemonikokkal.

A leírtakból annyit sikerült kihámoznom, hogy az az orosz csodagép többre volt képes 1980 tájékán, minz egy 486 valamikor 1997 tájékán. Ha elérhető áron lehetett volna olyan gépet venni, nyilván nem terjedt volna el az IBM cucca, legalábbis a keleti blokkban nem.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba