OT Programmazione - rolling release

[Scara95]

Odio Java.

Plot twist.

[MItaly]

Mi sembra abbastanza

void *dummy

Nah, quello era necessario (è un callback stile C che deve avere quella firma lì).

Volendo continuare, anche atoi è discutibile: se uno dei parametri non è rappresentabile in un int, .

Assumi pure che i dati in input siano sempre buoni. C'è un problema ben più grosso, e che si verifica con praticamente qualunque valore.
(la cosa bella è che è così da tipo tre anni ma non se n'è mai accorto nessuno perché quel callback non è mai stato chiamato ; settimana scorsa ho cambiato il codice che chiama il callback per cui effettivamente viene chiamato ed è successo il finimondo)

Di cosa, poi?

Del functore che si porta dietro. Avevo in mente che copiare std::function fosse equivalente ad avere un altro reference allo stesso functore (come funzionano i riferimenti a closure in qualunque altro linguaggio).

Odio Java. Mi domando come chi lo usi (quanti e dove, poi?) non sia travolto dalla tremenda inconsistenza che lo forgia.

Oh be' se parliamo di linguaggi inconsistenti c'è ben di peggio.

Plot twist.

[Scara95]

Oh be' se parliamo di linguaggi inconsistenti c'è ben di peggio.

E poi ci sono i linguaggi consistenti che sono peggio comunque, un quicksort in J tanto per:

(] (([: $: < # [) , (= # [) , [: $: > # [) {.)^:(# > 1:)

[MItaly]

E poi ci sono i linguaggi consistenti che sono peggio comunque, un quicksort in J tanto per:

(] (([: $: < # [) , (= # [) , [: $: > # [) {.)^:(# > 1:)

E questa è la versione non offuscata?

[signoredeltempo]

E poi ci sono i linguaggi consistenti che sono peggio comunque, un quicksort in J tanto per:

(] (([: $: < # [) , (= # [) , [: $: > # [) {.)^:(# > 1:)

Però parliamo di un linguaggio virtualmente inutilizzato, non di uno ampiamente adottato e, per di più, ostenato come "semplice". Alcune cose sono più semplici (e consistenti) in asm, per esagerare.

[Scara95]

E questa è la versione non offuscata?

Questa è una versione standard:
Divide gli elementi in < del primo e chiama ricorsivamente, = al primo, > del primo e chiama ricorsivamente. Continua finché la lista è 1+ elementi.
Nulla di speciale insomma.

Le chiamate ricorsive sono le $:

@signoredeltempo quel linguaggio è derivato da apl, il quale è ancora utilizzato e le uniche implementazioni degne di nota sono commerciali e costose.

Quel linguaggio si comporta in modo sime a K/Q, un altro linguaggio commerciale piuttosto costoso (sostanzialmente un database).


Non sottovalutare...

In ogni caso una volta compresa la sintassi è piuttosto semplice da comprendere.

# > 1: controlla se la lista è più lunga di 1 elemento
^: esegue ciò che precede se ciò che segue è vero, altrimenti restituisce l'argomento
] verb {. passa come argomenti ] l'argomento (ovvero la lista intera) {. il primo elemento della lista
, concatena

< # [ seleziona gli elementi minori del primo elemento
[: $: chiama ricorsivamente la funzione
= # [ seleziona gli elementi uguali al primo
> # [ seleziona gli elementi maggiori del primo
[: $: chiama ricorsivamente la funzione

Basta farci un attimo l'abitudine.

[MItaly]

Mi sfugge un attimo il meccanismo di salvataggio dei risultati temporanei... c'è uno stack implicito in tutta la vicenda? È una specie di FORTH all'ennesima potenza?

[XWolverineX]

Vorrei un momentino fare un cambio totale di argomento: API Design.

Chi di voi si è mai ritrovato a dover progettare e implementare delle API (che siano Web o meno) che verranno poi utilizzati dai vostri clienti? Quale è l'approccio che seguite? Avete voglia di condividere delle esperienze in merito?

[Scara95]

Mi sfugge un attimo il meccanismo di salvataggio dei risultati temporanei... c'è uno stack implicito in tutta la vicenda? È una specie di FORTH all'ennesima potenza?

C'è un meccanismo implicito di composizione di funzione.
Una funzione v può prendere 1 o 2 argomenti:
v y
x v y
Date tre funzioni v u w
(v u w) y <-> (v y) u (w y)
x (v u w) y <-> (x v y) u (x w y)

una serie di funzioni
f g u v w
Viene interpretata come
f g (u v w)
E quindi ci si può rifare alle regole di cui sopra.
Ci sono un altro paio di regole di composizione ma non sono utili alla comprensione del codice sopra.
[: serve alla composizione di funzione com'è nella matematica
([: u v) y <-> u (v y)
Un modo equivalente è usare la congiunzione @:
(u@:v) y <-> u (v y)

La valutazione procede da destra a sinistra, quindi un altro modo per comporre è
u v y

Una serie di funzioni
f g u v w
Viene interpretata come
f g (u v w)
E quindi si procede con le regole di composizione di cui sopra.
Ci sono un altro paio di regole, ma non sono utili alla comprensione del codice.

[MItaly]

Vorrei un momentino fare un cambio totale di argomento: API Design.

Chi di voi si è mai ritrovato a dover progettare e implementare delle API (che siano Web o meno) che verranno poi utilizzati dai vostri clienti? Quale è l'approccio che seguite? Avete voglia di condividere delle esperienze in merito?

È capitato abbastanza di rado, e l'ultima volta è fallito tutto (ma perché il cliente era un imbecille, non per le nostre API ), per cui non credo di poter dare consigli troppo validi tanto credo dipenda molto dal tipo di applicazione e di target di utilizzo delle API - un conto è se è un progetto pilota per un singolo cliente con API fatte su misura per lui, un altro è se sono Twitter e devo fare API per il pubblico generale. Tu in che caso rientri?

C'è un meccanismo implicito di composizione di funzione.
Una funzione v può prendere 1 o 2 argomenti:
v y
x v y
Date tre funzioni v u w
(v u w) y <-> (v y) u (w y)
x (v u w) y <-> (x v y) u (x w y)
...

Credo di capicchiare... in realtà quindi le funzioni come sintassi tendono più verso l'idea degli operatori (unari e binari)... sostanzialmente è tutto un gioco di notazione infissa (vs prefissa => LISP, postfissa => FORTH, Postscript & co., prefissa in generale e infissa solo per alcuni operatori => più o meno tutto il resto).