quale ?

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

A questo punto perchè non iniziare con l'assembly?
tanto usare i registri e capire quanto siano importanti nellla cpu è essenziale.
senza questo concetto non puoi nemmeno scrivere una riga di codice
Anzi, a questo punto meglio iniziare col codice macchina...
no, ma che dico!
perchè non gli facciamo anche studiare lo schema elettrico del full-adder, la disposizione dei transistor della cache di primo livello, e magari l'implementazione hardware dello scheduler e dell'unita FP o SSE?
tanto se proprio li devi usare non fa male e almeno impari per bene a cosa servono.

Io sono per iniziare con la programmazione in linguaggio macchina, per la famiglia Intel Itanium: non c'è nulla di meglio per farsi del mal, ehm, per partire col piede giusto dalle "basi".

Se sopravvivono a questo saranno sicuramente dei Veri Programmatori.

Originariamente inviato da Albi89

Il punto però rimane quello: un principiante difficilmente riuscirà ad organizzare il proprio codice "ad oggetti", quindi per quanto si sforzerà, per le prime settimane/mesi della sua formazione applicherà una forma di programmazione più vicina a quella procedurale (ossia studiando le azioni conseguenti che il mio programma esegue, e non quelle che eseguono le componenti, collaborando tra loro).

Su questo non concordo.

A parte che non credo proprio sia stato declassato: c'è tanto software C in giro, tantissimo, ed è facile che se vorrai lavorare su un progetto open source ti ritroverai a doverlo usare,

Già. Purtroppo c'è gente che non è capace di andare oltre quest'orribile e giurassico linguaggio di programmazione...

per non parlare del fatto che potresti avere la sfortuna di trovarti a svolgere compiti di manutenzione su vecchio software C scritto secondo metodologie vecchie come il cucco.

Esattamente.

In ogni caso, non la reputo una cosa bella... è un peccato perdere 3/4 di corso a parlare di puntatori e allocazione quando si potrebbero dedicare a cose davvero utili e interessanti.

Concordo.

Originariamente inviato da das

Io ti consiglio di usare un RAD, ovvero un ambiente che ti consente di disegnare le finestre e i bottoni come con il Paint. Con python ti tocca scrivere tutto a mano, io ti suggerisco Delphi della Borland o il suo clone Open Lazarus.

Consentono di fare quasi tutto quello (a meno che tu non sviluppi driver o simili) che fa il c++ ma in molto meno tempo e con un linguaggio molto molto più
intuitivo.
Tanto per darti un esempio:

&&(C++)----> AND (delphi)
i++(C++)---->inc(i)(delphi)

Inoltre puoi compilare sia per Linux che Windows e se usi Lazarus anche per MAC ma per quello ti conviene aspettare la prox versione.

Tutto a mano no, ma sicuramente con un RAD come Delphi si va più spediti per lo sviluppo di applicazioni dotate di GUI.

In questo caso, quando mi capita, uso Delphi per lo scheletro dell'applicazione / interfaccia grafica, e cerco di spostare su Python quanta più logica possibile.

Insomma, cerco di sfruttare il meglio dei due mondi (grazie anche a ottimi strumenti, come Python4Delphi, che permettono ai due mondi di comunicare agevolmente).

Lazarus purtroppo è ancora molto immaturo, e ha una frazione (incompleta) delle classi che la VCL di Delphi mette a disposizione.

Originariamente inviato da ^TiGeRShArK^

appunto in C il problema è gestire correttamente i puntatori..
non risolvere il VERO problema che devi affrontare.
E' proprio questo il motivo per cui NON è assolutamente adatto ad un principiante.
Anzichè preoccuparti di risolvere il problema ti devi preoccupare di MILLE altre cose che non c'entrano assolutamente nulla col tuo problema e quindi sprechi del tempo che avresti potuto impiegare per apprendere meglio la programmazione.

Concordo con tutto quello che hai scritto, ma quoto soltanto questo perché IMHO il nocciolo della discussione sta tutto qui, riassunto benissimo in poche righe.

Originariamente inviato da Strat

Io comunque, se dovessi partire da zero, userei c++ come linguaggio, ma soprattutto mi farei il c**lo sui concetti di base, sull'architettura, sui pattern, sull'uso della memoria, ecc...
Il linguaggio è l'ultimo dei problemi ....

