λ’Coding in draft
λ’Coding in draft - premessa.
Alla data 06/02/2023.
Il repository https://gitlab.com/minimalprocedure/lambda_coding è stato reso pubblico.
Esempi: https://gitlab.com/minimalprocedure/lcodc
As of 06/02/2023.
The repository https://gitlab.com/minimalprocedure/lambda_coding has been made public.
Examples: https://gitlab.com/minimalprocedure/lcodc
Attenzione, il testo del libro è solo in italiano.
Per poter accedere al testo occorre un account gitlab. Potete contattarmi su mastodon come @anzu@octodon.social,
@anzu@livellosegreto.it o
@minimalprocedure@octodon.social, twitter come @minimalproc, email: massimo.ghisalberti@pragmas.org. Per il momento questo è, in futuro sarò più disponibile.
Nel caso in cui vogliate proprio donare qualcosa, contattatemi.
Questo testo si potrebbe risolvere velocemente e alla domanda a chi sia rivolto non c'è nessuna risposta e se voglia essere un corso di programmazione nemmeno.
Andrebbe preso semplicemente, come una serie di spunti e informazioni più o meno frammentarie su un mondo, quello della programmazione, considerato troppo spesso oltremodo complesso o decisamente troppo semplice. Per questo motivo non è così facile identificare un vero target di potenziali lettori e provarci andrebbe oltre i miei possibili meriti. Quindi non è né per eventuali insegnanti e né per studenti, ma solo per chi possa essere almeno per un minimo curioso.
Affrontare in maniera sistematica l'argomento potrebbe essere oggetto di un'intera enciclopedia, quella che qualcuno ricorderà veniva venduta porta a porta da signori gioviali in giacca grigia e cravatta sgargiante. Come dire… Troppo tempo e troppa fatica. I programmatori sono gente pigra che parla di cose strane e quindi come mi si conviene nel ruolo, ho cercato saltellando qua e là di allestire delle piccole finestre verso questo strano mondo da tecnici (ma non chiamateci tecnici per favore, che non sappiamo riparare i videoregistratori). Starà ad altri aprirle.
Dimenticavo… Meno che mai vorrei fare del coding.
Il testo è diviso in alcune parti ma raggruppabili in due principali. Nella prima si presenteranno alcuni degli strumenti con cui solitamente chi programma ha a che fare. È una scelta puramente arbitraria e dettata da preferenze strettamente personali nonché infarcita di nomi, che almeno nelle scuole si tenderà a non incontrare. Lo scopo sarebbe quello di instillare nel potenziale lettore una sana curiosità dell'altro da sé e spingerlo ad almeno provare l'alternativa.
Molti di questi strumenti inoltre, potrebbero essere utilizzati anche nella vita digitale di tutti i giorni: per scrivere, mantenere uno storico di ciò che si è prodotto e così via. Il testo qui presente, è stato scritto con l'editor Emacs e con una sua estensione chiamata Org mode, che permette da un unico sorgente di generare altri formati di documento come, per esempio, il pdf.
Nella seconda invece si affronterà un vero e proprio linguaggio di programmazione. Uno di quelli veri e di quelli che nessuno si sognerebbe, forse mai, di insegnare in una scuola superiore: niente blocchetti colorati ma anche niente Python (niente di personale contro il Python) e né Java o C++. Volendo, avrei potuto affrontate l'impresa con Kojo, avendo partecipato anche se in una minima (minima!) parte al suo sviluppo o con il mio piccolo ambiente per sperimentare in Ruby: DuckQuack.
Non sarà così.
Che posso dire a mia discolpa? Per Kojo c'è un altro libro interessante dell'amico Stefano Penge e quindi sarei arrivato comunque tardi e per DuckQuack invece, non ho una vera risposta. DuckQuack è nato quasi per sfida e per dimostrare che se gli ambienti per insegnare la programmazione non ci sono o sono abbandonati, con un pizzico di buona volontà si potrebbero sempre fare o adattare. Lo consideriamo pensiero computazionale? Se non altro è problem solving.
Gli esempi proposti, i progetti, avranno un taglio definibile come educativo ma non nel senso del codice perfetto o performante e bello. A sguardo esperto saranno sicuramente poco o molto artigianali, ma cercheranno di trasmettere al lettore i principi di base della programmazione funzionale senza troppo attingere a librerie interne o esterne e talvolta reinventando la ruota. Sicuramente molti altri avrebbero potuto scrivere di meglio e se qualche lettore arriverà al punto di criticare questi codici, avranno comunque e forse anche di più, raggiunto il loro scopo. Il programmare deve, non dovrebbe, essere un mettersi in discussione continuamente accettando umilmente gli eventuali propri errori. Ci sarà sempre qualcuno che ne saprà più di noi o avrà trovato strade più interessanti. È un imparare continuo e questo è forse ciò che lo rende affascinante.
Per chiudere senza farla troppo lunga, non sarà certamente un percorso lineare da libro che insegna un linguaggio di programmazione, quanto piuttosto una sorta di confusionario progetto perennemente in beta: come direbbe un programmatore di computer.
Prendetelo per quello che è e senza pretese.
λ’Coding in draft (english, maybe…)
Warning, textbook is in italian! (and sorry for my poor english)
A gitlab account is required to access the text. You can contact me on mastodon as @anzu@octodon.social, @anzu@livellosegreto.it or @minimalprocedure@octodon.social, twitter as @minimalproc, email as massimo.ghisalberti@pragmas.org This is it today, in the future it will be more available.
In the case you really want to donate something, please contact me.
This textbook could be resolved quickly and to the question to whom it's addressed there is no a real answer and neither if it wants to be a programming course.
It should be taken simply, as a series of spots, more or less a fragmentary information, on the world, of programming, too often considered very complex or too simple. For this reason it's not so easy to identify a true potential readers target, and trying would be beyond my possible merits. So it's neither for teachers nor for students, only for those who may be, at least for a minimum, nosey.
A systematic way to address this argument could be the subject of an full encyclopedia, the one that some will remember was being sold by a door-to-door jovial gentlemen in gray jackets and flamboyant ties. How say … Too much time and too much effort. Programmers are a very lazy agent who talks about strange things and therefore, as it suits me in the role, I tried to hop here and there opening some small windows towards this strange world by technicians (but don't call us technicians please, we don't know how to fix VCRs ). It will be up to others to open them.
I forgot… Least of all I would like to do some coding.
Text is divided into some parts, but this can be grouped into two main ones. In the first, will be presented some of the tools that the programmer usually deals with. It's a purely arbitrary choice and dictated by strictly personal preferences as well as filled with names, which at least in schools you'll tend not to meet. The aim would be to instill in the potential reader a healthy curiosity about the other than himself and push him to try the alternative.
Furthermore, many of these tools could also be used in everyday digital life: to write, keep a history of what has been produced and so on. The text herein was written with the Emacs editor and with an extension called Org mode, which allows you to generate other document formats from a single source, such as, for example, a pdf.
In the second, on the other hand, a real programming language will be dealt with. One of the real ones and the ones that no one would dream, perhaps ever, of teaching in a high school: no colored blocks but also nothing Python (nothing personal against Python) and neither Java or C++. If I wanted, I could have tackled the feat with Kojo, having participated even if in a minimal (minimal!) part in its development or with my own little environment to experiment in Ruby: DuckQuack.
It will not be so.
What can I say in my defense? For Kojo there is another interesting book in italian by my friend Stefano Penge and therefore too late I arrived anyway, for DuckQuack instead, I don't have a real answer. DuckQuack was born almost as a challenge and to demonstrate that if the environments for teaching programming dont exist or are abandoned, with a pinch of good will they could always be done or adapted. Do we consider it computational thinking? If nothing else, it's almost a problem solving.
The proposed examples, the projects, have a slant that can be defined as educational but not in the sense of the perfect or performing and beautiful code. At an expert look, they will certainly be little or very naive, but try to convey the reader to the basic principles of functional programming without drawing too much on internal or external libraries and sometimes reinventing the wheel. Surely many others could have written better and if any reader gets to the point of critifying these codes, they will have achieved the purpose anyway and perhaps even more. The act of programming must be a continually questioning oneself and humbly accepting one's own mistakes. There will always be someone who will know more of ourself or will have found ways more interesting. It is a continuous learning and this is perhaps what makes it so fascinating.
To close without making too long, it will certainly not be a linear path by a book that teaches a programming language, but rather a sort of confusing project perpetually in beta as a computer programmer would say.
Take it for what it is.
m.