I’ve just been re-reading Byte August 1981 - an edition dedicated to
Smalltalk-80. Often people say Ruby has roots in Smalltalk (amongst
other things) but the thing you notice is Smalltalk is visual ie it has
a graphical interface. How is it that 28 years later we work by typing
text into an editor?
Hi,
Am Donnerstag, 30. Jul 2009, 18:23:54 +0900 schrieb Mike S.:
I’ve just been re-reading Byte August 1981 - an edition dedicated to
Smalltalk-80. Often people say Ruby has roots in Smalltalk (amongst
other things) but the thing you notice is Smalltalk is visual ie it has
a graphical interface. How is it that 28 years later we work by typing
text into an editor?
Learn the Vim editor and you know the differences. Sorry.
Bertram
On 30.07.2009 11:23, Mike S. wrote:
I’ve just been re-reading Byte August 1981 - an edition dedicated to
Smalltalk-80. Often people say Ruby has roots in Smalltalk (amongst
other things) but the thing you notice is Smalltalk is visual ie it has
a graphical interface. How is it that 28 years later we work by typing
text into an editor?
I do not know a programming language for which the basis is not text.
So, text usually comes first and then there are tools which help you
produce this text. This is actually a quite nice separation IMHO
because you can pick the type of tool you prefer (text editor, UML,
integrated IDE, GUI builder).
Despite the old fashionedness of typing text that your question suggests
there seem to be quite many people which are happy typing program code
with a text based tool. In Ruby it is actually quite easy compared to
other programming languages because of the clean syntax which helps a
lot reduce the overhead (just think of all the semicolons in Java…).
Kind regards
robert
How is it that 28 years later we work by typing
text into an editor?
I once asked people on the Squeak smalltalk list about using Squeak
for scripting purposes and little apps that run from the command line
etc. The most sensible advice was to use ruby (they didn’t even
suggest to use GNU Smalltalk). This really isn’t an answer to your
question but could provide a hint as to why.
Mike S. wrote:
I’ve just been re-reading Byte August 1981 - an edition dedicated to
Smalltalk-80. Often people say Ruby has roots in Smalltalk (amongst
other things) but the thing you notice is Smalltalk is visual ie it has
a graphical interface. How is it that 28 years later we work by typing
text into an editor?
This is because “all” languages are text based.
There was one attempt at a language that plugged together data flow
pipes. I can no longer remember the name.
It had devices that converted files into sequences and others to
generate sequences of numbers. These were filtered and processed to
generate other sequences, that were finally converted back into files
(some on paper). It all worked by pulling data. The sort would wait
until the report requested the first record, when it would suck in all
the incoming data, sort it, and return the first record, leaving
internal status ready to return later records when (and if) required.
It failed. The following reasons contributed I think.
Pulling the data through the structure is not sufficient. Some
junctions need storage. This led to some unexpected restrictions on what
could be written, with no easy way to overcome these.
The obvious implementation of one process per widget was horrendously
inefficient on the hardware of the day (286/386 era IIRC). Green threads
may have worked better.
The trade-off between time and memory use was hard to discern so it
was easy to create programs that either ran for ages or ran out of
memory. IIRC the price was high (for unproven technology, that had no
obvious market).
Attempting to change the paradigm of programming is hard (and
fascinating).
Regards
Ian
Ian H. wrote:
There was one attempt at a language that plugged together data flow
pipes. I can no longer remember the name.
Fantastic. That would let you store all programs as graphs, which could
be serialised as big blobs of XML for ultimate portability. Programming
could then become as simple as this:
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#_Toc164738480
(scroll down a little to see the examples)
A ‘while’ loop could be accomplished with just a few dozen clicks of the
mouse:
http://www.activebpel.org/samples/samples-2/BPEL_Samples/Resources/Docs/while.html
Mike S. wrote:
How is it that 28 years later we work by typing
text into an editor?
Color coded text helps some.
There are database programs that have/had a GUI, although you’d have to
type in the conditions. I tried one maybe 15 years ago on the Mac. I
still found FileMaker easier and I’m not a programmer.
A visual program gets to be a mess and hard to navigate.
in the media/audio/video, what is called “dataflow” is a very popular
paradigm.PureData is a good open source example of it:
http://puredata.info/
but still, these dataflow environments have provision for script/code
boxes
to be integrated with the rest of the flow, because in the end, certain
things are really easier to do with a couple of words in a text file.
for pure programming, I heard recently of flow based programming as a
forgotten programming paradigm which could solve many of the problems we
nowadays face with OO:
http://jpaulmorrison.com/fbp/
L-P
2009/7/30 Brian C. [email protected]
On Jul 30, 10:11 am, Brian C. [email protected] wrote:
Ian H. wrote:
There was one attempt at a language that plugged together data flow
pipes. I can no longer remember the name.Fantastic. That would let you store all programs as graphs, which could
be serialised as big blobs of XML for ultimate portability. Programming
could then become as simple as this:
But if we’re going to the point of serializing the program as XML, why
not take the next logical step on simplify the XML in S expressions?
Wait…
I programmed in Smalltalk in the 80s, and I loved it. But, Smalltalk
was a
terrible neighbor, it did not interact well with the other software on
my
computer or my network. Everything had to be Smalltalk’s way or
nothing.
When Ruby came along 10 years later, I was impressed by how careful the
developer was to play well with all the neighbors, even if this meant
forgoing the fancy IDE. In my opinion, this allowed Ruby to grow and
become
useful in so many different domains, whereas Smalltalk was stuck on the
very
expensive engineering workstations.
In my opinion, it is much easier to learn Ruby with a good book
(Pickaxe)
and a command line, than to try to convince your boss that you need that
new
$$ workstation.
2009/7/30 pharrington [email protected]
not take the next logical step on simplify the XML in S expressions?
Wait…
–
Regards,
Ken
Seek wisdom through disbelief
pharrington wrote:
On Jul 30, 10:11�am, Brian C. [email protected] wrote:
Ian H. wrote:
There was one attempt at a language that plugged together data flow
pipes. I can no longer remember the name.Fantastic. That would let you store all programs as graphs, which could
be serialised as big blobs of XML for ultimate portability. Programming
could then become as simple as this:But if we’re going to the point of serializing the program as XML, why
not take the next logical step on simplify the XML in S expressions?
Wait…
You are Pascal J. Bourguignon and I claim my five pounds.
On Thu, Jul 30, 2009 at 5:55 AM, Robert
Klemme[email protected] wrote:
On 30.07.2009 11:23, Mike S. wrote:
I’ve just been re-reading Byte August 1981 - an edition dedicated to
Smalltalk-80. Often people say Ruby has roots in Smalltalk (amongst
other things) but the thing you notice is Smalltalk is visual ie it has
a graphical interface. How is it that 28 years later we work by typing
text into an editor?
Well even in Smalltalk, you typed the program text into browser
windows in the IDE. The browser really is much like most text editors
today with project/file system selection panes, like those in Textmate
or Vim/Emacs given appropriate plugins.
The real difference was how Smalltalk stores/d the source code,
traditionally there were no per-class source code files, code was kept
in a log and the IDE maintained pointers into the log for individual
methods/class definitions. Later, Smalltalk specific
version/configuration control systems like OTI’s Envy/Developer
allowed for easier team development.
Like many things this was a blessing and a curse. Smalltalk at the
time had advanced features for browsing, sharing, and managing code
compared to the state of the art, but it did this in a way which was
incompatible with the state of the art file based techniques.
I haven’t kept up, but recently some Smaltalk advocates have been
working on making environments which are more compatible with standard
practice here.
I do not know a programming language for which the basis is not text. So,
text usually comes first and then there are tools which help you produce
this text. This is actually a quite nice separation IMHO because you can
pick the type of tool you prefer (text editor, UML, integrated IDE, GUI
builder).
There are some, most shrouded in the mists of the past.
For example there were online programming ‘systems’ in the early 1960s
like COLASYL and the Klerer-May system which used special hardware and
represented programs in a ‘natural’ 2 dimensional representation.
For example an ‘ASCII Art’ representation of a formula to calculate
the resistance of two resistors in parallel might be
R x R
1 2
R = ------------
eq R + R
1 2
But with more typographical control over such things as subscripting.
There was also a movement for ‘visual’ programming languages, where
you ‘programmed’ by direct manipulation of graphical objects.
The Apple Cocoa Interface builder is a partial example of this. The
original IBM VisualAge products, (starting with Smalltalk) started
with graphical construction and connection of UI objects along the
lines of the Interface Builder (which goes back to NeXTStep, and
originally to something written in Common Lisp before that) and took
it farther so that doing application logic visually was encouraged.
http://talklikeaduck.denhaven2.com/2007/11/17/cool-but-stupid-things-ive-done
Another example is Self which has an IDE which draw a graphical
network representation of object instances. You add methods to the
instance by typing code into a field associated directly with the
instance.
If you have a Mac you can play with self yourself
http://research.sun.com/self/
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
On Thu, Jul 30, 2009 at 10:59 AM, Ken B.[email protected]
wrote:
In my opinion, it is much easier to learn Ruby with a good book (Pickaxe)
and a command line, than to try to convince your boss that you need that new
$$ workstation.
Of course one of the things that has changed since the 80s is that
today’s $ desktop/laptop is WAY more powerful, has WAY more RAM and
file capacity, and has WAY better graphics capability, than a $$$$$$$
workstation had back then.
The most powerful computer I had back when I was in the IBM/Visualage
team working on Smalltalk was an IBM PS/2 Model 80
http://www.cs.cuw.edu/museum/IBMPS280.html
Look at those specs:
RAM 1-16MB
16 MHz 80386
70 MB Hard drive
Cost: $10,895
Compare that to something like a $1000 low-end MacBook today!
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
For an example of a popular and well-known graphical programming
language,
check out LabVIEW: LabVIEW - Wikipedia
I agree with Bertram. You can take my vim when you pry it from my cold,
dead
fingers. I am far too productive with text editors to code in anything
else.
Robert K. [email protected] wrote:
On 30.07.2009 11:23, Mike S. wrote:
I’ve just been re-reading Byte August 1981 - an edition dedicated to
Smalltalk-80. Often people say Ruby has roots in Smalltalk (amongst
other things) but the thing you notice is Smalltalk is visual ie it has
a graphical interface. How is it that 28 years later we work by typing
text into an editor?I do not know a programming language for which the basis is not text.
Google is your friend:
My favorite was Prograph. It wasn’t just visual, it was dynamic: if you
hit a bug while running, you could just fix it right then and carry on
from the point of the bug (like Smalltalk, really). It was great for
dataflow, but programming a loop of any kind was a pain.
Nonetheless I’m surprised that after all these years we aren’t
programming by assembling parts diagrammatically. I started programming
in 1964 and except for the punch cards nothing much has changed. 
OTOH if we have to be textual, Ruby strikes a very nice balance
between conciseness and legibility. Objective-C or AppleScript are not
just textual, they’re novelistic! m.
On 30.07.2009 16:11, Brian C. wrote:
A ‘while’ loop could be accomplished with just a few dozen clicks of the
mouse:
http://www.activebpel.org/samples/samples-2/BPEL_Samples/Resources/Docs/while.html
Is it just me or did you actually forgot to include a smiley here?
“just a few dozen clicks of the mouse” - typing just a few characters
would be my preferred finger activity then.
Cheers
robert
Mike S. [email protected] writes:
I’ve just been re-reading Byte August 1981 - an edition dedicated to
Smalltalk-80. Often people say Ruby has roots in Smalltalk (amongst
other things) but the thing you notice is Smalltalk is visual ie it has
a graphical interface. How is it that 28 years later we work by typing
text into an editor?
Because Smalltalk, it was in the 5th generation of the Matrix. Now
we’re in the 6th generation, and we’re doing it again almost all the
same. Well, we use Ruby for Smalltalk and Python for Lisp, etc, but
really it’s all the same.
Don’t worry, soon we will see Ruby Graphic Environments and they will
be a big novelty. It’s necessary for the One to become aware and
reset the world once again.
Strangely enough there are some ghosts surviving the previous
generations who still use Smalltalk or Lisp. They’ve got unbelievable
powers.
Have a look at http://www.squeak.org/ and http://www.opencroquet.org
You could also ask “why are we still reading books, when we can see
almost anything in movies or on TV?”.
I don’t think any graphical programming language will ever obsolete
text languages. That would be like we all forgot how to write and
started drawing pictures instead.
I have programmed in LabVIEW, and while it had a very kind learning
curve it became horrible when I tried to do something complicated.
Robert K. wrote:
On 30.07.2009 16:11, Brian C. wrote:
A ‘while’ loop could be accomplished with just a few dozen clicks of the
mouse:
http://www.activebpel.org/samples/samples-2/BPEL_Samples/Resources/Docs/while.htmlIs it just me or did you actually forgot to include a smiley here?
I thought it was sufficiently sarcastic as it was, but I could have been
wrong. Perhaps you’ll like this though:
Mike S. [email protected] writes:
I’ve just been re-reading Byte August 1981 - an edition dedicated to
Smalltalk-80. Often people say Ruby has roots in Smalltalk (amongst
other things) but the thing you notice is Smalltalk is visual ie it has
a graphical interface. How is it that 28 years later we work by typing
text into an editor?
I’ve got also another answer. Perhaps you will find it more serrious,
perhaps not:
That’s because alphabetic text is actually a GIANT PROGRESS, compared
to pictural (parietal) or ideographic modes. It is not 28 years later
that we’re still in text, it’s 4700 years later, and it has still all
the advantages it had over hieroglyphs.
Good students may learn 800 ideograms per year, but even bad students
need only three months (with the alphabetical method) to learn to read
all the words of their language (up to 1,000,000 words or more).
There have been deleterious forces that want to fight literacy,
they’ve been pushing global methods to learn reading alphabetical
language and the only results are that in 2000+ 70% of the pupils
can’t read after 4 years of learning, while in 1900, 95% of them could
read and write very well.
The Graphical User Interfaces are promoted for the same reason.
Notice that chimps can do even better than human on most tasks
involving GUIs…