"Állapotfelmérés: Mono"

Szerszám

A H Open hasábjain jelent meg egy érdekes cikk Miguel de Icaza-ról - a szabad és nyílt forrású szoftverfejlesztőről, aki a GNOME mellett többek közt a Midnight Commander-ről, a Gnumeric-ről és a Linux kernelhez nyújtott hozzájárulásairól ismert -, a .NET-ről és a Mono-ról. A Mono és a GNOME kapcsolatáról, a Mono-val kapcsolatos ellenérzésekről, a Mono jövőjéről, lehetséges felhasználásáról a GNOME projekttel kapcsolatban. A cikk itt olvasható.

( kl3on v | 2009. 08. 20., cs – 22:15 )

Bírom ezt az embert, de miért erőlteti ennyire, hogy a Java már halott?

,,Java was platform independent...''
,,..purpose of Java, and were designed to..''

--
Keep it simple, stupid.

Elso feladat: sorolja fel az ubuntuban alapbol helyet kapo, sokak altal hasznalt java alkalmazasokat! (1 vagy annal tobb felsorolasa: 0 pont; ures halmaz/ nincs ilyen / stb: max pont)

Masodik feladat: sorolja fel az ubuntuban alapbol helyet kapo, sokak altal hasznalt .net alapu alkalmazasokat (tomboy: 1 pont, f-spot: 1-pont......)

Vesd össze, hogy Java mióta van, és .net. Nézd meg, hogy az elmúlt egy évben mennyit fejlődtek.

Vesd össze, hogy .net-ben milyen kliens alkalmazásokat lehet írni, és Java-ban milyet (a managert úgyis az érdekli).

A Java-t jelenleg az Oracle birtokolja, és nem láttam, hogy annyira nyomná, mint amennyire az MS nyomja a .net-et (itt nem marketinget, hanem fejlesztést értek).

Tudod, a penzugyi szferaban nem valaszthatom meg szabadon, milyen nyelven kezdem el a projektet, hanem a menedzsment donti el. Ha a menedzsment azt mondja, nem akar fuggni a microsofttol, akkor java lesz, ha azt mondja, igy-is-ugy-is fuggunk, akkor legalabb ne szopassuk magunkat, akkor meg dotnet, aztan ehhez keresnek programozokat, szerintem ez ennyire egyszeru.

De az azert brutalis, hogy ahol emberek megvalaszthatjak a nyelvet - mert pl. epp a szabadidos, opensource projektjukrol van szo - akkor mennyire NEM hasznalnak javat. Ez egyebkent igaz a .NET-re is: http://danlorenc.blogspot.com/2009/08/stackoverflow-experiment-results…

En meg ugy vagyok vele, addig jar a korso a kutra, amig el nem torik. Az meg, hogy a C#.NET-et egy fokkal tuleleseselyesebbnek tartom, az az, hogy a C# picivel kozelebb all a pythonhoz/rubyhoz, mint a java, de teny, nem sokkal.

Az a baj ezekkel a grafikonokkal, hogy ha csak rápislantasz, akkor könnyen félreérthetőek a tendenciák.
Pl. a balszélen a C, C++, és Java együtt kb. 65%, de most csak kb. 35%. Ha megnézzük a C#-ot, akkor látszik, hogy nem ennek kárára csökkent a többiek részesedése. Nagyjából látszik, hogy a C++ és a Java már nagyjából egy érték körül ingadozik. Kb. amennyivel csökkent a C++, annyival nött a Java. A C még vaszínűleg csökkenő ágban van. De hova lett a C vesztesége? A C# növekedése lassú, de nagyjából lineáris. Alapvetően nem a C# az oka a C csökkenésének.
Ez az ami látszik a grafikonról.
Ha felteszünk még néhány nyelvet a grafikonra, akkor előkerül a C veszteségének egy része: http://www.ohloh.net/languages/compare?measure=commits&percent=&l0=c&l1…
A perl kicsit vesztett népszerűségéből, a php és a python nagyjából együtt halad. Tölük lemaradva következik a ruby és a C#. 2008 közepéig kb. együtt növekedtek, azóta a ruby stagnál, illetve kis mértékben visszaesett.
Az persze jó kérdés, hogy a statisztikai adatokat hogyan gyűjtötték össze, a tényleges fejlesztések hány százaléka alapján készült a kimutatás.

re: jesszusom

Nyugi, az en melohelyemen meg projektjeimben is repked a spring, a hybernate, meg amit akarsz...

Csak azt is tudom, hogy ha hazamegyek, vagy en valasztok a projekthez nyelvet, az nem java.

Otthon max a hirekben olvasok javarol, hogy epp miket talalnak ki, mert az EE architekturalis mintak jo resze jo es valid.

Ennek megfeleloen szepen hasznalom is oket - sok mas nyelvbol.

