REPL driven programming

ruby-talk
1

Hello,

this is a spawn of "ruby text editor for beginner", in essence, because that
thread inspired the question in me.

LISP has SLIME.

With SLIME, alternating between REPL and source code files is trivial - you
have a shortcut to send a s-exp from one to the other and it all works great
together.

I wondered if that kind of programming style is supported in other
languages.

So I googled. I found many bloggers hail "repl-driven software development"
as a better-than-yours style that everyone should know or they are COBOL
monkeys, but nobody really explained what "REPL-driven software development"
is.

From a bit of work with SLIME (and screencasts of others using it), I
understand how some automation makes it really easy to play with your code
while working on it (it's supposed to be a Smalltalk thing, too, but I find
the tools very non-productive - at least in squeak - with there being no
easy way to navigate the code with the keyboard and hop to the correct
places and the mouse is a must for almost every operation) but I don't see
how a REPL alone makes it possible. Some more automation, in my opinion, is
needed - an interface that supports alternating file and REPL easily and
gives you a full IDE (code completion, macros) that is consistent in both.

Am I wrong?

If I'm correct, do such tools exist for other languages?

Either way, could anyone who uses the REPL for more than experimentation
with APIs elaborate on the way they use it to assist in their programming?
This really interests me, and I'm sure others could learn a lot from it.

Aur Saraf

2

Hello,

this is a spawn of "ruby text editor for beginner", in essence, because that
thread inspired the question in me.

LISP has SLIME.

With SLIME, alternating between REPL and source code files is trivial - you
have a shortcut to send a s-exp from one to the other and it all works great
together.

I wondered if that kind of programming style is supported in other
languages.

So I googled. I found many bloggers hail "repl-driven software development"
as a better-than-yours style that everyone should know or they are COBOL
monkeys, but nobody really explained what "REPL-driven software development"
is.

From a bit of work with SLIME (and screencasts of others using it), I
understand how some automation makes it really easy to play with your code
while working on it (it's supposed to be a Smalltalk thing, too, but I find
the tools very non-productive - at least in squeak - with there being no
easy way to navigate the code with the keyboard and hop to the correct
places and the mouse is a must for almost every operation) but I don't see
how a REPL alone makes it possible. Some more automation, in my opinion, is
needed - an interface that supports alternating file and REPL easily and
gives you a full IDE (code completion, macros) that is consistent in both.

Am I wrong?

If I'm correct, do such tools exist for other languages?

Emacs also has ruby-inferior mode which you can use to give you a very
SLIME-like experience with ruby.

···

On Wed, Jan 24, 2007 at 06:31:17PM +0900, SonOfLilit wrote:

Either way, could anyone who uses the REPL for more than experimentation
with APIs elaborate on the way they use it to assist in their programming?
This really interests me, and I'm sure others could learn a lot from it.

Aur Saraf

3

SonOfLilit wrote:

Either way, could anyone who uses the REPL for more than experimentation
with APIs elaborate on the way they use it to assist in their programming?
This really interests me, and I'm sure others could learn a lot from it.

Aur Saraf

Outside of the rather intimate and wildly successful Emacs/Lisp/Scheme connections, the only other really usable environment for Design-At-The-Keyboard that I know of is Forth. Almost every language that has an interactive interpreter shell (like "irb") will sport people who *like* to develop that way, and indeed, for small projects, it's fine. But when it comes to larger projects, Emacs and Forth stand out above most of the "non-GUI" IDEs.

An awful lot of thought and many person-decades of experience went into the whole Emacs idea. It's a very well-honed set of tools built by and for first-class programmers in a variety of languages. But it owes a lot of its elegance to Lisp, and not every programmer is suited to that style of development. I think design-at-the-keyboard's days are numbered, quite frankly. I've reached the point in my learning of Ruby where I'm ready for real tools -- KDevelop or Komodo, or maybe Eclipse. I'm spoiled; even Forth has a world-class IDE now (SwiftForth for Windows). :slight_smile:

···

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

4

As good as SLIME in that you can easily move code back and forth between
REPL and source files?

Aur Saraf

···

On 1/25/07, Logan Capaldo <logancapaldo@gmail.com> wrote:

On Wed, Jan 24, 2007 at 06:31:17PM +0900, SonOfLilit wrote:
> Hello,
>
> this is a spawn of "ruby text editor for beginner", in essence, because
that
> thread inspired the question in me.
>
> LISP has SLIME.
>
> With SLIME, alternating between REPL and source code files is trivial -
you
> have a shortcut to send a s-exp from one to the other and it all works
great
> together.
>
> I wondered if that kind of programming style is supported in other
> languages.
>
> So I googled. I found many bloggers hail "repl-driven software
development"
> as a better-than-yours style that everyone should know or they are COBOL
> monkeys, but nobody really explained what "REPL-driven software
development"
> is.
>
> From a bit of work with SLIME (and screencasts of others using it), I
> understand how some automation makes it really easy to play with your
code
> while working on it (it's supposed to be a Smalltalk thing, too, but I
find
> the tools very non-productive - at least in squeak - with there being no
> easy way to navigate the code with the keyboard and hop to the correct
> places and the mouse is a must for almost every operation) but I don't
see
> how a REPL alone makes it possible. Some more automation, in my opinion,
is
> needed - an interface that supports alternating file and REPL easily and
> gives you a full IDE (code completion, macros) that is consistent in
both.
>
> Am I wrong?
>
> If I'm correct, do such tools exist for other languages?
>
Emacs also has ruby-inferior mode which you can use to give you a very
SLIME-like experience with ruby.
> Either way, could anyone who uses the REPL for more than experimentation
> with APIs elaborate on the way they use it to assist in their
programming?
> This really interests me, and I'm sure others could learn a lot from it.
>
> Aur Saraf

5

Why is a graphical IDE more "real" than a text editor with macros?

Not flaming, just asking what in full-blown IDEs you find more useful than
emacs.

It's just that lately I've moved to emacs for C++ GUI code, and that shows
that I can't find ANYTHING better in IDEs...

Aur

···

On 1/26/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

SonOfLilit wrote:
> Either way, could anyone who uses the REPL for more than experimentation
> with APIs elaborate on the way they use it to assist in their
> programming?
> This really interests me, and I'm sure others could learn a lot from it.
>
> Aur Saraf
Outside of the rather intimate and wildly successful Emacs/Lisp/Scheme
connections, the only other really usable environment for
Design-At-The-Keyboard that I know of is Forth. Almost every language
that has an interactive interpreter shell (like "irb") will sport people
who *like* to develop that way, and indeed, for small projects, it's
fine. But when it comes to larger projects, Emacs and Forth stand out
above most of the "non-GUI" IDEs.

An awful lot of thought and many person-decades of experience went into
the whole Emacs idea. It's a very well-honed set of tools built by and
for first-class programmers in a variety of languages. But it owes a lot
of its elegance to Lisp, and not every programmer is suited to that
style of development. I think design-at-the-keyboard's days are
numbered, quite frankly. I've reached the point in my learning of Ruby
where I'm ready for real tools -- KDevelop or Komodo, or maybe Eclipse.
I'm spoiled; even Forth has a world-class IDE now (SwiftForth for
Windows). :slight_smile:

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

6

SonOfLilit wrote:

Why is a graphical IDE more "real" than a text editor with macros?

Not flaming, just asking what in full-blown IDEs you find more useful than
emacs.

It's just that lately I've moved to emacs for C++ GUI code, and that shows
that I can't find ANYTHING better in IDEs...

Aur

I never learned Emacs. :frowning: I consider myself an ultimate geek, and that admission alone will probably get me kicked out of the club. :slight_smile: But most of my career has been spent in industrial settings where the tools available were dictated. And when I did end up working with UNIX (BSD 4.2/4.3) "vi" was preferred over Emacs because Emacs was a memory hog. So I learned "vi" and today use "vim" and "Gvim". I *know* Emacs is the ultimate text editor and Lisp is the ultimate programming language -- I just never learned how to use Emacs and never had an opportunity to use Lisp and get paid for it. Then again, I never got paid to work in Forth either. :slight_smile: There's a better chance I might get paid to work in Ruby, though. And if so, I'll insist on a Komodo license, or maybe Sapphire in Steel. :slight_smile:

Speaking of Komodo in general and Komodo vs. KDevelop in particular, I downloaded the beta of Komodo Editor 4.0 and compared it with KDevelop for some "simple Ruby development tasks". KDevelop is, as I've noted before, an "industrial strength multi-language IDE" and is free as in freedom. The downside of KDevelop is that it is very intimately integrated with Linux, Qt and KDE. If you have different ideas about what an application should look like, you'll find yourself fighting the tool. And I think there are licensing gotchas that more or less constrain you to using KDevelop only for GPL projects.

The downside of Komodo Editor is that it isn't a full IDE, and it only supports scripting languages. But if all you're interested in is Ruby and portability is a concern, the Komodo Editor looks like a great tool. It's free as in beer and I think, though I don't know for sure, that it's "smarter" than Scite.

The full Komodo is limited only by the fact that it only supports scripting languages and is not free in either sense. It appears to be toolkit agnostic, although given that it supports Tcl/Tk, it's probably biased in that direction. It appears to be *much* easier to use when you want to import an existing CVS command-line project -- I tried for about two hours to import one of mine into KDevelop and couldn't get it to work. Komodo synced up with RubyForge as soon as I opened the directories, and it took me about five minutes to get the RSpec stuff to work, including the Rake task to run "rcov". :slight_smile: The only issue I have is that Komodo uses "/usr/bin/ruby" as the Ruby "command line interpreter", not "irb". I couldn't make "irb" work and I don't know why just yet.

The other criterion I'm looking at is the ability to handle new languages. As you may know, I do a lot of work in R, and eventually would want my IDE to work with R code. It looks like both KDevelop and Komodo are capable of being taught new languages, and it looks like the process is equally complex and detail-oriented for both tools. :frowning: And yes, Emacs has an excellent R interface, called "ess" (Emacs Speaks Statistics).

···

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

7

Alle 21:40, domenica 28 gennaio 2007, M. Edward (Ed) Borasky ha scritto:

And I think there are licensing gotchas that more or less
constrain you to using KDevelop only for GPL projects.

This isn't true. From the KDevelop FAQ
(KDevelop - A cross-platform IDE for C, C++, Python, QML/JavaScript and PHP):

Everyone and all entities are free to use KDevelop. The generated Code can be
put under all licenses you wish. [...] So you can write commercial/closed
software with it despite the fact that KDevelop itself is GPL

Of course, as the same document explains, you still have to fulfill the
requirements imposed by any library you use in your project (for example, to
develop a commercial application which use Qt, you'll need a commerical Qt
license).

Stefano

8

Stefano Crocco wrote:

Alle 21:40, domenica 28 gennaio 2007, M. Edward (Ed) Borasky ha scritto:
  

And I think there are licensing gotchas that more or less
constrain you to using KDevelop only for GPL projects.
    
This isn't true. From the KDevelop FAQ (KDevelop - A cross-platform IDE for C, C++, Python, QML/JavaScript and PHP):

Everyone and all entities are free to use KDevelop. The generated Code can be put under all licenses you wish. [...] So you can write commercial/closed software with it despite the fact that KDevelop itself is GPL

