Newsgroup: it.comp.programmare
Titolo: Ignorante chiede...

Salve a tutti, 
è la prima volta che posto qui e lo faccio per chiedervi: 
vorrei imparare a programmare iniziando con qualcosa di davvero
elementare, non ho un' idea precisa e a tal proposito spero che mi
darete voi delle dritte. 
Grazie per i consigli.

 Grazie per i consigli.
Se hai bisogno chiedi ancora...Ciao 
-- 
Abruzzo Silvio
studente, 16 anni
goku_...@libero.it
silvi...@aruba.it
^____^

darete voi delle dritte. 
credo che pascal vada bene.
ci sarebbe anche il basic, prorpio ieri ho rispolverato un computer
vecchio (tipo commodore 64) e mi sono divertito un po' con il basic
che ci ho trovato sopra ma ti consiglio cmq il pascal (anche se
ammetto di non poterne piů)

On Sat, 01 Sep 2001 12:05:18 GMT, 
pasqual...@hotmail.com
(3210man) wrote:

Il linguaggio forse + semplice è Python ma non è sicuramente un
linguaggio "giocattolo" in quando permette anche di realizzare
programmi molto complessi (viene ad esempio usato da Google)
Se vuoi più info puoi provare 
www.python.it
 o 
www.python.org
, un
documento che parte da zero nella programmazione lo trovi a
www.crosswinds.net/~agauld
. Se il linguaggio ti interessa ti consiglio
di iscriverti alla ml italiana, maggiori info sulla ml la trovi sul
sito che ti ho detto prima (
www.python.it
)
--
Marco Barisione (ICQ 84277092)

 
E, invece, indipendentemente dalla facilità con cui può essere
imparato, qual è il linguaggio che permette di creare più programmi? 
Su che cosa ci si basa per valutare la facilità di un linguaggio?

Su che cosa ci si basa per valutare la facilità di un linguaggio?
sulle capacità del programmatore :-P
--
Rhymes
--------------------------
rhy...@myself.com
http://www.foxhound-games.it
http://embyte.mascanc.net
--------------------------
Linux User #219707

Su che cosa ci si basa per valutare la facilità di un linguaggio?
Deve essere un linguaggio coerente, i cui sorgenti siano facili da
leggere e capire anche se critti da altri o scritti anni prima, in cui
non ci siano comportamenti imprevisti e che non ti obblighi a pensare
a cose troppo difficili e non indispensabili.
Per tutti questi motivi ti consiglio Python.


 Su che cosa ci si basa per valutare la facilità di un linguaggio?
Piu` spesso che no, si valuta "a braccio", ovvero "a naso",
basandosi sull'intuizione e sul ragionamento e non sui soliti
metodo scientifici.  Ci sono un piccolo numero di eccezioni:
lo Stichting Mathematisch Centrum di Amsterdam, ad esempio,
condusse a suo tempo studi rigorosi sul linguaggio di
programmazione ABC, che era stato sviluppato da ricercatori
olandesi con lo specifico obiettivo di essere un linguaggio
adatto ai principianti, esaminando vari aspetti del linguaggio
stesso con metodi analoghi (ma non altrettanto rigorosi) a
quelli usati in farmacologia nello studio degli effetti sulla
salute di un certo complesso di medicine e cure.  Ad esempio,
due versioni del linguaggio, differenti soltanto relativamente
al particolare X, venivano insegnate a due diversi gruppi di
studenti (demograficamente bilanciati, campioni statisticamente
significativi, ecc), verificando poi se vi erano differenze
statisticamente significative, quali, e quante, sull'efficacia
degli studenti nei due gruppi nella scrittura di programmi per
vari specifici problemi.
Come puoi bene immaginare, questi studi sono costosissimi.
Solo trovare e motivare molte centinaia di principianti a
partecipare allo studio, senza dire degli anni-uomo degli
istruttori necessari a condurlo, per CIASCUN dettaglio di
un linguaggio: valutandone i costi a livello commerciale,
si parlerebbe di molte decine di milioni di dollari per una
analisi anche modesta e ben delimitata.  Poco da stupirsi,
dunque, che pochissime analisi del genere siano reperibili
in letteratura, e la progettazione di linguaggi (come per
molti aspetti quella di altri sistemi software) resti piu`
un'arte che non una scienza.
Che io sappia, l'unico linguaggio esistente ad avere tratto
un (sia pur parziale) beneficio da questo tipo di studi
rigorosi e` Python.  Molti aspetti in cui differisce da
altri linguaggi seguono esattamente le risultanze degli
studi olandesi (cio` non stupisce, visto che l'architetto
di Python e` di origine olandese e lavorava appunto allo
SMC allo sviluppo del linguaggio ABC).  Alcuni degli attuali
sviluppi del linguaggio sono motivati dal desiderio di
tenere conto di altre ricerche piu` recenti, che (pur
non essendo altrettanto complete e rigorose) sembrano
convalidare (dal punto di vista della facilita` per i
principianti) due scelte progettuali che hanno in comune
Pascal e Basic, ma non altri linguaggi diffusissimi:
    -- considerare minuscole e maiuscole come separate
        aumenta la difficolta` di apprendimento del
        linguaggio
    -- la divisione fra numeri interi con il segno di /
        NON dovrebbe effettuare troncamento (se tronca,
        aumenta la difficolta` di apprendimento)
In C, Java, Perl, e cosi` via, le variabili Peep e peep
sono distinte e separate, e 1/2 vale 0.  Python a suo
tempo adotto` le stesse convenzioni.  Non e` certo facile
cambiarle oggi, su un linguaggio in uso da dieci anni e
con molti milioni di righe di codice in produzione (su
Python si basano ad esempio gli strumenti usati dal
motore di ricerca Google!), ma sembra che Guido van
Rossum sia deciso, almeno relativamente al problema della
divisione fra interi: a un certo punto nel futuro 1/2
varra` "un mezzo" (numero razionale), NON 0 (intero con
troncamento).  Pare invece che sulla questione della
distinzione fra minuscole e maiuscole Guido dovra`
accettare la quasi unanimita` dei pareri degli utenti,
praticamente tutti opposti alla rimozione di questa
distinzione (io sono fra le poche eccezioni:-).
Fra gli aspetti piu` fondamentali della progettazione
di Python che discendono da studi rigorosi di usabilita`:
-- moderazione nell'uso peculiare di segni di punteggiatura
    e altri glifi strani: linguaggi come APL e Perl ne
    usano a bizzeffe, mentre il Lisp e derivati sono
    rigorosamente minimalisti (solo le parentesi, e in
    certi casi il segno di . [punto], hanno valore
    speciale); secondo gli studi, la massima facilita`
    di apprendimento si ha ad un livello intermedio.
-- uso dello spazio bianco ("indenting") come indicazione
    di raggruppamento: pochi linguaggi ne hanno fatto uso
    (OCCAM, linguaggio di Tony Hoare per la programmazione
    concorrente, e Haskell, linguaggio funzionale puro,
    sono le due principali eccezioni), ma gli studi mostrano
    la validita` di questo concetto, e Python lo adotta.
-- *regolarita`*, ovvero, mancanza di eccezioni, casi
    particolari, "comode" scorciatoie, interpretazioni
    dipendenti dal contesto, e cosi` via: per Python e`
    praticamente una bandiera.
Alex

 wrote in message
news:3b90ceb...@news.inwind.it...

Pascal e i linguaggi da esso derivati si basano sull'idea
chiave di vincolare al massimo le tue scelte, cercando di
obbligarti a "fare le cose giuste".  Se ti piace l'idea di
essere cosi` vincolato, Pascal e` una buona scelta.
L'alternativa "filosofica" e` un linguaggio che (in tutta
semplicita`, anche maggiore del Pascal) ti da` tutti gli
strumenti utili, ma lascia il concetto di "fare le cose
giuste" alla tua (crescente, si spera:-) competenza
professionale (o, si spera, ad un buon libro e/o docente
che provveda a guidarti).  In questa famiglia, Python e`
quasi senza rivali, unendo l'assoluta semplicita` ad una
potenza incredibile.  Ma di vincoli ne pone assai pochi.
Alex

        linguaggio
non ho mai capito questa affermazione, io non ho mai trovato nessuna
difficoltà nella differenza maiuscole/minuscole, al massimo può essere
più difficile ricordare i nomi ma secondo ma dà ordine al codice
sorgente, soprattutto in un linguaggio come python dove sarebbe molto
difficile la correzione automatica del "case" del testo inserito
dall'utente a causa della sua alta dinamicità.
Forse l'unico punto in cui penso tu abbia ragione è in ciò che dicevi
un po' di tempo fa su comp.lang.python, cioè che è difficile scrivere
codice ad esempio in caso di dettatura


 codice ad esempio in caso di dettatura
Considera che le persone a elevatissima orientazione verbale
in un certo senso RICORDANO, PENSANO "verbalmente", quindi
piu` "come una dettatura" (piu` in generale "un discorso")
che non in termini grafici, visuali, di ASPETTO del codice.
Alex

[...]


 più difficile ricordare i nomi ma secondo ma dà ordine al codice
pero' devi anche considerare che un linguaggio case-insensitive aiuta il 
programmatore ad adottare uno stile di programmazione migliore, 
impedendogli di scrivere orrendita'; qualche tempo fa avevo fra le mani un 
sorgente in C che utilizzava una costante di nome FiLE, per differenziarla 
dal FILE della lib std del C...
Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 esempi di Guido van Rossum.
Fortunatamente no, perche` le parentesi vuote sulla prima
delle due righe costituiscono un errore di sintassi:-),
comunque, tolte le parentesi, e` in effetti un idioma di
uso sfortunatamente comune.  Parte del "passo iniziale"
suddetto sarebbe naturalmente quello di ripulire tutti i
documenti esistenti (compresi quelli scritti da Guido) da
quest'uso deprecato e deprecabile.  Non sarebbe la prima
volta: ancora di recente la guida di stile, scritta da
Guido, *raccomandava* di mischiare tab e spazi a scopo di
indentazione (con un tab=8 spazi, e 4 spazi per livello),
oggi e` stata editata e raccomanda caldamente di NON
usare mai i tab nei propri sorgenti, solo spazi.  Vedi,
il progresso non e` impossibile, solo difficile:-).
Alex

il progresso non e` impossibile, solo difficile:-).
Ok inizierò a non fare più queste cose brutte :-)


    di apprendimento si ha ad un livello intermedio.
Ma allora anche il ":" del python non dovrebbe essere eliminato?
dopotutto all'interprete non serve. Es:
def pippo():
    print "ciao"
potrebbe essere:
def pippo()
    print "ciao"
Anche i troppi "_" non creano confusione? Mon sarebbe più semplice
avere (come mi pare faccia Ruby):
class Pippo:
    def +(self, other):
        ...
invece di:
class Pippo:
    def __add__(self, other):
        ...
