Perché lo sviluppo in stile REPL non è più comune in Ruby?

Question

Sembra che i programmatori Lisp e Clojure sviluppino spesso programmi direttamente in REPL. cf. Clojure Development: IDE or REPL?

La mia domanda è, perché questo approccio non è più comune in Ruby, tramite irb? Questa è solo una differenza culturale, o ci sono ragioni strutturali (specifiche della lingua) per cui lo sviluppo REPL-centrico è più comune con i Lisps che con linguaggi come Ruby e Python?

Answer 1

La sintassi del Lisp sembra prestarsi molto bene per un approccio combinato REPL-e-source-file. È molto più facile spostare gli snippet di codice in modo programmatico quando i limiti testuali di ciascun modulo sono chiari.

Answer 2

Io uso Emacs per Clojure e Ruby e spesso carico i miei moduli ruby ​​in irb e gioco interattivamente in emacs nello stesso modo in cui eseguo REPL.

Answer 3

In realtà questo è il mio modo di sviluppare Ruby.

Di solito scrivo il mio codice, quindi ne incollo alcune parti in irb, le adattare, le incollo di nuovo e così via.

Non c'è un modo in Lisps per stampare lo "stato corrente" che hai sviluppato in stile REPL in un programma? Penso che non sia possibile in ruby.

Answer 4

Spesso eseguire i test di unità è meno impegnativo rispetto alla digitazione di cose tramite l'equivalente di Ruby al REPL. Poi di nuovo, a volte devo aggiungere un po 'di debugging di printf al codice ...

Answer 5

Penso che molto di questo è dovuto agli editori che i Rubyisti tendono ad usare. Io uso vim, che non ha un ottimo modo per interagire con un REPL. Il compagno di testo è nella stessa barca (AFAIK). Emacs, Dr Racket, ecc., D'altra parte, hanno tutti un meraviglioso meccanismo per interagire con un REPL. Credo che i Lispers tenderebbero ad usare questi tipi di editor/ambienti.

Answer 6

Forse questi vi aiuterà:

• interactive_editor è un'estensione che aggiunge IRB nella capacità di aprire vim, emacs, MacVim, nano e TextMate e fare l'editing del buffer IRB.
• irbtools include interattivo_editor insieme ad altre belle aggiunte.
• Utility Belt è un'altra raccolta di gemme IRB che estende la sua funzionalità e include anche qualcosa per consentire la modifica del buffer.

Sono vecchio stile quindi di solito ho un editor aperto e irb in esecuzione in una finestra del terminale; Le vecchie abitudini sono dure a morire, lo sai. Uso gli irbtools, ma intendo passare a Utility Belt per vedere come ci si sente in confronto.

Answer 7

Non sono uno sviluppatore di Ruby. Tuttavia ritengo che la ragione sia la trasparenza referenziale.

La maggior parte delle funzioni di Clojure idiomatiche sono funzioni puri che obbediscono alla trasparenza referenziale. Come risultato, personalmente trovo molto più facile testare funzioni che sono unità indipendenti indipendenti e in qualche modo forniscono lo scopo dei test unitari. Clojure essendo un linguaggio altamente supponente preferisce che la maggior parte delle funzioni siano apolidi. Rende chiara la distinzione tra codice in cui gli effetti collaterali si verificano e gli stati vengono mantenuti utilizzando varie altre alternative come var, refs, agents, atoms ecc, mantenendo la maggior parte del codice pulito, privo di effetti collaterali e referenziale trasparente.

Ritengo che qualsiasi codice strutturato attorno a funzioni referenzialmente trasparenti e senza stato si presti automaticamente a beneficiare del REPL sia che si tratti in Ruby o in qualsiasi altro linguaggio di programmazione.

Sebbene per la maggior parte degli scopi pratici, la CLI fornita da un'altra lingua sarebbe ugualmente utile, tuttavia il concetto di Read, Eval, Print and Loop non è lo stesso in LISP come in qualsiasi altra lingua. Qualsiasi lingua non-homoiconic non avrebbe una fase READ e sarebbe solo leggendo la rappresentazione testuale o una stringa, tuttavia in LISP la fase READ è effettivamente in grado di analizzare in qualsiasi forma di s-expression che si lancia a esso. Per ulteriori informazioni su di esso si riferiscono al di sotto dei 2 risposte:

Is Lisp the only language with REPL?

How is Lisp's read-eval-print loop different than Python's?