[Vari]I linguaggi che più avete odiato. [Archivio] - Pagina 2

View Full Version : [Vari]I linguaggi che più avete odiato.

Pagine : 1 [2]

malocchio

30-07-2009, 23:09

No, si puo' ottenere hard real-time anche in linux, ci sono tre implementazioni differenti (RTLinux, RTAI e Xenomai).
Tra l'altro l'approccio e' abbastanza simile a quello del link (architettura co-kernel).

Non mi ricordo neanche più com'è venuto fuori il discorso, ma evidentemente ricordavo male.
Qui (http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#About_the_RT-Preempt_Patch) un link che mi ha interessato

cionci

31-07-2009, 06:58

La disassembli e vedi perché non funziona. :fagiano:

Closed != impossibile vedere cosa fa il codice. :cool:
E' comunque illegale apportare modifiche ;)

cdimauro

31-07-2009, 07:28

sicuramente non sono tutto, però contano.
vai da un cliente, gli fai vedere un applicativo scritto in X, lo stesso in Y, dove X è più veloce fino a 45 volte di Y... secondo te al cliente frega qualcosa del linguaggio? della facilità di sviluppo? della mantenibilità del codice?
a noi programmatori si, a loro clienti no.
e visto che s'ha da guadagnare la pagnotta... :oink:

poi ovviamente se si trova il giusto compromesso, tanto di guadagnato! :sofico:

PS: ovviamente non ce l'ho con python/java/php/altro né sono un fan di c#/altro.
ribadisco, erano solo commenti su quei bench. :cincin:

PPS: e tra l'altro, molti risultati sono per me inattesi! :O
E sarà ancora meglio in futuro, visto che Google ha deciso di dare una notevole accelerata alle prestazioni di Python:

http://code.google.com/p/unladen-swallow/wiki/ProjectPlan

:cool:
E' comunque illegale apportare modifiche ;)
Questo dipende dalla nazione. In Italia, ad esempio, lo puoi fare.

Comunque conoscere la natura del bug non implica necessariamente che lo si debba poi correggere: è sufficiente sviluppare un work-around in attesa che il problema venga corretto. ;)

insane74

31-07-2009, 08:00

E sarà ancora meglio in futuro, visto che Google ha deciso di dare una notevole accelerata alle prestazioni di Python:

http://code.google.com/p/unladen-swallow/wiki/ProjectPlan

:cool:
...

in effetti l'avevo già letto tempo fa e promette bene, sulla carta.
i risultati per ora però mi sembrano piuttosto scarsi, no? soprattutto perché mi pare di aver letto che usa un botto di ram, ora come ora.
comunque, dato che c'è dietro google, i risultati si vedranno!:sofico:

marco.r

31-07-2009, 08:54

