assembly-generation V java-generation

[cdimauro]

Originariamente inviato da Unrue

Non è vero, dipende dal problema che devi risolvere

Se è fra i requisiti, certamente. I requisiti devono essere risolti, ci mancherebbe.

Originariamente inviato da Unrue

Quando dico "dietro le quinte", non intendo per forza il conoscere l'assembler.. Non dico che uno debba conoscere come funziona il processore a livello di transistor, ci mancherebbe. Ma mi sono accorto che molti programmatori, o presunti tali, sanno solo usare le librerie che danno la pappa pronta, e nient'altro. Ecco, quelli per me non sono programmatori. Inb fin dei conti, per saper usare una libreria, basta impararsi il manuale. Per risolvere problemi invece, ci vuole ingegno.

Questo è un altro discorso ed è condivisibile.

[DanieleC88]

Originariamente inviato da VICIUS

Semplicemente che chi è nato prima ha avuto più tempo. Il mio primo computer è del 17/12/1988 quindi se non sei un alieno io sono partito quei 7/8 ani prima di te.

Direi che ci hai preso più o meno.
Il tuo primo computer è giusto un po' più giovane di me, io ho cominciato a programmare forse a 13 anni. Comunque, be', chi è nato prima fino ad adesso ha avuto più tempo, chiaro, quelli che sono nati dopo lo avranno in seguito.

Originariamente inviato da khelidan1980

Questo imho è un requisito di base,ma non solo nella programmazione,in tutto ciò che si fa per hobby,per passione,per lavoro...credo che il topic fosse molto piu preciso,voleva proprio fare un paragone tra chi ha iniziato già nell'era dei linguaggi managed e quelli che iniziarono con l'assembly,perchè c'era quello e al massimo il c,basic....

Sì, certo, solo intendevo dire, ammetto però di non essermi espresso bene, che chi vuole può scavare nei meandri dell'assembly ancora oggi, magari però partendo da linguaggi che permettono una programmazione concettualmente più semplice. Un ragazzino che inizia a programmare adesso con linguaggi più "comodi" raggiunge i primi risultati in breve tempo ed evita di sbattere troppo la testa con cose che possono essere demoralizzanti. Semplicemente, ora c'è più scelta, ma chi vuole può decidere in ogni momento di percorrere la strada più tosta per imparare cosa c'è "dietro".

ciao

[Unrue]

Comunque sicuramente chi ha iniziato prima, con linguaggi meno di alto livello, conosce meglio la macchina. I linguaggi di oggi, ti nascondono molte cose, dunque impari meno. Esempio stupido: secondo me alcuni programmatori Java neanche sanno cosa sia un segmento di memoria, per il semplice fatto di non essersi imbeccati mai, o quasi, in un bel SEGMENTATION FAULT.

[D3stroyer]

Originariamente inviato da khelidan1980

dipende comunque io ho fatto l'uni negli ultimi anni(sto facendo la tesi ora) e l'approccio a basso livello c'è stato con tanto di programmazione in assembly,ovvio sicuramente il tempo dedicato è decisamente minore di quello di 20 anni fa ma allora non c'era java e compagnia bella da studiare!
E anche una questioni di ottimizzare il tempo in base a ciò che po realmente ti servirà sapere

dai l'assembly universitario è completamente inutile se non per capire piu' o meno cosa succede nei giri tra registridimemoria&friends. Magari ci può essere un vantaggio attuale per chi l'assembly l'ha usato per anni..non per 4 mesi.

[cdimauro]

Originariamente inviato da Unrue

Comunque sicuramente chi ha iniziato prima, con linguaggi meno di alto livello, conosce meglio la macchina. I linguaggi di oggi, ti nascondono molte cose, dunque impari meno. Esempio stupido: secondo me alcuni programmatori Java neanche sanno cosa sia un segmento di memoria, per il semplice fatto di non essersi imbeccati mai, o quasi, in un bel SEGMENTATION FAULT.

Beati loro: tanti mal di testa in meno.

[khelidan1980]

Originariamente inviato da D3stroyer

dai l'assembly universitario è completamente inutile se non per capire piu' o meno cosa succede nei giri tra registridimemoria&friends. Magari ci può essere un vantaggio attuale per chi l'assembly l'ha usato per anni..non per 4 mesi.