I concetti che hai esposto sono l'ultimo dei problemi per chi deve imparare a programmare (e anche, tante volte, per chi programma professionalmente).

Originariamente inviato da k0nt3

dai che è la volta buona che python sparisce dalla faccia della terra
eh si anche lui supporta la programmazione procedurale (oltre che quella a oggetti e quella funzionale )

Purtroppo vedo che ritorni sempre sullo stesso tasto, nonostanto sia stato battuto una quantità smodata di volte e in un'occasione ti ho dimostrato che Python è un linguaggio orientato agli oggetti.

[^TiGeRShArK^]

Originariamente inviato da k0nt3

dai che è la volta buona che python sparisce dalla faccia della terra
eh si anche lui supporta la programmazione procedurale (oltre che quella a oggetti e quella funzionale )
comunque non si può nascondere che i primi programmi che si scrivono tipicamente sono tentativi di codice procedurale.
e non è un caso, perchè prima bisogna perlomeno conoscere le strutture di controllo, le variabili e un paio di altri concetti basilari. la programmazione procedurale ha il pregio di contenere il minimo essenziale per imparare questi concetti. senza dubbio avrà anche dei difetti, ma sta di fatto che non ho mai visto qualcuno che al primo tentativo tira fuori una gerarchia di classi magari usando il polimorfismo
probabilmente si potrebbe fare un discorso diverso per certi linguaggi esotici (come prolog ad esempio), ma nel caso generico no

Beh, anch'io scrivo codice procedurale se devo fare uno spike oppure se devo fare un programmino da 30 righe di codice....
Ma quella non è assolutamente programmazione.
Per me programmare vuol dire risolvere problemi complessi utilizzando gli strumenti migliori che si hanno a disposizione e focalizzandosi sul problema da risolvere.
Ovviamente un problema complesso può solitamente essere scomposto in n problemi semplici, ma iniziando a programmare col paradigma procedurale, non si acquisiscono le nozioni necessarie a fare da "collante" per il nostro codice.
In quel modo si rischia di scrivere semplicemente codice procedurale con qualche chiamata a funzione utilizzata tipo macro.
Mi rendo conto che è difficile all'inizio apprendere questi concetti, ma è proprio per questo motivo che imho è assolutamente necessario concentrarsi su questo.

[cdimauro]

Originariamente inviato da k0nt3

aggiungo che di solito nei corsi base di programmazione si usa C e non un altro linguaggio procedurale (come pascal) proprio perchè espone dei problemi legati alla memoria. potrebbe sembrare un controsenso, ma allo stesso tempo potrebbe avere senso perchè solitamente si affianca lo studio del linguaggio allo studio della macchina di von neumann.

Non vedo cos'abbia il Pascal meno del C per queste cose.

Originariamente inviato da marco.r

Proprio per questa difficolta' non sarebbe male imparare non solo questi due paradigmi, ma avere un panorama generale di quelli presenti in letteratura. Aiuta a capire quali sono gli aspetti generali e quali no, e a non restare intrappolati nelle idiosincrasie dell'uno o dell'altro. Ovviamente e' un obiettivo a lungo termine, e resta il problema del linugaggio con cui iniziare . Proprio per andare al sodo il prima possibile, consiglio anch'io di partire direttamente da un linguaggio OO di alto livello (non necessariamente moderno, Smalltalk ha vent'anni piu' di Java ma secondo me e' ancora una spanna sopra ). E' vero che alcune cose che si imparano in C si possono riciclare, ma quelle che poi non servono piu' sono tante e tali che il gioco non vale la candela. Tanto vale partire con qualcos'altro ed essere pienamente produttivi in meno tempo.
Dal punto di vista prettamente tecnico sarebbe un'ottima idea anche partire direttamente con la programmazione funzionale, ma ci sono anche altri aspetti che la rendono meno consigliabile (diffusione, tools disponibili ... )

Concordo, a parte che con Python si potrebbe agevolmente passare in rassegna ogni paradigma di programmazione grazie alle capacità degli oggetti che espone.

[k0nt3]

Originariamente inviato da cdimauro

