Il linguaggio di oggi e del futuro?

[71104]

Originariamente inviato da giannola

credo intendesse dire che il C è considerato il linguaggio di più basso livello tra i linguaggi di alto livello.
Nel senso che si può usare appena sopra l'assembly per creare sistemi operativi ecc.
In questo senso viene spiegata la maggiore potenza rispetto agli altri linguaggi concorrenti.

ma non solo: Java per esempio non da' la possibilità di ereditare da basi multiple. che il signor Turing la mettesse come gli pare, è una cosa che in C++ posso fare e in Java no.

E' da un po' di tempo che ritengo il l'ANSI C il linguaggio didattico di base. Lo step successivo è sicuramente un linguaggio ad oggetti. A questo punto bisogna però tenere conto di quello che vuoi fare ... t'interessi esclusivamente o quasi della piattaforma Windows? Meglio C# e .Net. Sei più orientato al web? Meglio Java. Hobbista? VB va bene così come altri linguaggi più "tranquilli".

Chiaro poi che ci stanno altre "intersezioni".

[mad_hhatter]

Originariamente inviato da 71104

ma il sistema operativo sottostante non è scritto ne' in Java ne' in Python; e neanche in C++ finora.

ovvio, la gestione degli oggetti non serve a niente a livello di kernel e anzi appesantirebbe il tutto in modo inutile

[mad_hhatter]

Originariamente inviato da 71104

no perché la "Turing-completezza" non coinvolge la potenza in termini di interazione con la piattaforma (in Java non puoi chiamare le API Win32).

beh, intanto dovremmo chiederci se tale interazione sia fondamentale e introduca limiti insormontabili... e qui andremmo a vedere quale scopo ciprefiggiamo, quindi nn possiamo dare valutazioni assolute... java gestisce in modo nativo meccanismi di sincronizzazione, mentre c, per esempio, si appoggia a librerie del s.o. ospite.

java è nato per essere indipendente dalla piattaforma, è ovvio che non dia la possibilità di chiamare le API di win... se ti servono le API di win vuol dire che non ti serve java e che sbaglieresti a usarlo. Ma questo non significa che java sia piu o meno potente... potente è un aggettivo tanto vago quanto relativo...

[thebol]

Originariamente inviato da 71104

ma non solo: Java per esempio non da' la possibilità di ereditare da basi multiple. che il signor Turing la mettesse come gli pare, è una cosa che in C++ posso fare e in Java no.

in c++ non puoi dichiarare un blocco threadsafe(aka syncronized) o dire che una variabile sia leggibile e scrivibile dai + thread in maniera sicura(aka volatile)

ps.in c++ si puo fare multithreading, come in java si puo aggirare la mancanza dell'ereditarieta multipla(ereditarieta multipla di interfaccie, delegation, etc)
solo che i linguaggi ti mettono a disposizione dei meccanismi per scrivere + o - meglio queste cose(un po come i generics/template, o un for each)

[71104]

Originariamente inviato da mad_hhatter

ovvio, la gestione degli oggetti non serve a niente a livello di kernel

tant'è vero che il kernel NT è scritto in un'ottica OOP, coi relativi vantaggi.

e anzi appesantirebbe il tutto in modo inutile

perché?

[repne scasb]

Originariamente inviato da LupettoOne

Il linguaggio di oggi e del futuro?

Non conosco il linguaggio del presente ma essendomi nota la fantasia di un creatore medio di linguaggi di programmazione, direi che per il futuro mi aspetto un linguaggio di programmazione del tipo:

D**
E$
Kava
Anaconda
PPHHPP

[mad_hhatter]

Originariamente inviato da 71104

tant'è vero che il kernel NT è scritto in un'ottica OOP, coi relativi vantaggi.

perché?

beh, che sia scritto in ottica OOP non significa che sia scritto con un linguaggio a oggetti... e' scritto in C o in C++?

anche il C puo' emulare con le struct il concetto di oggetto, ma non e' la stessa cosa!

per il discorso che si appesantisce... mah guarda, francamente non ho test sotto mano ma cosi' mi era stato detto. Probabilmente la gestione degli oggetti implica un overhead superiore e poi sicuramente hai un costo in termini di occupazione di memoria maggiore... ma potrei sbagliarmi, se hai info in merito mi piacerebbe discuterne.

[LupettoOne]

