Newsgroup: it.lavoro.informatica
Titolo: Linguaggio Scala

Ciao a tutti
sono un programmatore Java che per interesse (molto interesse) si è dedicato allo studio (coursera, book odersky e smanettamenti vari) del linguaggio Scala.
Vorrei sapere se qualcuno di voi nel mondo lavorativo lo utilizza già e come si è trovato.
Chiedo perché mi piacerebbe prima o poi finire in un qualche progetto che utilizzi proprio questo linguaggio (magari una web app con playframework), ma il mercato italiano mi sembra ancora un po' acerbo in tal senso.
 
Grazie a tutti per le eventuali risposte ^^

 tal senso.
 
il mercato è destinato a ridisegnarsi, fai bene a tenerti pronto.
 

 il mercato è destinato a ridisegnarsi, fai bene a tenerti pronto.
 
speriamo!
Il linguaggio l'ho imparato non tanto come investimento per il futuro ma solo per passione. Ma se potessi unire il diletto al lavoro sarebbe meraviglioso, Java mi sta proprio stretto e non regala le stesse soddisfazioni.

 Il linguaggio l'ho imparato non tanto come investimento per il futuro ma
solo per passione. Ma se potessi unire il diletto al lavoro sarebbe
meraviglioso, Java mi sta proprio stretto e non regala le stesse soddisfazioni.
 
 
perchï¿œ dici che Java non ti "regala le stesse soddisfazioni"?
 
 

 perchï¿oe dici che Java non ti "regala le stesse soddisfazioni"?
 
Sostanzialmente perché è troppo verboso (solo l'idea di un if (variabile != null) adesso mi fa venire il latte alle ginocchia)
 
Poi beh Scala è avanti anni luce sulla programmazione concorrente e altri concetti che anche java sta rincorrendo (vedi le ultime feature della versione 8).

 perché dici che Java non ti "regala le stesse soddisfazioni"?
 
se lo chiedi è perché non puoi capire.
 

 perché dici che Java non ti "regala le stesse soddisfazioni"?
 
Immaginati un linguaggio dove:
 
- usi gli elementi funzionali invece dei vari pattern listener, observable/
observer, etc... 
 
- hai de facto l'eredità multipla (trait -> mixin)
 
- ti scordi del NullPointerException (Option)
 
- implementa direttamente nelle API della concorrenza l'actor model
 
- puoi aggiungere metodi a classi già esistenti
 
- hai ADDIRITTURA gli operatori matematici per gli oggetti Number
 
- hai il type inference
 
E mi fermo qui.
 
 


Ah, Erlang, tolto il nonsense dell'invocare elementi funzionali per parlare di classi 3 righe sotto
Con il nonsense, in effetti solo quell'obbrobrio di Scala :D
 
  ngw


gli operatori matematici per oggetti numerici li ha anche java da un bel 
po'
 
-- 
Sopranopoulos

 po'
 
	java.math.BigDecimal o1 = new java.math.BigDecimal(1);
	java.math.BigDecimal o2 = new java.math.BigDecimal(1);
	java.math.BigDecimal result = o1 + o2;
 
operator + cannot be applied to java.math.BigDecimal,java.math.BigDecimal
 
---
 
scala> val o1 = BigDecimal(1)
o1: scala.math.BigDecimal = 1
 
scala> val o2 = BigDecimal(2)
o2: scala.math.BigDecimal = 1
 
scala> val result = o1 + o2
result: scala.math.BigDecimal = 2
 


L'autoboxing funziona per tutte le classi wrapper come Integer e Double. 
Per cui puoi scrivere 
 
Integer o1 = 1;
Integer o2 = 1;
Integer result = o1 + o2;
 
BigDecimal non supporta autoboxing e ti toccherà scrivere 
 
BigDecimal result = o1.add(o2);
 
invece di 
 
BigDecimal result = o1 + o2;
 
È un gran problema ?
 
-- 
Sopranopoulos

 L'autoboxing funziona per tutte le classi wrapper come Integer e Double.
 
eh ho capito. ma anche BigDecimal è un Number e a differenza di Double è 
l'unico usabile in ambito scientifico e finanziario avendo una precisione 
finita.

 Con il nonsense, in effetti solo quell'obbrobrio di Scala :D
 
 
Un altro vantaggio di Scala è che gira sulla jvm e la compatibilità con le innumerevoli librerie Java è immediata.
 
Comunque Scala mi ha aperto al mondo funzionale quindi un giorno mi metterò sotto anche sul mito Erlang ;D
 

 Un altro vantaggio di Scala è che gira sulla jvm e la compatibilità con le innumerevoli librerie Java è immediata.
 
Questo è essenziale. Purtroppo tante implementazioni di linguaggi funzionali sono drammaticamente prive di librerie lontanamente paragonabili a quelle Java (od anche in "semplice" C), e sono pure molto complesse da interfacciare con tali librerie esterne.
 


Essanzialissimo.
Ok, dopo 15 anni tra Python, Ruby, Erlang, Elixir e Lisp e avendo tirato su qualunque cazzata ti possa venire in mente non mi sono bloccato una singola volta perchè mi mancava una libreria, ma vabbè.
In compenso il mischiotto tra OO  e funzionale per la concorrenza è notoriamente una bella idea, avere un actor model in cui puoi cambiare lo stato degli attori è assolutamente ottimale, una botte di ferro, meglio dei puntatori in C nel 2014.
 
  ngw

 assolutamente ottimale
 
Ma ne è incoraggiata la pratica? Di Akka ho solo letto un pò la
documentazione tempo fa ma mi riesce difficile credere che scambiarsi
messaggi (attori o non) mutabili sia la norma o che non ci sia sorta di
protezione per accesso in concorrenza al local state etc.
Del resto anche in Erlang puoi alterare lo stato del process dictionary
(ed infatti è sconsigliato nella docs) - che si possa non vuol dire si
debba.
 


una semplice media pesata viene
 
//score = (first * 0.23) + (second * 0.27) + (last * 0.50)
 
BigDecimal score = first.multiply(0.23)
                     .add(second.multiply(BigDecimal.valueOf(0.27)))
                     .add(last.multiply(BigDecimal.valueOf(0.50)));
 
 
un loop naive nella versione iterativa del metodo di Newton tipo
 
/*
while abs(x - xprev) > eps * abs(x)
    xprev = x
    x = 0.5 * (x + N/x)
*/
 
while( x.subtract(xprev).abs().compareTo(eps.multiply(x.abs())) == 1 )
{
    xprev = x;
    x = BigDecimal.valueOf(0.5).multiply(x.add(N.divide(x) ));
}
 
 
Calcoli più interessanti? Matrici? Un coltello da cucina in gola diventa
un miraggio. Mettici la richiesta di performance e boxing/unboxing
automatici sarebbero solo d'intralcio - l'unica resta una forma di
preprocessing/macro (ma non faccio calcoli sulla JVM da anni e non mi
ricordo più come si risolveva).

 protezione per accesso in concorrenza al local state etc.
 
le raccomandazioni sono che ovunque, in scala, si dovrebbero usare oggetti 
immutabili. poi ovviamente le 'var' esistono come esistono le zappe per 
cui se uno proprio vuole tirarsela sui piedi se la tira. 


Sfugge quindi il motivo per cui e' OOP, se non nella logica catch all ndo coio coio di Scala.
E, ehm, in Erlang se uno vuole tirarsi la zappa sui piedi non se la tira, visto che un processo bloccante sta fuori. Cosi' in Clojure, tanto per dire. 
 
  ngw


Si, per farlo devi violentare i tuoi parenti piu prossimi, col cavolo che sia cosi banale.
 
  ngw

 ndo coio coio di Scala.
 
una oop senza side effects... 


cazzo vuol dire? l'oop e' side effects

 cazzo vuol dire? l'oop e' side effects
 
Si, come no...

 cazzo vuol dire? l'oop e' side effects
 
vuol dire che non lo ritengo un limite, ma non sono un purista del 
paradigma.


Gente che usa un paradigma senza neppure conoscerlo, been there done that (and later fired)
 
  ngw


Non è questione di essere puristi, è questione di non spacciare un linguaggio come funzionale, caratteristica ormai usata come un banale sales pitch, quando in realtà è un linguaggio OOP con le closure.
 
  ngw

 ricordo più come si risolveva).
 
Problemi di prestazione (am anche di algoritmo) che si potrebbero risolvere demandando ad una libreria esterna ad alte prestazioni, risultato di anni ed anni di affinamenti, che non puoi certo riscriverti in due giorni (magari perfino scritta nel vituperato e vituperabile C, od, orrore degli orrori, in Fortran!!).
Ecco a che serve il facile accesso all'esterno. CVD :-)
 
 
 
 

 Gente che usa un paradigma senza neppure conoscerlo, been there done that (and later fired)
 
Non mi meraviglio che sei stato fired.
Basta vedere l'esempio di oggetti di tipo String in Java o delle
stringhe in Python, che sono immutabili, niente stati e niente
side-effects (le tre cose sono strettamente correlate).
E leggere il libro di Joshua Bloch "Effective Java" per vedere in
quanti casi si consiglia l'uso di oggetti _immutabili_ anche in Java
(e l'ammissione di certe "imperfezioni" di Java).
Dunque, la tua affermazione "oop e' side effects" ï¿œ palesemente
falsa. Che poi gente (ab)usa le libertï¿œ che un linguaggio gli ha dato
ï¿œ un altro discorso. Che non c'entra niente con la tua affermazione.

 closure.
 
Tu si che hai capito tutto dalla vita.

 ï¿oe un altro discorso. Che non c'entra niente con la tua affermazione.
 
Nemmeno come arrampicata sugli specchi risulta interessante, peccato.
Sorry, una volta mi sarei lanciato a pesce a spiegare come e quanto il concetto stesso di OOP sia basato sui side effects, oggi sono troppo vecchio per rimediare all'ignoranza del mondo da solo, specialmente alla tua.
Liberissimo di credere a quello che vuoi, 
 
  ngw


Un wrapper Java intorno ad una libreria numerica (ad altre prestazioni o
meno è ininfluente) cambierebbe la sintassi stessa di Java tanto da
risolvere il problema di cui stiamo discutendo?.
Ma almeno fai finta di pensarci prima di buttarle al vento così.


Dimenticavo l'altra parte.  Perché poi introdurre librerie ad altre
prestazioni nella discussione?  Non sei forse a conoscenza del fatto che
ogni giorno in Java ci sono programmatori che vogliono manipolare una
matrice di rotazione per un gioco su Android o una applicazione di
visualizzazione, che fanno calcoli dal semplice al complicato, dalla
finanza di piccolo conto al bancario al trading? Se pensi che da
price.multiply(taxes).add(shipping) si passi direttamente a
LAPACK... hai bisogno di un serio reality check.

 LAPACK... hai bisogno di un serio reality check.
 
Mah, mi era sembrato di aver letto di uno (non tu, eh) che dichiarava in estrema sintesi: "chi se ne fotte se Scala interagisce con facilità con le innumerevoli librerie Java, io mi riscrivo tutto da solo ogni volta".  
Perciò quel che dici mi pare confermi esattamente l'opposto di questa idea, ovvero molto meglio accedere facilmente a librerie *esterne al linguaggio* (non necessariamente esterne alla VM).
Oltretutto rileggi bene, non ho scritto affatto che per libreria "esterna" si intende per forza una in C, comunque alla bisogna meglio poter accedere anche quella senza diventare matti a reinventarsi ogni volta la ruota (e pure mezza quadrata :-)
 


Che brutto livello di discussione, da dimenticare.
 
Ripartendo - perché dici che non sei un "purista"? A quale definizione
di oop ti riferisci/fai capo e che ha (o meno) i side-effects tra le
caratteristiche di base dell'essere object-oriented?
 

 Che brutto livello di discussione, da dimenticare.
 
(La fretta - quanto sopra ovviamente riferito alle infelici uscite non tue...)

 caratteristiche di base dell'essere object-oriented?
 
era una risposta ironica e per tagliare corto una polemica in cui non 
volevo entrare. ovviamente sono d'accordo con te i side-effects li intendo 
come dei bug e non delle feature.


Bella forza: pensavo ti riferissi a qualche forma di object calculi di
tipo imperativo, ma non capivo la questione "purista" (visto che è più
spesso attribuita al message-passing alla Alan Kay o Hewitt che dir si
voglia). Come direbbero dove sono nato, m'aggio fatt 'nu bellu film
'ncapa :)

 tue...)
 
ah :-)
 

 volta la ruota (e pure mezza quadrata :-)
 
Guarda io sono per l'accesso a tutto quando server - usando una
terminologia strettamente tecnico-accademica, sono proprio una gran
puttana al riguardo. Tu mi dici entra diqquà, primo binding a sinistra e
poi giù dritto fino all'abi presa di faccia e io vado nessun problema.
 
Ma il punto è che qui noi discutevamo di un fattariello semplice
semplice che più non si può, e che è totalmente indipendente sia che tu
ti scriva la tua semplice class Matrix da te, che prenda una libreria
scritta in Java usabile da chiunque sulla JVM, un wrapper per LAPACK
(Fortran), un sarcazzo qualsiasi in C o quello che è. Possibile mai mi
sia capito solo io? Anque.

 Mah, mi era sembrato di aver letto di uno (non tu, eh) che dichiarava in estrema sintesi: "chi se ne fotte se Scala interagisce con facilità con le innumerevoli librerie Java, io mi riscrivo tutto da solo ogni volta".  
 
Se hai sul serio capito questo da quello che ho detto non capisci la lingua italiana, oltre ad una grossa dose di malafede.
Niente di nuovo sotto il sole insomma.
 
  ngw


Leggo: Object-oriented programming (OOP) is a programming paradigm that represents the concept of "objects" that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs.[1][2] C++, Objective-C, Smalltalk, Delphi, Java, C#, Perl, Python, Ruby and PHP are examples of object-oriented programming languages.
 
