Software multipiattaforma

[cdimauro]

Originariamente inviato da 2186

allora la definizione di professionista la puoi tranquillamente trovare tra wikipedia e google :-P
per quanto riguarda il discorso dell'assembly ora mi spiego...
per usare il linguaggio asm non è come usare il c++ o vb o java delphi e via discorrendo... per usare in maniera corretta l'asm bisogna conoscere a fondo l'achitettura del controllore da programmare, quindi nonchè una buona conoscenza di sistemistica, controlli, elettronica e dulcis in "findus" anche un minimo di programmazione.... ora se sei in grado di conoscere vita morte e miracoli dell'architettura per cui stai sviluppando un software sigifica che non sei uno quaquaraqà.... anzi....per non parlare poi di ADA e VHDL (o verilog) meno complessi dell'asm e simili al c ma di gran lunga più complessi dato che per fare una buona struttura si deve conoscere a menadito la struttura interna del chip e quindi anche come lui stesso implementa le funzioni da noi scritte....

insomma spero di essermi spiegato :-P
ciao

Ti sei spiegato, ma non concordo. Si può programmare discretamente in assembly conoscendo lo stretto indispensabile per risolvere il problema a cui stai lavorando.

Originariamente inviato da 2186

2)mi spiace ma l'assembly non è un linguagggio come un altro... oserei dire che è IL LINGUAGGIO... e quello che puoi fare con quello te lo puoi sognare con gli altri... (a meno di implementare ad esmpio in un sorgente una porzione in asm stesso per fare la particolare operazione richiesta )

IL linguaggio per eccellenza è quello macchina: l'UNICO col quale puoi fare veramente di tutto senza scendere a compromessi.

[2186]

Originariamente inviato da cdimauro

Ti sei spiegato, ma non concordo. Si può programmare discretamente in assembly conoscendo lo stretto indispensabile per risolvere il problema a cui stai lavorando.

IL linguaggio per eccellenza è quello macchina: l'UNICO col quale puoi fare veramente di tutto senza scendere a compromessi.

si vero su questo sono daccordo anche io :-P
anche se quando intendo programmare in asm intendo vermante programmare e non solo conoscere quei set comandi che ti servono nello specifico...
ciau

[cdimauro]

Per me programmare in assembly, come per qualunque altro linguaggio, significa risolvere i problemi che mi vengono sottoposti.

[banryu79]

Originariamente inviato da 2186

3) Registri? Ram? Periferiche? In Java? esatto proprio per questo dicevo che dipende cosa devi fare... nel momento in cui devi lavorare con quei componenti non userai mai java... ma non perchè non sia buono, ma semplicemente perchè non farà quello che vorrai e come lo vorrai soprattutto

Ma appunto non è il linguaggio che non te lo permette, attenzione, ma solo la sa implementazione. Quando programmi in Java, come target hai una Virtual Machine.
Con Java in quanto linguaggio ci puoi scrivere (e si sta facendo) anche un sitema operativo (vedi JNode).

Inoltre: un programmatore risolve problemi.
Sono i problemi che deve risolvere e i requisiti che essi determinano per la soluzione a determinare il preciso livello di astrazione al quale il programmatore deve operare.
E questo non ha niente a che vedere con la professionalità; sono solo ambiti diversi di competenze (e domini di conoscenza diversi).
La professionalità di un programmatore si misura in base alla sua capacità di risolvere i problemi per i quali è richiesta la sua opera. Se i problemi che deve risolvere richiedono l'uso del linguaggio assembly e la conscenza minuziosa di una specifica architettura, bene, quello deve sapere; viceversa se i problemi da risolvere richiedono l'uso di un linguaggio di alto livello e la conoscenza minuziosa di alcune librerie, bene, quello deve sapere.
A volte poi capita di avere bisogno di risolvere problemi che richiedono competenze "trasversali": bene, quelle competenze bisogna avere.
Non si può ogni volta "assolutizzare": esistono diversi strati o livelli di astrazione dalla macchina nuda & cruda e diverse "brache" di sapere: inutile e privo di fondamento dire che un pezzo del quadro è più importante degli altri.
Ciao

[2186]

Originariamente inviato da banryu79

Ma appunto non è il linguaggio che non te lo permette, attenzione, ma solo la sa implementazione. Quando programmi in Java, come target hai una Virtual Machine.
Con Java in quanto linguaggio ci puoi scrivere (e si sta facendo) anche un sitema operativo (vedi JNode).

