[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: REPL driven programming

M. Edward (Ed) Borasky

1/26/2007 6:17:00 AM

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). :)

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

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

M. Edward (Ed) Borasky

1/28/2007 8:41:00 PM

0

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. :( I consider myself an ultimate geek, and that
admission alone will probably get me kicked out of the club. :) 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. :) 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. :)

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". :) 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. :( 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.blo...

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

Stefano Crocco

1/28/2007 8:58:00 PM

0

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
(http://www.kdevelop.org/index.html?filename=3.4/faq.html#...):

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

M. Edward (Ed) Borasky

1/28/2007 9:13:00 PM

0

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
> (http://www.kdevelop.org/index.html?filename=3.4/faq.html#...):
>
> 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.blo...

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

benjohn

1/28/2007 9:50:00 PM

0


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.

:) Not sure that's a gem though.

M. Edward (Ed) Borasky

1/28/2007 10:13:00 PM

0

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.
>
> :) 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.blo...

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

Christian Neukirchen

1/31/2007 8:55:00 PM

0

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.
>
> :) 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. :)

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

M. Edward (Ed) Borasky

2/1/2007 3:40:00 AM

0

Christian Neukirchen wrote:
> 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.
>>
>> :) 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. :)
>
>
Ah yes ... yet another wonderful command line trick from the days when
nobody had GUIs except the guys inventing them in the labs. :) 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?

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

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

Mike Stok

2/1/2007 2:49:00 PM

0


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

[...]

> :) 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? http://en.wikipedia.org/wiki/J_programmin...

Mike

--

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

The "`Stok' disclaimers" apply.

M. Edward (Ed) Borasky

2/2/2007 3:37:00 AM

0

Mike Stok wrote:
>
> On 31-Jan-07, at 10:39 PM, M. Edward (Ed) Borasky wrote:
>
> [...]
>
>> :) 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? http://en.wikipedia.org/wiki/J_programmin...
>
> Mike
>
> --
> Mike Stok <mike@stok.ca>
> http://www.stok...
>
> The "`Stok' disclaimers" apply.
>
>
>
>
>
>
Yeah ... J, K and A Plus ... but who uses them?

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

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

Christian Neukirchen

2/3/2007 5:26:00 PM

0

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

> Mike Stok wrote:
>>
>> On 31-Jan-07, at 10:39 PM, M. Edward (Ed) Borasky wrote:
>>
>> [...]
>>
>>> :) 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? http://en.wikipedia.org/wiki/J_programmin...
>>
> 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...

> M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneuk...