Dlaczego rozwój języka w stylu REPL nie jest bardziej powszechny w Ruby?

Question

Wygląda na to, że programiści Lisp i Clojure często tworzą programy bezpośrednio w REPL. cf. Clojure Development: IDE or REPL?

Moje pytanie brzmi: dlaczego to podejście nie jest bardziej powszechne w Rubim, poprzez irb? Czy jest to tylko różnica kulturowa, czy też istnieją strukturalne (zależne od języka) powody, dla których rozwój języka skoncentrowany na REPL jest bardziej powszechny w przypadku Lisps niż w przypadku języków takich jak Ruby i Python?

Answer 1

Składnia Lisp wydaje się bardzo dobrze pasować do połączonego podejścia opartego na pliku REPL i źródłowym. Znacznie łatwiej jest przenosić fragmenty kodu programowo, gdy ograniczenia tekstowe poszczególnych formularzy są jasne.

Answer 2

Używam Emacsa do Clojure i Ruby i często ładuję moje moduły ruby ​​do irb i gram interaktywnie w emacs w taki sam sposób jak REPL.

Answer 3

W rzeczywistości ten jest mój sposób na rozwój Ruby.

Zazwyczaj piszę swój kod, a następnie wklejaję jego części do irb, dostosowuję je, wklejam je ponownie i tak dalej.

Czy w Lisps nie ma sposobu na wydrukowanie "obecnego stanu", w którym opracowałeś styl REPL w programie? Myślę, że nie jest to możliwe w rubinach.

Answer 4

Często przeprowadzanie testów jednostkowych to mniej wysiłku niż wpisywanie danych za pośrednictwem Rubinowego odpowiednika REPL. Potem znowu, czasami muszę dodać trochę debugowania printf do kodu ...

Answer 5

Myślę, że wiele z tego wynika z redaktorów, których używają Rubiści. Używam vima, który nie ma świetnego sposobu na interakcję z REPL. Textmate jest w tej samej łodzi (AFAIK). Z drugiej strony, Emacs, Dr Racket itp. Mają wspaniały mechanizm interakcji z REPL. Wierzę, że Lispers miałby tendencję do używania tego typu edytorów/środowisk.

Answer 6

Może to pomoże:

• interactive_editor jest IRB rozszerzenie, które dodaje się możliwość otwierania vim, emacs, MacVim, nano i TextMate i zrobić edycję bufora IRB.
• irbtools zawiera interactive_editor wraz z kilkoma dodatkowymi dodatkami.
• Utility Belt to kolejna kolekcja klejnotów IRB poszerzająca jego funkcjonalność, a także zawierająca coś, co pozwala na edycję bufora.

Jestem old-school, więc zwykle mam otwarty edytor i irb działający w oknie terminala; Stare nawyki umierają ciężko, wiesz. Używam irbtools, ale zamierzam przejść na pasek narzędzi, aby zobaczyć, jak to jest w porównaniu.

Answer 7

Nie jestem programistą Ruby. Jednak czuję, że powodem jest przejrzystość referencyjna.

Najbardziej idiomatyczne funkcje Clojure są czystymi funkcjami spełniającymi przejrzystość referencyjną. W wyniku tego osobiście znacznie łatwiej jest testować funkcje, które są niezależnymi autonomicznymi jednostkami i w pewnym stopniu zapewniają cel testów jednostkowych. Clojure jest językiem wysoce opiniotwórczym, woli, aby większość funkcji była bezpaństwowa. Wprowadza wyraźne rozróżnienie między kodem, w którym występują efekty uboczne, a stanami są utrzymywane za pomocą różnych innych opcji, takich jak var, refs, agents, atoms itp., Utrzymując większość kodu czysty, efekt uboczny wolny i przejrzystość referencyjna.

Uważam, że jakikolwiek kod utworzony wokół przejrzystych i bezpaństwowych funkcji będzie automatycznie korzystał z REPL-u, niezależnie od tego, czy będzie to Ruby, czy jakikolwiek inny język programowania.

Chociaż w większości praktycznych zastosowań, interfejs CLI dostarczony przez inny język będzie równie przydatny, jednak koncepcja Read, Eval, Print and Loop nie jest taka sama w LISP jak w jakimkolwiek innym języku. Każdy język non-homoiconic nie miałby fazy READ i byłby to po prostu odczytanie reprezentacji tekstowej lub ciągu znaków, jednak w fazie LISP faza READ faktycznie jest w stanie przeanalizować w dowolnej formie s-expression, którą rzuca się na nią. Aby uzyskać więcej informacji na jej temat patrz poniżej 2 odpowiedzi:

Is Lisp the only language with REPL?

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