 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/19/2012 3:13, Orchid Win7 v1 wrote:
>>> You wouldn't be able to do this for arbitrary code.
>>
>> And that's what I'm talking about. If you want your program to run 15
>> years without ever stopping, you pretty much need to be able to replace
>> arbitrary bits of code, including type signatures, while you're running.
>
> And if this was a problem for your application, you would write it in such a
> way as to facilitate doing this.
Except it's exponentially harder if your language doesn't support it.
For example, there's STM for C#. But it's tremendously harder to make it
work, because C# supports arbitrary mutations of variable values. You
*could* make it work, with enough strictures, but it's not worth it.
> (And, again, if somebody wanted this, you could probably come up with a
> Haskell implementation that supports it natively. It's just that nobody has.
> It would take some design work, but I think you could do it without changing
> the language itself.)
See STM on C#.
> Implementing an Erlang interpreter in BBC BASIC would be hellishly
> difficult. Doing it in Haskell wouldn't be all that hard. That's the
> difference.
We're not comparing Haskell to BBC BASIC. The point I'm making is that many
of the decisions in Erlang were made to support this sort of long-running
self-healing software. Yes, you could do the same thing in Haskell, but then
it would look like Erlang. I could do the same thing in C# by writing an
Erlang interpreter in C# and linking in a bunch of C code for the stuff that
C# can't do natively (like reboot the machine it's running on). But that's
not comparing language strengths. That's just asserting they're turing complete.
--
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 19/08/2012 05:08 PM, Darren New wrote:
> On 8/19/2012 3:13, Orchid Win7 v1 wrote:
>>>> You wouldn't be able to do this for arbitrary code.
>>>
>>> And that's what I'm talking about. If you want your program to run 15
>>> years without ever stopping, you pretty much need to be able to replace
>>> arbitrary bits of code, including type signatures, while you're running.
>>
>> And if this was a problem for your application, you would write it in
>> such a way as to facilitate doing this.
>
> Except it's exponentially harder if your language doesn't support it.
No, it isn't.
It's exponentially harder IF YOUR LANGUAGE SUCKS. If you have a powerful
language, then adding new things is quite easy.
> For example, there's STM for C#. But it's tremendously harder to make it
> work, because C# supports arbitrary mutations of variable values. You
> *could* make it work, with enough strictures, but it's not worth it.
Well, no, that should be quite easy: You have a rule that inside a
transaction, you don't try to do anything observable to the outside
world. If you do, it won't work, and it will be your fault. Problem solved.
The trouble is, they tried to make it so that any arbitrary code can be
run in a transaction. That's impossible. Which is why it didn't work.
You might say "but almost all C# code would be disqualified!" But
remember, the purpose of a transaction is /only/ to coordinate threads.
You don't run the entire application inside STM, just the tiny bits
related to synchronisation.
> The point I'm making is that
> many of the decisions in Erlang were made to support this sort of
> long-running self-healing software. Yes, you could do the same thing in
> Haskell, but then it would look like Erlang.
Would it, now?
Adding features for distributed concurrency and hot code replacement
would make Haskell have crap syntax and weak typing?
No, I didn't think so. :-P
You're aware of the prior art on this subject, I assume? You know about
the project where they managed to actually implement typed message
sending and remote code execution? Transparently? Without altering the
Haskell language at all, just the compiler?
Sure, it didn't do /everything/ that Erlang does. It was only a
prototype. But it refutes the whole "it would make Haskell identical to
Erlang" argument.
> I could do the same thing
> in C# by writing an Erlang interpreter in C# and linking in a bunch of C
> code for the stuff that C# can't do natively (like reboot the machine
> it's running on). But that's not comparing language strengths. That's
> just asserting they're turing complete.
Being able to implement something is one thing. Being able to implement
it /easily/ is another. And that's the goal of designing a good
language: to make stuff easy.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> I very much doubt that C# lets you trivially call arbitrary machine
>>>> code.
>>>
>>> You would be mistaken. It's no harder in C# to call COM or C code than
>>> it is to do so from C++. Machine code? Well, you have to know the
>>> calling convention, but sure, you can do that.
>>
>> It's no harder to call C than to call Haskell, once you define where the
>> hell the function is and what arguments it's expecting. Your point?
>
> I'm not following. You said C# doesn't let you call machine code. I said
> it did.
No.
You said C# lets you call arbitrary machine code as easily as calling
another C# function. I said it doesn't.
> And if Haskell tends to use things like lists extensively, or options,
> or something like that, then yeah, it can be hard to pass such things
> across computation boundaries, let alone lazy expressions.
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.
> 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.
> 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.
> Note I'm not bashing Haskell. I'm simply pointing out the assertion that
> Haskell does everything as well as every other language doesn't sound
> right to me.
And, as I keep pointing out, that isn't what I said. I said the core
language design is simple and clean. I didn't say it has a library for
every possible task. However, the language design itself doesn't rule
out any particularly large possibilities, as far as I can tell.
>> 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?
> For example, MongoDB interprets javascript to decide how to do queries
> and build indexes.
>
> And have you not heard of node.js?
I've /heard of/ node.js; I have no idea what it /is/ though.
>>> Except that JS is dynamically-typed.
>> And Haskell can't manage dynamically-typed code.
>> Oh, wait. Yes it can.
>
> OK. Again, I didn't know that. I thought Haskell is statically typed.
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.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
