[FoRK] Programming languages, operating systems, despair and anger

Jeff Bone jbone at place.org
Thu Nov 12 13:15:06 PST 2009


Dr. Ernie writes:

> a) Clean syntax b) Rich basic datatypes c) Functional operations d)  
> Metaprogramming


> Am I missing your point?

While you are are correct in naming these 4 as general facilities  
required, they are the necessary but not sufficient set.  Or rather,  
sufficient but not adequate, kind of like claiming that e.g. almost  
any language is Turing complete therefore there's no benefit to using  
e.g. C vs. assembler.

First point:  Ruby doesn't supply "syntactic closure" over a large- 
enough subset of its data types.  Almost no language does!  I.e.,  
there aren't enough literal data type constructors.  This is *the*  
main advantage of e.g. Rebol over anything else, these days.  The  
ability to simply literally construct various data types directly is  
THE key to resolving a lot of the various impedance mismatches that  
characterize most coding today (cf. Meijer, http://tinyurl.com/yfbal8z  
--- though this is the work that eventually became LINQ, nothing Rebol- 
related.)  (You could argue that homoiconic languages provide this in  
a much more general and powerful way, but if that were true Lisp  
wouldn't have evolved to have strings.  Ironically bash achieves much  
of its power by simply treating *everything* as a string.)

Second point:  A rich standard library (or standard class library)  
isn't the same, expressively, as having a lot of "rich basic  
datatypes" that are supported at the language level.  And even Ruby  
doesn't get particularly further than other similar entrants (Lua,  
Python, I'm looking at you.)  It might have a slight advantage over  
both of those, though I have to say Lua's tables rock the free world.

Third point:  write a program that, when your phone is near your  
laptop at work, checks your security system at the house, determines  
via various heuristics whether there's anyone else in the family home,  
locks the doors remotely if they aren't and arms the alarm, and sends  
you a message (determined by where you're most active --- SMS if  
computer is idle, IM if not idle, copies e-mail in either case)  
indicated that it detected that the last person out (also determined  
heuristically by spanning machines to build a complex "context) forgot  
to lock the door.  Also, if this person was your teenage son, sends  
him a text indicating that he's grounded, gets on his cell provider  
web page and "locks down" his account to strictly-family-and-emergency  
use, and automatically logs into the bank and changes the PIN number  
on his ATM card.  (Where all does this program run?  How does it  
orchestrate all this activity?  Etc.)

That *SHOULD* be simple.  It should be TRIVIAL!

It's not, and it won't be until we start picking apart what all the  
abstractions are and supporting them better.

Re: Shoes...  Shoes is a bright light along the way, not so much  
strictly from a language level, but from recognizing and making a run  
at a large subset of the problem in the first place.  If you get why  
Shoes is cool, and you understand the use case I described above and  
why existing stuff is *essentially* and *fundamentally* prohibitive of  
addressing that in any sensible way, then you can bootstrap your way  
to understanding the kinds of "other things" that belong on your list  
besides (a)-(d).

Sadly, Shoes was actually a kind of back-to-the-future attempt.  It  
was sort of an attempt to get back to the ability to simply put  
together rather interesting, useful, or fun kinds of little graphics  
apps that folks used to build in these little language environments  
like BASIC and Logo and such.  An attempt to build, say, a kind of  
Squeak w/o the cultism.  But we need to not just get back to the  
future --- we need to push the future further along.  At least to the  
*present.*




jb



More information about the FoRK mailing list