Ragazzi vi ringrazio per avermi dato tantissime risposte! Ovviamente come hanno detto tanti... dipende da quello ke vorrei fare! Bhè io vorrei creare programmi che devono avere una veste grafica! Sia installer che standalone mi va bene entrambi ma la cosa che non ho mai capito l'installer è sempre megliore dello standalone come esecuzione o viceversa?
Vorrei imparare un linguaggio che oggi si usa e che è ricercato nel mondo del lavoro! Da come ho capito ogni linguaggio ha un suo modo di programmazione che a seconda del programmatore cosa vuole fare! Sicuramente mi mettere la scelta tra il java e il .net! Vi ringrazio di nuovo!

[jappilas]

Originariamente inviato da mad_hhatter

ovvio, la gestione degli oggetti non serve a niente a livello di kernel e anzi appesantirebbe il tutto in modo inutile

che io sappia, non è "la gestione degli oggetti" in senso lato che appesantirebbe il kernel , sarebbero eventualmente costrutti complessi di certo linguaggio con supporto OO ( vedi: templates, RTTI, eredità multipla...), ma questo si applicherebbe a programmi di qualunque tipo, e per il kernel nella fattispecie si tratta di costrutti di cui non si ha bisogno

comunque a livello di kernel gli oggetti servono eccome, pensa solo alla gerarchia delle risorse (file system locali e remoti), la gestione dei device

Originariamente inviato da mad_hhatter

beh, che sia scritto in ottica OOP non significa che sia scritto con un linguaggio a oggetti... e' scritto in C o in C++?

anche il C puo' emulare con le struct il concetto di oggetto, ma non e' la stessa cosa!

per il discorso che si appesantisce... mah guarda, francamente non ho test sotto mano ma cosi' mi era stato detto. Probabilmente la gestione degli oggetti implica un overhead superiore e poi sicuramente hai un costo in termini di occupazione di memoria maggiore... ma potrei sbagliarmi, se hai info in merito mi piacerebbe discuterne.

http://www.caravan.net/ec2plus/rationale.html

Il System Expert (che gestisce la topologia dei device nel sistema e la loro mappatura a inode) di Mac Os X è scritto in questo linguaggio

Originariamente inviato da repne scasb

Non conosco il linguaggio del presente ma essendomi nota la fantasia di un creatore medio di linguaggi di programmazione, direi che per il futuro mi aspetto un linguaggio di programmazione del tipo:

D**
E$
Kava
Anaconda
PPHHPP

LOL

[71104]

Originariamente inviato da repne scasb

Non conosco il linguaggio del presente ma essendomi nota la fantasia di un creatore medio di linguaggi di programmazione, direi che per il futuro mi aspetto un linguaggio di programmazione del tipo:

guarda che i nomi vanno si a fantasia ma mica sono scelti a casaccio
e poi secondo me ormai l'era delle note musicali è finita

[mad_hhatter]

Originariamente inviato da jappilas

comunque a livello di kernel gli oggetti servono eccome, pensa solo alla gerarchia delle risorse (file system locali e remoti), la gestione dei device

ok, ma che io sappia il kernel linux è scritto in C, non in c++... o sbaglio?

purtroppo oggi non ho tempo, ma mi piacerebbe documentarmi su questi aspetti...

c'è anche da dire che come linguaggio OO ho in mente java, mentre non posso dire di conoscere C++... forse questo mi crea dei preconcetti errati... se hai altro materiale mi piacerebbe avere maggiori info, grazie

[71104]

Originariamente inviato da mad_hhatter

beh, che sia scritto in ottica OOP non significa che sia scritto con un linguaggio a oggetti... e' scritto in C o in C++?

in C, ma solo per retrocompatibilità: la mancanza degli oggetti si sente (penso che se fosse stato scritto veramente in C++ sarebbe stato più veloce).

anche il C puo' emulare con le struct il concetto di oggetto, ma non e' la stessa cosa!

infatti vedi sopra: in C++ sarebbe probabilmente ancora meglio.

per il discorso che si appesantisce... mah guarda, francamente non ho test sotto mano ma cosi' mi era stato detto.

infatti anche questa è una credenza tanto diffusa quanto falsa. il buon vecchio fek su Diamond Crush ci ha messo poco a smontarla col suo classico esempio della GetType.

Probabilmente la gestione degli oggetti implica un overhead superiore e poi sicuramente hai un costo in termini di occupazione di memoria maggiore...

ma non mi risulta proprio... secondo te perché un programma a oggetti dovrebbe occupare più memoria ed essere più lento di un programma scritto in paradigma procedurale?

[mad_hhatter]

Originariamente inviato da 71104

infatti anche questa è una credenza tanto diffusa quanto falsa. il buon vecchio fek su Diamond Crush ci ha messo poco a smontarla col suo classico esempio della GetType.