infatti il target è quello e imho deve essere quello,essere da supporto allo studio di un architettura,capire come funziona dietro le quinte un pc,un esempio di come anche adesso si fanno cose a basso livello,ma per l'appunto si fanno a scopo didattico non certo per essere produttivi

[71104]

Originariamente inviato da Unrue

Comunque sicuramente chi ha iniziato prima, con linguaggi meno di alto livello, conosce meglio la macchina. I linguaggi di oggi, ti nascondono molte cose, dunque impari meno. Esempio stupido: secondo me alcuni programmatori Java neanche sanno cosa sia un segmento di memoria, per il semplice fatto di non essersi imbeccati mai, o quasi, in un bel SEGMENTATION FAULT.

non c'azzecca una sega
nemmeno chi è incappato in un segmentation fault necessariamente sa cos'è un segmento; per saperlo devi studiare, punto.
e comunque Java non ti protegge affatto dai puntatori nulli (anche se nello specifico prendono il nome di "riferimenti" anziché "puntatori", e nonostante l'incoerenza del nome della NullPointerException).

[Unrue]

Originariamente inviato da 71104

non c'azzecca una sega
nemmeno chi è incappato in un segmentation fault necessariamente sa cos'è un segmento; per saperlo devi studiare, punto.

Se uno incappa in un problema e non approfondisce cavoli suoi. Io lo faccio sempre. Più sbatti la testa su un problema e più impari. Quando tutto fila liscio, difficile che uno si preoccupi di tanti aspetti..

Originariamente inviato da 71104

e comunque Java non ti protegge affatto dai puntatori nulli (anche se nello specifico prendono il nome di "riferimenti" anziché "puntatori", e nonostante l'incoerenza del nome della NullPointerException).

Non ho mica detto che in Java non possa capitare. Ma di sicuro capita molto più facilmente programmando in C che in Java Le varie librerie che ci sono in giro, per qualsiasi linguaggio, semplificano la vita certamente, ma ti nascondono molte cose. Vuoi un esempio: un mio amico laureato in Informatica, quindi non il primo che passa, mi ha chiesto a cosa serva studiarsi gli algoritmi di ordinamento affermando che tanto lo fanno le librerie! Ecco ditemi voi se questo è il modo rdi ragionare. Quindi se uno usa una libreria può allegramente dimenticarsi tutto quello che c'è dietro? Forse per un mero utilizzatore si, ma non un programmatore. Ma qualcuno dovrò pur farla quella libreria no? Quindi qualcuno dovrà pure impararsi gli algoritmi di ordinamento.

Io ribadisco che chi si limita ad usare le librerie, senza sapere minimamente cosa ci sia dietro, NON è un programmatore. Poi, come tutte le cose, più conosci a fondo lo strumento che usi, meglio è.

[71104]

Originariamente inviato da Unrue

Se uno incappa in un problema e non approfondisce cavoli suoi. Io lo faccio sempre. Più sbatti la testa su un problema e più impari. Quando tutto fila liscio, difficile che uno si preoccupi di tanti aspetti..

per quale assurdo motivo della terra uno dovrebbe studiare solo quando c'è un problema? a me per esempio tocca studiare ogni giorno cose che risolvono problemi che non vedrò mai (faccio l'università).

a chi ottiene un segmentation fault in genere gli si spiega che non può accedere ad indirizzi di memoria non allocati, questo è quanto; la nozione di segmento non ha nulla a che vedere ne' col linguaggio C ne' con la soluzione del problema del segfault, e potrebbe non esistere neanche su determinate architetture. alla vittima del segfault non si spiega cos'è un segmento, si dice solamente che se accede ad un indirizzo che punta a memoria non allocata ottiene un generico "errore" (che tra l'altro su Windows non si chiama neanche "segmentation fault", e che tra l'altro credo che su Linux non sia neanche un "segmentation fault").

Non ho mica detto che in Java non possa capitare. Ma di sicuro capita molto più facilmente programmando in C che in Java

beato te.

[Unrue]

Originariamente inviato da 71104

per quale assurdo motivo della terra uno dovrebbe studiare solo quando c'è un problema? a me per esempio tocca studiare ogni giorno cose che risolvono problemi che non vedrò mai (faccio l'università).