Non mi ricordo neanche più com'è venuto fuori il discorso, ma evidentemente ricordavo male.
Qui (http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#About_the_RT-Preempt_Patch) un link che mi ha interessato
Riguardo della path RT_Preempt hai ragione, ma non e' l'unica soluzione possibile.
Se vuoi maggiori dettagli li trovi sui siti dei progetti:

http://www.rtlinuxfree.com/
http://rtai.org
http://xenomai.org

zulutown

31-07-2009, 10:59

insane74

31-07-2009, 11:03

La velocità di esecuzione penso sia importante nel 1% dei progetti software legati al mondo della consulenza.

Per il restante 99% al cliente interessa sapere quanti giorni uomo servono per fare quello che gli serve e poi quanti giorni uomo serviranno per far modifiche al software.

sai quanti clienti si lamentano della "lentezza" di determinate operazioni?
sai quante ore passate ad ottimizzare il codice per spremere lo spremibile?
poi se fate progetti per clienti cui non interessano le prestazioni, buon per voi.

noi (almeno, nel settore dell'azienda in cui lavoro) dobbiamo SEMPRE fare i conti sulle prestazioni perché altrimenti i clienti ci fanno il :ciapet: a strisce.

PS: mai parlato tra l'altro di "mondo della consulenza" :mbe:

Johnn

31-07-2009, 12:10

banryu79

31-07-2009, 12:24

insane74

31-07-2009, 12:28

All'università mi hanno insegnato che se sono richieste performance elevate per un software il segreto sta nella corretta progettazione (architetturale e algoritmica) piuttosto che nel codice. Detto in altri termini, se un software è lento è poco probabile che diventi veloce ritoccando il codice o cambiando linguaggio a parità di implementazione.

vero.
peccato che "nel mondo reale" ci si scontra con due nemici implacabili: il tempo e i commerciali.
:D

spesso si è costretti dal poco tempo a disposizione/dai commerciali spudorati a rilasciare applicativi che magari fanno il loro dovere, ma che non sono certo delle perle di programmazione.
quindi poi a posteriori si lavora di lima sul codice e annessi&connessi.

insane74

31-07-2009, 12:31

Che il software "giri fluido" ha la sua importanza, non è che chi non ne parla o non tende a enfatizzare questo aspetto normalmente scrive software lenti e gli va bene...

Ho come l'impressione che chi ne parla sempre o tende spesso a metterci l'accento sopra sia perchè opera in campi in cui questo aspetto è particolarmente critico e presente, e va bene ci mancherebbe.

@insane74: ma per curiosità, in che settore operate? che tipo di applicazioni dovete scrivere? chi sono i vostri clienti?

azienda di milano con 300 dipendenti.
nel settore in cui lavoro di occupiamo di logistica a tutti i livelli.
nel particolare, sviluppiamo un sw gestionale (un WMS, per intenderci).
clienti? dal singolo soggetto con un magazzino (tipo famoso produttore di vestiario) ai grossi terzisti (tipo quelli che gestiscono le spedizioni per conto terzi).
qui serve velocità di esecuzione dei singoli task, stabilità, integrità dei dati, bla bla bla.
con questi soggetti la velocità operativa è "sentita".

PS: che resti tra noi, il nostro SW a me fa schifo! :D :D :D :D

banryu79

31-07-2009, 13:03

con questi soggetti la velocità operativa è "sentita".

Ok, quindi la velocità è un requisito, nel senso che fa parte dei requisiti che la soluzione deve soddisfare.

PS: che resti tra noi, il nostro SW a me fa schifo! :D :D :D :D
Eh-eh, che culo :ciapet:

javaboy

31-07-2009, 13:20

40K euro??! E che cazzo fa? Simula la Guerra Termonucleare Globale (cit.) e il Tic-Tac-Toe (cit., sempre la stessa) quando è in idle?

40.000 euro ti sembra tanto?

insane74

31-07-2009, 13:38

Ok, quindi la velocità è un requisito, nel senso che fa parte dei requisiti che la soluzione deve soddisfare.

Eh-eh, che culo :ciapet:

2 volte esatto! :D

insane74

31-07-2009, 13:39

40.000 euro ti sembra tanto?

infatti.
anche perché se il cliente si piazza un "sorter" da 2 milioni di €, sai che gli pesa 40000€ di gestionale? ;)

shinya

31-07-2009, 13:45

40.000 euro ti sembra tanto?
Dipende da quello che fa, e se sono comprese personalizzazioni o se è il pacchetto di default.

Poi non vorrei scivolare in un altro discorso... anche qua spendono un sacco di soldi per cose che si potrebbero avere gratis (quella merda di websphere, tanto per dirne una)... ma poi entriamo in un discorso perverso secondo cui all'interno di una gerarchia aziendale, più spendi, più incidi sul budget, più sei potente...

insane74

31-07-2009, 14:22

Dipende da quello che fa, e se sono comprese personalizzazioni o se è il pacchetto di default.

Poi non vorrei scivolare in un altro discorso... anche qua spendono un sacco di soldi per cose che si potrebbero avere gratis (quella merda di websphere, tanto per dirne una)... ma poi entriamo in un discorso perverso secondo cui all'interno di una gerarchia aziendale, più spendi, più incidi sul budget, più sei potente...

ultimo OT: il pacchetto "base" sta sui 23K€, poi si sale a seconda delle personalizzazioni, spesso PESANTI (anche perché i commerciali di turno spesso dicono "si, lo fa" e dopo averlo venduto corrono giù da noi "in cantina" a dire "mi fai questo e quest'altro per ieri?" :sofico: ).

PS: tra l'altro nella mia azienda noi della "logistica" contiamo un c@zzo (circa il 6% del fatturato)... :cry:

astorcas

31-07-2009, 15:13

ultimo OT: il pacchetto "base" sta sui 23K€, poi si sale a seconda delle personalizzazioni, spesso PESANTI (anche perché i commerciali di turno spesso dicono "si, lo fa" e dopo averlo venduto corrono giù da noi "in cantina" a dire "mi fai questo e quest'altro per ieri?" :sofico: ).

PS: tra l'altro nella mia azienda noi della "logistica" contiamo un c@zzo (circa il 6% del fatturato)... :cry:

credo sia un mal comune di molte aziende (ITALIANE) :D

Ma mica siamo colleghi? :fagiano:

insane74

31-07-2009, 15:30

credo sia un mal comune di molte aziende (ITALIANE) :D

Ma mica siamo colleghi? :fagiano:

mmm... tu siena, io milano... o lavori qui? :confused:

astorcas

31-07-2009, 15:41

mmm... tu siena, io milano... o lavori qui? :confused:

ci sono sedi anche lì....

insane74

31-07-2009, 15:44

ci sono sedi anche lì....

mmm, non mi pare che abbiamo sedi a siena. c'è qualcosa a roma, mantova e da qualche parte in liguria (che memoria...:doh: ) ma siena no.

questo cmq torna col discorso: "in italia"!!! :D :D :D :D

zulutown

31-07-2009, 15:58

sai quanti clienti si lamentano della "lentezza" di determinate operazioni?
sai quante ore passate ad ottimizzare il codice per spremere lo spremibile?
poi se fate progetti per clienti cui non interessano le prestazioni, buon per voi.

noi (almeno, nel settore dell'azienda in cui lavoro) dobbiamo SEMPRE fare i conti sulle prestazioni perché altrimenti i clienti ci fanno il :ciapet: a strisce.

PS: mai parlato tra l'altro di "mondo della consulenza" :mbe:

di solito "early optimization is the root of all evil" e.. costa meno comprare hardware più potente rispetto a pagare consulenti per migliorarlo :)

Johnn

31-07-2009, 16:36

di solito "early optimization is the root of all evil" e.. costa meno comprare hardware più potente rispetto a pagare consulenti per migliorarlo :)

