[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Lisp dinamism vs ML safety

atbusbook

10/16/2006 3:43:00 AM


Jon Harrop wrote:
> Wolfram Fenske wrote:
> > Yeah, yeah, I was only using stuff I found in an OCaml tutorial.
> > While we're at it, in Lisp I might have gotten away with simply using
> > CONS cells and the built-in PUSH and POP macros. This might not be
> > ideal for a production quality application but it might do for a
> > prototype.
>
> In ML, you could get away with list literals and pattern matching:
>
> let empty = [] and push h t = h::t and pop l = hd l, tl l
>
> However, they are purely functional.
>
> > On a similar note, I see a lot of Python code where
> > dictionaries (Python-speak for hash tables) are used instead of
> > classes (Python doesn't have structs so classes would be the only
> > alternative). This is probably because Python's syntax for
> > dictionaries is pretty concise and in a situation where all they want
> > to do is pass around two or three values between a handfull of
> > functions, people think the overhead of writing a class is just not
> > worth it.
>
> Classes are generally the wrong tool for the job in OCaml.
>
> >> The functor approach makes better use of static typing but a generic
> >> print will not be as elegant in OCaml as it is in Lisp.
> >
> > This is my point. None of these is really "plug & play". They have
> > other qualities, like higher efficiency and better support for static
> > checks. But I don't value these as much as you do. IMO, programmer
> > efficiency is more important a lot of the time. However, in your
> > domain (your signature suggests it's scientific computing), things
> > might be different. I imagine it involves a lot of number crunching,
> > using complicated algorithms. Maybe I'd use OCaml instead of Lisp for
> > this, too.
>
> From my point of view, having to write type-specific functions for a tiny
> number of generic functions (e.g. print) is a small price to pay for
> getting all of your programs checked by the compiler.
>
> >> Other MLs (e.g. F#) carry run-time type information and implement
> >> print_any, which does what you want. However, they are as slow as
> >> Lisp...
> >
> > Efficiency again. Yes, a statical type system makes building an
> > optimizing compiler much easier. But this is the only real advantage
> > I see, and it doesn't come for free.
>
> Absolutely, except I'd add "correctness" along with "performance".
>
> > I'd like to see an optimizing Lisp compiler that uses type inference
> > in the way OCaml does. I know that SBCL infers types where it can and
> > uses this during optimization, but I don't know to what extent.
>
> Stalin does this for Scheme but it requires whole-program compilation and is
> incredibly slow, e.g. 2,000x slower.
>
> > E. g., when OCaml compiles a function like Lisp.fold, I assume it
> > duplicates it for each type signature the function is used on, like a
> > C++ template. I wonder if any Lisp compilers do this.
>
> No, OCaml compiles to polymorphic assembler and does very little type
> specialisation.
>
> >> to accept a value of this type (you can probably do more by
> >> specifying the type of the function).
> >
> > I know, but why would I want write additional source code if I don't
> > have to?
>
> You're going to write it in the docs. Why not have the docs checked against
> the code by the machine?
>
> > I assume my programs would look like this:
> >
> > --8<---------------cut here---------------start------------->8---
> > type variant =
> > Str of string
> > | Int of int
> > ;;
> >
> > let printv arg =
> > match arg with
> > | Str s -> Printf.printf "%s\n" s
> > | Int i -> Printf.printf "%d\n" i
> > ;;
> >
> > let _ =
> > printv (Str "foo");
> > printv (Int 3)
> > ;;--8<---------------cut here---------------end--------------->8---
>
> Absolutely not! You're implementing dynamic typing, which weakens the type
> system to the point that you might as well be writing Lisp code. Write:
>
> print_string "foo";
> print_int 3
>
> instead.
>
> > The explicit type declaration isn't so bad, and a Lisp equivalent of
> > printv would look very similar because it would also have to
> > dispatch on the type of its input. But I imagine having to write (Str
> > "foo") and (Int 3) all the time would get on my nerves.
>
> Yes. This is bad style in OCaml.
>
> >> Then the type is explicit, so you don't need documentation that says
> >> things like "Got that? Neither did I...", and your types will be
> >> automatically and statically checked for you. Basically, you get
> >> machine-verified documentation.
> >
> > Come on, putting OCaml type declarations into the *end user*
> > documentation (because this is were the quotation came from) wouldn't
> > really make things more understandable, would it.
>
> Absolutely. Almost all API documentation includes type information in
> statically typed languages. In dynamically typed languages, it often
> contains a waffly description of the allowed values in English that is
> likely to be out of date.
>
> >> Lisp should do a lot better on tasks where performance is irrelevant
> >> or not CPU-limited and where EVAL is useful. I don't believe
> >> (decent) static typing is ever enough of a hindrance that it will
> >> offset Lisp's missing features,
> >
> > Missing features? OK, it doesn't have pattern matching [1], but what
> > else?
>
> Features related to pattern matching, like variant types. Features related
> to static typing, like tuples vs arrays/lists. Features related to type
> inference, like polymorphic variants and objects.
>
> >> so trying to find tasks well suited to dynamic typing is a red
> >> herring (IMHO).
> >
> > The way I see it, using a statically typed language instead of a
> > dynamically typed one has to be justified, not the other way around.
> > IMO, a static type system is an additional cost most of the time, not
> > a benefit. So I'd need a good reason to use a statically typed
> > language, e. g. performance is critical or much better library
> > support.
>
> Reliability is the main reason to use static typing, IMHO.
>
> >> So if I wanted to make Lisp look relatively better then I'd try to write
> >> an efficient interpreter. I'd like to see a Lisp equivalent of the
> >> interpreter that I've put up here, for example:
> >>
> >> http://www.ffconsultancy.com/free/ocaml/interp...
> >
> > Using OCaml's built-in lexer and parser support is cheating a bit,
> > isn't it?
>
> I've used the built-in lexer generator that contains rules for ints and
> floats but the parser is completely general. Using ocamllex to generate a
> lexer that included rules for ints and floats explicitly would only add a
> couple of LOC.
>
> > I could just use Common Lisp's READ (reads an s-expression
> > form stdin) and EVAL and be about done. :-)
>
> My interpreter contains a recursive descent parser for the grammar that I
> chose. You can easily alter it to parse a different grammar (e.g. BASIC)
> and it wouldn't require any extra code.
>
> > [1] I'm pretty sure pattern matching could be added using macros. In
> > just under 50 lines I wrote a little macro that allowed me to
> > define the good old flatten like this:
> >
> > (defun flatten (list)
> > (match list
> > (() ())
> > (((x . y) . z) (append (flatten (cons x y)) (flatten z)))
> > ((x . y) (cons x (flatten y)))))
> >
> > That was really fun!
>
> Absolutely. Even naive pattern matching is incredibly useful.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> Objective CAML for Scientists
> http://www.ffconsultancy.com/products/ocaml_for_...

I am More of a Ruby guy but i programed in CL and Scheme and SML.
dynamic typeing allows for less code and faaster develipment. static
typeings safty benifits are pointless becaus the # of bugs is
preporial to the lines_of_code. a line of code not needed is a correct
line of code!!!!! and how often do you get type errors
6 Answers

Jeremy Tregunna

10/16/2006 3:51:00 AM

0


On 06-10-15, at 23:45, atbusbook@aol.com wrote:

> I am More of a Ruby guy but i programed in CL and Scheme and SML.
> dynamic typeing allows for less code and faaster develipment. static
> typeings safty benifits are pointless becaus the # of bugs is
> preporial to the lines_of_code. a line of code not needed is a correct
> line of code!!!!! and how often do you get type errors

A line of code not needed is a bug; it complicates maintenance and
adds unnecessary complexity.

--
Jeremy Tregunna
jtregunna@blurgle.ca

atbusbook

10/16/2006 4:01:00 AM

0


Jeremy Tregunna wrote:
> On 06-10-15, at 23:45, atbusbook@aol.com wrote:
>
> > I am More of a Ruby guy but i programed in CL and Scheme and SML.
> > dynamic typeing allows for less code and faaster develipment. static
> > typeings safty benifits are pointless becaus the # of bugs is
> > preporial to the lines_of_code. a line of code not needed is a correct
> > line of code!!!!! and how often do you get type errors
>
> A line of code not needed is a bug; it complicates maintenance and
> adds unnecessary complexity.
>
> --
> Jeremy Tregunna
> jtregunna@blurgle.ca
what i ment was a line of code not nesasary to write and not writen is
a correct line of code sorry for the ambiguity

M. Edward (Ed) Borasky

10/16/2006 4:16:00 AM

0

atbusbook@aol.com wrote:
> Jeremy Tregunna wrote:
>> On 06-10-15, at 23:45, atbusbook@aol.com wrote:
>>
>>> I am More of a Ruby guy but i programed in CL and Scheme and SML.
>>> dynamic typeing allows for less code and faaster develipment. static
>>> typeings safty benifits are pointless becaus the # of bugs is
>>> preporial to the lines_of_code. a line of code not needed is a correct
>>> line of code!!!!! and how often do you get type errors
>> A line of code not needed is a bug; it complicates maintenance and
>> adds unnecessary complexity.
>>
>> --
>> Jeremy Tregunna
>> jtregunna@blurgle.ca
> what i ment was a line of code not nesasary to write and not writen is
> a correct line of code sorry for the ambiguity

Interesting conversation -- but where might I find the beginning of it?

I always liked Dijkstra's comment about counting lines of code *spent*
rather than lines of code *produced*. :)
>
>