Of course, as the same document explains, you still have to fulfill the requirements imposed by any library you use in your project (for example, to develop a commercial application which use Qt, you'll need a commerical Qt license).
  

Yes, and I found KDevelop to be strongly biased towards Qt as the GUI toolkit. As I said, if you have different ideas you'll find yourself fighting the tool.

···

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

9

This conversation is very insightful, but I find myself impatient as to when
more REPL-driven-programming gems will be given.

If anyone has on-topic info, I'd appreciate :slight_smile:

Aur

PS Please feel free to /also/ continue the interesting IDE conversation.

10

Something I liked about old school BASICs was the line numbering. This, in my opinion, was quite a clever (but primitive) way of having a combined editor and immediate mode. A line number prefix signifies that you're setting or amending a line. Without the prefix, a line is evaluated immediately.

:slight_smile: Not sure that's a gem though.

···

On 28 Jan 2007, at 21:31, SonOfLilit wrote:

This conversation is very insightful, but I find myself impatient as to when
more REPL-driven-programming gems will be given.

11

Benjohn Barnes wrote:

This conversation is very insightful, but I find myself impatient as to when
more REPL-driven-programming gems will be given.

Something I liked about old school BASICs was the line numbering. This, in my opinion, was quite a clever (but primitive) way of having a combined editor and immediate mode. A line number prefix signifies that you're setting or amending a line. Without the prefix, a line is evaluated immediately.

:slight_smile: Not sure that's a gem though.

I think the real "gem" is that Emacs rocks, and if you *must* do REPL programming, that's the way to do it.

···

On 28 Jan 2007, at 21:31, SonOfLilit wrote:

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

12

Benjohn Barnes <benjohn@fysh.org> writes:

···

On 28 Jan 2007, at 21:31, SonOfLilit wrote:

This conversation is very insightful, but I find myself impatient
as to when
more REPL-driven-programming gems will be given.

Something I liked about old school BASICs was the line numbering.
This, in my opinion, was quite a clever (but primitive) way of having
a combined editor and immediate mode. A line number prefix signifies
that you're setting or amending a line. Without the prefix, a line is
evaluated immediately.

:slight_smile: Not sure that's a gem though.

APL had that too, and you could even use floating point numbers to
insert between lines (they'd get renamed after editing).

*That's* a gem. :slight_smile:

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

13

Yes, I've figured that part out, but HOW?

Perhaps tools must be created.

What does everyone say? Are the tools needed for good REPL driven
development with ruby there, or do we need new tools?

Aur Saraf

···

On 1/29/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

Benjohn Barnes wrote:
>
> On 28 Jan 2007, at 21:31, SonOfLilit wrote:
>
>> This conversation is very insightful, but I find myself impatient as
>> to when
>> more REPL-driven-programming gems will be given.
>
> Something I liked about old school BASICs was the line numbering.
> This, in my opinion, was quite a clever (but primitive) way of having
> a combined editor and immediate mode. A line number prefix signifies
> that you're setting or amending a line. Without the prefix, a line is
> evaluated immediately.
>
> :slight_smile: Not sure that's a gem though.
>
I think the real "gem" is that Emacs rocks, and if you *must* do REPL
programming, that's the way to do it.

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

14

Christian Neukirchen wrote:

Benjohn Barnes <benjohn@fysh.org> writes:

This conversation is very insightful, but I find myself impatient
as to when
more REPL-driven-programming gems will be given.
      

Something I liked about old school BASICs was the line numbering.
This, in my opinion, was quite a clever (but primitive) way of having
a combined editor and immediate mode. A line number prefix signifies
that you're setting or amending a line. Without the prefix, a line is
evaluated immediately.

:slight_smile: Not sure that's a gem though.
    
APL had that too, and you could even use floating point numbers to
insert between lines (they'd get renamed after editing).

*That's* a gem. :slight_smile:

Ah yes ... yet another wonderful command line trick from the days when nobody had GUIs except the guys inventing them in the labs. :slight_smile: I can't for the life of me figure out why APL didn't take over the world. It was literally a decade ahead of its time and really only Lisp represents as profound a breakthrough in programming languages. Lisp is still around, thriving, in two dialects -- what happened to APL?

···

On 28 Jan 2007, at 21:31, SonOfLilit wrote:

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

15

[...]

:slight_smile: I can't for the life of me figure out why APL didn't take over the world. It was literally a decade ahead of its time and really only Lisp represents as profound a breakthrough in programming languages. Lisp is still around, thriving, in two dialects -- what happened to APL?

J? J (programming language) - Wikipedia

Mike

···

On 31-Jan-07, at 10:39 PM, M. Edward (Ed) Borasky wrote:

--

Mike Stok <mike@stok.ca>
http://www.stok.ca/~mike/

The "`Stok' disclaimers" apply.

16

M. Edward (Ed) Borasky wrote:

...what happened to APL?

VisiCalc.

(I mean that quite seriously. It cut the legs off one of APL's main gateways.)

···

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams. "Taliessin through Logres: Prelude"

17

Mike Stok wrote:

[...]

:slight_smile: I can't for the life of me figure out why APL didn't take over the world. It was literally a decade ahead of its time and really only Lisp represents as profound a breakthrough in programming languages. Lisp is still around, thriving, in two dialects -- what happened to APL?

J? J (programming language) - Wikipedia

Mike

--
Mike Stok <mike@stok.ca>
Mike Stok

The "`Stok' disclaimers" apply.

Yeah ... J, K and A Plus ... but who uses them?

···

On 31-Jan-07, at 10:39 PM, M. Edward (Ed) Borasky wrote:

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

18

John W. Kennedy wrote:

M. Edward (Ed) Borasky wrote:

...what happened to APL?

VisiCalc.

(I mean that quite seriously. It cut the legs off one of APL's main gateways.)

Could you even do a linear regression in VisiCalc, let alone in one line of code? I thought that entered the spreadsheet vocabulary with Lotus 1-2-3.

···

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

19

"M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

Mike Stok wrote:

[...]

:slight_smile: I can't for the life of me figure out why APL didn't take over
the world. It was literally a decade ahead of its time and really
only Lisp represents as profound a breakthrough in programming
languages. Lisp is still around, thriving, in two dialects -- what
happened to APL?

J? J (programming language) - Wikipedia

Yeah ... J, K and A Plus ... but who uses them?

I hear K is used in lots of banks etc.

It's too unfortunate that only A+ is open sourced of these...

···

On 31-Jan-07, at 10:39 PM, M. Edward (Ed) Borasky wrote:

M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

20

M. Edward (Ed) Borasky wrote:

John W. Kennedy wrote:

M. Edward (Ed) Borasky wrote:

...what happened to APL?

VisiCalc.

(I mean that quite seriously. It cut the legs off one of APL's main gateways.)

Could you even do a linear regression in VisiCalc, let alone in one line of code? I thought that entered the spreadsheet vocabulary with Lotus 1-2-3.

It's been ages since I used VisiCalc, so I really have no idea. But as a purely practical issue, the COBOL-oriented mainframe world was just beginning to open the door to APL for what-if purposes when VisiCalc on back-door Apple IIs (and, later, official IBM PCs) aborted it. IBM tried to bring APL to the PC (it was the first piece of software to require an 8087), but the opportunity had passed.

···

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams. "Taliessin through Logres: Prelude"