Perché?

L'idea è di progettare un software dall'inizio tenendo conto delle performance quindi non si dovrebbe pagare nessuno dopo per migliorarlo (e potrebbe anche essere impossibile), nè si dovrebbe impiegare di più nello sviluppo (quindi alla fine impiega di più quello che parte con l'implementazione e dopo parte con l'ottimizzazione disperata :D ).

Questo discorso rimane comunque abbastanza astratto se non si specifica l'ambito in cui serve il software. Per certi problemi comprare hardware potrebbe bastare, per altri sarebbe solo uno spreco di soldi.

zulutown

31-07-2009, 19:13

Perché?

L'idea è di progettare un software dall'inizio tenendo conto delle performance quindi non si dovrebbe pagare nessuno dopo per migliorarlo (e potrebbe anche essere impossibile), nè si dovrebbe impiegare di più nello sviluppo (quindi alla fine impiega di più quello che parte con l'implementazione e dopo parte con l'ottimizzazione disperata :D ).

Questo discorso rimane comunque abbastanza astratto se non si specifica l'ambito in cui serve il software. Per certi problemi comprare hardware potrebbe bastare, per altri sarebbe solo uno spreco di soldi.

bè ovviamente se scrivo del software che dovrebbe stabilizzare il volo di un aereo militare c'è una bella differenza se impiega 5 secondi per far i calcoli o 5 millisecondi.

Nei restanti casi se inizi a scrivere un codice pensando a ottimizzarlo, è molto più probabile che avrai un codice poco leggibile e quindi difficile da adattare alle esigenze del cliente che nel frattempo stai pur certo che saranno cambiate :-)

morskott

31-07-2009, 19:21

Le prestazioni non sono tutto. Anzi, sono l'ultima cosa a cui pensare (soltanto nel caso in cui non risultano oggettivamente adeguate alla risoluzione del problema). ;)

Come dissero i progettisti di vista, poi........

cdimauro

31-07-2009, 22:57

Vista ha buone prestazioni, ma non mi sembra sia in linea con l'argomento del thread. :read:

morskott

31-07-2009, 23:06

Vista ha buone prestazioni, ma non mi sembra sia in linea con l'argomento del thread. :read:

EDIT: vabbeh, un po di OT non ha mai fatto male a nessuno!!!!

eraser

31-07-2009, 23:15

Questo dipende dalla nazione. In Italia, ad esempio, lo puoi fare.

Beh via, oddio. Sì, nel caso specifico potrebbe essere legale, ma non è che in generale reverse engineering = legale in Italia :D La legge fà alcune precise specifiche :)

cdimauro

01-08-2009, 07:27

Se non ricordo male puoi farlo se puoi "fruire meglio dell'opera".

cionci

01-08-2009, 08:36

Perché?

L'idea è di progettare un software dall'inizio tenendo conto delle performance quindi non si dovrebbe pagare nessuno dopo per migliorarlo (e potrebbe anche essere impossibile), nè si dovrebbe impiegare di più nello sviluppo (quindi alla fine impiega di più quello che parte con l'implementazione e dopo parte con l'ottimizzazione disperata :D ).

