On 15/05/2011 3:55 AM, john skaller wrote:
In the sense I used it to describe Java "Rubbish" is perjorative. I withdraw it
with the
comment that I am unhappy billions of dollars were spend by Sun to promote a
language
which was a major backward step in computing - in my opinion. Sorry for being
emotional on the issue, I not only care about programming languages I have
devoted
my life to it (and I think, largely wasted my time).
I care about them too, and have likewise devoted much time to them, but
I guess I see them as a field of great (and often very pretty)
"ecological diversity", not a process to discover the One True Way.
I don't even mind Java that much, though I think they shipped before
they were ready and greatly overdid the design pattern thing in their
standard library. Java demonstrated a few really important points to
language designers and users alike:
- We really were wasting a whole lot of time chasing memory errors!
- Tooling matters a lot. The IDEs are incredible.
- Fast compilation is mostly a matter of compilation model.
- Well defined primitive types are handy.
- There's a large class of business programmers who value
predictability over many other features.
- The line between dynamic and static language is blurrier than
everyone was saying.
Maybe some of these were lessons well known to the lisp camp, but some
weren't, and in any case "lisp people know X" is seldom the final word
that needs to be written. I am sometimes sad that java got as much
attention as it did, when other pretty languages did not, but maybe
that's just the price of "anything going mainstream".
"Mandatory" means necessary and is therefore not perjorative.
The context should have been clear: I believe polymorphism is paramount
and the argument -- which could be false of course -- that multi-argument
functions need to be removed.
I don't know if there's a single concern I hold to be "paramount" in
rust, but if I had to pick one it'd be "safety", which really isn't at
play here. Polymorphism is by no means a dominant concern for me. It's a
nice thing to support where and when we can, in whatever senses seem
reasonable, and when we can't everyone knows how to work around its
absences.
(I don't even think in general it's a well-defined term. There are
several perfectly valid senses to the word, and some of them are at odds
in implementation technique. How do multimethods, overloading, subtyping
&c fit into your worldview?)
Of course if you don't agree polymorphism is important, you're not accepting
the premise, so that's fine. And if my argument is incorrect I'd love to have
that demonstrated.
Ok. Demonstration A: every language with less-than-Ideal (in whatever
sense you mean) polymorphism but perfectly usable pragmatics, currently
having millions of lines of code written in it every day. Code that
ships and works and is not totally worthless. See language list below...
Please understand: I wrote the article in attempt to prevent yet another
language
making a serious mistake, and thereby forfeiting all its good features.
Rust has many good features and some interesting ones (like the 3 level
memory management system).
I'm afraid I don't see how some loss of compositionality (or
polymorphism) equates to forfeiting all good features. You've made it
sound like you don't think any language that fails on this point is
usable at all. Yet I've read and written code in dozens of languages
that don't do what you advise. Indeed, of the influences on rust I can
name off hand (nil/hermes, newsqueak/alef/limbo, C, C++, python, lisp,
ada, C#, clu, mesa, eiffel/sather, ml, D, erlang) I don't think more
than a couple did what you're demanding, yet they all seem quite usable
to their respective communities. How do you get from "lack of
compositionality" to "forfeit all other features"?
As I tried to explain I think you can keep aliases, and it will have the
desired effect *most* of the time even with tuples. If you're willing to throw
out a few cases, you can go with tuples.
Really? It sounded like something quite different to me: that the
pragmatics of making a function call would change to entail implicit
heapification on every library boundary. That would further entail:
- Making calls to precompiled libraries using pointers less
efficient than just passing by value (!), unless we..
- Overhauled the whole compilation model to stick a copy of the
text (say, pickled AST) in each library and rebuilt it every
time we built final binaries. Compile times shoot up and we've
got the C++ "recompile libstdc++ each time" system.
- Also we could never do varargs.
- Also we could never do keyword args.
- Also mutable values would become significantly more mysterious
because the compiler sometimes inserts copy-to-heap operations
that change where the mutable thing is located.
- Also the semantics of destructors and/or gc would change because
we'd have phantom copies of things being synthesized by the compiler
that we'd have to decide when and how to dispose of.
IOW it would change a lot of quite major pragmatics of the language. I
recognize that some compositionality of function types is being lost
here, but I simply don't think the mathematical abstraction of a
function with a single, purely compositional domain-and-range is an
adequate model of what real programmers want to be doing (and are
accustomed to doing elsewhere).
I do think it's a model of a subset of what programmers want to be
doing, and we support that model adequately. We have tuple types and
inferred parametric polymorphism of a sort, and you can write your
functions as pure and composable in FP style. We'll certainly ship FP
bits to support this style in the standard library, as C++ increasingly
does. I don't think C++ failed here at all; I don't think it's essential
to convert *everything* to FP style to reap some of the benefits of it
in some cases, and in cases where it's not a benefit it can be set aside
in favour of a more appropriate style.
I'm a pluralist and intend the language to support writing in multiple
styles. That includes FP, but it doesn't mean that the considerations of
FP get to throw out the considerations of other styles to make sure
everything composes perfectly in FP style.
I may be wrong. Maybe it isn't just a few cases. But I think it is worth
investigating
because you're paying huge price. unfortunately it isn't the kind of balance
than can be quantified.
I agree it's very hard to quantify these things. It's a trade between
compositionality and several other factors (predictability, performance,
FFI, compiler complexity, compilation model, various non-tuple-like
features) few of which are obvious or even visible in the FP worldview.
I realize there's some compositionality being lost here, but like
orthogonality, do not think it the sole concern.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
