 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.08.2012 10:31, schrieb Invisible:
> And, as I keep pointing out, that isn't what I said. I said the core
> language design is simple and clean.
The thing is that this is NOT what you said (or rather, what you
implied). Your claim was (or appeared to be) that Haskell is simple and
elegant AND a "solution for everything".
We keep disputing the latter, while you keep insisting on the former
(which we're not disputing in any way).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> And, as I keep pointing out, that isn't what I said. I said the core
>> language design is simple and clean.
>
> The thing is that this is NOT what you said (or rather, what you
> implied). Your claim was (or appeared to be) that Haskell is simple and
> elegant AND a "solution for everything".
>
> We keep disputing the latter, while you keep insisting on the former
> (which we're not disputing in any way).
It seems the confusion here is "solution for everything".
It seems you guys think that I meant "every possible computing task that
can ever exist". Obviously Haskell does /not/ solve every such problem.
Indeed, it doesn't solve /most/ of them, due to the much-discussed
extreme lack of libraries. Want to load a JPEG image? Good luck with
that. I could come up with dozens of other examples off the top of my head.
What I meant was to contrast Haskell against C# and languages like it.
With most mainstream languages, somebody will be writing a program, and
find that some facet of it is really awkward to structure. Basically,
the language doesn't solve that well. So they invent yet another new
feature to solve that problem - or rather, to solve one particular
instance of it. And then later somebody else invents another, in
compatible, new feature to solve a slightly different instance of it.
And so, after a few decades, we have a feature-encrusted language which
/still/ doesn't solve all the problems.
The "problems" that I was discussing are not "can I interact with legacy
systems?" or "have I got good multimedia support?" or "does my toolchain
support distributed processing well?" Rather, I was talking about
problems such as "can I express the core application logic in a robust,
maintainable, bug-free way?"
Object-oriented programming was supposed to make everything polymorphic
and wonderful. But then they discovered the container problem, so they
invented generics. And then they figured out that sometimes, you want
multiple inheritance. So they invented multiple inheritance, and decided
to not use it and have "interfaces" instead, for no really defined
reason. And then they decided that having eight-billion interfaces like
"Runnable", "ScrollEventListener", "DragEventListener",
"CheckBoxEventListener" and so on was just stupid. So Eiffel invented
"agents", C# invented "delegates", and Java offered the "reflection
API"; all of them different attempts to solve the same language design
problem.
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.
[OK, I take that back: Records with named fields is a joke in Haskell.
But the language solves everything /else/ pretty damned well.]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.08.2012 13:02, schrieb Invisible:
> The "problems" that I was discussing are not "can I interact with legacy
> systems?" or "have I got good multimedia support?" or "does my toolchain
> support distributed processing well?" Rather, I was talking about
> problems such as "can I express the core application logic in a robust,
> maintainable, bug-free way?"
And here here we are maintaining that how best to express the core
application logic in a robust, maintainable, bug-free way depends on the
type of problem the application is supposed to solve.
If you are tied to a particular language, then for some problems you
WILL end up with writing libraries, metaprogramming tools and the like,
and you're actually no longer programming in that language - you're only
using it as glue code here and there. (Provided you do aim for that
robust, maintainable, bug-free way of expressing stuff of course.)
> Object-oriented programming was supposed to make everything polymorphic
> and wonderful. But then they discovered the container problem, so they
> invented generics. And then they figured out that sometimes, you want
> multiple inheritance. So they invented multiple inheritance, and decided
> to not use it and have "interfaces" instead, for no really defined
> reason. And then they decided that having eight-billion interfaces like
> "Runnable", "ScrollEventListener", "DragEventListener",
> "CheckBoxEventListener" and so on was just stupid. So Eiffel invented
> "agents", C# invented "delegates", and Java offered the "reflection
> API"; all of them different attempts to solve the same language design
> problem.
I think you're getting the order of events somewhat wrong here.
Anyway - at present it looks like function-oriented programming is
supposed to make everything functional and wonderful now. But what
problems will they discover (if they haven't done so already and you
just haven't heard of it yet)? I betcha there will be quite a few and
then some, just like with every other programming paradigm we've had so
far under the sky.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> And here here we are maintaining that how best to express the core
> application logic in a robust, maintainable, bug-free way depends on the
> type of problem the application is supposed to solve.
OK. But if you have an inflexible language, then you have only one way
to express your solution. And if that isn't a good way for a certain
problem, things get tricky. If you have a powerful and expressive
language with the flexibility to support multiple ways to solve the
problem, it's far more likely you can find one that works well. No?
> If you are tied to a particular language, then for some problems you
> WILL end up with writing libraries, metaprogramming tools and the like,
> and you're actually no longer programming in that language - you're only
> using it as glue code here and there. (Provided you do aim for that
> robust, maintainable, bug-free way of expressing stuff of course.)
And this is bad somehow?
> Anyway - at present it looks like function-oriented programming is
> supposed to make everything functional and wonderful now. But what
> problems will they discover (if they haven't done so already and you
> just haven't heard of it yet)? I betcha there will be quite a few and
> then some, just like with every other programming paradigm we've had so
> far under the sky.
From what I've seen, "every other programming paradigm so far" has been
ad hoc without much in the way of a strong, consistent theoretical basis.
I mean, take SQL. It solves only one problem, but it solves it so damned
well that it is basically the /only/ language of its type. And oh look,
it's based on a theoretical model. Funny coincidence, that...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.08.2012 16:34, schrieb Invisible:
>> Anyway - at present it looks like function-oriented programming is
>> supposed to make everything functional and wonderful now. But what
>> problems will they discover (if they haven't done so already and you
>> just haven't heard of it yet)? I betcha there will be quite a few and
>> then some, just like with every other programming paradigm we've had so
>> far under the sky.
>
> From what I've seen, "every other programming paradigm so far" has been
> ad hoc without much in the way of a strong, consistent theoretical basis.
Structured paradigm being ad-hoc? Don't think so. It's the result of
people wrecking their brain about what was wrong with their previous
coding approaches, and revolutionizing the world of software development
with essentially just ONE strong rule.
OO paradigm being ad-hoc? Don't think so either; it only got ad-hoc the
moment it left the realm of scientific studies and entered the realm of
real-world hype.
Finite state paradigm? DEFINITELY has a well-analyzed, theoretical basis.
Actually, I can't think of how a programming paradigm could be ad-hoc
without a consistent theoretical basis; I mean, that's why it is called
a /paradigm/ rather than just coding style or some such.
Maybe you're confusing programming paradigms with programming languages
here.
Yes, virtually ALL mainstream programming languages have something
ad-hoc-ish about them, in how they're not strictly adhering to any
single programming paradigm.
But wait... maybe that's why they ARE mainstream after all - because you
can mix & match different paradigms with just one language? You know,
solve the different parts of the software in the way that's most suited
to each one. Get around some problems with one paradigm by offering
alternative paradigms to base your software (or module) design on.
After all, for practical purposes it is perfectly irrelevant whether
your language is simple and elegant at its core - all that matters is
whether it can solve YOUR problems in a way that YOU can wrap your
brains around after a reasonable amount of training.
Oh, wait... you're probably right: C# sucks - for YOU. Because if
everything you're familiar with are dremel tools, the cassic cluttered
tool box will look extremely unelegant and inefficient to you.
Speaking of wrong tools for the job, here's a mandatory viewing. No, not
hammers this time:
http://www.youtube.com/watch?v=WxxG0faDT_M
> I mean, take SQL. It solves only one problem, but it solves it so damned
> well that it is basically the /only/ language of its type. And oh look,
> it's based on a theoretical model. Funny coincidence, that...
Yeah, strange though that they didn't use a functional paradigm for
those databases...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> From what I've seen, "every other programming paradigm so far" has been
>> ad hoc without much in the way of a strong, consistent theoretical basis.
> Actually, I can't think of how a programming paradigm could be ad-hoc
> without a consistent theoretical basis; I mean, that's why it is called
> a /paradigm/ rather than just coding style or some such.
>
> Maybe you're confusing programming paradigms with programming languages
> here.
Yeah, perhaps.
> Yes, virtually ALL mainstream programming languages have something
> ad-hoc-ish about them, in how they're not strictly adhering to any
> single programming paradigm.
The thing is, there /are/ programming languages which stick consistently
to one programming approach. Unfortunately, it tends to be the mish-mash
languages which have backwards compatibility to all the pre-existing
crap that tend to be popular.
> But wait... maybe that's why they ARE mainstream after all - because you
> can mix & match different paradigms with just one language? You know,
> solve the different parts of the software in the way that's most suited
> to each one. Get around some problems with one paradigm by offering
> alternative paradigms to base your software (or module) design on.
I would argue that it's just because they continue the poor design
choices that came before. Half the complexity in C++ is due to backwards
compatibility with C. Java and C# just copy the syntax from C++. Visual
Basic even has "basic" in the name. And so on.
> After all, for practical purposes it is perfectly irrelevant whether
> your language is simple and elegant at its core - all that matters is
> whether it can solve YOUR problems in a way that YOU can wrap your
> brains around after a reasonable amount of training.
Sure. And having a complicated, messy language which lacks internal
consistency makes it so much easier to learn. Oh, wait...
> http://www.youtube.com/watch?v=WxxG0faDT_M
When I hear [yet another] story about people storing XML in the database
rather than change the schema, this is what I think it sounds like.
>> I mean, take SQL. It solves only one problem, but it solves it so damned
>> well that it is basically the /only/ language of its type. And oh look,
>> it's based on a theoretical model. Funny coincidence, that...
>
> Yeah, strange though that they didn't use a functional paradigm for
> those databases...
Functional programming is a model of computation, but databases don't
compute anything. They just store stuff. Far more logical to use a model
of knowledge for that, no?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.08.2012 10:57, schrieb Invisible:
>> But wait... maybe that's why they ARE mainstream after all - because you
>> can mix & match different paradigms with just one language? You know,
>> solve the different parts of the software in the way that's most suited
>> to each one. Get around some problems with one paradigm by offering
>> alternative paradigms to base your software (or module) design on.
>
> I would argue that it's just because they continue the poor design
> choices that came before. Half the complexity in C++ is due to backwards
> compatibility with C. Java and C# just copy the syntax from C++.
Definitely NOT. They do copy the syntax from C (not C++) for the short
imperative snippets, but that's about it.
They also do make some features of their language /look/ akin to similar
C++ features, like C# generics vs. C++ templates. Again, they're totally
different breeds there though. Even exceptions are fundamentally
different, in that both Java and C# require the thrown exception to be
of a special type.
I don't know a single feature of the C++ language (aside from what's
also available in C) that also features in Java and/or C# in the same
way. Well, maybe line comments - but even the C++ line comments also
feature in C99.
>>> I mean, take SQL. It solves only one problem, but it solves it so damned
>>> well that it is basically the /only/ language of its type. And oh look,
>>> it's based on a theoretical model. Funny coincidence, that...
>>
>> Yeah, strange though that they didn't use a functional paradigm for
>> those databases...
>
> Functional programming is a model of computation, but databases don't
> compute anything. They just store stuff. Far more logical to use a model
> of knowledge for that, no?
See?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/20/2012 1:31, Invisible wrote:
> You said C# lets you call arbitrary machine code as easily as calling
> another C# function. I said it doesn't.
Assuming it uses one of the calling conventions that C# understands, then
yes, it does.
> You cannot pass arbitrary Haskell expressions to C. You can only pass
> primitive data types that C understands. (Things like int or long or void*.)
> If C needs to access Haskell stuff, you write Haskell functions that inspect
> the Haskell stuff and return something that C understands, and then have C
> call that.
So it's hard to call across the boundaries there.
>> And of course
>> if the C isn't actually a function in the functional sense, I'm not sure
>> how Haskell handles it.
>
> If the code you're trying to call has no observable side effects (e.g.,
> sinh() or something) then you mark it as a pure function. If it /does/ have
> observable side-effects, then you mark it as an I/O action, and handle it
> the same way as any other I/O action. Really, it's not hard.
OK, cool.
>> For example, it's really not obvious how easy it
>> would be to invoke a C function that takes as one of its arguments a
>> pointer to a function.
>
> Do you remember that time I used the C sort() function to work a Haskell
> data structure? Do you remember how I don't even know all that much about C,
> and yet it only took me about 20 minutes to figure it out?
>
> Seriously, it's not "trivial". But it's pretty damned simple.
OK. Again, note that I didn't say it's not easy. I said it's not obvious to
me how easy it is. I don't know Haskell very well, remember?
>>> JavaScript is a language invented for controlling web browsers. I
>>> don't know of anything else that runs it.
>>
>> There are lots of other applications that have incorporated javascript.
>
> Really?
I gave you a wikipedia link to a giant list, even! :-)
> Haskell is statically typed. But there's a library for doing stuff with
> dynamic types. Basically, it lets you convert any suitable value to a
> special "Dynamic" type. You can then later try to cast it back to something
> else, which succeeds iff that is actually the correct type. You know, the
> usual deal.
OK. Still a bit clunkier than C#. :-)
> At worst, if you wanted to talk to something dynamic, you could just mark
> every single thing it touches is "type unknown" until you try to do
> something with it. It isn't that hard.
It sounds more clunky than difficult.
--
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/20/2012 4:02, Invisible wrote:
> Object-oriented programming was supposed to make everything polymorphic and
> wonderful.
Uh, no.
> But then they discovered the container problem, so they invented
> generics.
The container problem you describe is only a problem for statically typed
languages.
> they decided that having eight-billion interfaces like "Runnable",
> "ScrollEventListener", "DragEventListener", "CheckBoxEventListener" and so
> on was just stupid.
It was always stupid, and most languages don't need that.
> So Eiffel invented "agents", C# invented "delegates",
> and Java offered the "reflection API"; all of them different attempts to
> solve the same language design problem.
The reflection API has nothing to do with delegates or agents. Indeed, C#
has a reflection API also.
> 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, which also solves all of it with the same level of
constructs. But the stuff you're complaining about in C# isn't the core
language either. Threads and the reflection API aren't part of the "core
language" of C# 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/20/2012 7:34, Invisible wrote:
> And this is bad somehow?
Yes. Quite a bit.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