Ma chi l'ha detto questo ? Io ho solo detto che se uno si imbatte in un problema, cerca di capire da dove venga e di risolverlo. Non che sia l'unico modo per imparare quel determinato argomento. Si impara molto anche dagli errori che si commette. Java ha un controllo della memoria migliore di C, quindi ti evita molti problemi che con il C ti ci imbatti per forza.

[71104]

Originariamente inviato da Unrue

Ma chi l'ha detto questo ? Io ho solo detto che se uno si imbatte in un problema, cerca di capire da dove venga e di risolverlo.

hai dato un'occhiata a quello che ho scritto dopo le due righe quotate?

Java ha un controllo della memoria migliore di C, quindi ti evita molti problemi che con il C ti ci imbatti per forza.

Java ti evita tutt'altra categoria di problemi di memoria dinamica: ti impedisce di creare puntatori dal nulla o di sovrascriverne il valore per errore e ti risparmia dal deallocare gli oggetti, ma i riferimenti nulli non te li toglie nessuno.

io vorrei tanto che esistesse un linguaggio di programmazione basato sui null objects

[cdimauro]

Non credo esisterà mai, perché le esigenze sono sempre diverse.

Voglio che quando chiamo un metodo venga sollevata un'eccezione? O che mi venga ritornato un valore "standard" (0, 0.0, '', ecc.)? O una combinazione dei due?

Dipende sempre dal preciso contesto in cui viene usato un null object, e questo... può saperlo soltanto il programmatore.

[marco.r]

Originariamente inviato da 71104

hai dato un'occhiata a quello che ho scritto dopo le due righe quotate?

Java ti evita tutt'altra categoria di problemi di memoria dinamica: ti impedisce di creare puntatori dal nulla o di sovrascriverne il valore per errore e ti risparmia dal deallocare gli oggetti, ma i riferimenti nulli non te li toglie nessuno.

io vorrei tanto che esistesse un linguaggio di programmazione basato sui null objects

E perche' non direttamente uno dove gli oggetti null non ci sono e basta ? (A meno che uno non lo voglia si intende). Quelli ci sono

[71104]

Originariamente inviato da cdimauro

Non credo esisterà mai, perché le esigenze sono sempre diverse.

Voglio che quando chiamo un metodo venga sollevata un'eccezione? O che mi venga ritornato un valore "standard" (0, 0.0, '', ecc.)? O una combinazione dei due?

Dipende sempre dal preciso contesto in cui viene usato un null object, e questo... può saperlo soltanto il programmatore.

si, ma non c'è supporto sintattico per deciderlo: in Java i null objects te li devi creare manualmente, altrimenti il riferimento non inizializzato resta nullo. a me piacerebbe un linguaggio dove ad esempio per ogni metodo che definisci puoi definire anche il comportamento del null object, oppure se non ne definisci uno ne viene adottato uno di default. esempi di comportamenti di default:

• tornare 0 per gli interi
• 0.0 per i numeri a virgola mobile
• lanciare eccezione per i booleani
• stringa vuota per le stringhe
• null object per le classi

[71104]

Originariamente inviato da marco.r

E perche' non direttamente uno dove gli oggetti null non ci sono e basta ? (A meno che uno non lo voglia si intende). Quelli ci sono