Posto che anche wikipedia non sia "infelice", mi sapete dire come si fa ad avere questo fantomatica OOP senza side effects? 
 
  ngw

 performance ce lo faremmo fritto comunque.
 
e comunque non ha alcun senso parlare di outboxing in quanto non esiste un 
tipo nativo equivalente ai BigDecimal. 

 sia capito solo io? Anque.
 
Ho risposto ad una tua frase, il resto mi è indifferente. Vediamo come va a finire la partita Scala-Resto del mondo :-) 
 

 Questo è quello che hai capito tu, io ho capito esattamente il contrario, visto il contesto del mio messaggio a cui costui rispondeva. 
 
 
Nono, proprio non ho scritto quello che mi attribuisci, ho scritto che non ho mai perso 5 minuti della mia vita a cercare una libreria che avevo a disposizione su JVM ma non sulla piattaforma su cui stavo sviluppando, la parte in cui riscrivo tutto è una tua personalissima e decisamente errata deduzione.
Ma sono sicuro che saprai produrre moltissimi esempi di librerie usate da più di 10 persone che esistono solo su JVM, sicuro sicuro.
 
  ngw

 Nono, proprio non ho scritto quello che mi attribuisci, ho scritto che non ho mai perso 5 minuti della mia vita a cercare una libreria che avevo a disposizione su JVM ma non sulla piattaforma su cui stavo sviluppando, la parte in cui riscrivo tutto è una tua personalissima e decisamente errata deduzione.
 
Perfetto, può essere benissimo. Anche se a tua volta hai dedotto, del tutto erroneamente, che mi riferissi esclusivamente all'interfacciamento a librerie  JVM, il che non è. 
Chiaramente Scala, che gira nella JVM, può avvalersi anche dei wrapper Java per librerie extra JVM. In altri linguaggi *funzionali* spesso non hai un bel ciufolo, non basta scrivere un moduletto con 4 declare extern, e ti devi riscrivere un bel wrapper con tutte le conversioni ed adattamento tipi da zero. Il tutto talvolta per librerie con centinaia di funzioni. Caso tipico: GUI e database. Non parliamo delle librerie a standard C++, queste sono inaccessibili anche a molti linguaggi procedurali/OO, tocca scrivere un wrapper C. 
Di questo non te ne fotte niente? Ti diverte un mondo? Più funzioni c'hanno, più ti stimola l'appetito? Il tuo standard è 5 minuti fissi? Magnifico, tanto di cappello! S'è capì? :-)
 

 fotto*...". Te pare? :-)
 
non capisco perché cerchi sempre di buttarla in discussioni assurde.
hai fatto una osservazione non pertinente, perché rivogersi ad una 
libreria esterna non risolve ne il problema di cui si discuteva ne quello 
delle performance. BigDecimal è già internamente ottimizzato per fare 
quello che deve fare, ciò che gli manca è una sintassi per scrivere delle 
espressioni decenti. tutto qua. 


Me ne fotte, e reiterando sul concetto "non ho mai perso 5 minuti della mia vita a cercare una libreria che avevo a disposizione su JVM ma non sulla piattaforma su cui stavo sviluppando", includendo anche i wrapper, non so bene che altro dirti.
 
  ngw

 è un altro discorso. Che non c'entra niente con la tua affermazione.
 
Non trovo ne' capo ne' coda in quanto hai scritto. Il consiglio di
favorire l'immutabilità o il fatto che certe implementazioni di certi
linguaggi abbiano le stringhe come immutabili non dimostra nulla
riguardo la sua affermazione.
 
Prendi ad esempio il linguaggio OCaml, che dalla prima versione ha
sempre avuto le stringhe mutabili. Sulla base di questo mero *dettaglio
implementativo* puoi mai dire qualcosa di utile riguardo al supporto
all'object-orientation nel linguaggio, o sugli aspetti di functional
programming o di supporto al lambda calcolo? Ovviamente no.


