 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 26.08.2012 10:51, schrieb Orchid Win7 v1:
>> You keep asserting that it's easier in Haskell to do some of these
>> things than it is in Erlang or C#. But you've yet to actually provide
>> any evidence of this beyond vigorous assertions.
>
> 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.
> My argument was never about how much external stuff is available for
> Haskell. My argument was that Haskell is a clean, simple language that
> manages to solve the same problems that other languages can only solve
> using a vast swathe of complicated "features" hard-wired into the language.
Of course it manages to solve the same problems - after all, it's Turing
complete (it is, isn't it?) - and from all I've heard it is indeed a
very clean, simple language. All that's disputed is whether it solves
those same problems as developer-friendly and efficiently as those other
languages with a vast swathe of complicated hard-wired features.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/27/2012 4:33, Warp wrote:
> Darren New<dne### [at] san rrcom> wrote:
>> On 8/20/2012 4:02, Invisible wrote:
>>> Object-oriented programming was supposed to make everything polymorphic and
>>> wonderful.
>
>> Uh, no.
>
> What do you mean? Isn't *everything* in a pure OO language an object (that
> can be inherited from and specialized)?
It was the "and wonderful" I was referring to.
>>> But then they discovered the container problem, so they invented
>>> generics.
>
>> The container problem you describe is only a problem for statically typed
>> languages.
>
> I'm not sure the problem is any better in dynamically typed languages.
Well, if you don't like dynamically typed languages, then generics seems to
be a decent solution. They didn't "discover the container problem then
invent generics."
>>> This is the kind of stuff I'm talking about. All these different languages,
>>> all with lots and lots of "features" for trying to solve stuff. And then
>>> there's Haskell, which consists of just 6 constructs in the entire language,
>>> and solves all of it.
>
>> And Smalltalk
>
> Don't forget Lisp.
None of which are particularly popular. Do you wonder why?
--
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/26/2012 11:15, Orchid Win7 v1 wrote:
> On 26/08/2012 05:45 PM, Darren New wrote:
>> (*) Yes, they would be, because a specific functionality built into the
>> compiler and language are going to be simpler than a hand-crafted
>> library in source code trying to provide the same functionality on top
>> of a generic base.
>
> This is really the central thing I disagree with.
>
> 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.
> 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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