atbusbook

10/16/2006 4:20:00 AM

0


M. Edward (Ed) Borasky wrote:
> atbusbook@aol.com wrote:
> > Jeremy Tregunna wrote:
> >> On 06-10-15, at 23:45, atbusbook@aol.com wrote:
> >>
> >>> I am More of a Ruby guy but i programed in CL and Scheme and SML.
> >>> dynamic typeing allows for less code and faaster develipment. static
> >>> typeings safty benifits are pointless becaus the # of bugs is
> >>> preporial to the lines_of_code. a line of code not needed is a correct
> >>> line of code!!!!! and how often do you get type errors
> >> A line of code not needed is a bug; it complicates maintenance and
> >> adds unnecessary complexity.
> >>
> >> --
> >> Jeremy Tregunna
> >> jtregunna@blurgle.ca
> > what i ment was a line of code not nesasary to write and not writen is
> > a correct line of code sorry for the ambiguity
>
> Interesting conversation -- but where might I find the beginning of it?
>
> I always liked Dijkstra's comment about counting lines of code *spent*
> rather than lines of code *produced*. :)
> >
> >

comp.lang.lisp

David Vallner

10/18/2006 9:11:00 PM

0

Before I even read this:

Oh for the love of god.

David Vallner

David Vallner

10/18/2006 10:36:00 PM

