Linguaggio definitivo (The Fishing Machine)

Dopo attentissime letture, minuziosissime prove e dettagliate valutazioni, sono giunto alla conclusione che tutti i linguaggi moderni siano una puttanata. Per questo motivo l'unico linguaggio degno di essere utilizzato per questo progetto è l'assembly.
Molti si chiederanno perchè l'assembly, è difficile, ci vuole un sacco di tempo; la risposta è semplice, con l'assembly si può scrivere tutto, senza nessun limite alla potenza e alla velocità, ottimizzazione totale del codice è la soluzione.
A dire il vero avevo anche pensato al linguggio macchina, però mi pare un po' eccessivo per via dei vincoli con l'hardware troppo stretti.

Ora, se non siete d'accoro scrivetelo e dimostratemi che un qualunque linguaggio fa qualcosa che l'assembly non può fare.

JJ

Non sono un programmatore, però penso sia interessante questa conversazione avuta con un coder che conosco e che sta sbirciando il progetto TK dalla distanza.

Gli avevo chiesto cosa pensasse della scelta di assembly.

----------

XXX: Il problema e' che per programmare un doppio ciclo che ordina due array in assembler ti ci vogliono 70-80 righe, in java o c o c++ una decina
Maan: non ho ben capito cos'hanno contro java... gira su tutte le macchine, ormai fanno tutto in java per le cose online. Credevo fosse considerato una scelta scontata, ormai
XXX: E' una vecchia lotta. A me sa di partito preso. I vecchi programmatori di C hanno trasmesso questa cosa del java brutto
Maan: le solite guerre tra parrocchie, eh?
XXX: Già. Io ho studiato i linguaggi di programmazione a fondo. Il java tende ad essere effettivamente più lento perchè interpretato e non compilato, quindi in programmi molto grossi si può sperimentare una lentezza superiore ad un c o c++; inoltre richiede una base di memoria aggiuntiva per la macchina virtuale. Ma sono tutte cose che per un gioco online sono ininfluenti. Inoltre, cosa che la maggior parte della gente non sa, java è anche compilabile. In quel caso diventa uguale a c o c++ in fatto di prestazioni
XXX: Il java rimane sempre piu' avanzato di c e c++. D'altronde e' stato costruito dopo c e c++ è stata un'aggiunta, una "pezza" a c per imitarlo
XXX: ha alcune meccaniche di protezione e gestione automatiche che facilitano di molte le cose. Alcuni si incazzano perchè non possono gestire la memoria, lo fa il garbage collector. In realtà si può forzare il garbage collector e non usare le malloc è una manna dal cielo, perchè è la maggior causa di errori su C
XXX: Nei giochi online il client java è un vantaggio per la sua facile portabilità, se si rispettano le norme per la programmazione compatibile. Visto che in java è possibile usare anche le chiamate di sistema, oltre a quelle di java che fanno le stesse cose. In tal modo si programma un solo client e si da accesso a tutti i sistemi senza che altri si debbano arrangiare per farli girare altrove. Sarebbe interessante utilizzare l'avanzata tecnologia web service della Sun, costruita appositamente perchè un client usi i metodi interni normalmente "ignorando" che questi facciano richieste direttamente al server

----------

...io personalmente non ne capisco molto, ma magari una critica vi torna utile.

a) Suppongo che la faccenda dell' assembly sia uno scherzo
b) Concordo con l' analisi su java (ricordiamoci che sono andati su Marte con java eh=))

Jumping Jack ha scritto:Dopo attentissime letture, minuziosissime prove e dettagliate valutazioni, sono giunto alla conclusione che tutti i linguaggi moderni siano una puttanata. Per questo motivo l'unico linguaggio degno di essere utilizzato per questo progetto è l'assembly.

Prima di fare certe affermazioni, JJ, devi pubblicare l'URL dove possiamo prendere visione di tante e tali letture, prove e valutazioni.

Jumping Jack ha scritto:
Ora, se non siete d'accoro scrivetelo e dimostratemi che un qualunque linguaggio fa qualcosa che l'assembly non può fare.
JJ

E' vero: l'assembly consente una libertà d'azione incomparabile che ti fa sfruttare la macchina fino al metallo; però necessita di una competenza che è faticoso acquisire e (soprattutto) mantenere.
Personalmente, conosco gli assembly Zilog Z80, Motorola 6800, Intel 8086, perché li ho usati da piccolo: ma usare un odierno Intel Itanium e riuscire a sfruttarne al meglio la potenza cioè scrivere codice nativo direttamente in Assembly, scusa la franchezza, è follia pura.

E' vero: non c'è nulla che l'assembly non possa fare, ma a quale costo? Ti faccio un banale esempio: lo Z80 non aveva l'istruzione di moltiplicazione, quindi per fare il prodotto di due interi era necessario usare una routine (fatta in casa oppure presa da una libreria) che lo facesse tramite addizioni successive. Questo per dire che in assembly si può fare tutto purché si disponga di molta competenza e molto tempo e/o di buone librerie che offrano tutte le funzionalità "complesse" che sono lunghe e difficili da fare e che il processore non dispone in modo "nativo".
Librerie che vanno studiate, capite e per essere sfruttate al meglio il che è quasi come usare un "altro" linguaggio di programmazione cioè quello "descrritto e imposto" dalle librerie che si hanno a disposizione.

Per il progetto faccio anch'io una provocazione: Useremo l'assembly per codificare le routine di apertura un socket TCP? E quindi useremo delle chiamate a servizi di sistema operativo oppure scriveremo da zero anche le routine di gestione degli interrupt?

Lo stesso problema si ripete comunque con qualsiasi altro linguaggio di programmazione ad alto livello. Ogni linguaggio consente di fare le stesse cose in più modi: per convertire una stringa in numero puoi scriverti la tua routine di conversione oppure utilizzare "bene" le funzioni di libreria.

Credo sia necessario puntare sul linguaggio che consenta la massima flessibilità anche a scapito di velocità ed efficienza. Problemi come l'ingombro di memoria RAM o la scarsa velocità sono sì punti da studiare ma non sono il cuore del problema.

Tanto per non smentirmi mai: Nel MUD-engine che ho scritto in Perl, in quanto linguaggio interpretato è consentito di "ricompilare" cioè caricare al volo parti di codice, senza fermare l'engine: cioè posso modificare un file sorgente Perl e forzare l'engine a ricaricare quel file. Non sono al corrente che Java sia in grado "ricompilare" singoli file senza dover effettuare una "build" completa, cioè di fatto fermando e riavviando l'engine.

Forse potremmo anche pensare al Ruby... o al FORTH
Invece il COBOL, per quanto stabile da trent'anni, mi sta proprio sulle balle.

Si accettano commenti.

M.

mattsteel ha scritto:
Per il progetto faccio anch'io una provocazione: Useremo l'assembly per codificare le routine di apertura un socket TCP? E quindi useremo delle chiamate a servizi di sistema operativo oppure scriveremo da zero anche le routine di gestione degli interrupt?

Ecco si, mi piace, giriamo direttamente sull'hardware macchina almeno non c'è discussione se linux, mac, windows o altro.

JJ

Ma perchè non costruirsi un hardware dedicato ? Coi PIC oggi si fanno miracoli

Comunque... il C prevede l'inline assembler se proprio non se ne vuole fare a meno... Anche se, personalmente, C++ forever come velocità di esecuzione e potenzialità

come maan anche io di programmazione ci capisco poco e posso solo dire questo:

abbiamo da affrontare un "mud complesso" ossia un qualche cosa che possa gestire molti mud contemporaneamente e che permetta allo stesso tempo la loro customizzazione oltre al fatto che vorremmo creare qualche cosa che espanda il concetto stesso di mud (sia per features che per caratteristiche intrinseche).

questo per dire che suppongo non esista il codice "migliore" in assoluto ma esista invece un codice che meglio si adatta a quanto dobbiamo fare ma che soprattutto meglio si adatta alle conoscenze del team di progettazione.

ossia dobbiamo ottenere il miglior risultato nel minor tempo e con il minor impegno dato che ora come ora si parla di programmare a gratis (almeno finche non avremo uno sponsor).

quindi il nostro obbiettivo giovedi sera sarà quello di stabilire con quale linguaggio si parte e partire subito dopo! gia da lunedi prossimo vi vorrei attivi a programmare le basi!

SomaOS ha scritto:Ma perchè non costruirsi un hardware dedicato ? Coi PIC oggi si fanno miracoli

Comunque... il C prevede l'inline assembler se proprio non se ne vuole fare a meno... Anche se, personalmente, C++ forever come velocità di esecuzione e potenzialità

somaos tu hai usato java per sword? come ti sei trovato?

Gadda ha scritto:come maan anche io di programmazione ci capisco poco e posso solo dire questo:

abbiamo da affrontare un "mud complesso" ossia un qualche cosa che possa gestire molti mud contemporaneamente e che permetta allo stesso tempo la loro customizzazione oltre al fatto che vorremmo creare qualche cosa che espanda il concetto stesso di mud (sia per features che per caratteristiche intrinseche).

Gadda: ti faccio notare che quello che hai appena descritto ha tutta l'aria di un Sistema Operativo... un MUD-OS in piena regola...

SomaOS ha scritto:Ma perchè non costruirsi un hardware dedicato ? Coi PIC oggi si fanno miracoli

Comunque... il C prevede l'inline assembler se proprio non se ne vuole fare a meno... Anche se, personalmente, C++ forever come velocità di esecuzione e potenzialità

