Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Fbi 25. 05. 2016, 22:38:33
-
Zdravím.
Zdědil jsem určitou aplikaci, kde běží několik win strojů, které komunikují s hlavním win strojem.
Všechny aplikace jsou napsány v C# - jsou to vícevlánkové aplikace (Běží hlavní server, k tomu se občas spouštějí některá další vlákna. Šlo by to však napsat i jinak, řídit to pouze nějakými eventy v jednom vlákně...), které používají TCPClient, SerialPort, timery, atd. Na hlavním stroji pak běží nějaká SQL databáze, to však není podmínkou.
Aplikace se 99% času flákají, po přijetí SerialPort dat proběhne nějaká TCP komunikace s hlavním PC, který posílá dotazy do DB a vrací odpovědi tazateli. Tazatel pak posílá data po SerialPort a tak pořád dokola. Takže je poněkud zbytečné stavět pro takovouto ptákovinu kompletní PC, platit licenci Win a tak dále...
Šel by tedy C# nahradit něčím, co by se dalo rozběhat jak na PC s Win, tak s Linuxem, tak například na RPi? Napadá mě Python. Ale nevím, jestli je použití výše zmíněných komponent tak jednoduché, jako v .NET.
Díky
-
Šel by tedy C# nahradit něčím, co by se dalo rozběhat jak na PC s Win, tak s Linuxem, tak například na RPi?
S vyjmenovanými platformami C# funguje - viz .NET Core (https://dotnet.github.io/) nebo Mono (http://www.mono-project.com/).
-
Java
-
Jde o to co vse to ma umet ma vyjit .net core ktere je multiplatformni nicmene minimalne ve verzi 1.0 to bude hodne osekane ale treba komunikaci se serial portem ma obsahovat
-
Java
Sice ji nemám rád ale java je to pravé ořechové.
-
Java + Netty (http://netty.io/). Netty umí komunikovat po TCP/IP i po sériovém portu a má dobře navržený model postavený na událostech.
-
C# .. je taky multiplatformni ...
-
Zdravím.
Zdědil jsem určitou aplikaci, kde běží několik win strojů, které komunikují s hlavním win strojem.
Všechny aplikace jsou napsány v C# - jsou to vícevlánkové aplikace (Běží hlavní server, k tomu se občas spouštějí některá další vlákna. Šlo by to však napsat i jinak, řídit to pouze nějakými eventy v jednom vlákně...), které používají TCPClient, SerialPort, timery, atd. Na hlavním stroji pak běží nějaká SQL databáze, to však není podmínkou.
Aplikace se 99% času flákají, po přijetí SerialPort dat proběhne nějaká TCP komunikace s hlavním PC, který posílá dotazy do DB a vrací odpovědi tazateli. Tazatel pak posílá data po SerialPort a tak pořád dokola. Takže je poněkud zbytečné stavět pro takovouto ptákovinu kompletní PC, platit licenci Win a tak dále...
Šel by tedy C# nahradit něčím, co by se dalo rozběhat jak na PC s Win, tak s Linuxem, tak například na RPi? Napadá mě Python. Ale nevím, jestli je použití výše zmíněných komponent tak jednoduché, jako v .NET.
Díky
Na to se vykasli.
Nahradou C# je samozrejme Java. C# neni nic jineho nez zamerne nekompatibilni kopie Javy, kterou MS vyrobil v dobach sveho obchodniho modelu:
- opajcuj poizivanou technologii a proved zamerne nekompatibilni klon
- klon protlac silou sveho monopolu
- rejzuj
Ale C# prisel na sklonku teto ery a uz se moc neuchytil.
C# a Java si jsou vicemene rovnocenne, C# mel az do prichodu Java FX navrch v oblasti desktop aplikaci (Java AWT a Swing je otres), naopak Java je multiplaformni a me mnohem lepsi set frameworku - pro MS neexistuje nic jako Apache Foundation a jeji luxusni softy, resp pouze jenom stin a omezene porty Javovych verzi.
Pokud ta aplikace nyni funguje a neni potreba ji nejak modifikovat, tak do toho rozhodne nehrab.
MS SW licence stoji par supu.
Je zbytecne menit existujici funkcni SW kvuli par supum za wokenni licence
-
samozrejme: golang.org (http://golang.org)
(akorat stary rpi ma tusim soft float,tam nevim)
-
C# .. je taky multiplatformni ...
Jojo, multiplatformni, akorat jenom na jedne platforme...
Mono podporuje subset funkcionalit .NET (treba vyvoj Windows Forms byl zastaven), naopak zavadi svoje nekompatibilni technologie, treba Moonlight, ktery je obdobou Silverlight, ktery MS zrusil nez nahrady.
S .NET je zbytecne ztracet cas. Proc delat s zamerne nekompatibilnim klonem, kdyz muzu delat primo s originalem.
-
S .NET je zbytecne ztracet cas. Proc delat s zamerne nekompatibilnim klonem, kdyz muzu delat primo s originalem.
haha, vdycky se dobre bavim jak Java evangelisti pisou zamerne nesmysly o vsech ostatnich jazycich/platformach.
Java je do ted pomaly a zastaraly jazyk. Ani neumi vytvorit typovy seznam, jen na oko do jazyka zavedla generiku a na pozadi je to kolekce objektu. Kdyby neprisel Android tak je Java uz davno mrtva. I tak zpusobuje na Androidu velke vykonnostni a pametove problemy na mobilech. Chtel bych opravdu vedet, kdo ma rad Javu. Mac lidi, kde odsuzujou uplne Garbage collectory? Tezko, Windows lidi, kde Java aplikace jsou pomale obludy s hnusnym UI? Tezko, Linux lidi? Podobne jako Mac lidi by se ji nejradeji zbavili a pouzili neco kompilovaneho do nativniho kodu.
Java je dobra akorat tak na pomale business sracky, kterych je vsude plno.
V dnesni dobe vyhrava JavaScript. V budoucnosti to bude uplne jiny jazyk.
-
Aha. Ja Javu nemam rad, ale uz si predstavuji, jak tazatel pise tu aplikaci znovu v JavaScriptu a jak to pak provozuji v browseru ke vseobecnemu nadseni. Tak to aby snad preventivne zacal brat Prozac.
-
Takže je poněkud zbytečné stavět pro takovouto ptákovinu kompletní PC, platit licenci Win a tak dále...
A kolik těch strojů plánujete? Jestli desítky, tak proboha nic neřeš a nech tam PC s win a odladěnou aplikaci v .NETu. Jestli stovky nebo tisíce, tak je to potřeba analyzovat.
Něco co přečte data na RS232 a pošle je někam dál přes TCP/IP (a naopak) se dá postavit na ledasjakém levném ARM.
Ale něco na čem poběží databáze - hmm - tady bude hodně záležet jak velká databáze, jak rychlé odezvy jsou požadované. Tady se může stát, že PCčko bude nejlevnější řešení i při tisících nasazení.
Ale proč mám pocit, že plánuješ jeden kus (tedy jeden nový server a několik RS232 stanic) nebo max. jednotky toho zařízení a tvoje otázka je tedy zcela nesmyslná?
-
Java
tos upad
-
Java
Sice ji nemám rád ale java je to pravé ořechové.
od kdy ?
-
S .NET je zbytecne ztracet cas. Proc delat s zamerne nekompatibilnim klonem, kdyz muzu delat primo s originalem.
haha, vdycky se dobre bavim jak Java evangelisti pisou zamerne nesmysly o vsech ostatnich jazycich/platformach.
Java je do ted pomaly a zastaraly jazyk. Ani neumi vytvorit typovy seznam, jen na oko do jazyka zavedla generiku a na pozadi je to kolekce objektu. Kdyby neprisel Android tak je Java uz davno mrtva. I tak zpusobuje na Androidu velke vykonnostni a pametove problemy na mobilech. Chtel bych opravdu vedet, kdo ma rad Javu. Mac lidi, kde odsuzujou uplne Garbage collectory? Tezko, Windows lidi, kde Java aplikace jsou pomale obludy s hnusnym UI? Tezko, Linux lidi? Podobne jako Mac lidi by se ji nejradeji zbavili a pouzili neco kompilovaneho do nativniho kodu.
Java je dobra akorat tak na pomale business sracky, kterych je vsude plno.
V dnesni dobe vyhrava JavaScript. V budoucnosti to bude uplne jiny jazyk.
Asi tak nějak.
-
Sam taketo nieco riesim na linuxe cez Mono.
Ziadny problem, vstetko ide pekne ako ma. Pri praci so seriovym portom ma Java ovela vacsiu latenciu.
Ked embedded tak radsej mono ako java. Alebo potom native/go/node.js ...
-
Ještě to upřesním...
Hlavní stanice, kde poběží DB bude Win, nebo Linux, tam je to jasný.
Sekundárních stanic je několik - 2 až 10.
Vždy to běží vše v jednom místě - třeba areálu firmy.
Celých těchto sestav je po čr několik, bez problémů fungují až na nějaké výjimky.
Budou se stavět další. Kód se tak jako tak bude muset upravit na přání.
Kód je napsaný velice složitě, nic se neloguje, těžko se v něm orientuje.
Časy se mění... Proč vždy stavět celou win stanici (Těch dalších zakázek můžou být desítky), když můžu použít nějaký MCU, připojit k němu UART/TCP, případně to řešit rovnou bezdrátově s ESP8266, nebo použít RPi, atd.
V Java to dělat nebudu. Čistě z přesvědčení...
-
Qt + JS/Cpp ?
-
Ještě se zeptám proč nikdo neřekl nic k Pythonu.
Ještě když jsem dělal testera, tak v tom kolega psal nějaký už dost složitější sw na tvorbu testovacích skriptů a měl to velice pěkné - jak GUI, tak byl schopný velice rychle to opravovat podle toho, co jsme našli za chyby.
-
kdyz to bude dostatecne jednoduche, tak to muzes napsat rovnou v C pro ESP8266 a nechat to bezet jen na tom chipu. Tedy uplne bez pocitace/raspberry.
Napis, jak slozity ten program je. Nacist serial, poslat na server, prijmou odpoved a poslat na serial by zvladlo to ESP8266 samotne.
-
Python tohle v pohode zvladne, takze smele do nej.
-
Pro ESP8266 je i Arduino IDE, pokud se nepletu, takže lze opět použít C#. ;D
-
Pro ESP8266 je i Arduino IDE, pokud se nepletu, takže lze opět použít C#. ;D
Arduino IDE v novejsi verzi podporuje i ESP8266. Ale neni to C# ale C/C++.
Pise se v tom ale fajn.
-
Nejlepsi kdyz to udelas v assembleru, to nikdo v praci nebude moct rict ani popel... 8)
Ještě to upřesním...
Hlavní stanice, kde poběží DB bude Win, nebo Linux, tam je to jasný.
Sekundárních stanic je několik - 2 až 10.
Vždy to běží vše v jednom místě - třeba areálu firmy.
Celých těchto sestav je po čr několik, bez problémů fungují až na nějaké výjimky.
Budou se stavět další. Kód se tak jako tak bude muset upravit na přání.
Kód je napsaný velice složitě, nic se neloguje, těžko se v něm orientuje.
Časy se mění... Proč vždy stavět celou win stanici (Těch dalších zakázek můžou být desítky), když můžu použít nějaký MCU, připojit k němu UART/TCP, případně to řešit rovnou bezdrátově s ESP8266, nebo použít RPi, atd.
V Java to dělat nebudu. Čistě z přesvědčení...
-
A udržovat ten kód v ASM bude kdo?
Za mně C# v Mono nebo Python (třeba s GTK na GUI). Ty ESP8266 bych nepoužíval, v dlouhodobém horizontu používání se to se.re
-
Dle popisu mi to trochu mi to pripomina zakazku, na ktere jsem delal loni.
Pokud tam nemas zadne GUI, tak bych sel bez vahani do Pythonu. Pokud delas s C#, tak v zakladnich vecech to moc velky sok nebude. Akorat budes muset najit jine IDE nez Visual Studio (i kdyz udajne i ve Visual Studiu lze tvorit v Pythonu, ale nezkousel jsem). Ja jsem pouzil PyCharm.
A pokud tam mas nejake GUI, tak nevim. Ja GUI mel, v ramci sebevzdelavani jsem pouzil Tkinter, ale moc se mi to nelibilo. Bez toho GUI by to byla krasna zakazka. Dalsi zakazku, ktera byla dost o GUI jsem zkusil v Lazarusu a to docela slo, akorat ten Pascalovsky ukecanej jazyk mi dost vadil. Proti tomu je psani v Pythonu parada.
-
Python ve Visual Studio se dá, ale IntelliSense je ještě docela na nic. PyCharm v tomhle ohledu stojí za každou korunu své ceny. Škoda že neumí Microsoftí TFS, ale to bych asi chtěl moc, naštěstí TFS umí git.
-
S .NET je zbytecne ztracet cas. Proc delat s zamerne nekompatibilnim klonem, kdyz muzu delat primo s originalem.
haha, vdycky se dobre bavim jak Java evangelisti pisou zamerne nesmysly o vsech ostatnich jazycich/platformach.
Java je do ted pomaly a zastaraly jazyk. Ani neumi vytvorit typovy seznam, jen na oko do jazyka zavedla generiku a na pozadi je to kolekce objektu. Kdyby neprisel Android tak je Java uz davno mrtva. I tak zpusobuje na Androidu velke vykonnostni a pametove problemy na mobilech. Chtel bych opravdu vedet, kdo ma rad Javu. Mac lidi, kde odsuzujou uplne Garbage collectory? Tezko, Windows lidi, kde Java aplikace jsou pomale obludy s hnusnym UI? Tezko, Linux lidi? Podobne jako Mac lidi by se ji nejradeji zbavili a pouzili neco kompilovaneho do nativniho kodu.
Java je dobra akorat tak na pomale business sracky, kterych je vsude plno.
V dnesni dobe vyhrava JavaScript. V budoucnosti to bude uplne jiny jazyk.
Přijde mi dost podivné si stěžovat na rychlost javy a ve stejném příspěvku si vybrat javascript. Na první pohled odborník :D
-
Pokud problem budou bez problemu pokryvat knihovny v C++, potom jednoznacne C++ s Qt 8) Python je pro male decka. A pokud tam poteebujes neco co v C++ neni k sehnni, tak Javu no. Furt lepsi nez Python, na ten neni nikdo zvedavej.
-
Coz mi prIpomina ze by bylo fajn mit pRo c++ nejaky easy to use framework pro tvrobu gui na bazi webovych technologii, protoze ruzne graficke veci typu grafy je v c++ bolest protoze na to nejsou knihovny, ale pro javascript jsou jich dve zadeke, takze jadro aplikace by bezelo hezky v c++ idelane v qt a gui by byl web browser. Nadhera.
-
Vtipné, nakonec budu hájit Javu.
Vite proč Javu a ne C#? Protože C# je rozšířený pouze na widlích, nikde jinde, mono je dosti problematický šmejd, takže na něj bych nespoléhal.
Co se týče rychlosti, Java je super drak. Zhruba 3x pomalejší než C/C++, a to je fakt dost dobrý na jazyk pod VM s GC.
-
S .NET je zbytecne ztracet cas. Proc delat s zamerne nekompatibilnim klonem, kdyz muzu delat primo s originalem.
haha, vdycky se dobre bavim jak Java evangelisti pisou zamerne nesmysly o vsech ostatnich jazycich/platformach.
Java je do ted pomaly a zastaraly jazyk. Ani neumi vytvorit typovy seznam, jen na oko do jazyka zavedla generiku a na pozadi je to kolekce objektu. Kdyby neprisel Android tak je Java uz davno mrtva. I tak zpusobuje na Androidu velke vykonnostni a pametove problemy na mobilech. Chtel bych opravdu vedet, kdo ma rad Javu. Mac lidi, kde odsuzujou uplne Garbage collectory? Tezko, Windows lidi, kde Java aplikace jsou pomale obludy s hnusnym UI? Tezko, Linux lidi? Podobne jako Mac lidi by se ji nejradeji zbavili a pouzili neco kompilovaneho do nativniho kodu.
Java je dobra akorat tak na pomale business sracky, kterych je vsude plno.
V dnesni dobe vyhrava JavaScript. V budoucnosti to bude uplne jiny jazyk.
Je pravda že někteří nekriticky vyzdvihujou Javu, to samé se ale děje u každého jazyka, s tím nic nenaděláš.
JS je podle mne v dnešní době nejvíc OOP jazyk dneška. Dědí přímo od jazyka Self (bratříček smalltalku s prototypama místo tříd).
Budoucnost možná přivane renesanci FP jazyků. Možná.
-
A co třeba mono + QtSharp?
-
Zdravím.
Zdědil jsem určitou aplikaci, kde běží několik win strojů, které komunikují s hlavním win strojem.
Všechny aplikace jsou napsány v C# - jsou to vícevlánkové aplikace (Běží hlavní server, k tomu se občas spouštějí některá další vlákna. Šlo by to však napsat i jinak, řídit to pouze nějakými eventy v jednom vlákně...), které používají TCPClient, SerialPort, timery, atd. Na hlavním stroji pak běží nějaká SQL databáze, to však není podmínkou.
Aplikace se 99% času flákají, po přijetí SerialPort dat proběhne nějaká TCP komunikace s hlavním PC, který posílá dotazy do DB a vrací odpovědi tazateli. Tazatel pak posílá data po SerialPort a tak pořád dokola. Takže je poněkud zbytečné stavět pro takovouto ptákovinu kompletní PC, platit licenci Win a tak dále...
Šel by tedy C# nahradit něčím, co by se dalo rozběhat jak na PC s Win, tak s Linuxem, tak například na RPi? Napadá mě Python. Ale nevím, jestli je použití výše zmíněných komponent tak jednoduché, jako v .NET.
Díky
Jak psali ostatni dobra volba je urcite Java. Ja osobne bych to nejspis napsal v jazyce D + vibe-d.
-
Zdravím.
Zdědil jsem určitou aplikaci, kde běží několik win strojů, které komunikují s hlavním win strojem.
Všechny aplikace jsou napsány v C# - jsou to vícevlánkové aplikace (Běží hlavní server, k tomu se občas spouštějí některá další vlákna. Šlo by to však napsat i jinak, řídit to pouze nějakými eventy v jednom vlákně...), které používají TCPClient, SerialPort, timery, atd. Na hlavním stroji pak běží nějaká SQL databáze, to však není podmínkou.
Aplikace se 99% času flákají, po přijetí SerialPort dat proběhne nějaká TCP komunikace s hlavním PC, který posílá dotazy do DB a vrací odpovědi tazateli. Tazatel pak posílá data po SerialPort a tak pořád dokola. Takže je poněkud zbytečné stavět pro takovouto ptákovinu kompletní PC, platit licenci Win a tak dále...
Šel by tedy C# nahradit něčím, co by se dalo rozběhat jak na PC s Win, tak s Linuxem, tak například na RPi? Napadá mě Python. Ale nevím, jestli je použití výše zmíněných komponent tak jednoduché, jako v .NET.
Díky
Jak psali ostatni dobra volba je urcite Java. Ja osobne bych to nejspis napsal v jazyce D + vibe-d.
Proč konkrétně v D ?
-
Zdravím.
Zdědil jsem určitou aplikaci, kde běží několik win strojů, které komunikují s hlavním win strojem.
Všechny aplikace jsou napsány v C# - jsou to vícevlánkové aplikace (Běží hlavní server, k tomu se občas spouštějí některá další vlákna. Šlo by to však napsat i jinak, řídit to pouze nějakými eventy v jednom vlákně...), které používají TCPClient, SerialPort, timery, atd. Na hlavním stroji pak běží nějaká SQL databáze, to však není podmínkou.
Aplikace se 99% času flákají, po přijetí SerialPort dat proběhne nějaká TCP komunikace s hlavním PC, který posílá dotazy do DB a vrací odpovědi tazateli. Tazatel pak posílá data po SerialPort a tak pořád dokola. Takže je poněkud zbytečné stavět pro takovouto ptákovinu kompletní PC, platit licenci Win a tak dále...
Šel by tedy C# nahradit něčím, co by se dalo rozběhat jak na PC s Win, tak s Linuxem, tak například na RPi? Napadá mě Python. Ale nevím, jestli je použití výše zmíněných komponent tak jednoduché, jako v .NET.
Díky
Jak psali ostatni dobra volba je urcite Java. Ja osobne bych to nejspis napsal v jazyce D + vibe-d.
Proč konkrétně v D ?
Tak protoze ho znam asi nejlepe s jazyku, ktere mi na to prijdou vhodne a splnuji pozadavky. A zejmena prace s vibe-d se mi velice zalibila. Takze jsou to zejmena osobni preference, nic extra technickeho. Proste se mi ten jazyk libi vic nez napriklad java.
-
Jak psali ostatni dobra volba je urcite Java. Ja osobne bych to nejspis napsal v jazyce D + vibe-d.
Proč konkrétně v D ?
Protože má rád když ho kolegové posílají do * s nějakým D.
-
Zelenáč je sice vůl, ale v tomhle s ním souhlasím. Napsat zakázku v jazyce, který používá dvacet lidí v naší sluneční soustavě je na přesdržku, i kdyby to byl ten nejvychytanější jazyk na světě.
-
Zelenáč je sice vůl, ale v tomhle s ním souhlasím. Napsat zakázku v jazyce, který používá dvacet lidí v naší sluneční soustavě je na přesdržku, i kdyby to byl ten nejvychytanější jazyk na světě.
Tak samozrejme v praci, kde se bude ocekavat ze to potom nekdo prebere, tak tam je samozrejme vhodne zvolit rozsirenejsi jazyk, jak jsem psal treba tu javu. Ja to myslel tak ze pokud bych neco takoveho delal pro sve potreby tak pouziji D. Jelikoz je to fajn jazyk a na hobby projekty je super.
Na druhou stranu nesouhlasim s tim ze by se jazyk D pouzival tak malo. Ano neni to nejrozsirenejsi jazyk, ale to nebylo ani go a stejne v nem zacali lide psat. To same plati pro rust. Kazdy jazyk byl v postaveni kdy nebyl nejrozsirenejsi. Samozrejme je treba vzit v uvahu ze na to jak dlouho tu jazyk D je tak se nerozsiril nejak zavratne. Takze se ani neda ocekavat nejaky zazracny boom.
Dalsiho vyhodou jazyka D je to ze i kdyz ho nepouziva tolik lidi, tak i clovek s prumernou znalosti javy, C#, C/C++ nema problem dany kod pochopit a pripadne jej upravit dle potreb.
-
Jak psali ostatni dobra volba je urcite Java. Ja osobne bych to nejspis napsal v jazyce D + vibe-d.
Proč konkrétně v D ?
Protože má rád když ho kolegové posílají do * s nějakým D.
Nikdo me s nim nikam neposila, ba prave naopak vsichni kolegove co meli tu cest si jazyk D vyzkouset, pak byli nestastni kdyz museli zpet psat v kod v PHP ;).
-
Zelenáč je sice vůl, ale v tomhle s ním souhlasím. Napsat zakázku v jazyce, který používá dvacet lidí v naší sluneční soustavě je na přesdržku, i kdyby to byl ten nejvychytanější jazyk na světě.
Paul Graham nesouhlasí. (http://www.paulgraham.com/pypar.html)
-
Daniel Kozak: Ok, to beru.
davkol: To pak vysvětluj zákazníkovi, že sice nejspíš nikoho na úpravu tvojeho deset let starého kódu v nějakém obskurním jazyce nesežene, ale když už, tak to bude Pan programátor... 8)
-
Ta komunikace po "sériovém portu" nejspíš znamená RS232 (+-12V). Tudíž gadgety jako raspi nebo esp8266 potřebují převodník úrovní (a teď je otázka jaké signály ta komunikace používá jestli jenom RX,TX nebo i další). Navíc ten konektor od externího zařízení má nějaký tvar (zpravidla 9pin canon) a ten je potřeba někam zastrčit (takže protikus). Celé by to mělo být asi nemělo vypadat jako chuchvalec drátů, takže krabička. Jinak jak tady padlo - esp8266 může v závislosti na výrobci a použitém FW tuhnout, totéž raspi při delším hoblování sd karty.
Pokud stávající aplikace A.exe nemá GUI, tak na linuxu tatáž aplikace spuštěná jako mono A.exe poběží bez problemů(sériový port a TCP komunikace z .NET frameworku je portovaná), stačí upravit název sériového portu v konfiguraci/jako parameter při spuštění nebo jak je to řešené - pokud to tedy není naprasáka přímo v kódu.
Jo a pokud je zákazník při výpadku služeb a) potěšen že může dopřát dodavateli hraní si s novou technologií b) nespokojen c) nasr..... d) posílá fakturu na xxx tisíc za způsobenou škodu tak od varianty b) včetně bych na to nesahal. Cena HW+OS je nic proti zbytku.
-
Tak se na to podíváme:
- Má to být multiplatformní? C# nehrozí.
- Má to mít možnost jet na jednočipu? Diskvalifikace Javy. Na aktuálním projektu jsem o ní uvažoval do chvíle, než jsem se dozvěděl licenční poplatek a požadavky na CPU/FLASH.
Pokud to má být na embedded zařízení, tak jasně Cčko pro embedded non-ui část. Zbytek v Qt, C jede všude a i UI se tam dá polepit.
-
Zelenáč je sice vůl, ale v tomhle s ním souhlasím. Napsat zakázku v jazyce, který používá dvacet lidí v naší sluneční soustavě je na přesdržku, i kdyby to byl ten nejvychytanější jazyk na světě.
Paul Graham nesouhlasí. (http://www.paulgraham.com/pypar.html)
Jak souvisí ten článek s příspěvkem na který reagujete? Python je vše, jen ne málo rozšířený.
-
Otázkou je, zda-li je potřeba na klientské straně nějaké GUI. Pokud ne a funkce spočívá opravdu pouze v přeposílání požadavků mezi RS232 a TCP (byť s nějakou vnitřní inteligencí), tak bych šel do nějaké ARM desky (nejlevnější asi to RPi - i když kvalita HW je prachbídná) a napsal to v Pythonu. Pokud je inteligence velmi malá a protokol nad TCP není složitý, tak lze jít o level níže a vzít na to obyčejné Arduino + Ethernet shield. Vše ale záleží na tom, co ten klient opravdu interně dělá.
-
Zelenáč je sice vůl, ale v tomhle s ním souhlasím. Napsat zakázku v jazyce, který používá dvacet lidí v naší sluneční soustavě je na přesdržku, i kdyby to byl ten nejvychytanější jazyk na světě.
Paul Graham nesouhlasí. (http://www.paulgraham.com/pypar.html)
Jak souvisí ten článek s příspěvkem na který reagujete? Python je vše, jen ne málo rozšířený.
> August 2004
-
C# neni nic jineho nez zamerne nekompatibilni kopie Javy, kterou MS vyrobil v dobach sveho obchodniho modelu:
- opajcuj poizivanou technologii a proved zamerne nekompatibilni klon
- klon protlac silou sveho monopolu
- rejzuj
To je pravda. Spominam si, ze kedysi mal MS produkt Visual J++, co bola vlastne okopirovana Java. Ale netrvalo to dlho.
-
C# neni nic jineho nez zamerne nekompatibilni kopie Javy, kterou MS vyrobil v dobach sveho obchodniho modelu:
- opajcuj poizivanou technologii a proved zamerne nekompatibilni klon
- klon protlac silou sveho monopolu
- rejzuj
To je pravda. Spominam si, ze kedysi mal MS produkt Visual J++, co bola vlastne okopirovana Java. Ale netrvalo to dlho.
A udelal to velice dobre, zrejme taky silou sveho monopolu. Proto se v tom asi podstatně líp dělá.
-
C# neni nic jineho nez zamerne nekompatibilni kopie Javy, kterou MS vyrobil v dobach sveho obchodniho modelu:
- opajcuj poizivanou technologii a proved zamerne nekompatibilni klon
- klon protlac silou sveho monopolu
- rejzuj
To je pravda. Spominam si, ze kedysi mal MS produkt Visual J++, co bola vlastne okopirovana Java. Ale netrvalo to dlho.
A udelal to velice dobre, zrejme taky silou sveho monopolu. Proto se v tom asi podstatně líp dělá.
Pohodlnost M$itu je relativní, někomu se v tom asi líp dělá, mě teda ne.
Leckdy mám pocit že v M$ maj firemní motto "FUCK the logic"
-
Tak se na to podíváme:
- Má to být multiplatformní? C# nehrozí.
Nekdy drive jsem zahledl nejakou GTK knihovnu, ktera jela jak pod Widlema tak pod Monem, ale co pamatuju, tak to nebyla zadna slava.
- Má to mít možnost jet na jednočipu? Diskvalifikace Javy. Na aktuálním projektu jsem o ní uvažoval do chvíle, než jsem se dozvěděl licenční poplatek a požadavky na CPU/FLASH.
Proč vždy stavět celou win stanici (Těch dalších zakázek můžou být desítky), když můžu použít nějaký MCU, připojit k němu UART/TCP, případně to řešit rovnou bezdrátově s ESP8266, nebo použít RPi, atd.
Byla rec o maline a ta asi dokonce podporuje i orig. Oracli JVM - https://www.raspberrypi.org/blog/oracle-java-on-raspberry-pi/.
V Java to dělat nebudu. Čistě z přesvědčení...
Chapu, sam bych uz nikdy znovu v C# a VS nic take nedelal. U me je to nechut podporovat spinave praktiky M$ a nalezeni lepsiho IDE. Mohu se zeptat, co se vam nelibi na Jave, potazmo jazycich na JVM?
Java je do ted pomaly a zastaraly jazyk.
Tezko, Windows lidi, kde Java aplikace jsou pomale obludy s hnusnym UI?
Protoze chce neco multiplatformniho, tak jsem nasel srovnani s Monem - https://benchmarksgame.alioth.debian.org/u64q/csharp.html a pouze v jedinem pripade je Mono rychlejsi nez Java - takze C# je jeste pomalejsi "shit" nez Java :D.
Ani neumi vytvorit typovy seznam, jen na oko do jazyka zavedla generiku a na pozadi je to kolekce objektu.
Sam za to Javu (a JVM) take nemam rad, ale kdyz to funguje, tak proc vam vadi, co je na pozadi? Ve vetsine pripadu to nepoznate ani na "popredi", kdyz pisete kod. Jsou sice pripady, kdy se to hodi (new T()), ale na to jsou zajete patterny a pokud nekdo dela v Jave, tak mu boilerplate kod moc nevadi.
Tezko, Windows lidi, kde Java aplikace jsou pomale obludy s hnusnym UI? Tezko, Linux lidi? Podobne jako Mac lidi by se ji nejradeji zbavili a pouzili neco kompilovaneho do nativniho kodu.
Pohybuji se na hrane Woken a Tucnaka, mel bych tedy spadat do tech vasich dvou kategorii, zaroven ale nemam problem s aplikacemi v Jave => vase tvrzeni je nepravdive? Na desktopu velmi casto pouzivam IntelliJ IDEA a Free Rapid Downloader, na servru mam treba XWiki. Pomalost Javy je ve vetsine pripadu pouze zhorseni o 0-2x oproti treba C++. Pokud me vyhovuje aplikace v Jave a nic jineho se ji nerozvna, tak ji budu pouzivat. Rozhodne si nebudu 5 let psat vlastni IDE v C++, protoze vsechny programy co pouzivam musim z nejakeho duvodu mit napsane v C/C++. Problem s vykonem na desktopu je malokdy, s pameti to stejne, proc by tedy vyvojari meli volit problematictejsi vice low-level pristupy/jazyky, kdyz maji rock-solid Javu, kde se vyviji rychle?
Java je dobra akorat tak na pomale business sracky
&& benchmark vyse =>
Java C# je dobry akorat tak na pomale business sracky.
BTW porad M$ zakazuje delat benchmarky, aby moc nepohorel? To me vzdycky rozesmalo, kdyz jsem cetl, proc nejsou nikde nezavisle benchmarky s .NETem :D.
V dnesni dobe vyhrava JavaScript. V budoucnosti to bude uplne jiny jazyk.
Jop, a vykonem je na tom lepe, nez ten Python. A Java na tom byla jeste lip. U Javy mate alespon jistotu, ze to kdyztak zvladne nekdo udrzovat i za 10 let. Take vyhlidky na preziti jazyka jsou lepsi, ne ze to M$ zabali, jak se SilverLightem (cetl jsem i zvesti o tom, ze .NET samotny taky moc nepodporuje, ze veci ve Woknech prepisuje do neceho rychlejsiho).
-
C# Rules.! Ziadna Java. Dnes to ovlada kazde hovno. C# budes vymykat
-
Vem python3, zvladne vse, jednoduse se spravuje, prasit se v nem moc neda (jako da, ale da se to rychle uklidit) je rychly veci v nem opravis velmi rychle, vse je objekt, existuje hromada knihoven, zavislosti se daji krasne ciste resit pres pip, PEP8 formatery/validatory... knihovny co napises muzes jednoduse pouzit i pro web kdyby bylo treba (flask/django), co se tyce GUI tak QT nebo GTK+ neni problem, na db napr SQLAlchemy...
-
Java EE: Spousta knihoven, ale udělat v nich něco je zdlouhavý a zbytečně složitý. MS .NET alspoň člověka vede jednim směrem (i když to má samozřejmě nevýhody).
Java na desktopu: Musím si vybrat jestli použiju starej Swing, nebo JavuFX(+zasekanej SceneBuilder), kterou skoro nikdo nepoužívá.
Stát se ideální technologií má podle mě .NET, ale jen za předpokladu, že MS udělá i multiplatformní GUI a to co dělá těď neposere (zatim to jde pěkně kostrbatě).
-
C# Rules.! Ziadna Java. Dnes to ovlada kazde hovno. C# budes vymykat
To spis C# ovlada kazde hovno, protože je to jednoduche.
-
Java EE: Spousta knihoven, ale udělat v nich něco je zdlouhavý a zbytečně složitý. MS .NET alspoň člověka vede jednim směrem (i když to má samozřejmě nevýhody).
Java na desktopu: Musím si vybrat jestli použiju starej Swing, nebo JavuFX(+zasekanej SceneBuilder), kterou skoro nikdo nepoužívá.
Stát se ideální technologií má podle mě .NET, ale jen za předpokladu, že MS udělá i multiplatformní GUI a to co dělá těď neposere (zatim to jde pěkně kostrbatě).
Tak co se Javy EE týče, to bych úplně nesouhlasil, neříkám Spring. Vždyť v EE to funguje obdobně jako asp.net, máš View a k němu máš Javovský kód (managed beanu), automaticky se ti generuje AJAX, když se ve View odvoláváš na metody z beany. Kde to zaostává jsou komponenty, to je problém IDEčka, že tam nejdou házet jako ve Visualku.
-
Ahoj,
Není tady dostatečně podrobně popsán projekt který řešíš (a zda-li cíl projektu je si s něčím pohrát, nebo vyřešit konkrétní problém), nicméně pokud potřebuješ jen číst a zapisovat do RS232, tak bys mohl použít průmyslové převodníky RS232 na TCP/IP (které by měli být dostatečně spolehlivé a budou levnější než PC + Licence ) a komunikaci pořešit jen na serveru...
-
Prumyslovy prevodnik? Co to tak procitam, tak mi to pripomina otazku: co bylo driv, jestli slepice nebo vejce.
Nejdriv resim co budu delat, potom cim. Nikdy naopak. To taky muzu shanet husu, co zlate vejce dava.
-
Ps: pouzil byh jsfuck. Bylo by to na h*, ale zase cool. 😂
-
Zdravím.
Zdědil jsem určitou aplikaci, kde běží několik win strojů, které komunikují s hlavním win strojem.
Všechny aplikace jsou napsány v C# - jsou to vícevlánkové aplikace (Běží hlavní server, k tomu se občas spouštějí některá další vlákna. Šlo by to však napsat i jinak, řídit to pouze nějakými eventy v jednom vlákně...), které používají TCPClient, SerialPort, timery, atd. Na hlavním stroji pak běží nějaká SQL databáze, to však není podmínkou.
Aplikace se 99% času flákají, po přijetí SerialPort dat proběhne nějaká TCP komunikace s hlavním PC, který posílá dotazy do DB a vrací odpovědi tazateli. Tazatel pak posílá data po SerialPort a tak pořád dokola. Takže je poněkud zbytečné stavět pro takovouto ptákovinu kompletní PC, platit licenci Win a tak dále...
Šel by tedy C# nahradit něčím, co by se dalo rozběhat jak na PC s Win, tak s Linuxem, tak například na RPi? Napadá mě Python. Ale nevím, jestli je použití výše zmíněných komponent tak jednoduché, jako v .NET.
Díky
Jednoznacne http://fsharp.org/
-
C# Rules.! Ziadna Java. Dnes to ovlada kazde hovno. C# budes vymykat
To spis C# ovlada kazde hovno, protože je to jednoduche.
To urcite. Kazdej srac sa dnes uci Javu a robi nefunkcne aplikacie pre Android. A spojazdnit Javu, ktora ma XYZ kniznic, ked to chce clovek prepojit este s dalsimi X vecami, no hroza.
Pri MS technologiach. Prepojit C# s EntityFramework a MSSQL ci hociakou inou DB napr. Oracle, to je uplna pohodka a usetrene nervy.
Ale som rad, ze ovladam C#, aspon nepatrim tych 9 z 10, ktori ovladaju Javu.
-
Ale prosim ta. Das do mavenu zavislost a hotovo. Rovnake ako s nugatmi. Vcera som videl velky billboard "hladame javistu", to k tomu 9/10 ovlada javu. Vsade je ich kopec asi..
A ze sa kazdej srac uci javu a robi nefunkcne apky? To je asi akoby si sa stazoval, ze kazdy srac sa uci pisat a potom je po nete popisanych kopec hluposti.
-
To je asi akoby si sa stazoval, ze kazdy srac sa uci pisat a potom je po nete popisanych kopec hluposti.
No, já mám někdy nutkání si na to opravdu postěžovat :-)
-
Zdravím.
Zdědil jsem určitou aplikaci, kde běží několik win strojů, které komunikují s hlavním win strojem.
Všechny aplikace jsou napsány v C# - jsou to vícevlánkové aplikace (Běží hlavní server, k tomu se občas spouštějí některá další vlákna. Šlo by to však napsat i jinak, řídit to pouze nějakými eventy v jednom vlákně...), které používají TCPClient, SerialPort, timery, atd. Na hlavním stroji pak běží nějaká SQL databáze, to však není podmínkou.
Aplikace se 99% času flákají, po přijetí SerialPort dat proběhne nějaká TCP komunikace s hlavním PC, který posílá dotazy do DB a vrací odpovědi tazateli. Tazatel pak posílá data po SerialPort a tak pořád dokola. Takže je poněkud zbytečné stavět pro takovouto ptákovinu kompletní PC, platit licenci Win a tak dále...
Šel by tedy C# nahradit něčím, co by se dalo rozběhat jak na PC s Win, tak s Linuxem, tak například na RPi? Napadá mě Python. Ale nevím, jestli je použití výše zmíněných komponent tak jednoduché, jako v .NET.
Díky
Co konkrétně ty aplikace dělají. Proč komunikují. Jestli to neni tajné
-
Ale prosim ta. Das do mavenu zavislost a hotovo. Rovnake ako s nugatmi. Vcera som videl velky billboard "hladame javistu", to k tomu 9/10 ovlada javu. Vsade je ich kopec asi..
A ze sa kazdej srac uci javu a robi nefunkcne apky? To je asi akoby si sa stazoval, ze kazdy srac sa uci pisat a potom je po nete popisanych kopec hluposti.
V cem delas andy a hlavne na cem? Protoze ja prosel javou i c# a musim rict, ze co se tyce konfigurace, tak jednodussi mi prisli veci v c#. Jednej i druhej jazyk maji sve plusy i minusy
-
Samozrejme v jave. Robil som aj c# chvilu, ale vtedy este bol .net cisto microsoft/intel zalezitost a musel som sa pre nieco rozhodnut. Navyse ta konfigurace - no neviem ci by som .net vedel urobit projekt bez visual studia. Inak to povazujem prast jak uhod, pricom .net ma iste ficurky ktore sa mi pacia (napr aot). Na apku ktora sa obcas pusti by som asi pouzil .net (resp mono), prave kvoli aot. Inak robim v eclipse a vyhovuje mi to.
-
Co se týče GUI u desktopových aplikací, proč se v dnešní době nedělá pomocí HTML+CSS, stejně jako weby nebo hybridní mobilní aplikace a máme furt JavaFX, WPF, teď zas nový UWP. Nebylo by to jednodušší v dnešní době mít na všechno jednu technologii?
Sice existuje projekt Electron, ale tam se používá JS a né Java/C#.
-
Co se týče GUI u desktopových aplikací, proč se v dnešní době nedělá pomocí HTML+CSS, stejně jako weby nebo hybridní mobilní aplikace a máme furt JavaFX, WPF, teď zas nový UWP. Nebylo by to jednodušší v dnešní době mít na všechno jednu technologii?
Sice existuje projekt Electron, ale tam se používá JS a né Java/C#.
Řekl bych, že hlavním důvodem bude výkon. U některých aplikací to je asi jedno. Třeba u takového Atomu to docela vadí.
-
Co se týče GUI u desktopových aplikací, proč se v dnešní době nedělá pomocí HTML+CSS, stejně jako weby nebo hybridní mobilní aplikace a máme furt JavaFX, WPF, teď zas nový UWP. Nebylo by to jednodušší v dnešní době mít na všechno jednu technologii?
Sice existuje projekt Electron, ale tam se používá JS a né Java/C#.
Řekl bych, že hlavním důvodem bude výkon. U některých aplikací to je asi jedno. Třeba u takového Atomu to docela vadí.
HTML+CSS nebývá tím úzkým hrdlem. Příčina bude jinde.
-
Co se týče GUI u desktopových aplikací, proč se v dnešní době nedělá pomocí HTML+CSS, stejně jako weby nebo hybridní mobilní aplikace a máme furt JavaFX, WPF, teď zas nový UWP. Nebylo by to jednodušší v dnešní době mít na všechno jednu technologii?
Sice existuje projekt Electron, ale tam se používá JS a né Java/C#.
Řekl bych, že hlavním důvodem bude výkon. U některých aplikací to je asi jedno. Třeba u takového Atomu to docela vadí.
Atom ale používá Javascript. A pro to GUI by se asi nepoužívalo asi klasický jádro prohlížeče.
Teď tu máme XAML, FXML a obojí je na stejnej způsob, místo toho by podle mě bylo jednodušší mít jen HTML. Teď třeba budu chtít dělat v FXML a budu muset zjišťovat co jak se dělá a co to neumí, místo toho abych jednoduše přenesl danou část z webovýho prostředí.
-
Co se týče GUI u desktopových aplikací, proč se v dnešní době nedělá pomocí HTML+CSS, stejně jako weby nebo hybridní mobilní aplikace a máme furt JavaFX, WPF, teď zas nový UWP. Nebylo by to jednodušší v dnešní době mít na všechno jednu technologii?
Sice existuje projekt Electron, ale tam se používá JS a né Java/C#.
Řekl bych, že hlavním důvodem bude výkon. U některých aplikací to je asi jedno. Třeba u takového Atomu to docela vadí.
Atom ale používá Javascript. A pro to GUI by se asi nepoužívalo asi klasický jádro prohlížeče.
Teď tu máme XAML, FXML a obojí je na stejnej způsob, místo toho by podle mě bylo jednodušší mít jen HTML. Teď třeba budu chtít dělat v FXML a budu muset zjišťovat co jak se dělá a co to neumí, místo toho abych jednoduše přenesl danou část z webovýho prostředí.
Někde jsem četl, že u Atomu je skutečně problém HTML. Když chcete v HTML nějaký jiný než defaultní widget, tak ho musíte reprezentovat pomocí DOMu a to je AFAIK náročné na výkon. Další možnost je používat canvas, ale potom ztrácíte výhodu HTML. O moderních frontendových technologiích toho moc nevím. Možná se mýlím. O ostatních GUI frameworcích toho také moc nevím.
-
Někde jsem četl, že u Atomu je skutečně problém HTML. Když chcete v HTML nějaký jiný než defaultní widget, tak ho musíte reprezentovat pomocí DOMu a to je AFAIK náročné na výkon. Další možnost je používat canvas, ale potom ztrácíte výhodu HTML. O moderních frontendových technologiích toho moc nevím. Možná se mýlím. O ostatních GUI frameworcích toho také moc nevím.
Hm, to bych necekal. Zvlast, kdyz na webu se to bezne pouziva a bottleneck byva spis v odezve nebo serveru. Z prolizani bugu Atomu na GitHubu jsem spis nabyl dojmu, ze je tam problem s architekturou - neco se na zacatku blbe zvolilo a nasledky vidime do dnes (urcite to bylo u casu startu, jinde nevim).
-
Někde jsem četl, že u Atomu je skutečně problém HTML. Když chcete v HTML nějaký jiný než defaultní widget, tak ho musíte reprezentovat pomocí DOMu a to je AFAIK náročné na výkon. Další možnost je používat canvas, ale potom ztrácíte výhodu HTML. O moderních frontendových technologiích toho moc nevím. Možná se mýlím. O ostatních GUI frameworcích toho také moc nevím.
Hm, to bych necekal. Zvlast, kdyz na webu se to bezne pouziva a bottleneck byva spis v odezve nebo serveru. Z prolizani bugu Atomu na GitHubu jsem spis nabyl dojmu, ze je tam problem s architekturou - neco se na zacatku blbe zvolilo a nasledky vidime do dnes (urcite to bylo u casu startu, jinde nevim).
Na webu je také nutné omezovat velikost stránky, proto se používá stránkování. Příliš velká stránka vám zamrzne prohlížeč. U Atomu je problém s velkými soubory (možná už není). Asi to bude částečně architekturou. Pro textový editor stačí GUI jako má Emacs. HTML je IMHO zbytečné.
-
JavaFX ;)
Ovšem v porovnání c sharpem je javafx na tom trochu časově hůř. To znamená, že projekt trvá v Javě cca 5x déle než v C sharp. Je to díky tomu, že Java je schizofrenní a s méně dokonalou dokumentací než c sharp. Schizofrennost Javy je ten fakt, že se musíme předělávat ze swift na fx. Když jsem se učil v základu pracovat s Javou, dělal jsem všechno ve swift podle pár let staré učebnice a najednou jsem našel fx a pochopil, že swift je minulost... Java je prostě těžká schíza. Ale já ji mám stejně rád. A doufám, že ji Oracle nehodí přes palubu. To by mě naštvalo.
A podobnost Javy a c sharpu? V syntaxi. Obecně se mi s c sharpem pracuje líp kvůli perfektnímu prostředí Visual Studia, které mi umožňuje být při tvorbě rychlý a přesný. U Javy jsem používal Eclipse = čistokrevná hrůza a teď dělám v Netbeans = menší hrůza. Abyste například něco vizualizovali v Netbeans potřebujete přídavek - třeba Scene Builder. Dlouho jsem si na tuto sračku nemohl zvyknout a nakonec to dopadlo tak, že si to pozicuju, styluju a parametruju stejně v kódu.
Na Javě mám rád její multiplatformitu. Vytvořím si aplikaci jar včetně všech knihoven (což samozřejmě Netbeans neumí), tento jediný soubor spustím na Windows i Linuxu. No problemo. 8)
Ještě jsem zvědavý na jednu poslední věc... zda je Java zpětně kompatibilní. PHP třeba není. Tak uvidím, co Java. Jestli nebude Java zpětně kompatibilní, tak prohlásím vývojáře Javy za dementy a začnu asi pracovat s lopatou, ta bude s hlínou kompatibilní vždycky. :(
Mimochodem, otevřel jsem pár 3D grafických Java projektů tvořených před 12ti lety a bez šance.... Takže mám takové hrozivé podezření..... Raději nemyslet.
No vita a lopata je i v ověření nespamu. Tomu se říká znamení osudu.
-
swift je minulost
myslite swing
eště jsem zvědavý na jednu poslední věc... zda je Java zpětně kompatibilní.
co si vojine kefaline predstavujete pod zpetnou kompatibilitou?
-
JavaFX ;)
Ovšem v porovnání c sharpem je javafx na tom trochu časově hůř. To znamená, že projekt trvá v Javě cca 5x déle než v C sharp. […] musíme předělávat ze swift na fx. […] Ještě jsem zvědavý na jednu poslední věc... zda je Java zpětně kompatibilní.
Opravdu by mne zajímalo, jestli to je myšlené vážně, nebo to měla být parodie Zelenáče. Nejdřív napsat takhle konkrétní srovnání, to si čtenář říká „pane jo, ten musí mít zkušeností, když dokáže nejrůznější typy projektů shrnout do jediného ‚5× déle‘“. A pak z něj vypadne, že vlastně o Javě prakticky nic neví a že to „5× déle“ je prostě jen hausnumero vycucané z prstu.
Jinak při vývoji Javy se dbá na zpětnou kompatibilitu až extrémně, třeba třídy a metody označené jako zastaralé už ve verzi 1.1 jsou pořád součástí JDK. Programy napsané pod Javou 1.0 by měly jít pořád spustit pod současným JRE, samozřejmě pokud nepoužívají vlastnosti konkrétního JRE. I kód napsaný pod Javou 1.0 by měl jít přeložit současným kompilátorem a se současným JDK, jediný problém může být s přidáním metod do rozhraní, která ten kód implementuje. Vím o jediném takovém reálném problému, a to přidání podpory pro W3C DOM Level 3 v Javě 5. Java 8 pro tyhle případy zavedla default metody. Někdo tvrdí, že to udržování zpětné kompatibility je až na škodu, třeba generika kvůli tomu byla implementována hůř než by mohla být (což je důvod, proč je C# má lepší). První plánované rozbití zpětné kompatibility se plánuje do Javy 9 v rámci projektu Jigsaw, tj. zavedení modularity přímo jako součásti základního běhového prostředí. A to opět nebude znamenat, že staré programy pod novou Javou nepustíte, pouze bude nutné udělat nějaké úpravy v nových programech, pokud v nich budete chtít modularitu používat.
-
Mně přijde, že JavaFX je u větších GUI pomalejší než Swing.
-
uz tu je .Net Core 1.0, ktore je multiplatformove a mozes robit v C#.
-
:) swing swift není to jedno? Ano, možná jsem začátečník. Zatím pracuji (po 12 leté přestávce) s Javou cca 8 měsíců, vytvořil jsem si pár projektů, třeba 3d šetřič, malovací program obdoba Pinty, manager program na mdb databázi, univerzální benchmark apod. A ano, na problém se zpětnou kompatibilitou jsem narazil, bohužel jsem to nezdokumentoval.
I když... zajímal by mě váš názor... Třeba na ten Benchmark Universal, který umí porovnat výsledky windows i linux stanice:
http://www.instaluj.cz/benchmark-universal
-
Jen aby tu Javu za chvili nepohrbili ;)
http://www.zive.cz/bleskovky/odbornici-varuji-oracle-by-mohl-pohrbit-javu-prestava-jej-udajne-zajimat/sc-4-a-183024/default.aspx (http://www.zive.cz/bleskovky/odbornici-varuji-oracle-by-mohl-pohrbit-javu-prestava-jej-udajne-zajimat/sc-4-a-183024/default.aspx)
-
Která korporace stojí za Pythonem, Perlem... čímkoli dalším?
-
praveze ziadna a tak to potom vyzera ;D
-
To není pravda. Python je sice patlanice, ale to je tím, že ti lidé jen nic moc neuměli. Pokud se na jazyk vrhnou odborníci, tak z toho uděláš špičku i bez firmy.
-
Programujem uz vyse 10 rokov a mozem povedat ze v jazykoch a frameworkoch ktore za sebou nemaju velkeho hraca ktory koordinuje vyvoj sa programuje horsie. Programoval som teraz asi pol roka v Node.Js a ked som sa vratil k .NET tak som si vsimol aky je to rozdiel. Proste .NET je ucelena konzistenta platforma v ktorej sa mi dobre programuje castokrat uz intuitivne dokazem urcit nazov triedy alebo metody. Node sa spolieha na roznych open source patlalov kazda kniznica alebo npm balik sa pouziva inak vacsinou su to neoptimalizovane one man shows. js programatori nedodrziavaju ziadne konvencie a casto sa stava ze robia spatne nekompatibilne zmeny. Trebars taky react ktory po kazdej verzii meni nazvy metod nema to ziadny standard a programator zabije kopu casu len touto zbytocnou reziou. Castokrat su js programatori pozadu za js normou takze namiesto async await pouzivaju callbacky namiesto tried prototypy nepoznaju let constatd atd, zlaty .NET
-
A ano, na problém se zpětnou kompatibilitou jsem narazil, bohužel jsem to nezdokumentoval.
To už si ani nepamatujete, jaký typ problému to byl? Aplikace přeložená se starším JDK neběžela pod novějším, nebo nešla pod novějším JDK přeložit?
I když... zajímal by mě váš názor... Třeba na ten Benchmark Universal, který umí porovnat výsledky windows i linux stanice:
Názor na co? Tedy, především jsem nepochopil, co to má vlastně testovat – výkon JVM, konfiguraci JVM, něco jiného?
-
Jen aby tu Javu za chvili nepohrbili ;)
http://www.zive.cz/bleskovky/odbornici-varuji-oracle-by-mohl-pohrbit-javu-prestava-jej-udajne-zajimat/sc-4-a-183024/default.aspx (http://www.zive.cz/bleskovky/odbornici-varuji-oracle-by-mohl-pohrbit-javu-prestava-jej-udajne-zajimat/sc-4-a-183024/default.aspx)
Java je pro Oracle klíčový produkt, vždyť skoro vše, co Oracle dělá, je na Javě přímo postavené, nebo se nejčastěji z Javy používá. CEO Oraclu Safra Catz prohlásila (http://www.itbiz.cz/zpravicky/oracle-nekoupili-jsme-sun-abychom-mohli-zalovat-google), že Oracle koupil Sun právě kvůli Javě, byla pro ně strategicky důležitá.
-
Není třeba psát informace pro toho, kdo si je nechce přečíst. Proč to vlastně komentujete? :D :D :D
-
Jen aby tu Javu za chvili nepohrbili ;)
http://www.zive.cz/bleskovky/odbornici-varuji-oracle-by-mohl-pohrbit-javu-prestava-jej-udajne-zajimat/sc-4-a-183024/default.aspx (http://www.zive.cz/bleskovky/odbornici-varuji-oracle-by-mohl-pohrbit-javu-prestava-jej-udajne-zajimat/sc-4-a-183024/default.aspx)
Medialne prdy zo zive a artechnica si netreba vsimat. Oracle zarezal GlassFish, technicky neznaly redaktor napise."Oracle rusi Java EE". Pritom je len jeden aplikacny server z mnohych, s malym podielom na trhu. Ak si dobre pamatam oracle ma este jeden, ktory napodiv nezarezal. Najpopularnejsi je JBoss od Red Hatu. Da sa zaobist aj bez aplikacneho servera, proste iba s cistym webserverom (tomcat, jetty). Java EE komponenty tiez nevyraba oracle, ale ine firmy. Nie je to prvy prd, co bol na arstechnica uvedeny, ale nebude ani posledny. (O zive nehovorim, to nie je ani bulvar, ale rovno sracka)
-
X firiem, X komponentov, X problemov a len samy chaos :)
-
Oracle zarezal GlassFish, technicky neznaly redaktor napise."Oracle rusi Java EE". Pritom je len jeden aplikacny server z mnohych, s malym podielom na trhu. Ak si dobre pamatam oracle ma este jeden, ktory napodiv nezarezal. Najpopularnejsi je JBoss od Red Hatu.
Oracle měl kdysi dávno svůj vlastní Java EE aplikační server OC4J. Pak – dávno před Javou, totiž Sunem – koupil firmu BEA a jejich WebLogic, to je dnes aplikační server Oracle. GlassFish získal spolu se Sunem. Oracle ruší komerční podporu GlassFish a zákazníky převádí na WebLogic – nedává žádný smysl, aby měl dva komerční aplikační servery (zvlášť když WebLogic je úplně jiná liga než GlassFish). Opensource GlassFish nadále zůstává referenční implementací Java EE.
-
No nevim jestli je to s tim opoustenim tak zhave - Not dead yet: Oracle promises big plans for Java EE (http://arstechnica.com/information-technology/2016/07/not-dead-yet-oracle-promises-big-plans-for-java-ee/).