Questo discorso rimane comunque abbastanza astratto se non si specifica l'ambito in cui serve il software. Per certi problemi comprare hardware potrebbe bastare, per altri sarebbe solo uno spreco di soldi.
Esatto, non tanto l'ambito, ma i requisiti del progetto. Se i requisiti dicono che una parte del software deve terminare l'esecuzione in tot ms allora è chiaro che il requisito debba essere rispettato.
Ciò non toglie che durante lo sviluppo convenga adottare una soluzione man mano più ottimizzata fino al raggiungimento dell'obiettivo, anche perché la maggior parte delle volte la complessità della soluzione è inversamente proporzionale alla velocità di esecuzione ;)

Imho invece è completamente scorretto cercare di ottimizzare quando non abbiamo questi requisiti.

eraser

01-08-2009, 09:19

Se non ricordo male puoi farlo se puoi "fruire meglio dell'opera".

Articolo 64-bis

Fatte salve le disposizioni dei successivi articoli 64-ter e 64-quater, i diritti esclusivi conferiti dalla presente legge sui programmi per elaboratore comprendono il diritto di effettuare o autorizzare:

a) la riproduzione, permanente o temporanea, totale o parziale, del programma per elaboratore con qualsiasi mezzo o in qualsiasi forma. Nella misura in cui operazioni quali il caricamento, la visualizzazione, l'esecuzione, la trasmissione o la memorizzazione del programma per elaboratore richiedano una riproduzione, anche tali operazioni sono soggette all'autorizzazione del titolare dei diritti;

b) la traduzione, l'adattamento, la trasformazione e ogni altra modificazione del programma per elaboratore, nonché la riproduzione dell'opera che ne risulti, senza pregiudizio dei diritti di chi modifica il programma;

c) qualsiasi forma di distribuzione al pubblico, compresa la locazione, del programma per elaboratore originale o di copie dello stesso. La prima vendita di una copia del programma nella comunità economica europea da parte del titolare dei diritti, o con il suo consenso, esaurisce il diritto di distribuzione di detta copia all'interno della comunità, ad eccezione del diritto di controllare l'ulteriore locazione del programma o di una copia dello stesso.

Art. 64-quarter

1. L'autorizzazione del titolare dei diritti non è richiesta qualora la riproduzione del codice del programma di elaboratore e la traduzione della sua forma ai sensi dell'art. 64- bis, lettere a) e b), compiute al fine di modificare la forma del codice, siano indispensabili per ottenere le informazioni necessarie per conseguire l'interoperabilità, con altri programmi, di un programma per elaboratore creato autonomamente purché siano soddisfatte le seguenti condizioni:
a) le predette attività siano eseguite dal licenziatario o da altri che abbia il diritto di usare una copia del programma oppure, per loro conto, da chi è autorizzato a tal fine;
b) le informazioni necessarie per conseguire l'interoperabilità non siano già facilmente e rapidamente accessibili ai soggetti indicati alla lettera a);
c) le predette attività siano limitate alle parti del programma originale necessarie per conseguire l'interoperabilità.
2. Le disposizioni di cui al comma 1 non consentono che le informazioni ottenute in virtù della loro applicazione:
a) siano utilizzate a fini diversi dal conseguimento dell'interoperabilità del programma creato autonomamente;
b) siano comunicate a terzi, fatta salva la necessità di consentire l'interoperabilità del programma creato autonomamente;
c) siano utilizzate per lo sviluppo, la produzione o la commercializzazione di un programma per elaboratore sostanzialmente simile nella sua forma espressiva, o per ogni altra attività che violi il diritto di autore.
3. Gli accordi contrattuali conclusi in violazione dei commi 1 e 2 sono nulli.
4. Conformemente alla convenzione di Berna sulla tutela delle opere letterarie ed artistiche ratificata e resa esecutiva con legge 20 giugno 1978, n. 399, le disposizioni del presente articolo non possono essere interpretate in modo da consentire che la loro applicazione arrechi indebitamente pregiudizio agli interessi legittimi del titolare dei diritti o sia in conflitto con il normale sfruttamento del programma".

cdimauro

01-08-2009, 11:23

E' molto più restrittiva di quel che ricordassi. :(

Grazie per il chiarimento! :)

eraser

01-08-2009, 12:26

E' molto più restrittiva di quel che ricordassi. :(

Grazie per il chiarimento! :)

Figurati :)

Comunque sia permette molto di piu che le leggi di altri paesi :fagiano: :D

zulutown

02-08-2009, 11:11

Imho invece è completamente scorretto cercare di ottimizzare quando non abbiamo questi requisiti.

Già..
e poi salta fuori certo codice da incubo.

Braccop

02-08-2009, 12:44

1)(B)Ash script
2)SQL
3)Java

in ordine decrescente di odio