Purtroppo vedo che ritorni sempre sullo stesso tasto, nonostanto sia stato battuto una quantità smodata di volte e in un'occasione ti ho dimostrato che Python è un linguaggio orientato agli oggetti.

questa è programmazione a oggetti?

a, b = 0, 1
while b < 10:
      print b
      a, b = b, a+b

non vedo nulla di particolare.. a parte l'uso di istruzioni inutilmente contorte come: a, b = b, a+b
python che piaccia o no è multiparadigma

[k0nt3]

Originariamente inviato da ^TiGeRShArK^

Per me programmare vuol dire risolvere problemi complessi utilizzando gli strumenti migliori che si hanno a disposizione e focalizzandosi sul problema da risolvere.

esattamente.. questo è programmare.
imparare a programmare invece significa risolvere problemi semplici utilizzando strumenti semplici (quindi non necessariamente migliori) e focalizzarsi nel tradurre le soluzioni ai problemi in algoritmi.
se non si sa fare questo difficilmente si impara a programmare

[Albi89]

Originariamente inviato da k0nt3

questa è programmazione a oggetti?

a, b = 0, 1
while b < 10:
      print b
      a, b = b, a+b

non vedo nulla di particolare.. a parte l'uso di istruzioni inutilmente contorte come: a, b = b, a+b
python che piaccia o no è multiparadigma

Beh sul fatto che Python sia multiparadigma non c'è dubbio, d'altra parte non ti costringe ad avere almeno una classe, così come il C++.
Allora il C++ non è un linguaggio a oggetti?
Che l'uso della , possa essere un po' disorientante per chi non lo conosce, è ok, ma non vedo in che modo renda un linguaggio "meno a oggetti".
Peraltro, sarei curioso di sapere se la soluzione che adotteresti in Java per questo frammento è molto più OO

[marco.r]

Originariamente inviato da k0nt3

questa è programmazione a oggetti?

a, b = 0, 1
while b < 10:
      print b
      a, b = b, a+b

non vedo nulla di particolare.. a parte l'uso di istruzioni inutilmente contorte come: a, b = b, a+b
python che piaccia o no è multiparadigma