Inoltre: un programmatore risolve problemi.
Sono i problemi che deve risolvere e i requisiti che essi determinano per la soluzione a determinare il preciso livello di astrazione al quale il programmatore deve operare.
E questo non ha niente a che vedere con la professionalità; sono solo ambiti diversi di competenze (e domini di conoscenza diversi).
La professionalità di un programmatore si misura in base alla sua capacità di risolvere i problemi per i quali è richiesta la sua opera. Se i problemi che deve risolvere richiedono l'uso del linguaggio assembly e la conscenza minuziosa di una specifica architettura, bene, quello deve sapere; viceversa se i problemi da risolvere richiedono l'uso di un linguaggio di alto livello e la conoscenza minuziosa di alcune librerie, bene, quello deve sapere.
A volte poi capita di avere bisogno di risolvere problemi che richiedono competenze "trasversali": bene, quelle competenze bisogna avere.
Non si può ogni volta "assolutizzare": esistono diversi strati o livelli di astrazione dalla macchina nuda & cruda e diverse "brache" di sapere: inutile e privo di fondamento dire che un pezzo del quadro è più importante degli altri.
Ciao

si esatto su questo quoto in pieno anche io... ma non mi puoi negare che programmare in asm sia una cosa banale o come un altro linguaggio, perchè non lo è affatto...anzi...

ciao

[banryu79]

Originariamente inviato da 2186

si esatto su questo quoto in pieno anche io... ma non mi puoi negare che programmare in asm sia una cosa banale o come un altro linguaggio, perchè non lo è affatto...anzi...

E chi ha banalizzato?
Io, personalmente, cerco di non banalizzare ne dare per scontato nulla, nei miei limiti.
Per me l'attività di programmare, non è mai banale. Tra l'altro la conoscenza di un linguaggio è solo uno degli strumenti di conoscenza che entrano in ballo, in tale attività.
Dunque, dal mio punto di vista, non è banale programmare ne in assembly, ne in C, ne in Java, ne in C#, ne in SmallTalk, ne in Delphi, ne in Eiffel, ne in Factor, ne in Haskell, ne in Lisp, ne in Ada, ne in Python, ne in.... credo si sia capito

Proprio per il fatto che saper programmare non significa la mera conoscenza del linguaggio (anche se la presuppone).

[2186]

Si, vero... ma io personalmente reputo linguaggio e linguaggio... anche se sono orientati a sviluppi differeni (settori) di certo non posso dire che il c++ sia piu difficile del VHDL e di certo che il vhdl lo sia piu di un ASM... insomma analizzando in maniera oggettiva dal mio punto di vista ci sono linguaggi e linguaggi, e come tale ne esistono di più semplici e più complicati, e questo penso sia innegabile.

[banryu79]

Originariamente inviato da 2186

insomma analizzando in maniera oggettiva dal mio punto di vista ci sono linguaggi e linguaggi, e come tale ne esistono di più semplici e più complicati, e questo penso sia innegabile.

Beh, se ognuno dovesse portare la sua personale "visione" non ci basterebbe un secolo per metterci tutti d'accordo.
Quello che dici ha un senso solo entro il limite determinato dal significato che tu attribuisci alla parola "semplice", e alla parola "complicato" nel contesto della tua affermazione.

In ogni caso, anche ammettendo che un linguaggio X è più complicato (facciamo sia da imparare che a utilizzare, in genere) di un linguaggio Y, anche prendendo due diversi programmatori A e B, che devono tipicamente risolvere problemi appartenenti a diverse branche applicative, ognuna delle quali richiede di operare a un diverso livello di astrazione BASSO oppure ALTO, dove A conosce X e opera al livello BASSO e B conosce Y e opera al livello ALTO, ancora non possiamo dire nulla su chi dei due sia più professionale.

Ovvero: non importa quanto è complicato il linguaggio che utilizza un certo programmatore: il solo fatto di utilizzarlo in ambito professionale (e quindi, presumibilmente, averlo padroneggiato) non ci dice nulla circa la sua professionalità in assoluto, e neppure relativamente ad altri programmatori che utilizzano linguaggi diversi.
Potrebbe al massimo darci un'idea stereotipata, parziale e di massima circa la sua "forma mentis" nell'approcciare e risolvere un problema dalla sua prospettiva; potrebbe anche darci una vaga idea dei campi applicativi in cui più spesso è richiesta la sua opera.

