On Sun, Apr 15, 2007 at 03:50:13PM +0900, Tim X wrote:
There have been some lisp dialects that combined the IDE with the language
similar to what smalltalk does.
With respect to coding in lisp, the combination of emacs and SLIME is a very
nice environment. I believe there is also a project that is developing
integration with SWANK (the lisp side of the emacs/slime combination) to VI, so
that you can get a similar integration, but with VI as the front end
editor/driver
If that’s Vim, and not just vi, I’m sure I’ll be all over it.
On Mon, Apr 16, 2007 at 01:48:59AM +0900, M. Edward (Ed) Borasky wrote:
Tim X wrote:
There have been some lisp dialects that combined the IDE with the language
similar to what smalltalk does.
Dr. Scheme comes to mind … an IDE and a language tutorial. And for
Forth, there’s the non-free and Windows-ia32-only SwiftForth package
from Forth, Inc. It’s not as tutorial as Dr. Scheme, but it does come
with an excellent tutorial in PDF.
I’ve seen Dr. Scheme, and it’s a really nice idea. One of these days,
I’ll actually spend some quality time with it.
Chad P. wrote:
Anyway, I’d rather code Lisp in Vim any day of the week.
If that’s Vim, and not just vi, I’m sure I’ll be all over it.
Does anyone actually use (or even know where to find) “just vi” any
more?
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
On Mon, Apr 16, 2007 at 03:18:12AM +0900, M. Edward (Ed) Borasky wrote:
Dr. Scheme comes to mind … an IDE and a language tutorial. And for
Forth, there’s the non-free and Windows-ia32-only SwiftForth package
from Forth, Inc. It’s not as tutorial as Dr. Scheme, but it does come
with an excellent tutorial in PDF.
I’ve seen Dr. Scheme, and it’s a really nice idea. One of these days,
I’ll actually spend some quality time with it.
SwiftForth is a lot more fun. 
Forth is a little further down my list of languages right now. Maybe
some day.
Chad P. wrote:
from Forth, Inc. It’s not as tutorial as Dr. Scheme, but it does come
with an excellent tutorial in PDF.
I’ve seen Dr. Scheme, and it’s a really nice idea. One of these days,
I’ll actually spend some quality time with it.
SwiftForth is a lot more fun. 
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
On Mon, Apr 16, 2007 at 03:19:05AM +0900, M. Edward (Ed) Borasky wrote:
Does anyone actually use (or even know where to find) “just vi” any more?
Yes . . . but not me.
Chad P. wrote:
There have been some lisp dialects that combined the IDE with the
with an excellent tutorial in PDF.
Forth is a little further down my list of languages right now. Maybe
some day.
A wise decision … it’s addicting.
–
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
On 15-Apr-07, at 2:19 PM, M. Edward (Ed) Borasky wrote:
Does anyone actually use (or even know where to find) “just vi” any
more?
Use, no; know where to find, yes:
On 4/13/07, Don L. [email protected] wrote:
Hello all,
A journey that has taken me from developing in Filemaker through the
self study of Ruby, Rails, and regular expressions has led me to
begin looking at algorithms and data structures. Though I don’t have
a traditional computer science background, I am trying to educate
myself as best I can.
brpreiss.com is worth a look. However, if your
goal is to teach yourself about algorithms and data structures, I’d
suggest working your way through How to Design Programs (download
DrScheme as the recommended scheme implementation), and then proceed
with Structure and Interpretation of Computer Programs, the classic
text on the subject.
martin
On Mon, Apr 16, 2007 at 04:07:55AM +0900, M. Edward (Ed) Borasky wrote:
Chad P. wrote:
Forth is a little further down my list of languages right now. Maybe
some day.
A wise decision … it’s addicting.
So are OCaml, Perl, Ruby, and UCBLogo.
Chad P. [email protected] writes:
–
Yes, I should have written vim - I’m pretty sure its vim (as opposed to
other
‘vi’ clones).
Tim
Ewald C. [email protected] writes:
of admission. In fact, if memory serves, those
illustrations have received high praise from Edward
Tufte, who is quite a stickler when it comes to
information representation.
Of course - I knew there was another author I wanted to mention, but for
the
life of me, couldn’t remember his name. I would agree his stuff is good.
I would also say not to worry too much about the fact his first edition
was
was based on Pascal. To some extent, the language is less important than
the
concepts. Knuth’s Art of Programming books used an abstract machine that
is even
at a lower level than Pascal. It could be argued that having a book that
used a
language you were not using or not familiar with may be beneficial as it
would
remove the temptation to just ‘cut and paste’ rather than working
towards
understanding.
The other nice thing about getting a book on algorithms that uses a
language
like pascal is that apart from Pascal being a fairly simple language to
follow,
your going to pick up the book for a lot less than a ‘modern’ book based
on
Java, Ruby or Python (many of which are written by people who I suspect
had
Sedgwick, Wirth and Knuth sitting next to them for reference!).
The key, find an Author with a style you like - that is the No. 1
priority. If
you can find such an author and they have a book that uses Ruby, well
your very
lucky. But don’t restrict yourself to only books on algorithms that use
the
language you are working in because you are likely to miss the insight
from
some really gifted communicators.
Tim
“Huw C.” [email protected] writes:
Thanks for the extra information about ‘semantic highlighting’. I can’t
quite picture how we would be able to indicate scope information clearly
using this technique, particularly as we already indicate syntax information
with colouring.
Yes, I agree it is not easy to identify the best visual way to represent
additional information since colour based syntax highlighting is already
extensively used. However, possibly things like showing out of scope
variables
etc in a different brightness, or with an underline or slightly
different sized
font or …
I guess what is really needed is someone with a really fresh take on the
whole
problem. I tend to feel that a lot of what we have come to accept as
standard
interface practices have become so more through chance than through real
analysis. For instance, we have all become use to syntax highlighting
using
colours and now we may consider how to indicate other information, such
as that
derived from semantic analysis. However, may be we have it around the
wrong
way. Maybe colours should be used to indicate semantic information and
some
other approach used for syntax info. Likewise for other interface
options. For
example, I’ve never understood why everyone appears to be so keen on
using
mice. I started before mice were common and grew up with keyborad macros
and
shortcut keys. Now, my collegues have commented on how fast I can get
things
done and a few of them have started moving away from heavy dependence on
the
mouse to using the keyboard. I’ve even known of someone who replaced
their
mouse with a foot powered system, which they really liked as it allowed
them to
keep their hands on the ‘home keys’ and use their feet to manipulate the
pointer.
The problem of course is that we are all now ‘polluted’ by our exposure
to
current interface design and find it hard to break away from conceiving
things
within that framework. However, I won’t be surprised when the martians
arrive
and we see a totally different interface!
On 16 Apr 2007, at 08:33, Martin DeMello wrote:
goal is to teach yourself about algorithms and data structures, I’d
suggest working your way through How to Design Programs (download
DrScheme as the recommended scheme implementation), and then proceed
with Structure and Interpretation of Computer Programs, the classic
text on the subject.
I’d also recommend “Data Structures: An Advanced Approach Using C” by
Esakov and Weiss.
Ellie
Eleanor McHugh
Games With Brains
raise ArgumentError unless @reality.responds_to? :reason
On 4/14/07, Chad P. [email protected] wrote:
On Sun, Apr 15, 2007 at 01:27:28AM +0900, M. Edward (Ed) Borasky wrote:
But what I’d really like is a language and an implementation of that
language that was an IDE! The closest thing to that I’ve ever seen is
the intricate entwining of Lisp and Emacs, and that, in a kind of
linear, one-dimensional, “auditory” way, is the core concept. But expand
that – data structures other than the linked list, two-dimensional and
three-dimensional diagrams, color, stereo sound, animation. And, of
course, it needs to be open source.
Isn’t that what Smalltalk does? It combines the language and the IDE in
one convenient package.
Most, but maybe not all, Smalltalk implementations combine the
language, the run-time and the development environment. In typical
Smalltalk implementation:
-
The compiler is written in Smalltalk, methods are compiled to
objects (usually instances of a class called something like
CompiledMethod which contains a reference to the compiled byte codes,
and information about the bindings of references to local variables
and the like.
-
The tools run in the same execution environment as the application.
The information needed by the compiler and other development tools is
kept by Smalltalk objects which model the code (Classes, Metaclasses,
Behavior, CompiledMethods). The IDE can do things like get a list of
all implementors of a particular method selector, or all the methods
which invoke that selector by querying the run-time environment. The
source code is located through these objects as well. One of the
things which newbies to Smalltalk find strange is that there are no
explicitly edited source files. In the original Smalltalk-80
implementation, source code was kept in a changes-log file and methods
had a pointer into that file so that they could find their source.
Often this is supplanted by a shared source database which provides
SVN like function. EnvyDeveloper which worked with a variety of
Smalltalk implementations including (Smalltalk/V, VisualWorks (later
merged), and IBM Smalltalk) was the most popular implementation of
this.
-
Another thing which some find strange is that the run-time state is
persistent and is saved as an image. You can terminate Smalltalk,
restart it and you’re right back where you were, complete with any
existing instances of objects, suspended threads (Smalltalk calls them
Processes) etc.
-
The reflection capabilities in Smalltalk are more powerful than in
Ruby, this enables quite a few of the tools. Smalltalk programs can
reflect not only on the class definitions and other semi-static
properties, but can also reflect on and manipulate the run-time
execution state. As an example of the difference, in Ruby, although
one can access a representation of the current process stack frame
using Kernel#caller, this representation is textual and only really
describes which methods are on the stack. In Smalltalk the process
stack can be examined in detail, and manipulated (usually by the
debugger, which like all of the other Smalltalk development tools is
written in Smalltalk). In the Smalltalk debugger you can do things
like change the values variables, or even change the source of a
method and recompile it, then resume execution from the point of
change. For efficiency the VM only reifies stack information as
objects when it is needed, but the key is that a rich set of
information about the run-time is available as objects.
This approach has it’s plusses and minuses, but for many it’s the
sine-qua-non of what constitutes an INTEGRATED Development
Environment.
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Rick DeNatale wrote:
course, it needs to be open source.
CompiledMethod which contains a reference to the compiled byte codes,
things which newbies to Smalltalk find strange is that there are no
persistent and is saved as an image. You can terminate Smalltalk,
using Kernel#caller, this representation is textual and only really
describes which methods are on the stack. In Smalltalk the process
stack can be examined in detail, and manipulated (usually by the
debugger, which like all of the other Smalltalk development tools is
written in Smalltalk). In the Smalltalk debugger you can do things
like change the values variables, or even change the source of a
method and recompile it, then resume execution from the point of
change. For efficiency the VM only reifies stack information as
objects when it is needed, but the key is that a rich set of
information about the run-time is available as objects.
A lot of this sounds like what Business Basic has been doing for over 20
years. Along with being able to modify code and variables while running
a program you can also tell the program to go back to an earlier
statement before continuing, this makes it very easy to debug a program
and make sure that any changes you make work.
Another thing that I really like about Business Basic is that it has
screen handling for normal 80 character by 24 character displays built
in so that you don’t have to work with a third-party add-in like curses.
It also has integrated flat file handling built in, again obviating
the need for add-ins like C-Tree.
On Tue, Apr 17, 2007 at 07:05:05AM +0900, Tim X wrote:
Getting back to Ruby, I have to say, the more I use this language the more I
like it. I got into a bit of perl’s OO some years back, which at the time, I
liked in preference to using Java. However, I really do think ruby has gotten
the whole OO stuff nailed, particularly from the perspective of a scripting
language. Despite my contributions to threads on IDEs etc, I have to say that
using ruby and emacs is for me a nice environment. I can see potential for an
even more powerful integrated emacs+ruby environment and once I get a better
appreciation of the language, may even try and see about using my emacs
knowledge/experience to contribute to the ruby mode for emacs.
That’s really saying some awful things about Java – not that I’m
all that surprised. Perl’s OO is ugly as sin (and I’m a fan of Perl,
saying this). Sure, it’s not as awful as PHP’s and VB’s OOP features,
but it’s not exactly elegant by any stretch.
I must agree that, judging by my own experience, Ruby really does get
object oriented programming substantially “right”.
On 16-Apr-07, at 8:53 PM, Chad P. wrote:
language. Despite my contributions to threads on IDEs etc, I have
all that surprised. Perl’s OO is ugly as sin (and I’m a fan of Perl,
saying this). Sure, it’s not as awful as PHP’s and VB’s OOP features,
but it’s not exactly elegant by any stretch.
I must agree that, judging by my own experience, Ruby really does get
object oriented programming substantially “right”.
Without hijacking this thread and making it about prototype
languages, I really do find statements like this cute (not
necessarily funny, but cute). While Ruby’s Classes (and Smalltalk’s
too) are just objects, it seems weird to me to separate the two
concepts. So any statement like that makes me wonder what kind of
exposure to object-oriented languages one has–or rather, lack of
exposure to many.
“Rick DeNatale” [email protected] writes:
and information about the bindings of references to local variables
explicitly edited source files. In the original Smalltalk-80
restart it and you’re right back where you were, complete with any
describes which methods are on the stack. In Smalltalk the process
sine-qua-non of what constitutes an INTEGRATED Development
Environment.
I’ve never done smalltalk, but a lot of what you have written reminds me
of
some of the lisp environments I’ve used.
One of the things I grew to love in lisp and have often missed in other
languages is conditional restarts and error trapping. It is one of the
few
languages I’ve used that really gives you the ability to step back, make
changes and recover rather than simply ‘trap and report’.
Getting back to Ruby, I have to say, the more I use this language the
more I
like it. I got into a bit of perl’s OO some years back, which at the
time, I
liked in preference to using Java. However, I really do think ruby has
gotten
the whole OO stuff nailed, particularly from the perspective of a
scripting
language. Despite my contributions to threads on IDEs etc, I have to say
that
using ruby and emacs is for me a nice environment. I can see potential
for an
even more powerful integrated emacs+ruby environment and once I get a
better
appreciation of the language, may even try and see about using my emacs
knowledge/experience to contribute to the ruby mode for emacs.
Tim
Eric P. wrote:
We use the ruby-debug-base.rb and ruby-debug.so, and call it like any
other Ruby library. This way people can install an upgrade and
Komodo
should just work with the new .so, assuming no compatibility
breakage.
I wouldn’t say there’s too much duplication – you just have to
implement a callback class to handle the ruby-debug events.
By duplication I meant several different extensions for ruby-debug-base
with the same aim.
I would like to implement DBGp (ruby-debug-dbgp?) extension for
ruby-debug-base in the future if nobody else do so in the meantime. That
would be easily utilized by any frontend then. Currently Markus
Barchfeld implemented ruby-debug-special_xml_based_protocol extension
for ruby-debug-base which is also pretty frontend-independent.
I think that ideal state would be to have one debugger backends central
utilized by all frontends and all peoples from frontends would work
together on those backends. E.g. in the Rubyforge’s debug-commons
project 
m.