ma non mi risulta proprio... secondo te perché un programma a oggetti dovrebbe occupare più memoria ed essere più lento di un programma scritto in paradigma procedurale?

hai qualche link sul "buon vecchio fek"? purtroppo non so di cosa parli

mah guarda, come ho scritto in un altro post, probabilmente ho troppo in mente java con RTTI e RTTR... secondo me questi meccanismi portano più occupazione di memoria e più overhead... ma ti ripeto, forse sono solo miei preconcetti. se hai documentazione in merito fammi la cortesia di segnalarmela perchè vorrei levarmi di dosso questi falsi miti, se tali sono

[71104]

Originariamente inviato da mad_hhatter

hai qualche link sul "buon vecchio fek"? purtroppo non so di cosa parli

1) mi pesa il mouse ad andare a ritrovare i post nei meandri del forum
2) non voglio suggerire
3)

comunque fek è (era) un utente di questo forum che ultimamente però è un po' sparito ^^

mah guarda, come ho scritto in un altro post, probabilmente ho troppo in mente java con RTTI e RTTR... secondo me questi meccanismi portano più occupazione di memoria e più overhead...

ma come fai a farti questa opinione se manco sai come sono implementati...
oppure lo sai?

ma ti ripeto, forse sono solo miei preconcetti. se hai documentazione in merito fammi la cortesia di segnalarmela perchè vorrei levarmi di dosso questi falsi miti, se tali sono

non ci vuole niente a levarteli di dosso: devi semplicemente metterti in testa che non devi dare per buono quello che ti dicono finché non te lo dimostrano. nel caso specifico probabilmente avrebbero avuto difficoltà a dimostrarti che la programmazione a oggetti di per se' è "pesante", e in tal modo tu stesso (da ignorante sull'argomento) avresti anche ottenuto di aver fatto qualcosa di utile alla causa comune smontando i loro falsi miti. il tutto senza praticamente muovere un dito e senza argomentare nulla: gli hai solo fatto notare che non sono in grado di dimostrarli. fico no?

[71104]

ah, comunque ad onor del vero per quanto riguarda l'RTTI aggiungo che neanche a fek è mai piaciuta: ricordo che ci ha espressamente vietato di usarla su DC e concordo pienamente perché la necessità di dover ritrovare il tipo di oggetto in un momento diverso dalla sua creazione è indice di un probabile cattivo design.

[giannola]

Originariamente inviato da LupettoOne

Ragazzi vi ringrazio per avermi dato tantissime risposte! Ovviamente come hanno detto tanti... dipende da quello ke vorrei fare! Bhè io vorrei creare programmi che devono avere una veste grafica! Sia installer che standalone mi va bene entrambi ma la cosa che non ho mai capito l'installer è sempre megliore dello standalone come esecuzione o viceversa?
Vorrei imparare un linguaggio che oggi si usa e che è ricercato nel mondo del lavoro! Da come ho capito ogni linguaggio ha un suo modo di programmazione che a seconda del programmatore cosa vuole fare! Sicuramente mi mettere la scelta tra il java e il .net! Vi ringrazio di nuovo!

precisando che .net non è un linguaggio ma un'architettura di programmazione.
Nel .net si può progammare in tre diversi linguaggi VB (che è l'erede del visual basic), C#(che è un linguaggio c con sintassi specifica di Microsoft), C++ e J# (java specifico microsoft).
Quindi non hai che l'imbarazzo della scelta per lavorare in .net, addirittura ti puoi divertire a fare pezzi di programma usando linguaggi diversi.

Visto che sei principiante ti consiglio il VB, perchè molto semplice ed intuitivo, anche per capire "come funziona" la programmazione.
Dopo, se lo desideri, potrai passare al c++ o a qualunque altro linguaggio più complesso nelle logiche di programmazione.

P.S. ciò non significa che con il VB.net tu non possa possa fare le stesse cose degli altri linguaggi.

[71104]

Originariamente inviato da giannola

Visto che sei principiante ti consiglio il VB, perchè molto semplice ed intuitivo, anche per capire "come funziona" la programmazione.

qui però è meglio specificare che stai consigliando la versione 2005 di Visual Basic, non la 6!

[giannola]

Originariamente inviato da 71104

qui però è meglio specificare che stai consigliando la versione 2005 di Visual Basic, non la 6!

ovvio.
esistono le versioni express che sono gratuite oppure al limite chi vuole una edizione completa si può comprare a pochi euro quella education.