42 risposte a questa discussione

[TigerShark]

Ah ok, pensavo stavate dicendo che i callback non si devono poter usare, invece vi serve solo un linguaggio safe perche' non li sapete usare

Certo che pure io, mettermi a discutere con gente che dice robe del genere:




vado a fare qualcosa di piu' interessante.

Learn2programmazione funzionale.
E in caso studiati un po' di f#/ocaml/haskell se non vuoi passare la vita a scrivere codice c++.
Mah.. Sarò strano io ma non mi ci vedo proprio a scrivere codice per il resto della mia vita in un solo linguaggio..

Messaggio modificato da TigerShark il 20 ottobre 2012 - 10:52

[trallallero]

no guarda che sei tu che non hai capito un cazzo se vedi i delegate solo come un qualcosa per fare delle callback


guardati cos'è una closure


poi solo il fatto di dire "vi serve un linguaggio safe perché non li sapete usare" va contro tutti i principi della SWE eh, non pensare che far codice "difficile" faccia figo

Se il tuo sistema si spacca perché hai passato un tipo X ad puntatore a funzione che richiede un tipo Y, o stai sperimentando, o sei un principiante, o il design è di merda. Il nostro sistema di comunicazione real time è tutto basato su callbacks e non si spacca mai perché il design non lo permette e non abbiamo junior nel gruppo.

Il codice difficile non fa figo ma il codice safe è, per ovvi motivi, meno performante di quello unsafe. Se ti servono ultra prestazioni (caso nostro), controlli meno e ti concentri più sul design.

Learn2programmazione funzionale.
E in caso studiati un po' di f#/ocaml/haskell se non vuoi passare la vita a scrivere codice c++.
Mah.. Sarò strano io ma non mi ci vedo proprio a scrivere codice per il resto della mia vita in un solo linguaggio..

Learn2programmazione e basta, non funzionale. C'è anche quella funzionale, quella strutturata, etc etc e nessuna è migliore dell'altra, punto.
Per fare una determinata cosa, quel tipo di programmazione è migliore dell'altra! Un concetto che si dovrebbe spiegare solo ai bambini...

E al lavoro uso C++, Python, bash, psql, etc. Il C# usalo tu visto che noi facciamo sistemi real time per linux (in b4 Mono )

[TigerShark]

Se il tuo sistema si spacca perché hai passato un tipo X ad puntatore a funzione che richiede un tipo Y, o stai sperimentando, o sei un principiante, o il design è di merda. Il nostro sistema di comunicazione real time è tutto basato su callbacks e non si spacca mai perché il design non lo permette e non abbiamo junior nel gruppo.

Il codice difficile non fa figo ma il codice safe è, per ovvi motivi, meno performante di quello unsafe. Se ti servono ultra prestazioni (caso nostro), controlli meno e ti concentri più sul design.



Learn2programmazione e basta, non funzionale. C'è anche quella funzionale, quella strutturata, etc etc e nessuna è migliore dell'altra, punto.
Per fare una determinata cosa, quel tipo di programmazione è migliore dell'altra! Un concetto che si dovrebbe spiegare solo ai bambini...

E al lavoro uso C++, Python, bash, psql, etc. Il C# usalo tu visto che noi facciamo sistemi real time per linux (in b4 Mono )

Immagino come usi Python se non sai nemmeno cosa sia una closure.
Cmq il problema per i sistemi realtime non è ovviamente dato dalle prestazioni, che in certi casi sono addirittura superiori per software scritti in Java rispetto alla controparte in c++ (si veda ruby vs jruby tanto per fare un banale esempio), ma è dato dalla latenza non deterministica causata dalle Garbage Collection. Tanto è vero che esiste anche una versione real-time di Java.
Se credi ancora che usando il c++ hai prestazioni maggiori mi sa che non hai capito molto dato che l'unica discriminante è quella da me descritta.

Edit: ah, dimenticavo, e poi dovresti gentilmente spiegarmi perché utilizzare i generics per avere codice type safe dovrebbe essere meno prestante del codice non type safe, grazie.

Messaggio modificato da TigerShark il 20 ottobre 2012 - 12:02

[leonardoalmeida]

Se il tuo sistema si spacca perché hai passato un tipo X ad puntatore a funzione che richiede un tipo Y, o stai sperimentando, o sei un principiante, o il design è di merda. Il nostro sistema di comunicazione real time è tutto basato su callbacks e non si spacca mai perché il design non lo permette e non abbiamo junior nel gruppo.

Il codice difficile non fa figo ma il codice safe è, per ovvi motivi, meno performante di quello unsafe. Se ti servono ultra prestazioni (caso nostro), controlli meno e ti concentri più sul design.

guarda che il check dei tipi dei delegate avviene a compile-time

dimmi come fanno a risentirne le prestazioni



comunque non sto dicendo che un linguaggio è meglio dell'altro, dipende sempre da cosa si deve fare

non discuto il fatto che il codice MANAGED (che è una definzione != da safe) abbia prestazioni genericamente (ma neanche sempre) inferiori a codice unmanaged, e grazie al cazzo ci aggiungo

stavo dicendo che allo stato attuale il C++ NON permette la programmazione funzionale. Ok ci sono i puntatori a funzioni(unsafe), ma la programmazione funzionale prevede molte altre features


again, guardati cos'è una closure

[willy_revenge]

Hai imparato l'italiano durante l'estate Leo?

[leonardoalmeida]

sì, leggendo (o come dite voi, lurkando) questo forum

[dreadknight]

now this thread is about codefighting

[trallallero]

Immagino come usi Python se non sai nemmeno cosa sia una closure.
Cmq il problema per i sistemi realtime non è ovviamente dato dalle prestazioni, che in certi casi sono addirittura superiori per software scritti in Java rispetto alla controparte in c++ (si veda ruby vs jruby tanto per fare un banale esempio), ma è dato dalla latenza non deterministica causata dalle Garbage Collection. Tanto è vero che esiste anche una versione real-time di Java.
Se credi ancora che usando il c++ hai prestazioni maggiori mi sa che non hai capito molto dato che l'unica discriminante è quella da me descritta.

Java ? chi ne ha mai parlato ?

Edit: ah, dimenticavo, e poi dovresti gentilmente spiegarmi perché utilizzare i generics per avere codice type safe dovrebbe essere meno prestante del codice non type safe, grazie.

Nulla si crea, nulla si distrugge. Qualcosa deve controllare il type e non lo fa gratis.

guarda che il check dei tipi dei delegate avviene a compile-time

Ok, non hai mai usato plugin systems

[TigerShark]

Java ? chi ne ha mai parlato ?




Nulla si crea, nulla si distrugge. Qualcosa deve controllare il type e non lo fa gratis.




Ok, non hai mai usato plugin systems

Java e c# sono entrambi linguaggi managed dotati di Garbage Collection, che é l'UNICO motivo per cui non possono essere usti in sistemi real time.
Per quanto riguarda la type safety é assolutamente errato.
Il controllo avviene al compile time, e addirittura in Java sono implementati utilizzando la type erasure, quindi il codice compilato usando i generics o no è ESATTAMENTE identico.
E comunque se avete davvero requisiti stringenti sul realtime spero che non stiate utilizzando Linux...

Messaggio modificato da TigerShark il 20 ottobre 2012 - 14:55

[trallallero]

Java e c# sono entrambi linguaggi managed dotati di Garbage Collection, che é l'UNICO motivo per cui non possono essere usti in sistemi real time.
Per quanto riguarda la type safety é assolutamente errato.
Il controllo avviene al compile time, e addirittura in Java sono implementati utilizzando la type erasure, quindi il codice compilato usando i generics o no è ESATTAMENTE identico.

Come cazzo controlli un plugin in compile time ?

Perché in compile time anche il C++ controlla i tipi passati ai puntatori a metodo.
L'unico problema ce l'hai coi plugins (se non hai fatto un buon design) che viene caricato dinamicamente e non compilato/linkato insieme all'exe.

E comunque se avete davvero requisiti stringenti sul realtime spero che non stiate utilizzando Linux...

Mi fai ricordare una demo quando, al volo, hanno dovuto sostituire un client winxp con uno Abbraccianigga OS perché il primo non ne voleva sapere di andare in real time (non so i dettagli ma ho visto e sentite le madonne tirate dai miei colleghi ).

[TigerShark]

Come cazzo controlli un plugin in compile time ?

Perché in compile time anche il C++ controlla i tipi passati ai puntatori a metodo.
L'unico problema ce l'hai coi plugins (se non hai fatto un buon design) che viene caricato dinamicamente e non compilato/linkato insieme all'exe.





Mi fai ricordare una demo quando, al volo, hanno dovuto sostituire un client winxp con uno Abbraccianigga OS perché il primo non ne voleva sapere di andare in real time (non so i dettagli ma ho visto e sentite le madonne tirate dai miei colleghi ).

Ma ci sei o ci fai?
Se usi i generics chiunque usi la tua interfaccia dovrà usare un contenitore di quel tipo specificato nei generics, altrimenti non gli compila il codice.

