Per Red Hat un application server open

La leader del mercato open source ha introdotto sul mercato il suo primo application server J2EE. Il software integra fra loro diversi progetti open source

San Francisco (USA) - Red Hat ha scelto l'evento clou del mondo open source, il LinuxWorld di San Francisco, per lanciare ufficialmente il suo primo e da lungo tempo preannunciato application server Java.

Basato sul software open source JOnAS del consorzio ObjectWeb, Red Hat AS è un application server basato sulla piattaforma J2EE che comprende molte delle funzionalità offerte dalle soluzioni proprietarie. L'intenzione di Red Hat è proprio quella di integrare nella propria piattaforma enterprise Linux un application server che, pur se leggero e relativamente economico, sia dotato di caratteristiche e supporto di livello commerciale.

"I nostri clienti ci chiedono da tempo un application server open source che sia pienamente interoperabile con le soluzioni J2EE già sul mercato, in questo modo possono far leva sui vantaggi offerti da un'applicazione open source conservando nello stesso tempo i propri investimenti", ha detto Paul Cormier, executive vice president of engineering di Red Hat. "Le comunità open source del Web e di Java stanno fiorendo ed espandendosi grazie ad organizzazioni che, come Apache, ObjectWeb ed Eclipse, stanno guidando l'innovazione. Il nostro application server rappresenta un naturale passo avanti per l'open source".
Oltre a JOnAS, Red Hat AS comprende altri componenti di ObjectWeb, tra cui il middleware di messaggistica JORAM e il distributed transaction manager JOTM, e li integra in modo omogeneo con il software open source Tomcat della Apache Software Foundation. Grazie alla fusione di questi progetti, Red Hat AS è in grado di fornire, attraverso un'unica applicazione, le funzionalità di Web ed enterprise application server ed il supporto a JakartaServer, ai Web service e alla messaggistica.