E' vero! Ecco la soluzione definitiva, sviluppiamo un hardware per mud con software dedicato, poi lo facciamo a forma di console e vendiamo la scatola magica con mud server integrato, ovviamente totalmente configurabile.

JJ

Si, mi immagino già il mercato dei muddisti a comprarsi sta mudBox con tastiera proiettata sul tavolo

Cazzate a parte, il problema del "multi mud" è facilmente affrontabile: in realtà va visto come un hosting di N istanze del tkCore, configurato in varie maniere ad hoc per ogni keeper. Poi la gestione la si affronta a livello + alto..KISS (Keep It Simple, Stupid)

macvart ha scritto:Si, mi immagino già il mercato dei muddisti a comprarsi sta mudBox con tastiera proiettata sul tavolo

Cazzate a parte, il problema del "multi mud" è facilmente affrontabile: in realtà va visto come un hosting di N istanze del tkCore, configurato in varie maniere ad hoc per ogni keeper. Poi la gestione la si affronta a livello + alto..KISS (Keep It Simple, Stupid)

ad ogni modo giovedi usciremo dalla riunione con un codice in mano (o meglio sotto le mani) e un imput di programmazione

lol.

Quoto maan.

Console! Console! "MudBox 360 - TheKeeper Edition"


OT-Notizia carina.
http://www.hwupgrade.it/articoli/software/2170/ivar-jacobson-ecco-cosa-non-insegnano-ai-programmatori_index.html Oltre alla sponsorizzazione M$.

Wow questo topic ha avuto effetti disparati e ora ho tante cosa da scrivere... Da cosa comincio?
Uhm... Beh, iniziamo a dire che è stata una buona pesca
Ovviamente la proposta dell'assembly non è assolutamente logica, è vero che è prestazionale, ma nel nostro caso non è di nessuna utilità, al limite, in futuro, potrebbe servire per scrivere alcune routine ma è solo un caso estremo.
Riguardo ai pensieri pro e contro, dico solo che le macchine professionali (personalmente ho a che fare con macchine a controllo numerico (CNC), macchine di misura 3d (CMM) e robot) utilizzano uno o due computer per il loro controlo e programmazione, solitamente per il controllo viene utilizzato il codice macchina (si tanti 0 e 1 in seguenza) mentre per la programmazione è variabile (anche versioni modificate di windows 95 e windows XP) oppure un linguaggio interpretato proprietario, solitamente quando vi è un solo computer che gestisce sia il programma che il controllo.
Con questo voglio dire che è sbagliato puntare il dito contro un sistema operativo, un harware o un linguaggio, ogniuno ha i suoi pregi e difetti.

Tra l'altro l'idea finale di evoluzione, che è uscita quasi per caso, del mud-OS e la mudBox, sarebbe l'idea effettivamente ultima, dove oltre non c'è niente, e questo varrebbe per qualunque software, solo che se il mercato è ridotto è anticommerciale

Riguardo invece SomaOS spero che non se la sia presa, mi abbia detto "fanculo", e non ci legga più

Invece c'è il discorso su Java, è vero che i programmatori tendono a restare un po' fissati su quello che conoscono, ma questo vale un po' per tutto, ci si affeziona a ciò che si possiede a ciò che si conosce. Tu sei fissato con una macchina, lui è fissato con una console, l'altro è fissato con un certo genere di libri... E' normale. L'importante è cercare di capire quando si sbaglia e non usare qualcosa di inappropriato, ma se magari va solo poco bene può essere accettabile.
In particolare Java ha i suoi pregi, ed è un linguaggio che sta a parte, ovvero non è scripting e non è compilato.
Compilare java comunque è come spararsi nelle palle, ovvero diventa un linguaggio compilato lento e limitato (rispetto ad un compilato) e platform dipendent.
Il pricipale pregio di java è proprio di poter girare praticamente su qualunque macchina, per cui sia stata sviluppata la virtual machine, il principale difetto è che è la learning curve (ovvero il tempo di apprendimento) e piuttosto alto, e spesso si perde molto tempo per comlpetare un progetto che funzioni alla perfezione. Ovvero progetti troppo complessi possono avere tempi dilatati anche esagerati per via della natura del linguaggio (che è una via di mezzo).
Il fatto che con java siano andati su marte mi pare una stronzata, o meglio una trovata pubblicitaria di Sun che avrà foraggiato per bene, magari fornendo l'hardware. Tutto ciò che è scritico si può scrivere solo in linguaggio macchina o alpiù con un compilato a basso livello. Ogni altra soluzione sarebbe come mettere delle pile cinesi, di dubbia fattura, in un pacemaker.
Java non è più avanzato di C e C++ e nemmeno centra che sia stato scritto dopo. Ci sono cose che si possono fare solo in C, cose che si possono fare solo in C++ e cose che si possono fare solo in Java, se queste cose sono importanti, implicano un certo linguaggio.
La base è che scripting vuole dire, seplicità e velocità, compilato vuole dire controllo e potenza, ma ci sono dei compilati ad alto livello che sono veramente notevoli.
Ultima sparata sul Java è che vengono fatti mille mila giochini in java, perchè li sanno fare così e perchè girano ovunque praticamente senza problemi, questi giochi li vedo spesso lentissimi, e mi fa venire l'angoscia vedere che giochi come quelli che giocavo sul 486, vengano riproposti ora e girino pessimamente su un pentium 3 per esempio. Che io sappia nessun giocone è scritto in java...