non definirei contorto l'assegnamento parallelo. Soprattutto non lo reputo inutile in quanto permette di evitare l'uso di variabili temporanee e di rendere un po' piu' chiaro il codice.
In un mondo perfetto programmeremo (perlopiu') con variabili immutabili e senza side effects, rendendolo inutile, nell'attesa dell'avvento ci si accontententa
Per inciso l'esempio sopra e' poco indicativo... le strutture di controllo per il loop ci sono praticamente in tutti i linguaggi, compresi quelli OO.

[k0nt3]

Originariamente inviato da Albi89

Beh sul fatto che Python sia multiparadigma non c'è dubbio, d'altra parte non ti costringe ad avere almeno una classe, così come il C++.
Allora il C++ non è un linguaggio a oggetti?
Che l'uso della , possa essere un po' disorientante per chi non lo conosce, è ok, ma non vedo in che modo renda un linguaggio "meno a oggetti".
Peraltro, sarei curioso di sapere se la soluzione che adotteresti in Java per questo frammento è molto più OO

C++ supporta sia la programmazione a oggetti che quella procedurale, questo è poco ma è sicuro perchè include totalmente il C (trascuriamo le poche eccezioni).
l'uso della , è solo un particolare che ho notato al momento, ma non rende meno a oggetti il linguaggio, solo più contorto
il creatore di python non ha capito che scrivere due istruzioni sulla stessa riga non migliora la leggibilità.
in java si potrebbe (idea scema) creare una classe Fibonacci con un metodo next() che calcola il prossimo numero della serie.
più probabilmente però uno che inizia a programmare cercherà di creare codice procedurale mettendo tutto nel main, ma a me ste cose fanno rabbrividire a sto punto userei un linguaggio procedurale (EDIT:almeno non mi costringe a creare un oggetto di cui non ne comprendo il significato)

[k0nt3]

Originariamente inviato da marco.r

non definirei contorto l'assegnamento parallelo. Soprattutto non lo reputo inutile in quanto permette di evitare l'uso di variabili temporanee e di rendere un po' piu' chiaro il codice.
In un mondo perfetto programmeremo (perlopiu') con variabili immutabili e senza side effects, rendendolo inutile, nell'attesa dell'avvento ci si accontententa
Per inciso l'esempio sopra e' poco indicativo... le strutture di controllo per il loop ci sono praticamente in tutti i linguaggi, compresi quelli OO.

quindi non è perfettamente equivalente a:

a = 0
b = 1
while b < 10:
      print b
      a = b
      b = a+b

[shinya]

Originariamente inviato da marco.r

In un mondo perfetto programmeremo (perlopiu') con variabili immutabili e senza side effects

Smettila di usare haskell. :P

Per curiosità, hai dato un'occhiata a Factor? http://factorcode.org/

[Albi89]

Originariamente inviato da k0nt3

C++ supporta sia la programmazione a oggetti che quella procedurale, questo è poco ma è sicuro perchè include totalmente il C (trascuriamo le poche eccezioni).

Certo, è lo stesso fa Python.
(No, non include il C, ma permette un approccio sia procedurale che a oggetti, oltre che funzionale)

l'uso della , è solo un particolare che ho notato al momento, ma non rende meno a oggetti il linguaggio, solo più contorto
il creatore di python non ha capito che scrivere due istruzioni sulla stessa riga non migliora la leggibilità.

Dipende, in casi dove è palese il collegamento tra le variabili può risparmiare spazio: mentre segui i nuovi valori, separati da virgole, devi poter tracciare in mente lo schema delle assegnazioni. Se non puoi farlo, è un caso in cui conviene fare assegnazioni su righe separate.
Comunque è un piccolo problema, male che vada puoi non usarlo
E poi direi che in generale Python non pecca certo di leggibilità, già solo la possibilità di scrivere:

a = 0 if a < 0 else 1

invece di

a = (a < 0) ? 0 : 1;

è impagabile

in java si potrebbe (idea scema) creare una classe Fibonacci con un metodo next() che calcola il prossimo numero della serie.
più probabilmente però uno che inizia a programmare cercherà di creare codice procedurale mettendo tutto nel main, ma a me ste cose fanno rabbrividire a sto punto userei un linguaggio procedurale (EDIT:almeno non mi costringe a creare un oggetto di cui non ne comprendo il significato)

Ok, venendo al succo del messaggio.
Potrebbe farlo non vuol dire molto, potrebbe farlo anche in Python.
Se non ha le conoscenze per farlo in Python, non lo farà neanche in Java.
La risposta, in sostanza, te la sei data tu, dicendo che probabilmente scriverà tutto nel main
Quì comunque Python fa questo: ti permette di non creare un oggetto se non ti serve. Per piccoli script è accettabile, e aggiunge solo alla sua versatilità.

Che poi puoi creare codice COMPLETAMENTE procedurale è vero, ma senza dubbio il concetto di oggetto è fortemente radicato in Python.

Un po' però mi dispiace che alcune cose, come le funzioni di conversione o la funzione che restituisce la lunghezza di una stringa, non siano implementate come metodi. Confido in cdimauro che mi illustri il perchè

[cdimauro]

Originariamente inviato da k0nt3

questa è programmazione a oggetti?

a, b = 0, 1
while b < 10:
      print b
      a, b = b, a+b

non vedo nulla di particolare.. a parte l'uso di istruzioni inutilmente contorte come: a, b = b, a+b
python che piaccia o no è multiparadigma

Ti ha già risposto Marco: l'assegnazione multipla è molto comoda e, al contrario di ciò che affermi, rende il codice più leggibile, se usata con raziocinio:

Info = DB.Gets('SELECT Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza FROM Utenti WHERE ID = %s', (12345, ))

Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza = Info

Casualmente, guarda cosa succede con la (prima, per comodità) assegnazione multipla che hai scritto:

>>> a, b = 0, 1
>>> a, b
(0, 1)
>>> 0, 1
(0, 1)
>>> type((0, 1))
<type 'tuple'>
>>> isinstance((0, 1), object)
True
>>>

Ma guarda un po': Python crea degli OGGETTI di tipo tupla che contengono i valori 0 e 1.

Chi l'avrebbe mai detto: oggetti.

Originariamente inviato da k0nt3

l'uso della , è solo un particolare che ho notato al momento,

E' questo il punto: tu sconosci perfino dei concetti BASILARI di Python, quali le tuple, e ti permetti di pontificare.

ma non rende meno a oggetti il linguaggio, solo più contorto
il creatore di python non ha capito che scrivere due istruzioni sulla stessa riga non migliora la leggibilità.

No, è diverso: è che tu non hai capito niente del linguaggio, e continui a tirare in ballo cose prese a casaccio perché ti sembrano "strane" pur di spalare letame su Python.

Peccato che, proprio perché ti mancano le basi, è facile dimostrare dove vuoi andare a parare...

in java si potrebbe (idea scema) creare una classe Fibonacci con un metodo next() che calcola il prossimo numero della serie.

def fib():
  a, b = 0, 1
  while True:
    yield b
    a, b = b, a + b

for n in fib():
  print n

Fallo in Java adesso, e fammi vedere come verrebbe fuori.

[cdimauro]

Originariamente inviato da Albi89

Che poi puoi creare codice COMPLETAMENTE procedurale è vero, ma senza dubbio il concetto di oggetto è fortemente radicato in Python.

Esattamente. Anche perché... qualsiasi cosa è un oggetto in Python.

Un po' però mi dispiace che alcune cose, come le funzioni di conversione o la funzione che restituisce la lunghezza di una stringa, non siano implementate come metodi. Confido in cdimauro che mi illustri il perchè

Scelte di Guido. Personalmente li avrei implementati come metodi d'istanza.

Per quanto riguarda le funzioni di conversione, suppongo che ti riferisca a str e repr. Perché int(), float(), bool(), ecc. non sono funzioni, ma costruttori.

[k0nt3]

Originariamente inviato da Albi89

Certo, è lo stesso fa Python.
(No, non include il C, ma permette un approccio sia procedurale che a oggetti, oltre che funzionale)

certo che lo include, la quasi totalità dei sorgenti validi in C sono validi anche in C++

Originariamente inviato da Albi89

Dipende, in casi dove è palese il collegamento tra le variabili può risparmiare spazio: mentre segui i nuovi valori, separati da virgole, devi poter tracciare in mente lo schema delle assegnazioni. Se non puoi farlo, è un caso in cui conviene fare assegnazioni su righe separate.
Comunque è un piccolo problema, male che vada puoi non usarlo
E poi direi che in generale Python non pecca certo di leggibilità, già solo la possibilità di scrivere:

a = 0 if a < 0 else 1

invece di

a = (a < 0) ? 0 : 1;

è impagabile

a = (a < 0) ? 0 : 1;
è una di quelle cose che non sopporto di solito infatti non viene insegnata questa sintassi.
per quanto riguarda python.. dopo che ho scoperto che:

b == ('a' and 'b')

restituisce TRUE non mi stupisco più di niente

Originariamente inviato da Albi89

Ok, venendo al succo del messaggio.
Potrebbe farlo non vuol dire molto, potrebbe farlo anche in Python.
Se non ha le conoscenze per farlo in Python, non lo farà neanche in Java.
La risposta, in sostanza, te la sei data tu, dicendo che probabilmente scriverà tutto nel main
Quì comunque Python fa questo: ti permette di non creare un oggetto se non ti serve. Per piccoli script è accettabile, e aggiunge solo alla sua versatilità.

Che poi puoi creare codice COMPLETAMENTE procedurale è vero, ma senza dubbio il concetto di oggetto è fortemente radicato in Python.

Un po' però mi dispiace che alcune cose, come le funzioni di conversione o la funzione che restituisce la lunghezza di una stringa, non siano implementate come metodi. Confido in cdimauro che mi illustri il perchè

certamente, ma la differenza è sottile. java non offre gli strumenti per programmare in maniera completamente procedurale e la dimostrazione è il fatto che bisogna per forza creare un oggetto.
senza dubbio uno può concludere che non cambia molto.. però è evidente che java non è stato creato per programmare in quel modo, mentre in python viene naturale quanto programmare a oggetti

[k0nt3]

Originariamente inviato da cdimauro

E' questo il punto: tu sconosci perfino dei concetti BASILARI di Python, quali le tuple, e ti permetti di pontificare.

No, è diverso: è che tu non hai capito niente del linguaggio, e continui a tirare in ballo cose prese a casaccio perché ti sembrano "strane" pur di spalare letame su Python.

Peccato che, proprio perché ti mancano le basi, è facile dimostrare dove vuoi andare a parare...

purtroppo ho dovuto imparare python, e so benissimo che qualsiasi cosa è un oggetto. ma non basta chiamare ogni cosa "oggetto" per programmare a oggetti

[Albi89]

Originariamente inviato da cdimauro

Scelte di Guido. Personalmente li avrei implementati come metodi d'istanza.

Per quanto riguarda le funzioni di conversione, suppongo che ti riferisca a str e repr. Perché int(), float(), bool(), ecc. non sono funzioni, ma costruttori.

Personalmente pensavo al perchè non ci fossero metodi come "toString" o "toInt", però non sapevo che quelli fossero i costruttori (per altro non ci voleva molto ad arrivarci )
Mia superficialità

Originariamente inviato da k0nt3

certamente, ma la differenza è sottile. java non offre gli strumenti per programmare in maniera completamente procedurale e la dimostrazione è il fatto che bisogna per forza creare un oggetto.
senza dubbio uno può concludere che non cambia molto.. però è evidente che java non è stato creato per programmare in quel modo, mentre in python viene naturale quanto programmare a oggetti

Penso che questo sia il ragionevole punto di incontro del nostro discorso, oltre il quale non ci muoveremo di un cm entrambi
Comunque ovviamente non intendevo dire che il C++ non include il C, ma che il Python non include il C (insomma, stavo solo scherzando perchè la mia frase precedente era "equivoca" )

[cdimauro]

Originariamente inviato da k0nt3

certo che lo include, la quasi totalità dei sorgenti validi in C sono validi anche in C++


a = (a < 0) ? 0 : 1;
è una di quelle cose che non sopporto di solito infatti non viene insegnata questa sintassi.

Purtroppo sì, invece.

per quanto riguarda python.. dopo che ho scoperto che:

b == ('a' and 'b')

restituisce TRUE non mi stupisco più di niente

Anche di questo ne abbiamo abbondantemente parlato, ma al solito fai orecchie da mercante e torni a ripetere la solita litania.

certamente, ma la differenza è sottile. java non offre gli strumenti per programmare in maniera completamente procedurale e la dimostrazione è il fatto che bisogna per forza creare un oggetto.
senza dubbio uno può concludere che non cambia molto.. però è evidente che java non è stato creato per programmare in quel modo, mentre in python viene naturale quanto programmare a oggetti

Originariamente inviato da k0nt3

purtroppo ho dovuto imparare python, e so benissimo che qualsiasi cosa è un oggetto. ma non basta chiamare ogni cosa "oggetto" per programmare a oggetti

Indubbiamente. Ci sarebbe da chiedersi: "se in Python qualsiasi cosa è un oggetto, perché non imparare cosa sono gli oggetti, quali proprietà hanno e in che modo si usano?"

Domanda che chi ha una mentalità da programmatore procedurale nemmeno si pone...

[rafpro]

io avevo solo chiesto da dove partire....poi magari studio il C il java ecc
per ora mi serve una cosa semplice che mi permetta di fare applicazioni semplici sotto win tutto qui

[cdimauro]

Originariamente inviato da Albi89

Personalmente pensavo al perchè non ci fossero metodi come "toString" o "toInt", però non sapevo che quelli fossero i costruttori (per altro non ci voleva molto ad arrivarci )
Mia superficialità

Piccolo lapsus: anche str(), ovviamente, invoca un costruttore, visto che str è la classe "base" delle stringhe, ma poi viene controllata la presenza del metodo __str__ all'interno dell'oggetto che è stato passato come argomento per effettuare la conversione vera e propria.

repr, però, l'avrei visto come metodo d'istanza dei vari oggetti, perché non esiste una classe repr, in quanto... non repr non è un tipo.
Idem per abs(), len(), ecc.: li avrei preferiti come metodi d'istanza.

[cdimauro]

Originariamente inviato da rafpro

io avevo solo chiesto da dove partire....poi magari studio il C il java ecc
per ora mi serve una cosa semplice che mi permetta di fare applicazioni semplici sotto win tutto qui

Se devi imparare a programmare, parti con Python.

Passare a sviluppare applicazioni dotate di interfaccia grafica adesso è pura follia: prima devi farti le ossa.