>> STM is implementable as an external 3rd party library. (I have personally
>> done this.) And yet, it works beautifully.
>
> OK, now without changing the interface, make it work across process
> address space boundaries. Make it work with machines across the network.

Did I not already post a link to the on-going project to do precisely 
this? (It only "changes the interface" in that it exposes a way to say 
where you want stuff computed.)

>> Just because something isn't hard-wired, doesn't mean it has to work
>> badly or be hard to use.
>
> No. But just because it's simple and elegant doesn't mean it's easy to
> use, either.

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.

Post a reply to this message

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

>>> And Smalltalk
>>
>> Don't forget Lisp.
>
> None of which are particularly popular. Do you wonder why?

Ooo, I think I know this one... Is it because it requires people to 
actually learn new ideas and concepts? Or because it isn't backwards 
compatible with the massive legacy codebases that already exist?

Post a reply to this message

>> And you keep asserting that Haskell is a bad language, without much
>> evidence either. :-P
>
> Nobody is asserting THAT.
>
> What we're talking about is that Haskell, Erlang and C# are each good
> languages for DIFFERENT types of problems.

That different languages solve different problems are hardly a 
contentious assertion - more like a verified FACT.

What I take issue with is the claim that for a language to be useful for 
anything it MUST be complex and badly designed.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >> And Smalltalk
> >
> > Don't forget Lisp.

> None of which are particularly popular. Do you wonder why?

They are too awesome to be handled by mere mortals?

-- 
                                                          - Warp

Post a reply to this message

>>>> And Smalltalk
>>>
>>> Don't forget Lisp.
>
>> None of which are particularly popular. Do you wonder why?
>
> They are too awesome to be handled by mere mortals?

Thanks for filling my daily LOLs quota. :-D

Post a reply to this message

On Tue, 28 Aug 2012 08:27:04 -0400, Warp wrote:

> Darren New <dne### [at] sanrrcom> wrote:
>> >> And Smalltalk
>> >
>> > Don't forget Lisp.
> 
>> None of which are particularly popular. Do you wonder why?
> 
> They are too awesome to be handled by mere mortals?

:)

When I was at uni, we had an 'intelligent' air traffic control program we 
were working on.  The first version was written on a machine that used 
lisp as its shell interface - and you could do weird things like reverse 
the direction the instruction pointer ran using a CLI script written in 
Lisp.

Wish I could remember what the machine was.  It wasn't very fast (this 
was in the 1989-1991 timeframe), but it was pretty amazing tech.

Jim

Post a reply to this message

On 28/08/2012 04:22 PM, Jim Henderson wrote:
> When I was at uni, we had an 'intelligent' air traffic control program we
> were working on.  The first version was written on a machine that used
> lisp as its shell interface - and you could do weird things like reverse
> the direction the instruction pointer ran using a CLI script written in
> Lisp.
>
> Wish I could remember what the machine was.  It wasn't very fast (this
> was in the 1989-1991 timeframe), but it was pretty amazing tech.

Probably one of the various "Lisp machines", I should think... I gather 
there were similar systems powered by Smalltalk.

At uni, we used Smalltalk VisualWorks(tm). The entire environment is 
written in Smalltalk. Which means that with a few simple variable 
assignments, you could TOTALLY SCREW THE SYSTEM. The canonical example is

   Smalltalk := nil.

This causes all the windows to stop repainting and the mouse pointer to 
disappear. The only solution is to terminate the process via Task Manager.

In a less stupid note, one time I was writing an application, and it had 
various "components". Each component is implemented by a class, and I 
tried to add a #name method to return the name of the component...

...oh dears. Yeah, it turns out that Class already *has* a method named 
#name. And by overriding it, I made the system do some *weird* crap... 
It took me ages to figure out what the hell has happening.

A bit like the time I had a method that returns an array constant. It 
turns out it isn't actually constant. So if you mutate the array, you 
now have a method that /appears/ to return one thing, and /actually/ 
returns something completely different. (Until you reload the source 
code from disk...)

Mutable state is evil. :-P

Post a reply to this message

On 8/28/2012 1:29, Invisible wrote:
> Is it because it requires people to actually learn new ideas and concepts?

Nope!  Remember, everyone has to learn new ideas and concepts for their 
first language.  People who learned assembler have to learn new ideas for 
Java, as do people who know C already. Javascript has lots of new ideas and 
it's quite popular.

> Or because it isn't backwards compatible with
> the massive legacy codebases that already exist?

Again, no. Remember that LISP predates COBOL and C++ and probably even C. 
All of that predates Java and Javascript.

-- 
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

On 8/28/2012 1:34, Invisible wrote:
> What I take issue with is the claim that for a language to be useful for
> anything it MUST be complex and badly designed.

Nobody is claiming that.

-- 
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