Tutto questo valutando le cose in modo "asettico"; cioè senza considerare che ogni programmatore ha invetibilmente dei gusti e delle inclinazioni particolari, e le sue idiosincrasie. E ricordandoci che stiamo solo pensando ai linguaggi, lasciando fuori tutto il resto (un'enormita' di roba). Ad esempio le concrete esperienze maturate in un certo dominio di problemi.

[cdimauro]

Originariamente inviato da 2186

si esatto su questo quoto in pieno anche io... ma non mi puoi negare che programmare in asm sia una cosa banale o come un altro linguaggio, perchè non lo è affatto...anzi...

ciao

Originariamente inviato da 2186

Si, vero... ma io personalmente reputo linguaggio e linguaggio... anche se sono orientati a sviluppi differeni (settori) di certo non posso dire che il c++ sia piu difficile del VHDL e di certo che il vhdl lo sia piu di un ASM... insomma analizzando in maniera oggettiva dal mio punto di vista ci sono linguaggi e linguaggi, e come tale ne esistono di più semplici e più complicati, e questo penso sia innegabile.

Prova a buttare giù del codice Python (che è un linguaggio di altissimo livello) che, scrivendo questo:

DB.PartnersSubAreas['id', 'name'].orderby['id desc'].limit[0, 5].List(partnerid = 1)

è in grado di tirarti fuori la seguente query:

SELECT id, name FROM PartnersSubAreas WHERE (partnerid = %s) ORDER BY id desc LIMIT %s, %s

passargli i seguenti parametri:

[1, 0, 5]

eseguirla sul DB, e restituire una lista di lista di elementi (id e name).

Ti assicuro che non è affatto banale. E non sto lavorando in assembly.

[tomminno]

Originariamente inviato da cdimauro

Prova a buttare giù del codice Python (che è un linguaggio di altissimo livello) che, scrivendo questo:

DB.PartnersSubAreas['id', 'name'].orderby['id desc'].limit[0, 5].List(partnerid = 1)

è in grado di tirarti fuori la seguente query:

SELECT id, name FROM PartnersSubAreas WHERE (partnerid = %s) ORDER BY id desc LIMIT %s, %s

passargli i seguenti parametri:

[1, 0, 5]

eseguirla sul DB, e restituire una lista di lista di elementi (id e name).

Ti assicuro che non è affatto banale. E non sto lavorando in assembly.

Che fai PyLINQ?

[2186]

Originariamente inviato da cdimauro

Prova a buttare giù del codice Python (che è un linguaggio di altissimo livello) che, scrivendo questo:

DB.PartnersSubAreas['id', 'name'].orderby['id desc'].limit[0, 5].List(partnerid = 1)

è in grado di tirarti fuori la seguente query:

SELECT id, name FROM PartnersSubAreas WHERE (partnerid = %s) ORDER BY id desc LIMIT %s, %s

passargli i seguenti parametri:

[1, 0, 5]

eseguirla sul DB, e restituire una lista di lista di elementi (id e name).

Ti assicuro che non è affatto banale. E non sto lavorando in assembly.

non dico che sia banale e non l'ho mai detto... ma se vuoi ti pasto il codice di un dsp scritto in asm che è nelle tastiere della korg :-P neanche immagini che lavoro da bestie c'è dietro tra FFT STFT OVERLAP etc... cmq fa nulla...

[2186]

fatto sta che tanto ognuno rimarrà della propria idea, com'è anche giuisto che sia.... io quel ke ho detto l'ho detto per esperienza personale...immagino e spero anche voi...
cmq son contento ugualmente di aver scambiato idee ed opinioni con voi, rimandendo però ferreo sulle mie (per ora)... kissà un dì potrei anche ricredermi e appoggiare le vostre tesi, ma per il momento no.
Grazie ancora della chiacchierata
ciao

[marco.r]

Originariamente inviato da cdimauro

Prova a buttare giù del codice Python (che è un linguaggio di altissimo livello) che, scrivendo questo:

DB.PartnersSubAreas['id', 'name'].orderby['id desc'].limit[0, 5].List(partnerid = 1)

è in grado di tirarti fuori la seguente query:

