5/11 To FP activists on the motd, if currying is such a great idea, why
it's not implemented symmetrically in say Caml? It seems more
natural to treat the arguments of a function more symmetrically.
\_ If by 'symmetric' you mean that if, for example, I have a function
f of two arguments a and b, I should be able to curry on either
a or b, then Ocaml does this using labeled arguments. Caml does
not since it's meant to be a 'minimalist' language. -- ilyas
not since it's meant to be a 'minimalist' language. In conclusion,
RIDE BULLET TRAIN! USE OCAML! -- ilyas
\_ I am looking at it. So far so disappointed.
\_ I think most people who have been programming for a while
have gotten past the 'perfect language' disease. I would be
happy to address specific questions you might have. Or better
yet email me, or drop by #csua. -- ilyas
\_ I am not through with the reading yet, so I could be wrong.
So far, my complaint is the following: (1) rather bad
grammar in general. (2) The use of capitalization and
special characters to signify different kinds of
identifiers at the language level. (3) Field name in
record has file scope. (4) If typing is such an important
aspect of it, it might as well make it optional to be
dynamic, same with patterns. (5) Data structure does not
feel as flexible as it could be. One might as well think
it is C and implemnt cons using record. (6) I am not sure
how ref works, but I certainly miss pointers. Overall,
it seems to be somewhere in the middle from C, Scheme, and
maybe Prolog.
\_ (1) People complain about the syntax. It doesn't
bother me. If it bothers you, Ocaml comes with a
syntax redefinition tool called camlp4 -- you can
change the ENTIRE syntax if you want.
\_ You can write preprocessors to make Fortran look
Lisp, Lisp look like Perl, Perl look like Basic,
Basic look like C, and C look like Fortran.
(2) This is because the language is 'rich.' Perl does
the same thing. I don't really know a better way.
What Ocaml has is better than throwing gobs of parens
at the problem like lisp does. In other words, too
much syntax is better than too little.
\_ ruby i think is as powerful as perl yet has
a very clean syntax, without $ % and bare filehandles
it's as fast as it sounds. -- ilyas
etc. -someone else
\_ It's true that ruby is clean, but this comes with
a price. Everything in ruby is an object, and
it's as fast as it sounds. The other thing about
ruby is that it's dynamically typed, so you need
to distinguish less things at compile time --
this translates into a lot less syntax. Naturally,
dynamic typing makes things slow, also. -- ilyas
\_ No it doesn't. You are wrong on both accounts,
here. There are implementation techniques
to make pure object-oriented languages and
dynamically typed languages perform very
fast.
\_ Sure it does. You may make it better than
what ruby has (no hard accomplishment since
ruby has possibly the slowest implementation
of any language), but you will not be able to
beat a statically typed language because
the compiler simply has less information.
OO is useful, but ruby makes everything an
object, which is convenient but those virtual
function calls do add up. Anyways, if
someone writes a fast ruby compiler, it will
make me happy, ruby is a neat language. A
good thing to ponder, if you ever go to the
'great language shootout' page, is why the
fastest languages there are either C or
statically typed. -- ilyas
\_ You are just wrong here. YMWTG
polymorphic inline cache, or Cecil
\_ Read what I said again. I would be
happy to look at some benchmarks of
Cecil or Self. Self is neat. -- ilyas
\_ Stop being condecending. I wasn't
referring to your complaints about
the Ruby interpreter, but to
your general statements about
dynamically typed and pure OO
languages. Virtual Machines
have access to all the type
information that was available
statically, and in the case of
some type systems, more. With
that info, the VM and generate
type-specific code, in-line away
virtual functions, usw.
\_ I think it's more to shift the burdern from the
parser and compiler to the user. Perl is not a
model for good design.
(3) Yes, I don't like that. There are deeper problems
with structs and typing.
\_ I guess that labels of variant and records are
internally represented as integers. I would be
nice to be able to access them directly. Array
type should have the option of specify size,
both for efficiency and type checking.
(4) I don't understand your reasoning here. Typing
in Ocaml makes me really happy because it catches bugs
for me, and because I know how to get around it if I
need to (Obj.magic).
\_ I am not saying typing is a bad idea. But it would
be nice to have the option (1) to turn it off for
some variables or some types and (2) to delay some
typing until runtime and (3) go (not so much) further
make type a type that one can modifies and manipulate
in runtime. The same goes for pattern. There will
conceptual problems involved, but they are worth the
reward. Plus, most of the logic underlying is
already present in the compiler and just need to
be incorporated in the runtime, if called for by
the program.
(5) Don't understand what you are trying to say. Did
you notice the object system too, and functors? Is the
stdlib bad? What couldn't you find that you would find
in another stdlib?
\_ sorry, haven't got to the object system yet, but
generally I feel that a language should either
provide very elementary data structure that allows
one to describe arbitrary complex ones with relative
ease or provide so many high level data structures
that it is hard to ask more. C and Lisp are
examples of the former, while custom programing
language (Maple, Mathematica, etc) falls with the
latter. OCaml seems to be in the middle, which is
annoying. For example, I haven't seen a set type,
which of course can be implemented with tuple. But
it is not easy to implement efficiently, unless you
employs tricks that seem to defeat many OCaml
principles. Again, I could be just ignorant of some
of the powers of ocaml.
(6) If you really want, you can play with pointers using
Obj.magic (again), but you probably don't need them.
Very few people these days need pointers (actual integer
values) over references (names referring to objects) in
practice. -- ilyas
\_ somehow I couldn't find documentation for Obj.magic
but it sounds like something bad that if you use all
the time, you might as well use another language. |
http://csua.com/feed/