ma immagino non abbiano molto supporto dalla loro... comunque (domando scusa per l'abissale ignoranza), esempi?

[cdimauro]

Originariamente inviato da 71104

si, ma non c'è supporto sintattico per deciderlo: in Java i null objects te li devi creare manualmente, altrimenti il riferimento non inizializzato resta nullo. a me piacerebbe un linguaggio dove ad esempio per ogni metodo che definisci puoi definire anche il comportamento del null object, oppure se non ne definisci uno ne viene adottato uno di default. esempi di comportamenti di default:

• tornare 0 per gli interi
• 0.0 per i numeri a virgola mobile
• lanciare eccezione per i booleani
• stringa vuota per le stringhe
• null object per le classi

Sì, ho capito Alberto ma, come dicevo, un comportamento "standard" non andrebbe bene per qualunque situazione.

Quella che proponi sarebbe un'ottima soluzione: supporto sintattico (magari tramite qualche annotazione, per non appesantire troppo il linguaggio) per specificare il comportamento almeno per quello di default, che potrebbe coprire buona parte dei casi (che è moooolto meglio di niente ).

Per il resto, vediamo cosa suggerisce Marco.

[71104]

altra idea che mi viene in mente: il programmatore potrebbe non aver bisogno di un null object perché potrebbe sapere a priori che ogni riferimento di quella classe verrà sempre inizializzato; in tal caso il supporto sintattico per questa situazione dovrebbe far sì che il compilatore dia errore per ogni riferimento non inizializzato.

[marco.r]

Originariamente inviato da cdimauro

Sì, ho capito Alberto ma, come dicevo, un comportamento "standard" non andrebbe bene per qualunque situazione.

Quella che proponi sarebbe un'ottima soluzione: supporto sintattico (magari tramite qualche annotazione, per non appesantire troppo il linguaggio) per specificare il comportamento almeno per quello di default, che potrebbe coprire buona parte dei casi (che è moooolto meglio di niente ).

Per il resto, vediamo cosa suggerisce Marco.

Ne avevamo gia' parlato tempo fa se non sbaglio. Secondo me il linguaggio i puntatori a null proprio non dovrebbe permetterli, in quanto questa concessione e' semanticamente sbagliata

Foo x;

non indica in realta' un oggetto di tipo Foo, ma 0 o 1 oggetti di tipo Foo. Forse mi sbaglio ma sopprerire a questo in Java (ad esempio con una classe Wrapper scritta dall'utente) non e' banale .In ogni caso il linguaggio dovrebbe favorire il comportamento piu' "safe", lasciando la possibilita' di inserire puntatori nulli solo quando serve. Ovviamente se cosi' fosse ci vorrebbe un modo relativamente semplice per poter indicare la potenziale assenzad del puntatore.
Tra i linguaggi con tipizzazione statica (per quelli dinamici ovviamente la questione non ha molto senso) che si comportano correttamente che io sappia ci sono quelli della famiglia ML, e Haskell, Clean, dove tra l'altro l'indicazione della mancanza di oggetto e' gestita in modo molto elegante con i tipi algebrici.

[marco.r]

Originariamente inviato da 71104

altra idea che mi viene in mente: il programmatore potrebbe non aver bisogno di un null object perché potrebbe sapere a priori che ogni riferimento di quella classe verrà sempre inizializzato; in tal caso il supporto sintattico per questa situazione dovrebbe far sì che il compilatore dia errore per ogni riferimento non inizializzato.

Esatto, era la mia idea e, secondo me, il modo migliore per gestire la cosa.

[cdimauro]

Originariamente inviato da marco.r

Ne avevamo gia' parlato tempo fa se non sbaglio. Secondo me il linguaggio i puntatori a null proprio non dovrebbe permetterli, in quanto questa concessione e' semanticamente sbagliata

Foo x;

non indica in realta' un oggetto di tipo Foo, ma 0 o 1 oggetti di tipo Foo.

Sì, ricordo che ne avevamo parlato, e infatti l'idea è quella di non avere proprio puntatori a null, ma soltanto istanze "particolari" di una certa classe.

Forse mi sbaglio ma sopprerire a questo in Java (ad esempio con una classe Wrapper scritta dall'utente) non e' banale .In ogni caso il linguaggio dovrebbe favorire il comportamento piu' "safe", lasciando la possibilita' di inserire puntatori nulli solo quando serve. Ovviamente se cosi' fosse ci vorrebbe un modo relativamente semplice per poter indicare la potenziale assenzad del puntatore.

Ed è appunto da dove è nato il dibattito: che tipo di Null Object possiamo utilizzare? Domanda non banale, vista la moltitudine di soluzioni allo scopo.

Tra i linguaggi con tipizzazione statica (per quelli dinamici ovviamente la questione non ha molto senso) che si comportano correttamente che io sappia ci sono quelli della famiglia ML, e Haskell, Clean, dove tra l'altro l'indicazione della mancanza di oggetto e' gestita in modo molto elegante con i tipi algebrici.

Ecco, questa è una cosa che non conoscevo e che, a questo punto, merita un approfondimento, visto che sembra una "bella" soluzione al problema.

Lo farò appena avrò un po' di tempo per studiarmi Haskell (che fra i tre è quello che da tempo mi ispira di più).