SELECT id, name FROM PartnersSubAreas WHERE (partnerid = %s) ORDER BY id desc LIMIT %s, %s

passargli i seguenti parametri:

[1, 0, 5]

eseguirla sul DB, e restituire una lista di lista di elementi (id e name).

Ti assicuro che non è affatto banale. E non sto lavorando in assembly.

Beh li' e' colpa piu' del linguaggio, che non e' facilmente estendibile

[cdimauro]

Originariamente inviato da tomminno

Che fai PyLINQ?

Francamente no, e nemmeno ci pensavo.

In questi giorni ho finito un progetto, e mi sono messo a rifattorizzare il codice, e ho notato dei pattern precisi per quanto riguarda le classiche operazioni al database. E' capitato anche con tanti altri progetti, ma questa volta avevo un po' di tempo e cominciato a raggruppare il codice in funzioni, a parametrizzarle, ecc.

Così sono arrivato a crearmi 4 funzioni abbastanza generali per coprire le classiche SELECT, INSERT, DELETE e UPDATE di SQL.

Ma non mi bastava. Anche se il codice era molto più pulito e lineare, non mi sembrava "naturale". Così ho cominciato a pensare come sarebbe stato comodo de dalla classe DB che usavo per crearmi la connessione al database, avessi potuto "estrarre" l'istanza di un'altra che rappresentasse l'entità tabella desiderata. E così via, da lì ho fatto diventare la classe DB una factory per la classe Entity che ho creato e che incapsulava tutte e 4 le operazioni SQL sopra citate.

Non so, magari sono stato influenzato da LINQ a causa dei numerosi esempi che ho visto da parte di gugoXX e di Tigershark, e incosciamente sono stato portato a creare un modello simile.

Simile, ma diverso, perché LINQ è un approccio alla manipolazione dei dati, mentre il mio voleva essere soltanto un metodo più naturale e semplice per gestire le 4 operazioni su DB.

E infatti sto già pensando di farlo evolvere in modo da poter rappresentare condizioni molto più complesse per la parte WHERE, e magari aggiungere le operazioni di UNION, INTERSECT, le JOIN, e così via.

Le potenzialità offerte dall'overloading degli operatori sono incredibili, e mi stanno facendo ammattire (nel senso buono).

Originariamente inviato da 2186

non dico che sia banale e non l'ho mai detto... ma se vuoi ti pasto il codice di un dsp scritto in asm che è nelle tastiere della korg :-P neanche immagini che lavoro da bestie c'è dietro tra FFT STFT OVERLAP etc... cmq fa nulla...

Originariamente inviato da 2186

fatto sta che tanto ognuno rimarrà della propria idea, com'è anche giuisto che sia.... io quel ke ho detto l'ho detto per esperienza personale...immagino e spero anche voi...
cmq son contento ugualmente di aver scambiato idee ed opinioni con voi, rimandendo però ferreo sulle mie (per ora)... kissà un dì potrei anche ricredermi e appoggiare le vostre tesi, ma per il momento no.
Grazie ancora della chiacchierata
ciao

Anch'io parlo per esperienza personale (cerca "the best amiga fighting game", e vedi cosa trovi ), visto che ho passato buona parte della mia vita da programmatore a lavorare in assembly. E tutta l'esperienza accumulata a basso livello non fa che farmi apprezzare i vantaggi e le potenzialità dei linguaggi di alto livello.

Fermo restando che, basso o alto livello che sia, da buon programmatore ribadisco che m'interessa risolvere i problemi che mi vengono sottoposti.

Originariamente inviato da marco.r

Beh li' e' colpa piu' del linguaggio, che non e' facilmente estendibile

Mumble. Francamente mi sono divertito molto e non ho trovato particolari impedimenti a livello di linguaggio, a parte una cosa. Questa:

DB.formats(name = 'Pippo') *= {id = 1}

che non posso scrivere perché non si può utilizzare l'operatore di moltiplicazione inplace sull'invocazione di una funzione. Per cui sono stato costretto a utilizzare l'operatore di indicizzazione / accesso a un vettore:

DB.formats[{'name' = 'Pippo'}] *= {id = 1}

Avrei preferito una catena di chiamata a metodi. Ma va bene anche così. Quindi ho riservato l'operatore di chiamata a funzione esclusivamente per implementare le SELECT, e dove serve passare parametri o impostare certe configurazioni (come orderby e limit, ad esempio), utilizzato l'operatore getitem.