Beh si quando hanno scritto "BigDecimal non supporta autoboxing" andava
precisato che è il compilatore che non applica boxing in quanto
blablabla (e magari un esempio buono era il parallelo con decimal in
C#/.Net che anche non essendo primitivo/non avendo istruzioni IL proprie
comunque supporta una sintassi e ha un corrispettivo con cui fare boxing
per l'uso nelle collections etc.) ma pensando di essere tra
programmatori Java mi pareva ok lasciarlo sottointeso.

 blablabla 
 
a scanso di equivoci, la mia era una precisazione rafforzativa del tuo 
discorso... 


Il tuo problema è che (come troppi) fai confusione tra vari concetti e
termini, parli per slogan e affermazioni arbitrarie che non possono
essere argomentazioni accettabili. Ad esempio non ti sei accorto che in
poche righe hai dato due "descrizioni" di object-oriented programming
diverse tra loro - la prima più un'affermazione arbitraria che altro, la
seconda si una descrizione ma non poi così precisa.
 
 
Supponi di avere un dialetto Lisp con forms e meccanismi interni
sufficienti a supportare una forma di lambda calcolo. Come lo sai?
Prendi uno dei papers originali sul lambda calcolo o altro più moderno
che fa al caso e verifichi che quel modello sia effettivamente quello
esposto e supportato dal dialetto in questione. Supponi poi inoltre che
questio dialetto supporti un comando di assegnamento nella forma di una
form set!, con effetti mutabili sul datum presente nello storage a cui
viene applicato.  Domanda: ai fini di considerare il supporto al lambda
calcolo nel dialetto, quanto è interessante la presenza del set! di cui
sopra?  Risposta: non ci interessa. E' un dettaglio implementativo, una
feature del linguaggio, una cosa esterna al lambda calcolo di cui
conosciamo la definizione e i meccanismi costituenti. Se consideriamo un
dialetto in tutto uguale al primo sopra ma privo della form set! (o
dualmente se modifichiamo il dialetto di sopra in tal senso) e con al
suo posto una form define, priva di mutabilità, la valutazione che
faremo della bontà del supporto al lambda calcolo *non cambia*. In altre
parole, la questione set!/mutabilità non è definizionale riguardo quello
che ci interessa discutere proprio perché... non rientra minimamente
nella sua stessa definizione.
 
Esempi concreti sono i linguaggi Racket e Common Lisp, entrambi basati
sul lambda calcolo e entrambi aventi diverse forme di set!. Si programma
in stile applicativo -> alias definizione e applicazione di funzioni ->
alias lambda calculus bene con entrambi; uno da supporto più diretto e
completo, l'altro meno. E set! ? Resta fuori dalla discussione: ho
definito/chiarito cos'è il lambda calculus nel mio contesto d'interesse
e so che non ne fa parte. Perché parlarne a sproposito.
 
 
Sull'oop. Chiedi a n persone cos'è object-oriented e avrai n+m risposte,
e tu ce lo confermi. Prima dici che è side-effect, ovvero che il
side-effect è costituente essenziale. Poi citi wikipedia, dove parlano
di objects, data fields e associated procedures, instances e classes. La
cosa più importante che citano è "Objects (...) are used to interact
with one another to design applications and computer programs", che
scritto così è ancora troppo vago. Di side-effects non vi è
assolutamente traccia.
Io l'object-orientation l'ho vista la prima volta su Common Lisp con
CLOS - una roba simile 'a bicicletta del tutorial ufficiale Java puoi
anche metterla come
 
 
(defclass bicycle ()
  ((gears :accessor bicycle-gears
        :initarg :gears
        :initform 3)))
 
(defclass mountain-bike (bicycle)
  ((model :accessor mountain-bike-model
        :initarg :model)))
 
(defun make-mountain-bicycle (gears model)
  (make-instance 'mountain-bike :gears gears :model model))
 
(defun main ()
  (setq ptr (make-mountain-bicycle 21 'Model42))
  ; ...
 
e puoi così programmare in parte come fossi su Java. I side-effects sono
in setq e sull'opzione :accessor per lo slot - chiaramente setq
sull'instance non è un problema. Che succede se specifico :reader
(read-only) al posto di :accessor, eliminando di fatto il side-effect
che muta il campo mentre ne ritorna il valore? CLOS smette di essere
object-oriented? No. I metodi e le funzioni sono quello che conta, non
le classi. L'assenza di message-passing, il fatto che i metodi
non siano espressamente legati ad un'instance, i multimethods
(ridefinire metodi senza ricompilare alcunchè) e altre caratteristiche
(che ci vorrebbe troppo per elencare in dettaglio) permettono di
programmare un object-oriented che può andare in due direzioni opposte:
oggetti con accessor mutabili e strutture dati imperative, interfacce e
function di tipo first-class e generiche sfruttando la parte più
funzionale. Oppure interfacce generiche e strutture dati persistenti di
tipo funzionale, entrambe comunemente senza identità e senza stato per
una programmazione pure functional. Il senso è che gli oggetti lasciano
il posto alle interfacce, e invece di passare in giro messaggi e oggetti
si fanno viaggiare le interfacce. Se il side-effect fosse una
costituente fondamentale di questa oop, nulla di questo sarebbe
fattibile in pratica.
 
Quindi cos'è l'oop. Per CLOS non è side-effects; anzi non è nemmeno
class e poi il fatto che uno scriva (bicycle-gears instance) come
fossero function e argomento slegati alla funzionale rende tutto
piuttosto lontano anche da un Java. E Java?
Secondo Alan Kay, che l'object-orientation l'ha inventata, è
fondamentalmente message-passing. Di più, nei suoi papers/libri precisa
che l'obiettivo è quello di arrivare ad eliminare la programmazione
basata sull'alterazione dello stato e per arrivarci indica la protezione
dall'esterno (cioè l'encapsulation) e (importante) il fatto che
l'oggetto debba essere acceduto solo tramite messaggi dall'esterno e
quando ha "senso" (come a dire, quando c'è una sorta di consistenza) con
il resto del sistema. A ben vedere è una visione vicinissima a quella di
Carl Hewitt, e i due si citano a vicenda in effetti.
 
Morale? (ho finito i pochi minuti a disposizione purtroppo) Java e
linguaggi simili come C++, proteggono solo dall'esterno l'accesso allo
stato (il famigerato quanto al 95% inutile "private"), per il resto ti
dicono organizzati da te. Ma questo l'abbiamo già visto da tempo (e pure
Alan Kay che infatti parla di programmi piagati dall'assignment style o
un'espressione del genere non ricordo): l'update allo stato e
l'encapsulation sono (ovviamente meno comodi) ma fattibili anche in C,
dove con le unità di traduzione si possono costruire ADTs senza
problemi.
 
Dov'è il message-passing, quello che dovrebbe creare e portare avanti le
interazioni tra gli oggetti e computare per davvero? 'nun c'è. La
sintassi object.method(arg) è un contentino per ciucci che poco
capiscono e infinocchiare si fanno. Smalltalk e Objective C si
possono scrivere davvero programmi object-oriented (per la definizione
di Kay e di diverse altre accreditate che da quella prendono); con Java,
C++, C# è molto più difficile, tanto per il linguaggio quanto per la
cultura di programmatori, i frameworks e i tools che ci gira
intorno. Qualcuno giustamente la chiama class-based programming per
sottolineare che non si sta facendo altro che organizzare computazioni
imperative sulla base di finti quanto scarsi moduli (le classi).
Ma questo dipende più dai linguaggi, dalle persone e dalla loro visione
contorta quando non stupida visione della oop (e della programmazione in
generale).
 
 
Allora l'object-oriented, per Alan Kay è message-passing (e late
binding, identità, protezione dello stato locale e quelle altre robe che
troverai se te lo leggi). Nun t'offendere ma la definizione che
funziona, in tutti i sensi, è la sua e non la tua. Altre definizioni e
discussioni utili che mi piacciono si trovano nei libri di Benjamin
Pierce, i papers di William Cook e molto altro. Pierce a memoria non
ricordo precisamente ma dalla definizione di object-orientation lascia
(ovviamente) fuori mutabilità/immutabilità, considera l'open recursion e
precisa anche altro sulle possibili semantiche di accesso ai fields. Nel
libro Types of Programming Languages ha capitoli/paragrafi dedicati
tanto agli oggetti imperativi quanto a quelli puramente funzionali.
 
 
(ultimo-ma-non-ultimo, prima che la fidanzata distrugga il laptop que
devo scappare:) i linguaggi di programmazione e i modelli computazionali
sono enti matematici e logica applicata. Quando qualcuno dice "Scala non
è un linguaggio funzionale", chiedere per quale *definizione* (o
idea/concetto/quello che è) di linguaggio funzionale lo si sta
affermando. E sarà meglio che suoni come qualcosa di preciso piuttosto
che "lo dico io che c'ho il cazzo a cavatappi per-cui-si". Altrimenti
inutile discutere, non ci si capisce. E se non ci si capisce a) il
software (e l'hardware) non funziona; b) si perde tempo; c) non so voi,
io m'annoio.
 
 
 
 
[*] altra atroce mancanza di una marea di linguaggi, quella di non avere
un sistema efficace per la modularità...
 
 
 
 
 

 seconda si una descrizione ma non poi così precisa.
 
Sorry, per farmi leggere una pappardella del genere mi paghi, ho letto a grandi linee e semplicemente sei verboso, esprimi concetti banalotti in una tonnellata di parole e non ho ne tempo ne voglia, per altro per dire cose non interenti.
Grazie a dio ho il dono della sintesi.
 
Non ho dato alcun genere di definizione dell'OOP, ho copiato wikipedia. Wikipedia dice che un oggetto e' l'unione di stato e procedure che influiscono sullo stesso (semplificando).
 
def print_foo
  @bar = 10
  print foo
end
 
Questo e' OOP, un metodo perfettamente valido, che cambia senza dire niente a nessuno lo stato dell'oggetto, senza alcun genere di protezione e ovviamente, impossibile da parallelizzare. Questo e' un side effect, anche facendo inutilmente il purista sul termine "side effect", lo stato dell'oggetto viene cambiato fino a nuovo ordine, e non c'e' nulla da fare.
 
Visto che parli di lambda calcolo anche abbastanza gratuitamente, dimostrando che sei abbastanza fiero di conoscere il termine, desumo che tu sappia che tra l'OOP e il funzionale c'e' un mare, specialmente a livello di mindset, la cosiddetta programmazione "idiomatica".
Un programmatore Java estremamente raramente pensa ricorsivamente, non c'e' nulla di male, semplicemente non lo fa perche' non ha nulla in cambio. Sai altrettanto bene che far pensare ad uno schemer "ad oggetti" (in qualunque accezione del termine) e' una cazzo di impresa.
Parli di CLOS, una roba talmente utile che portata ai giorni nostri con Clojure e' stata bellamente ignorata nonostante Clojure sia implementato su 2 piattaforme dove "everything is an object", pensa che bello. In realta' CLOS serve a nulla, Lisp e' Lisp in quanto omoiconico, questo e' il genio di lisp, certamente non un object model incollato sopra alla benemeglio, francamente per moda della meta' degli anni 90. Kurt Kobain moriva mentre Lisp aveva un object model, non so quale mi sta piu' sul cazzo.
 
In definitiva, Scala e' un linguaggio con una sintassi orrenda, che regolarmente aggiunge feature su feature senza mai prendere una sceltra precisa (mi immagino un testo di "idiomatic scala", presumo sulle 4000 pagine), sia funzionale che a oggetti, quindi ancora senza prendere una scelta precisa ma ndo coio coio. Decisamente una moda, non ha caratteristiche tali da giustificare l'hype, la gente vuole switchare a funzionale in modo indolore e prende il ne carne ne pesce della situazione.
 
Giochino: trovami quel capolavoro di "the joy of clojure" in Scala se ci riesci. Non si puo' scrivere, in Scala paese che vai usanza che trovi, come con C++ ogni opinione e' buona, tanto ha tutto, non ti obbliga mai a prendere decisioni sensate e "idiomatiche". Currying? Celo. Tail recursion? Celo. OOP? Celo. Pattern matching? Celo.
 
Un linguaggio cosi' mi fa violentemente cagare, mi viene da non usare niente perche' niente e' idiomatico. Prova a non usare i blocchi in ruby, o le list comprehension in python, auguroni.
 
E questo e' quanto avevo da dire. Magari non scrivere guerra e pace
 
  ngw

 non so quale mi sta piu' sul cazzo.
 
Altro che inutile. Citando Peter Norvig in PAIP, i sistemi
object-oriented in Lisp sono stati gli unici dall'era Smalltalk ad
apportare innovazioni significative nel panorama della oop -
multimethods e generic functions in testa. Rich Hickey, che li ha
studiati e usati, lo sa bene e infatti il polimorfismo a
runtime e i protocols, preponderanti caratteristiche a cui Clojure si
affida per l'astrazione, sono esattamente prese da CLOS, integrate e
estese nel linguaggio. Anche Fogus, autore di Joy of Clojure e
programmatore CL proprio come Hickey e di cui ho letto tanti posts
interessanti negli anni, ovviamente se n'è accorto. CLOS è così inutile
che alcune delle sue caratteristiche migliori _sono già_ in Clojure e
Hickey infatti nella sua wishlist amazon e quando interrogato al
riguardo consiglia diversi libri che trattano solo quello (come quello
della Keene che è il classico dal quale abbiamo studiato un pò tutti me
compreso) e quel capolavoro del MOP di Gregory Kiczales.
 
Eventuale pieno supporto a CLOS e/o portings a cui pari riferirti, e di
cui ignoro l'esistenza, sono ovviamente del tutto irrilevanti alla
discussione: la sopravvivenza di Clojure è per stessa ammissione del suo
autore legata alla JVM e a Java. Qualsiasi sistema (non solo CLOS) che
si sostituisse in toto non potrebbe fare altro che disturbare lo stato
di compatibilità con l'oo di Java di cui Clojure si avvantaggia e da cui
(anche) dipende. La stessa natura non monolitica di CLOS ha permesso a
Hickey di prendere praticamente il grosso di CLOS e quanto gli piaceva e
integrarlo (a mio parere) piuttosto bene.
 
 
- Per chi ha voglia di saperne di più su Lisp, invece che leggersi le
  stronzate gratuite del poster a cui sto rispondo:
 
http://clojure.org/runtime_polymorphism
 
http://clojure.org/protocols
 
http://codequarterly.com/2011/rich-hickey/
 
http://www.se-radio.net/2010/03/episode-158-rich-hickey-on-clojure/
 
 bel podcasts che non ho mai cancellato dallo smartphone e da cui ho
 appreso dei protocols e altre belle caratteristiche del linguaggio.
http://www.se-radio.net/2008/01/episode-84-dick-gabriel-on-lisp/
 
 Richard Gabriel - nessun bisogno di presentazione.
 
http://www.dreamsongs.com/RPG.html
 
 
 
Tra tante idiozie che potevi scrivere, sei andato a scegliere proprio
una che dimostra inequivocabilmente come tu non sappia granché di Lisp,
Common Lisp, CLOS e cosa ancora più imbarazzante di Clojure, linguaggio
che di cui blateri ma che come si vede chiaramente conosco e comprendo
meglio di te. Pensavo di farti cosa grata con esempi di Lisp e invece.
Ignorante, presuntuoso e pure fesso nello smascherarti da solo.

  
http://www.dreamsongs.com/RPG.html
 
 
e come detto anche
http://www.amazon.com/Clojure-Bookshelf/lm/R3LG3ZBZS4GCTH
 

 Ignorante, presuntuoso e pure fesso nello smascherarti da solo.
 
Minchia, mi hai smascherato, nuoooo!! Io volevo bullarmi di conoscere i linguaggi che uso per lavorare su un newsgroup su cui scrivo un post al mese, che mi interessa tantissimo!!! Che cattivo che sei ;(
Ti faccio notare due cose due, poi sinceramente ho di meglio da fare che farti da tampax:
1) Non hai risposto al mio post, hai preso una frase di 8 righe e sei partito con una filippica sul fatto che non so questo e non so quello. Dono della sintesi 0, ma cazzo che capacità deduttive, un Sherlock Holmes. Anzi Watson, che l'è dottore, devi essere uno fiero dei suoi titoli.
2) Hai avvertito Hickey e Fogus che hanno opinioni diverse da quelle che hanno? 
http://codequarterly.com/2011/rich-hickey/
 
 
"When we drop down to the algorithm level, I think OO can seriously thwart reuse. In particular, the use of objects to represent simple informational data is almost criminal in its generation of per-piece-of-information micro-languages, i.e. the class methods, versus far more powerful, declarative, and generic methods like relational algebra. Inventing a class with its own interface to hold a piece of information is like inventing a new language to write every short story. This is anti-reuse, and, I think, results in an explosion of code in typical OO applications. Clojure eschews this and instead advocates a simple associative model for information. With it, one can write algorithms that can be reused across information types."
 
Simple associative model for information = il CLOS, 2 anni solo per scrivere la specifica :D
Ti facevo meno scemo, tolte le citazioni a cazzo e l'attacco ad hominem il tuo post avrebbe potuto scriverlo Audano. Con l'attacco ad hominem ovviamente, altrimenti era whitespace.
 
  ngw


Cazzo, devo controllare di non avere dei libri su PHP nella wishlist amazon, che qualche pirla di PM poi li usa come "prova" se non voglio... uh, sviluppare un progetto in PHP. Guarda a ngw piace PHP, una volta ha desiderato un libro!
Argomenti fortissimi.
 
  ngw

 C
 
Non fai ridere. Torna quando saprai di cosa di parla. bye
 
http://www.goodreads.com/review/show/101101162
 


Giusto, su questo gruppo non pensavo fosse possibile ridefinire il mio concetto di "figura di merda", ma ci sei riuscito. Continua cosi', cazzaro.
 
  ngw

On Friday, June 13, 2014 9:18:35 PM UTC+2, cpascoshi wrote:

Per la cronaca, giusto che cosi' non si ascolta 'sto cazzaro che per avere ragione su argomenti che decide lui e per buona parte ignora, sviando l'impossibile, si inventa opinioni di terzi deducendole dalle wishlist di amazon (lol): Hickey vede l'OOP circa come il fumo negli occhi, e trova che sia buona parte del problema per cui e' cosi' difficile scrivere software concorrente (argomento su cui questo orsacchiotto cacatore di consigli di libri ha giustramente glissato): lo stato degli oggetti cambia, bel problema per il software concorrente, parzialmente risolto da queste nuove tecnologie (IMHO molto parzialmente, per quanto riguarda Scala).
Sono opinioni che vale la pena discutere, certamente in modo un tantino piu' serio.
 
  ngw


Per completezza, e anche un unghia divertente:
 
http://www.flyingmachinestudios.com/programming/the-unofficial-guide-to-rich-hickeys-brain/
 
 
Assicurarsi di fare parte della comunita' di un determinato linguaggio prima di fare gli sboroni e' una idea *grandiosa* :D
 
  ngw

 tantino piu' serio.
 
Uso alberi di threads, class applicative di cui creo istanze; faccio
wait e aspetto uno o l'altro, oppure entrambi. Uso anche threads con una
particolare struttura che mi garantisce una certa sequenza di
passi. Molto veloce e sicuro.