0

> I am More of a Ruby guy but i programed in CL and Scheme and SML.
> dynamic typeing allows for less code and faaster develipment. static
> typeings safty benifits are pointless becaus the # of bugs is
> preporial to the lines_of_code. a line of code not needed is a correct
> line of code!!!!! and how often do you get type errors
>

So, still bedazzled as to:
a) why you crossposted the whole shenanigans that came before when it
was unrelated to Ruby,
b) why did you post into the thread at all when you had nothing to say,
c) why the freaking hell can't you for once press the hotkey for
"spellcheck" instead of the fifth exclamation mark,

I'll bite on the sweet, sweet trollbait.

Let me introduce you to my good friend, ITMS. A fairly common type of
software project, automate paper-pushing for [insert European Union Perk
here].

My friend weighs in at 750 model classes in 20 modules. (To that about
1900 controller classes and some 2800 view pages, but those are horribly
redundant, and irrelevant for the topic at hand.)

And mind you, those are model classes. No amount of metaprogramming
shenanigans will save you from the fact that number's not changing
between programming languages.

So. Do you want to bet money on that you could avoid type errors? I
would estimate no less than a week spent on you hunting typos. Not to
forget that once erb evals your code, any exception thrown in it won't
have a u

And yes, I know that the app I'm describing is mostly boring grind. Yet,
it needs to be done, and it needs to be done without a NoMethodError
when an approval for several hundreds thousands of euros goes through it.

[cue comment about unit testing being able to catch those] That is
arguably replacing following type constraints with another sort of grind.

Now, for the more salient bits of your twaddle than the chance to
reinforce my position of resident [insert C++-derivative language here]
troll.

Nagging at ML is a very, very, very stupid idea. Nagging at it with how
dynamic typing reduces code volume is even more stupid.

In fact, dynamic typing in Ruby is the least contributing factor to
reducing code volume - manifest typing declarations are hardly code that
is prone to bugs in any way - it's just a declaration.

To add insult to injury, ML isn't manifestly typed - not even optionally
as opposed to Haskell as well as I'm aware. (Corrections on that point
welcome). So that means the extra code volume of manifest typing just
isn't there.

Also, most of the code volume reductions that dynamic typing does bring
are in my opinion achievable in other languages if you make a very
granular object model. Think Java with one interface per one method as
the very extreme. Since interfaces are only contract declarations, once
again, that's lines of code that can't possibly contribute towards bugs
- only lines of code where "something happens" do.

The more important contributing factor to Ruby's productivity I see is
an API designed for utility, straightforward regexps (despite all my
rants against side-effect variables of those, even I get a migraine when
I have to do RE hackery without $0-$9), good text-processing,
each/map/select/inject, tab-completion in irb, and the fact that a Ruby
quick hack doesn't get out of hand as early as a Perl one thanks to the
first-class OO semantics and lack of a culture of implicit argument abuse.

Amusingly enough, ML can do enumerations just as well, and if you need
to work with numbers more than text, the text-processing features get
rather irrelevant. For problems backed by a more formal theorethical
model than a use-case one, I would put my money on ML being much more
productive than Ruby simply because it offers better ways to represent
that model. Yes, amongst other things a strict type system that will let
you tag even structurally identical entities with different types to
fail fast when they are confused. (A type error between an annotated
mixed directed / undirected graph and an automathon operating on the
graph would be rather iffy to track down. Disclaimer: those are probably
not structurally identical types, just a scary smug-looking namedropping
example.)

And oh, yes. <rant> Fail-fast is GOOD. If there's an unrecoverable error
in your code, it should crash and burn in a rain of tears. The sad thing
is that Ruby's NoMethodError is anything than fail-fast - the type error
is detected usually far from the place where it originated. Defensive
programming can of course prevent that, but I sort of have my doubts
about whether goes through the chore of making his code more
maintainable when it reaches a scope when that is needed. </rant>

David Vallner