Comunque sarei molto interessato a sapere in che modo avresti pensato di implementarlo. Quindi quale sintassi sarebbe stata più comoda per te (se Python lo avesse permesso).

[gugoXX]

Originariamente inviato da cdimauro

Francamente no, e nemmeno ci pensavo.

In questi giorni ho finito un progetto, e mi sono messo a rifattorizzare il codice, e ho notato dei pattern precisi per quanto riguarda le classiche operazioni al database. E' capitato anche con tanti altri progetti, ma questa volta avevo un po' di tempo e cominciato a raggruppare il codice in funzioni, a parametrizzarle, ecc.

Così sono arrivato a crearmi 4 funzioni abbastanza generali per coprire le classiche SELECT, INSERT, DELETE e UPDATE di SQL.

Ma non mi bastava. Anche se il codice era molto più pulito e lineare, non mi sembrava "naturale". Così ho cominciato a pensare come sarebbe stato comodo de dalla classe DB che usavo per crearmi la connessione al database, avessi potuto "estrarre" l'istanza di un'altra che rappresentasse l'entità tabella desiderata. E così via, da lì ho fatto diventare la classe DB una factory per la classe Entity che ho creato e che incapsulava tutte e 4 le operazioni SQL sopra citate.

Non so, magari sono stato influenzato da LINQ a causa dei numerosi esempi che ho visto da parte di gugoXX e di Tigershark, e incosciamente sono stato portato a creare un modello simile.

Simile, ma diverso, perché LINQ è un approccio alla manipolazione dei dati, mentre il mio voleva essere soltanto un metodo più naturale e semplice per gestire le 4 operazioni su DB.

E infatti sto già pensando di farlo evolvere in modo da poter rappresentare condizioni molto più complesse per la parte WHERE, e magari aggiungere le operazioni di UNION, INTERSECT, le JOIN, e così via.
.

Eheh.

LINQ ha parecchi flavour.
Il primo, generalmente il piu' usato, anche qui sul forum, e' "LINQ to Object", ovvero il manipolare i dati gia' presenti nelle collezioni in memoria.
Il secondo e' "LINQ to SQL", che fa proprio quello che stavi studiando, ovvero prendere una sequenza di istruzioni funzionali e trasformarla in una istruzione SQL da sottomettere al DB di turno.
Che e' simile se non identico a quanto stai studiano.

Ci sono poi "LINQ to XML" e "LINQ to Dataset".

Relativamente a "LINQ to SQL" c'e' gia' stata un'evoluzione, sotto il nome di Entity Framework.


Impagabile vedere trasformare cose come

var res = Persone.Where(persona => persona.Nome.StartsWith("Pippo"))
                       .OrderBy(persona => persona.Cognome)
                       .Select(persona=> new {persona.citta, persona.indirizzo});

in

SELECT Citta,Indirizzo
  FROM Persone
  WHERE Nome LIKE 'pippo%'
  ORDER BY Cognome

[cdimauro]

Concordo: è una goduria.

Ed effettivamente sono molto simili (d'altra parte queste soluzioni sono nate per risolvere gli stessi problemi).

Io ho usato una notazione forse un po' troppo stringata, ma mi sembra che bene o male sia comprensibile.

Ovviamente ogni suggerimento è il benvenuto.

[cdimauro]

marco.r, perché non ti spieghi? Guarda che non ti mangio mica! Sono seriamente interessato al tuo punto di vista (e, tempo fa, anche a quello sui thread).

[cionci]

Originariamente inviato da JoJo

Dovrei realizzare un software di controllo per macchine CNC da utilizzare sia in ambiente Windows che in ambiente Linux.

Puoi indicare brevemente la composizione hardware della macchina che controlla la CNC ?
Spesso sono macchine vecchie e poco performanti.

[marco.r]

Originariamente inviato da cdimauro

marco.r, perché non ti spieghi? Guarda che non ti mangio mica! Sono seriamente interessato al tuo punto di vista (e, tempo fa, anche a quello sui thread).

Carenza di tempo . Oggi provero' ad esporre con calma il discorso.

[cdimauro]

Ma no, guarda: prenditi pure tutto il tempo che vuoi. E' già tanto se mi risponderai, e ti ringrazio anticipatamente per il disturbo.