E comunque Linux NON è un sistema hard real time, ergo le robe che fate voi non sono hard real time.
Il sistema di controllo degli attuatori di un elicottero tanto per fare un esempio è hard realtime e immagino usi QNX.
Esiste anche linuxRT per inciso.

Messaggio modificato da TigerShark il 20 ottobre 2012 - 15:15

[Yurassik]

Che bello leggere e non capire una benemerita fava

[trallallero]

Ma ci sei o ci fai?
Se usi i generics chiunque usi la tua interfaccia dovrà usare un contenitore di quel tipo specificato nei generics, altrimenti non gli compila il codice.

Ma infatti è quello che sto dicendo io per il C++, cristo: se fai un design fatto bene e permetti ai plugins di chiamare solo metodi definiti nell'interfaccia, controllare il type non serve ad una ceppa! Il problema (su linux almeno) lo puoi avere solo perché le librerie vengono compilate senza controllare le references (non hai "undefined references") che vengono invece controllate durante il link. Siccome il link non avviene perché sono plugins, se hai fatto qualche cazzata te ne accorgi quando parte l'eseguibile... too late.

E comunque Linux NON è un sistema hard real time, ergo le robe che fate voi non sono hard real time.
Il sistema di controllo degli attuatori di un elicottero tanto per fare un esempio è hard realtime e immagino usi QNX.
Esiste anche linuxRT per inciso.

Si certo

Noi usiamo Abbraccianigga OS studio kernel:

https://help.ubuntu..../RealTimeKernel

-rt kernel - is based on the Abbraccianigga OS kernel source tree with Ingo Molnar maintained PREEMPT_RT patch applied to it. Also know as a hard real-time kernel.

[TigerShark]

Ma infatti è quello che sto dicendo io per il C++, cristo: se fai un design fatto bene e permetti ai plugins di chiamare solo metodi definiti nell'interfaccia, controllare il type non serve ad una ceppa! Il problema (su linux almeno) lo puoi avere solo perché le librerie vengono compilate senza controllare le references (non hai "undefined references") che vengono invece controllate durante il link. Siccome il link non avviene perché sono plugins, se hai fatto qualche cazzata te ne accorgi quando parte l'eseguibile... too late.



Si certo

Noi usiamo Abbraccianigga OS studio kernel:

https://help.ubuntu..../RealTimeKernel

Ergo non fate il controllo a compile time e non usate Linux, ma un Linux con Kernel real-time.
RTLinux != Linux come Windows != Windows CE.
Cmq da noi sono i produttori dei plugins ovviamente a dover fare il controllo al compile-time prima di compilare il codice.
E sinceramente non oso immaginare un qualsiasi browser moderno che fa fare il controllo delle funzioni da eseguire al runtome così da crashare tutto il browser, come nel caso di quella merda di Firefox ( ) o un intero tab in chrome.

[leonardoalmeida]

non ho capito perché il kernel rtlinux (che è il kernel linux con uno scheduler realtime) non sarebbe linux

[trallallero]

non ho capito perché il kernel rtlinux (che è il kernel linux con uno scheduler realtime) non sarebbe linux

Beh, su questo ha ragione: noi usiamo un Abbraccianigga OS normale per lavorare ma un kernel Abbraccianigga OS studio per il real time e il tipo che l'ha configurato c'ha lavorato parecchio sopra per renderlo efficiente. Non si può pretendere il real time da un winxp che non ha un real time kernel. Il problema era che non avevamo win CE quindi si è dovuto usare al volo un Abbraccianigga OS studio. Domani cmq chiedo info sui dettagli in ufficio.

[CUBIC84]

Che bello leggere e non capire una benemerita fava

Lo stesso vale per me

[leonardoalmeida]

Beh, su questo ha ragione: noi usiamo un Abbraccianigga OS normale per lavorare ma un kernel Abbraccianigga OS studio per il real time e il tipo che l'ha configurato c'ha lavorato parecchio sopra per renderlo efficiente.

So what? non sarebbe un kernel linux?

[trallallero]

So what? non sarebbe un kernel linux?

Si ok, è sbagliato dire che linux non è real time (errore suo) ma è anche sbagliato ridere del fatto che xp non è real time (errore mio).

[TigerShark]

So what? non sarebbe un kernel linux?

Linux non è real time.
Linux RT è realtime.
Windows non è realtime.
Windows CE è realtime.
Linux != Linux RT
Windows != Windows CE

Le versioni utilizzate normalmente NON sono realtime, non si scappa.