Sebbene la società dal cappello rosso debba ancora ultimare tutti i test, Red Hat AS promette di fornire piena interoperabilità con gli altri application manager basati sulla piattaforma J2EE di Sun, tra cui quelli di BEA, IBM e Oracle. Questi tre nomi sono fra i leader del mercato degli application server, tuttavia, come proprie partner, Red Hat spera che possano appoggiare il suo AS in nome di "un approccio allo sviluppo maggiormente collaborativo". Una speranza retta da basi piuttosto solide visto che tutte e tre le partner hanno già annunciato il proprio supporto a Red Hat AS: IBM farà in modo che lavori al meglio sulla propria linea di sistemi eServer, BEA si preoccuperà di integrarlo con il proprio ambiente di sviluppo Java Beehive, mentre Oracle collaborerà a svilupparne il supporto per il suo JDeveloper 10g.
118 Commenti alla Notizia Per Red Hat un application server open
Ordina
  • Subsequently http://www.badcreditcarloans9.com/bad-credit-loans... high income bad credit home loans You can lender apply online with no processing fee for wedding loans for bad credit. http://www.badcreditcarloans9.com/bad-credit/bad-c... best bad credit financing for mobile homes When you are in a crisis situation, espanol accessible version then some may charge you more. http://www.badcreditcarloans9.com/bad-credit-loan-... best bad credit loan against car Adverse credit disables a borrower to take #link1# a loan, as lender finds it risky to lend to the borrower. .
    non+autenticato
  • For The Time Being http://www.felipelopezfoundation.org/ Garcinia Cambogia Review A 40 ounce bottle of water garcinia would be baseline .
    non+autenticato
  • Ma quale .NET J2EE spacca il kiulo di brutto
    si è vero ci metterai 8 anni per fare un cenco di hello mammete pero vuoi mettere la figata a costruire tutti quei simpatici beans che si parlano
    fra di loro ?A bocca aperta . Rotola dal ridere
    non+autenticato
  • L'articolo parlava di application server J2EE e il dibattito di questo forum verte per lo più su C# e Java visti come linguaggio.

    L'architettura di un AS ha poco a che vedere con le decorazioni più o meno carine rese disponibili da un linguaggio.

    Come ho già scritto in replica a qualcuno vi ricordo che in .NET:
    - non esistono specifiche aperte e standardizzare per un'application server simile a J2EE.
    - non esiste un meccanismo standard per la persistenza, come il CMP per un EJB in un AS J2EE.
    - non esiste un mecanismo standard per messaggistica tra oggetti come i message driven bean
    - non esiste un meccanismo standard per la manipolazione di componenti come gli MBean e l'MBeanServer in java.
    - non esiste una interfaccia di connessione astratta verso EIS terzi, come JCA
    - non esiste un meccanismo di astrazione per servizi di directory evoluto come JNDI. Non ditemi System.Directory...
    - non esiste un meccanismo pluggabile standard di autenticazione-autorizzazione come JAAS.


    Se voglio costruire una applicazione scalabile, estensibile, manutenibile, che lavori nativamente con un misto di interattività con l'interfaccia e con l'asincronia di job schedulati, che supporti servizi di sutenticazione enterprise com eLDAP, non ho molti dubbi su cosa usare. Java.

    Se voglio scrivere un sitarello leggero e veloce, mi sta bene ASP.NET.

    Attendo repliche tecniche.
    non+autenticato

  • - Scritto da: Anonimo
    > L'articolo parlava di application server
    > J2EE e il dibattito di questo forum verte
    > per lo più su C# e Java visti come
    > linguaggio.

    si sai com'è qui ognuno ha la sua bandiera chi net e chi java
    questi articoli sono la linfa per i trollzA bocca aperta

    > - non esistono specifiche aperte e
    > standardizzare per un'application server
    > simile a J2EE.

    esiste il Remoting che poi sarebbe l'equivalente dell'RMI
    cui si basa il tuo bel AS che per inciso non è altro
    che una specifica fuffosa alla CORBA....
    cmq ASP.NET gira su una specie di application server...
    microsoft lo chiama application hosting.
    a si non ha specifiche perche semplicemente non servono
    il framework dotnez contiene security active directory
    certificati digitali crittografia ecc ecc ecc.
    l'APPLICATION SERVER è nato perche java di nativo
    non ha un cazzo cosi 4 ingegneri ci hanno messo 3 anni
    per tirare fuori 8mila specifiche super cazzute solo
    per mangiare ancora di piu i soldi sopra le teste delle
    aziende boccalone.

    > - non esiste un meccanismo standard per la
    > persistenza, come il CMP per un EJB in un AS
    > J2EE.

    ma come sei sofisticato,si vede che quelli della SUN
    ti hanno ammaestrato per bene.
    la persistenza dei dati la fa il tuo bel databasino
    tipo che so postgresql o oracle o mysql.
    java crea delle viste bitmap sul loro container e ti fa credere
    che è grazie a lui che i dati stanno materilizzati pure quando
    dai un calcio alla macchina.


    > - non esiste un mecanismo standard per
    > messaggistica tra oggetti come i message
    > driven bean

    System.Messaging

    > - non esiste un meccanismo standard per la
    > manipolazione di componenti come gli MBean e
    > l'MBeanServer in java.

    i controlli ASP.NET sono managed e puoi manipolarli
    direttamente dall'assembly

    > - non esiste una interfaccia di connessione
    > astratta verso EIS terzi, come JCA

    un giorno mi spiegherai cosa te ne fai di tutte queste siglette..
    ma porca puttana cosa cazzo ti costa dire connettori db ?
    no è ? EIS JCA fa piu scena vero ?Sorride

    > - non esiste un meccanismo di astrazione per
    > servizi di directory evoluto come JNDI. Non
    > ditemi System.Directory...

    ok te ne dico un'altro Novell.LDAP

    > - non esiste un meccanismo pluggabile
    > standard di autenticazione-autorizzazione
    > come JAAS.

    Whats ?
    System.Security guarda quanti meccanismi ci stanno...

    >
    > Se voglio costruire una applicazione
    > scalabile, estensibile, manutenibile, che
    > lavori nativamente con un misto di
    > interattività con l'interfaccia e con
    > l'asincronia di job schedulati, che supporti
    > servizi di sutenticazione enterprise com
    > eLDAP, non ho molti dubbi su cosa usare.
    > Java.

    3 database su macchine diverse, 1 per le query 1 per le insert e uno per la replica
    sistema high avail linux Xseries345 con raid5
    mod_mono e proxy su hearthbeat per la distribuzione
    asp.net e controlli per la logica.
    ma che cazzo stai a di' fratello la scalabilità è 98% hardware
    1% software 1% configurazione.



    > Se voglio scrivere un sitarello leggero e
    > veloce, mi sta bene ASP.NET.
    >
    > Attendo repliche tecniche.
    non+autenticato
  • > > - non esistono specifiche aperte e
    > > standardizzare per un'application server
    > > simile a J2EE.
    >
    > esiste il Remoting che poi sarebbe
    > l'equivalente dell'RMI
    > cui si basa il tuo bel AS che per inciso non
    > è altro
    > che una specifica fuffosa alla CORBA....
    > cmq ASP.NET gira su una specie di
    > application server...
    > microsoft lo chiama application hosting.
    > a si non ha specifiche perche semplicemente
    > non servono
    > il framework dotnez contiene security active
    > directory
    > certificati digitali crittografia ecc ecc
    > ecc.
    > l'APPLICATION SERVER è nato perche
    > java di nativo
    > non ha un cazzo cosi 4 ingegneri ci hanno
    > messo 3 anni
    > per tirare fuori 8mila specifiche super
    > cazzute solo
    > per mangiare ancora di piu i soldi sopra le
    > teste delle
    > aziende boccalone.

    Ok, dimostri di non aver mai neppure provato un J2EE.
    Confonderlo con un banale RMI è come confondere l'acqua con il minestrone.

    > > - non esiste un meccanismo standard per
    > la
    > > persistenza, come il CMP per un EJB in
    > un AS
    > > J2EE.
    >
    > ma come sei sofisticato,si vede che quelli
    > della SUN
    > ti hanno ammaestrato per bene.
    > la persistenza dei dati la fa il tuo bel
    > databasino
    > tipo che so postgresql o oracle o mysql.
    > java crea delle viste bitmap sul loro
    > container e ti fa credere
    > che è grazie a lui che i dati stanno
    > materilizzati pure quando
    > dai un calcio alla macchina.

    Tesoro caro, l'indipendenza astratta del db sottostante in J2EE c'è, tant'è vero che non devi scrivere istruzioni SQL.

    In .NET non c'è. ADO.NET è una descrizione ad oggetti delle strutture relazionali del db. I meccanismi di persistenza di un J2EE (qualunque esso sia) invece nasconde al programmatore la struttura relazionale sottostante. Ti sembra una differenza sottile????

    > > - non esiste un mecanismo standard per
    > > messaggistica tra oggetti come i message
    > > driven bean
    >
    > System.Messaging

    System.Messaging usa il servizio MSMQ (sigle sigle sigle.... anche per M$) di windows, tra l'altro neppure managed. System.Messaging non è una specifica che descrive interfacce e che lasci a chiunque una propria implementazione.

    Dai un occhio a Mono, tu che lo conosci, è guarda i sorgenti del System.Messaging....... e tutto un NotImplementedException!!!!!!!!!!!!!!

    Il JMS (Java Message System) di Java è un banale insieme di interfacce. Di implementazioni ve ne sono a bizzeffe, managed o no.

    > > - non esiste un meccanismo standard per
    > la
    > > manipolazione di componenti come gli
    > MBean e
    > > l'MBeanServer in java.
    >
    > i controlli ASP.NET sono managed e puoi
    > manipolarli
    > direttamente dall'assembly

    Bene, non sai neppure cosa sono gli MBean. L'idea è questa: prendo un componente (grafico o no, e la maggior parte _non_ lo sono) lo installo nel server (besta copiarlo in una cartella anche a server up) e poi lo manipolo con una interfaccia web o con un client qualunque.

    Se, ad esempio, il componente fosse un server di posta, dopo averlo copiato, posso avviarlo, connettere la coda dei messaggi in arrivo ad un altro componente j2ee che me li smista, agganciarlo ai componenti che necessitano di un server di posta per l'inoltro....ecc ecc

    Questo vale per qualunque sia il componente. In .NET non c'è nulla di simile.

    > > - non esiste una interfaccia di
    > connessione
    > > astratta verso EIS terzi, come JCA
    >
    > un giorno mi spiegherai cosa te ne fai di
    > tutte queste siglette..
    > ma porca puttana cosa cazzo ti costa dire
    > connettori db ?
    > no è ? EIS JCA fa piu scena vero ?Sorride

    JCA _non_ è un connettore di database. JCA sta a un server informativo generico come JDBC sta ai database.

    JCA è una astrazione di connessione generica verso un'altra infrastruttura, ad esempio un application server costruito su una tecnologia diversa da java, o verso una interfaccia che gestisce un hardware custom qualunque.

    > > - non esiste un meccanismo di
    > astrazione per
    > > servizi di directory evoluto come JNDI.
    > Non
    > > ditemi System.Directory...
    >
    > ok te ne dico un'altro Novell.LDAP

    Novell.LDAP gestisce directory LDAP.
    JNDI astrae un _qualunque_ servizio di directory anche non-LDAP.

    Ma vi è così oscura l'utilità dell'astrazione a voi di .NET? Cristo, uno dei capisaldi dell'ingegneria del software è che l'astrazione aiuta e rende le architetture più potenti....

    > > Se voglio costruire una applicazione
    > > scalabile, estensibile, manutenibile,
    > che
    > > lavori nativamente con un misto di
    > > interattività con l'interfaccia
    > e con
    > > l'asincronia di job schedulati, che
    > supporti
    > > servizi di sutenticazione enterprise com
    > > eLDAP, non ho molti dubbi su cosa usare.
    > > Java.
    >
    > 3 database su macchine diverse, 1 per le
    > query 1 per le insert e uno per la replica
    > sistema high avail linux Xseries345 con
    > raid5
    > mod_mono e proxy su hearthbeat per la
    > distribuzione
    > asp.net e controlli per la logica.
    > ma che cazzo stai a di' fratello la
    > scalabilità è 98% hardware
    > 1% software 1% configurazione.

    Ma secondo te, il framework di ASP.NET è un application server??????? ha ha...

    Per convincerti del tutto, prendi una applicazione ASP.NET e scrivici dentro (senza scrivere un servizio o un'applicazione stand-alone a parte) un componente puramente managed che manda ogni ora puntualmente una mail ad un certo indirizzo.... se ci riesci a M$ ti assumono.

    In J2EE son 10 righe.
    non+autenticato
  • > Dai un occhio a Mono, tu che lo conosci,
    > è guarda i sorgenti del
    > System.Messaging....... e tutto un
    > NotImplementedException!!!!!!!!!!!!!!

    http://lists.ximian.com/archives/public/mono-list/...

    http://www.go-mono.com/mono-1.0.html
    (guarda tra i missing)

    http://www.gotmono.com/cgi-bin/yabb/YaBB.pl?board=...
    non+autenticato
  • Leggiti pure questa, dedicata a quelli del ".NET è aperto".
    Bah!

    -------

    http://www.mail-archive.com/mono-list@ximian.com/m...

    System.Messaging is very tied to MSMQ, you can't even opt for another provider, like you do in ADO.NET and on J2EE JMS. That's why I started a Server Project.

    However, I want to extend System.Messaging (in truth, the extensions are planned to go within a Mono.Messaging namespace) to allow for pluggable queueing services providers, but it may penalize performance, or bypass server features: for instance, IBM's now renamed WebSphere MQ, have encoding/codepage conversion of messages built-in.

    Cheers,

    Rafael Teixeira
    Brazilian Polymath

    -------

    e ancora:
    http://www.mail-archive.com/mono-list@ximian.com/m...

    Hey,
    I've actually done some research on this topic... Your right in that the current .Net implementation is tightly bound to MSMQ.(and I don't think anyone wants to write that). So your options are:
    1) Extend the interface to make it usable to other providers
    2) Wait for MS to release the next version of the System.messaging libraries and then implement it.

    I know of numerous people who have bashed the leading MS guys about the crappy Messaging library. The MS developers ackowledged it was a problem but haven't publicly stated when or what they would do about it...

    So it kinda leaves you in a bind... you could start down implementing and extending the class(I'm guessing make it as JMS like as possible) and then back port that work to a new interface if/when MS releases it. Since its messaging it shouldn't be to hard to backport any work done... it would probably be no more than an abstraction interface and you would be done...

    Anthony

    --------

    Questa è la M$ che odio: capace di rendere chiuso pure un framework ad oggetti.
    non+autenticato
  • - Scritto da: Anonimo
    > Questa è la M$ che odio: capace di
    > rendere chiuso pure un framework ad oggetti.

    che ti aspettavi da un framework che utilizza i puntatori ?A bocca aperta
    di managed ci staranno 2 classi tutto il resto è un P/Invoke
    a palla sule librerie wins.
    non+autenticato
  • Basta, ho letto troppe cazzate messe insieme in questo forum .... E meglio M$.NET, noo è meglio JAVA, nooo è meglio RUBY ... mha non capisco.... perchè avete la coppa del nonno infilata negli occhi?

    A) Java è una tecnologia matura
    B) E' un linguaggio di programmazione completo (non come il C++ ma copre gran parte delle sue lacune)
    C) E' realmente multipiattaforma. Se non era per mono la M$ non avrebbe mai realizzato un frameworks per linux. (multipiattorma vuol dire che funziona dappertutto, dai cellulari al PowerMac G5)
    D) Sto studiando JAVA (già, non è un linguaggio immediato) ed è veramente ben fatto. Ottima leggibilità del codice, ottima organizzazione delle librerie e della gestione degli errori, Tutto è un oggetto!!
    E) Puoi realizzare applicazioni molto complesse con una visione del problema quasi banale.

    Non ho provato .NET perchè per ME, SECONDO ME, il futuro è Java. Nel senso che non ci costruisci un sistema operativo ma il 99% delle applicazioni sì.

    Attualmente l'uso principale che ne faccio è Servlet, JSP e programmi con interfaccie grafiche.

    Non per ultimo, per tutti quelli che sparano a zero su PHP, non avete capito nulla! Php ha una potenza (per il web intendo) miliardi di volte superiore a qualunque altro linguaggio per il Web. Basti vedere siti come Yahoo! ... uno dei portali più visitati al mondo. Già è sviluppato in PHP.

    Sapete perchè? Perchè è OpenSource e in quanto tale potete scrivere direttamente voi le API in C++ ed espanderlo a piacere.

    Java potrebbe espandersi ancora molto se la SUN lo rilasciasse sotto una licenza Open...


    aspetto il solito flame,
    notte

    non+autenticato
  • mi dispiace per te amico ma java sta perdendo il treno
    dell'innovazione.
    .NET è una tecnologia migliorata che punta a scansare java
    dall'olimpo delle applicazioni middleware.
    non importa se è stata creata da microsoft,cio che conta
    è la sostanza.
    io per esempio non tocco macchine win da piu di 3 anni,
    però sulla mia debian ho installato mono 1.0 mod_mono
    e sviluppo i miei programmi in c#.
    questo per dirti che se una tecnologia è buona allora
    è giusto utilizzarla,al contrario se fa cagare (ASP) bisogna
    rimpiazzarla con qualcosaltro (PHP)
    non+autenticato
  • > A) Java è una tecnologia matura

    E con forti sostenitori come IBM ed altri

    > B) E' un linguaggio di programmazione
    > completo (non come il C++ ma copre gran
    > parte delle sue lacune)

    Lacune? nel C++, questa mi giunge nuova.
    A volte e' piu' complesso programmare in c++ ma con le librerie giuste si fa tutto presto e bene.

    > C) E' realmente multipiattaforma. Se non era
    > per mono la M$ non avrebbe mai realizzato un
    > frameworks per linux. (multipiattorma vuol
    > dire che funziona dappertutto, dai cellulari
    > al PowerMac G5)

    Anche il python, ed e' open sourceA bocca aperta, anche se non ha tutte le librerie di java.

    > D) Sto studiando JAVA (già, non
    > è un linguaggio immediato) ed
    > è veramente ben fatto. Ottima
    > leggibilità del codice, ottima
    > organizzazione delle librerie e della
    > gestione degli errori, Tutto è un
    > oggetto!!

    Quando si studia un linguaggio sembra di poter far tutto poi ci si scontra sulla realta' di progetti complessi che mettono in luce le carenze del linguaggio di programmazioneTriste

    > E) Puoi realizzare applicazioni molto
    > complesse con una visione del problema quasi
    > banale.

    Seeeh, aspetta e spera, l'idea e quella ma la realta' e' un po' diversa.

    > Non ho provato .NET perchè per ME,
    > SECONDO ME, il futuro è Java. Nel
    > senso che non ci costruisci un sistema
    > operativo ma il 99% delle applicazioni
    > sì.

    Provarlo non ti fara' male almeno per zittire i fan di questo "framework".

    > Attualmente l'uso principale che ne faccio
    > è Servlet, JSP e programmi con
    > interfaccie grafiche.

    Si e' un utilizzo molto comune, pesa parecchio sull'hadware ma adesso che il server costano sempre meno...

    > Non per ultimo, per tutti quelli che sparano
    > a zero su PHP, non avete capito nulla! Php
    > ha una potenza (per il web intendo) miliardi
    > di volte superiore a qualunque altro
    > linguaggio per il Web. Basti vedere siti
    > come Yahoo! ... uno dei portali più
    > visitati al mondo. Già è
    > sviluppato in PHP.

    PHP non e' male ma e soprattutto utilizzato da chi offre hosting, quindi il piu' delle volte una scelta obbligata.

    > Sapete perchè? Perchè è
    > OpenSource e in quanto tale potete scrivere
    > direttamente voi le API in C++ ed espanderlo
    > a piacere.

    Si dal 2% che lo sa fare veramente.

    > Java potrebbe espandersi ancora molto se la
    > SUN lo rilasciasse sotto una licenza Open...

    Gia' ma non verrebbe piu' cosi' sostenuto dalle grosse aziende che non potrebbero specularci sopra.Perplesso

    > aspetto il solito flame,
    > notte

    Perche' "fammare" ogniuno ha le sue esperienze, il piu' delle volte molto diverse, visto l'enorme offerta di risorse.

    Tante volte ci si schiera a favore di un software rispetto ad un altro per esorcizzare la paura di diventare obsoleti come il software che si e' abiutati ad utilizzare.Con la lingua fuori

    non+autenticato
  • > Tante volte ci si schiera a favore di un
    > software rispetto ad un altro per
    > esorcizzare la paura di diventare obsoleti
    > come il software che si e' abiutati ad
    > utilizzare.Con la lingua fuori

    Psicologia da quattro soldi, non è che te l'ha detta l'amica del Mechano?
    non+autenticato

  • - Scritto da: Anonimo
    > > Tante volte ci si schiera a favore di un
    > > software rispetto ad un altro per
    > > esorcizzare la paura di diventare
    > obsoleti
    > > come il software che si e' abiutati ad
    > > utilizzare.Con la lingua fuori
    >
    > Psicologia da quattro soldi, non è
    > che te l'ha detta l'amica del Mechano?

    E' la verità. Ha perfettamente ragione.
    non+autenticato

  • - Scritto da: Anonimo
    > B) E' un linguaggio di programmazione
    > completo (non come il C++ ma copre gran
    > parte delle sue lacune)

    No. java copre con delle enormi lacune, tra cui la mancanza di puntatori e la garbage collection automatica ed incontrollabile, l'enorme POTENZA e CONTROLLO del C++.
    Per non dire delle prestazioni, argomento peraltro inutile: tutti i veri programmatori in assembly e C sanno benissimo che java è ORRIBILMENTE LEEEEEEEEEEEEEENTO, ma chi sceglie java soffre di una particolare distorsione cognitiva che rende impossibile valutare questo aspetto, specialmente perchè abituati ad usare macchine con clock di qualche THz e svariati petabyte di RAM. L'argomento è irresistibilmente ridicolo per chi è abituato a scrivere un copper in 40 bytez o per chi ha implementato una FFT realtime su un PIC con 1 k di ROM, 96 bytez di RAM e 4MHz di clock....
    non+autenticato
  • > L'argomento è irresistibilmente
    > ridicolo per chi è abituato a
    > scrivere un copper in 40 bytez o per chi ha
    > implementato una FFT realtime su un PIC con
    > 1 k di ROM, 96 bytez di RAM e 4MHz di
    > clock....

    Senti qua, il _tuo_ argomento è irresistibilmente ridicolo. Nell'articolo si parla di application server: un calderone nel quale pluggare a caldo componenti software di svariati servizi, che possono contare migliaia di componenti (intesi come tipi e non istanze), mappatura nativa sul database e gestione nativa di aspetti distribuiti come la sicurezza e le transazioni. L'astrazione di java è necessaria e non venirmi a dire che lo sapresti gestire/mantenere/sviluppare in C++.

    Il software che citi tu appartiene ad altre categorie di applicazioni dove la semplicità e le performance sono necessarie e prioritarie.
    non+autenticato

  • - Scritto da: Anonimo
    >
    > non venirmi a dire che lo
    > sapresti gestire/mantenere/sviluppare in
    > C++.

    _TUTTO_ si può fare in Assembly e C/C++, è solo questione di tempo e di manico. Per cose veramente raffinate, che richiedano grande astrazione ci sono Eiffel e CLOS (per rimanere sulla OOP VERA), ma anche ML, Prolog...   
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | Successiva
(pagina 1/3 - 13 discussioni)