A StackOverflow felmeresenek eredmenyet nem tekintenem fuggetlen es autentikus forrasnak, a ket inditoja, Joel es Jeff koztudottan .NET- es Windows programozok, igy a stackoverflow, mint programozoi forum, kozosseg alakitasaban ennek nem keves szerepe volt, hogy az inditoi a projektnek mit, kit ismertek, mint mertekado segitotars a SO kozossegenek alapitasara.

Viszont a Linux-desktopra gyártott alkalmazások szempontjából nem :). És tény, hogy pl Ubuntun a sun-java6-jre csomagtól nagyon kevés csomag függ, még a mono-runtime-hoz viszonyítva is. A python csomaghoz viszonyítva viszont mindkettőtől nevetségesen kevés dolog függ, és szerintem itt lehet a kutya, meg ez a két környezet elásva.

"The original objective of Mono was not so much to achieve compatibility with Microsoft as to enable faster development of distribution and language neutral Linux desktop applications."

Ebből a szempontból halottnak lehet nyilvánítani, mert bár a gépek még életben tartják, de a doki már a szervadományozási papírt lobogtatja a rokonoknak.

Úgy van. Szerver oldalon még megélhetne, de kliens oldalon csak linuxon futó alkalmazást fejleszteni, mikor ugyanannyi erőfeszítéssel java-ban megoldható hogy mindenhol fusson? Vicc.

A szerver oldali történetnek meg az a baja, hogy ott mindenek fölött áll a teljeskörű funkcionalitás, a teljesítmény, a stabilitás, és ami ezt bizonyítja, a meglévő installált és komoly feladatokat futtató alkalmazások száma.
Valahogy egy novell-es side projectről, amit nyilván csak azért hoztak létre hogy a microsoftnak nyaljanak (és addig tart amíg a jó viszony) nem tudom elképzelni hogy valaha is kielégíti ezeket a feltételeket.
Ha egyszer muszáj lesz C#-ban fejlesztenem, akkor az windowsra fog készülni, windowsos eszközökkel.

Az pedig, hogy egy nyelvben valamit kényelmetlenebb egy picit lekódolni, lényegtelen. Ha viszont nincs refaktor, pl. a legtriviálisabb az átnevezés, az használhatatlanná teszi az egészet.

( Aadaam v | 2009. 08. 20., cs – 23:13 )

Magara a cikkre reagalva: a gnome appok jo resze pythonban van irva. Ezzel kulonosebb baj nincs, egeszen addig, amig IDE-t nem kell irni, automatikus refactoring, civilizalt kodkiegeszites, meg egyeb szintaxisfa-alapu muveletek igenyevel, ezek elvegzesere ugyanis ez a nyelv nem alkalmas, mint ahogy a legtobb mai nyelv nem az, kiveve a javat es tarsait (scala,anyone?), meg a jo oreg C++ -t.

Persze ezek egyszeru appokhoz nem is igazan kellenek, de jo ha van egy ilyen is a keszleten, es aktivan karban van tartva, meg fejlesztik, stb.

Nem gondolom azt, hogy a tomboyt ne lehetne ujrairni, ha az MS bejelentene a C#-ra az igenyet. De ha ujra is kene irni, akkor is csak egy C# kozeli nyelvet kene kitalalni (a c# java kozeli, meg az android is, megse ettek meg oket reggelire), meg egy uj language runtime vagy VM, es makrokkal atirni arra a nyelvre. Na nem mintha a tomboy bonyolult program lenne....

(Az meg szepen nezne ki, ha az MS patensjogot formalna minden, az altaluk kitalalt nyelven irt szoftverre. Akkor azt hiszem, elerne az anyazas a kritikus penztomeget, ahol ez mar nem vicces - vallalati alkalmazasok .netben, ezek meg szabadalmazgatnak? na nem.)

Az MS pedig a .NET-tel egy mindenki szamara kedvezobb utat valasztott vilaguralmi tervei vegrehajtasahoz: a C#.NET egyszeruen klasszisokkal jobb, modernebb, mint a java, es ez meglatszik a gnome projecten is, megha ehhez kell is de Icaza munkassaga.

Nem teljesen vilagos, hogy mi a problema a Python-nal a szintaxisfa alapu muveletekkel. Ha jol latom van hozza antlr target. Az sem teljesen tiszta, hogy a Scala miert lenne olyan sokkal jobb nala ebben a feladatban? (Ketsegtelen, hogy az eros tipusossag segithet ezen a teren.) Esetleg probaltal mast is a beepitett parser combinator-on (valtozik valamit 2.8-ban?) kivul? (Ez tenyleg erdel, fontolgatom, hogy keszulo Scalaz, vagy a kiama projektet alaposabban megismerem. Ha van otleted, hogy melyiket erdemes, ne tartsd magadban.)

A C# szerinted tenyleg ennyivel jobb mint a Java? Nekem a Visual Studio (2005) nem igazan allt kezre (szeretek kenyelmesen programozni) es a nyelvi elemek sem teljesen gyoztek meg arrol (meg a 2.0 tajekan, tehat eleg reg), hogy azt lenne praktikusabb hasznalnom.

Igen, a celzas itt az eros tipusossagon volt, pythonnal statikus kodelemzessel is mindig kideritheto egy valtozo tipusa? Az IDE-nel ez a lenyeg sokszor.

Persze lehet, fejlodnek a toolok es elobb-utobb ennyit "lefuttatnak", hogy kiderulhessen, mert szemmel ugye latjuk, elobb-utobb a gep is fogja latni.

A scala egy erosen tipusos ujgeneracios nyelv, ezert van oda erte a java vilag (theserverside, infoq, artima)

A modernsegrol (egybe a kov. hozzaszolasra is valaszolva): Egyfelol a java az 1.5-ben egy csomo "ja, igy is lehet?" dolgot hozott be a .net-bol, peldaul a just in time compiling is onnan jon at, de ami engem rendkivul zavar, az a korulmenyes reflection API. Lehet, hogy sarlatansag egyesek szerint a reflektiv programozas, en azt gondolom, azon dolgok hosszu soraba tartozik, amit esszel kell jol tudni hasznalni. Nem mellesleg az aktualis EE buzzword, az Inversion of Control is reflektivitas-alapu sokszor. A C#-ba pedig nyelvi szinten bekerultek funkcionalis elemek is (kulonosen: lambda operator), ami lehetove teszi pl. a linq-t (sot, igazsag szerint barmely DSL-t), ez megint olyan, hogy persze, lehet nelkule elni, de latjuk, hogy ezen ugralnak a javasok (Groowy, hogy csak a legregebbit emlitsuk).

Osszessegeben en ugy latom - lehet erte kovezni - hogy a java kozosseg fobb beszelgetesei igazsag szerint a lemaradasukrol szol, reszint a C# / .NET CLR vilag fele, reszint pedig azon nyelvek fele, amiket a java szuletese ota kitalaltak (ruby, python, php, javascript - tudom, mar mind fut jvm felett), ill. a nyelv korulmenyessegenek kerulgeteserol (DSL -ek).

En oszinten szolva nem latom a scala-t megoldasnak, mert tul sok benne az operator, es emiatt felo, hogy nem terjed el - egy picit tavolabbi scope-ban pedig egyszeruen potmegoldasnak gondolom, egy problema nemmegoldasanak. De nyilvan kikuszobolheti a java nyelv egy csomo kenyelmetlenseget, tehat ha a java toolsetre valamiert epitened kell, maga a modul mindegy, miben keszul (nem epul ra vmi olyan, ami feltetelezi, hogy java nyelvu), viszont sejted, hogy jelentosen gyorsitana a dolgot ha nem kene a nyelvet kerulgetni (pl. a lambda operator miatt), akkor jo valasztas a scala.

De en elotte a helyedben megneznem, nincs-e ehhez egy jo python modul (vagy barmi...)...

Hatalmas csusztatasokat irsz.
A JIT Compiling a HotSpot JVM-mel jott be a platform eszkozei koze, 1999-ben a Java 1.2-es verziojaban, mig a .NET Framework elso verzioja 3 evvel kesobb kerult nyilvanossagra.

A generikus adattipusok tamogatasa a .NET keretrendszerbe a 2.0-s verzioval jott be, 2006-ban, ket evvel kesobb, mint a Java 1.5.s verziojanak megjelenese.

Amit te emlitesz, miszerint C#-ban van egy cosmo olyan nyelvi elem, ami Java-ban nincs, es ezen ugralnak a Javasok, az egyszeruen csusztatas: a Javaban tenyleg nincs ilyen nyelvi elem, amit emlitettel, Groovy, az csak egy olyan nyelv, ami JVM bytecode-ra fordit, es kb. pont ennyi koze van a Java-hoz, mint szoftver platformhoz.

Dontsuk el, mit hasonlitunk ossze, ha mar hasonlitunk:
- A Java platformot es a .NET platformot, ha mar JIT-rol es hasonlokrol beszelunk,
- A Java programozasi nyelvet (amely csak egyike a JVM nyelveknek) a C#-pal (amely csak egyike a CLR nyelveknek),
- A Java SE, EE, ME API-kat a .NET API-kkal

> C++-ban mióta vannak Template-k? :)

Ezt találtam:

1990 - First ANSI X3J16 technical meeting (Somerset, NJ) [see group photograph, courtesy of Andrew Koenig]; templates accepted (Seattle, WA); exceptions accepted (Palo Alto, CA); first Borland C++ release

http://www.softwarepreservation.org/projects/c_plus_plus

The October
1991 AT&T release 3.0 of Cfront (my* original C++ compiler
[121]) was the first to support templates.

*Bjarne Stroustrup: Evolving a language in and for the real world: C++ 1991-2006