Al riguardo vi mostro una tabella comparativa con il linguaggio D, da qui si vede che NESSUN linguaggio è definitivo e NESSUN linguaggio può essere scelto prima di sapere che cosa si vuole fare.
Tuttavia ora proveremo a correre un po' e per farlo serve partire un po' come viene e poi cercheremo di aggiustarci. Per questo motivo proporrò Python come linguaggio per il server, anche perchè va a coppietta con il C, ovvero si può passare da Python a C e viceversa senza problemi. Quindi se guardate il grafico e leggere assieme Python e C vedere che si compensano in buona parte.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD
La proposta ricade sul Python per molti altri motivi, ma ne parlerò in altro topic.

Il quadro mostrato da Jvar Jacoboson è molto interessante e approvo completamente ciò che dice.

Una ultima pillola, il progetto più che grande che mi viene in mente scritto completamente in assembly, è Mathematica. 1.000.000 di linee di codice assemply!!!
Certamente al tempo è stato un lavoro immenso, ma i risultati si vedevano, per esempio per calcolare il fattoriale di 10.000 su un 386 (se non ricordo male) impiegava 3 secondi per la compilazione e 2 secondi per l'esecuzione, dopo di che passava diversi minuti a scrivere il risultato a schermo. Il mio programma scritto in assembly ottimizzato, ma senza codice dublicato, impiegava circa 10 secondi. (NB: duplicando il codice il risultato sarebbe stato sicuramente non maggiore ai 2 secondi)

JJ

Concordo sull' orientamento verso Python. Vista la varietà di linguaggi conosciuti sembra effettivamente la "mediana" per tutti. In più partiremmo tutti dallo stesso livello e potremmo quindi formare dei gruppi di lavoro all' uopo (accchio vuol dire, non lo so, ma suona proprio bene ).
Ho solo copiato ed incollato del codice che ho trovato nel manuale di Py (per brevità) ed in 10 righe (commenti a parte) ho ottenuto un socketServer funzionante e stabile (lo stesso dicasi per il client). Tralaltro è nativamente supportato dagli ultimi kernel linux, il che lo rende appetibile.

Qua sono presenti dei benchmark dei vari linguaggi... Dateci un occhio, il link è quello globale di cpu+memoria ma sotto sono divisibili per tipi di test.

http://dada.perl.it/shootout/craps_cpumem.html

Edit: Ad ogni modo... usare i puntatori ha sempre il suo perchè ed è una cosa di cui faccio fatica fare a meno

Jumping Jack ha scritto:Uhm... Beh, iniziamo a dire che è stata una buona pesca

Guarda che l'avevamo capito già dalla quarta riga...

Jumping Jack ha scritto:Tra l'altro l'idea finale di evoluzione, che è uscita quasi per caso, del mud-OS e la mudBox, sarebbe l'idea effettivamente ultima, dove oltre non c'è niente, e questo varrebbe per qualunque software, solo che se il mercato è ridotto è anticommerciale

Questa del MUD-OS, l'ho scovata proprio dal profondo dell'universo, eh...

Jumping Jack ha scritto:In particolare Java ha i suoi pregi, ed è un linguaggio che sta a parte, ovvero non è scripting e non è compilato.
Il principale pregio di java è proprio di poter girare praticamente su qualunque macchina, per cui sia stata sviluppata la virtual machine, il principale difetto è che è la learning curve (ovvero il tempo di apprendimento) e piuttosto alto, e spesso si perde molto tempo per comlpetare un progetto che funzioni alla perfezione. Ovvero progetti troppo complessi possono avere tempi dilatati anche esagerati per via della natura del linguaggio (che è una via di mezzo).

Lo stesso vale per il Perl. Senz'altro.

Jumping Jack ha scritto:La proposta ricade sul Python per molti altri motivi, ma ne parlerò in altro topic.

Bene, stasera me lo installo e lo provo.
Ciao.
M.

Stavo considerando...
Ho installato il Python 3.0 i primi di aprile e nel volgere di 5-6 settimane sono riuscito a realizzare lo smoke-test di quest'altro post.
In linguaggio macchina avrei cominciato con

Codice:


NON STA A
    ROM
    PER
    LES B,A
    LLE NON