On 8/27/2012 13:51, Orchid Win7 v1 wrote:
> Did I not already post a link to the on-going project to do precisely this?

I don't know. Honestly, I don't really memorize every Haskell feature you 
talk about. :-)

> Sure. BASIC is a simple language. But it's the "wrong kind" of simple - the
> kind of simple that makes everything wickedly hard to do. Finding the right
> kind of simple? Well, that's pretty hard... But just throwing lots and lots
> of "features" at the problems? That's not really a very good solution.

It depends on your goals for the language. If everything looks the same, it 
can be very difficult to understand some piece of code. Every time I see a 
declaration of an event in C#, I know exactly what it's for and how it 
works. I'm not sure the same semantics would be any simpler if it was in a 
library, and I'm pretty sure you'd wind up with multiple subtly different 
implementations of the same ideas, in a way that wouldn't work together. 
(Which is exactly what happened to every other such language, inclulding 
LISP, Tcl, and FORTH.)

The advantage of having the "normal" stuff built in is that everyone tends 
to use it in preference to one-off functionality in libraries.

For example, FORTH does not have directories, or even files. What's the 
likelihood that you take a disk from one FORTH-like implementation and plug 
it into another FORTH-like implementation and you'll be able to use it?

Remember that the vast amount of difficulty in software engineering in at 
least the business world is the vast numbers of simple interactions with 
other systems. My program (www.google.com/ads/agencyedge/) for example looks 
simple. But it uses... let's see... at least nine languages off the top of 
my head, interacts with 14 services that I know of, oh wait add another 10 
or 12 just to run the damn thing and another five or six languages 
describing where to run it and how to let people connect and such... It's 
all pretty straightforward stuff. There's not a single thing out there I'd 
call "an algorithm." No complex data structures. The hardest individual bit 
of code I've worked out is a distributed processing queue that handles 
failures of processes in progress, on top of a system that offers nothing 
but atomic updates. But nevertheless, it's interacting with literally dozens 
of custom servers (not even counting java libs, the kernel, etc.)  *That* is 
the problem your language has to solve for it to not be a niche language.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message