Jon Harrop wrote:
> topmind wrote:
> > If you don't have type declarations, then that is one less thing that the
> > code has. QED.
>
> Type inference lets you remove type declarations from the code without
> completely forbidding them.
Perhaps, but they create their own problems, such as reducing WYSIWYG
because you don't know how something is going to act. For example,
(a>b) will act differently if something is a number versus a string.
That creates mental grokking overhead. I prefer a Perl-like approach
of explicitly telling whether you are going to compare as a number or
string. There is no hidden or underlying "type flag", only values.
> The shortest implementation of this ray tracer is only about 40 lines of
> code. Perhaps you could translate this into your chosen dynamically typed
> language and we can see if it really is shorter?
I would like to see something from my domain, not graphics, such that
math notation issues are not such a large part. But these size
comparisons can get sticky because it is often possible to make a
domain-specific or solution-specific sub-language that beats all.
Also, your link calls Lisp the most verbose. However, I would like to
see Lisp fans opinion on that. I am sure they wouldn't roll-over so
easily
-T-
topmind wrote:
> Jon Harrop wrote:
>> Type inference lets you remove type declarations from the code without
>> completely forbidding them.
>
> Perhaps, but they create their own problems, such as reducing WYSIWYG
> because you don't know how something is going to act. For example,
> (a>b) will act differently if something is a number versus a string.
> That creates mental grokking overhead. I prefer a Perl-like approach
> of explicitly telling whether you are going to compare as a number or
> string. There is no hidden or underlying "type flag", only values.
In languages like OCaml, types do not affect the running of the program,
e.g. equality behaves uniformly for all types. It is interesting that you
cite types affecting run-time dispatch as a disadvantage though, as this is
something that I would like OCaml to adopt. I would often like to define a
custom equality or comparison function for one of my types and there is no
automated way to do this in OCaml.
On a related note, type inference is vastly more practicable when the
inferred types can be obtained directly from the IDE. This was a relatively
recent addition to most FPLs and it makes an enormous difference to
productivity.
>> The shortest implementation of this ray tracer is only about 40 lines of
>> code. Perhaps you could translate this into your chosen dynamically typed
>> language and we can see if it really is shorter?
>
> I would like to see something from my domain, not graphics, such that
> math notation issues are not such a large part. But these size
> comparisons can get sticky because it is often possible to make a
> domain-specific or solution-specific sub-language that beats all.
> Also, your link calls Lisp the most verbose. However, I would like to
> see Lisp fans opinion on that. I am sure they wouldn't roll-over so
> easily
I would not say there is anything domain specific in the ray tracer
implementations. They are all accurate reflections of the C++ and the
functions can be reused for other purposes.
Let me see. There is a Sudoku solver (with GUI) and I recently partook in an
OCaml vs Lisp benchmark of interpreters that was quite interesting. You
have to write a program that can evaluate programs written in a given
language. The language is called Minim and has the following syntax:
<program> := <statement>
| <statement> <program>;
<statement> := <assignment>
| <conditional>
| <goto>
| <tag>;
| <print>
| <input>
<assignment> := (<var> is <val>) { assign a value to a variable }
| (++ <var>) { increment a variable }
| (-- <var>); { decrement a variable }
<val> := <constant> | <var>;
<var> := any symbol;
<constant> := any number
<conditional> := (if <test> then <statement> else <statement>);
<test> := (<val> <comp> <val>)
| (<test> and <test>); { boolean AND}
| (<test> or <test>) {boolean OR}
| (not <test>); {boolean NOT}
<comp> := > | < | =;
<goto> := (goto <tag>); {go to}
<tag> := any symbol
<print> := (print <string>) | (print <val>); nl; {nl is new line}
<input> := (input <var>); {input the users response to
var}
<string> := any string;
--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
From: Kent M Pitman
Subject: Re: Design Patterns and Functional programming
Date:
Message-ID: <u644bu7sj.fsf@nhplace.com>
[ comp.lang.lisp only.
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
topmind <·······@technologist.com> writes:
> But these size comparisons can get sticky because it is often
> possible to make a domain-specific or solution-specific sub-language
> that beats all. Also, your link calls Lisp the most
> verbose. However, I would like to see Lisp fans opinion on that. I
> am sure they wouldn't roll-over so easily
Here are a few quick opinions from one Lisp programmer:
First, I reject the notion that shortness of program is acceptable as
a measure of aesthetic. I used to write a lot of TECO, and while I
enjoyed it, I don't think most people would have said that it was more
aesthetic than other languages that were more verbose.
Second, directly to your question of verbosity, one of the reasons I
reject the implied notion of aesthetics in global line counts is that
I discount a small fixed amount of code that is often done in Lisp to
let you "climb out of" Lisp's initial syntax and mold a syntax you
like for the domain in question. Counting that information is like
adding O(n) + O(1) and getting something bigger than O(n), since the
complexity of the code is a function of how hard it is to write on a
rolling basis, not how hard it is to set up that basis. Yet other
languages often offer no mechanism for climbing out of their syntax,
and there are lots of examples of tedious notation that you're forced
to repeat because you can't overcome it.
Third, the mere fact that someone can write a toy problem shorter in
one language than another is no proof that the typical large program
will be writable in a more short way. Large programs often have
different kinds of obstacles that are not shown up in toy programs.
It's like choosing the best novelist by challenging several novelists
to come to a contest where they each get a topic and have to write an
award-winning paragraph in the fewest minutes... or with the fewest
characters. The real problems of structure are not that, and the
outcome of such a battle, while it measures something, pretty clearly
doesn't measure "goodness as a novelist".
Fourth, toy problems often accidentally or intentionally manage to
"overlook" details that allow a particular idea to narrowly win out in
a certain range of data extremes, and toy problems also sometimes take
unfair advantage of out-of-the-box functions that are incidental to a
particular language, and not fundamental to its power. There is a
great deal of felicity in small examples that is not accounted for
fairly. A typical case in point is that toy problems are often
arranged so that 32 bit arithmetic is good enough but a few fewer bits
is not. This often favors languages that don't use dynamic tag bits,
but is no proof that most real world problems never grow across the 32
bit boundary... at which point those tag bits often help really a lot.
Fifth, I think there are areas in which users want to be able to
rearrange more than what the language wants you to rearrange, and
languages are differently able to accommodate change outside of a
base. That will end in religious discussion. e.g., in some
functional languages it's easy to add an extra operator with new
precedence or change something from infix to prefix, but it's hard to
decide not to use standard operator notation. Is it critical to have
the rearranging property? Is it critical to provide ways out of
operators? That's mostly religion, I think, and you have to be much
more precise about terms to have a meaningful debate. People have
legitimate differences in what how they feel good about writing
things. Reducing things to numbers of lines skips over this detail
and actively presupposes that fewer lines is a good metric of what
people want to do. (For example, drag&drop interfaces for designing
UI's often generate mountains of code "automatically", and yet people
seem to love programming that way. Would they like it any better if
the secret codes it generated were longer or shorter? I'm not so
sure.)
I personally recommend not finding yourself led down the garden path
in the first place into assuming that any of these is a true challenge
of one language against another. The problem is that there is no
clean room choice one can make. Any real world problem will likely
only be budgeted to be solved one way. Maybe one day a rich person
will bring together several high-quality teams to do the same project
with the same resources and see who can win, but even then it will
only be a single data point and not statistically valid. It would
probably require many such experiments on many kinds of projects to
see legitimate science. In the meantime, what you're talking is a
kind of Jerry Springer or Fox News approach to fairness and balance if
you allow yourself to even debate these things on the idea that you
are comparing "languages". It's either a mistake or a strategic ploy
when someone tries to pretend that's what it is.
I personally get great insight out of seeing how different people
think about problems and different languages present them. I see no
reason to pursue that as competitive other than for bloody sport. I'd
rather see people amuse and enlighten each other rather than try
nullify each other with numbers, because the result is often to cause
people to not look at the other languages, rather than to say "was
there a reason this language seeks to be different?" or "is there
another way to look at problems of this sort?" or "was there a hidden
benefit in doing things a different way even though it was slower or
longer or lost on some other objective (but possibly uninteresting)
metric?"
It's like having a debate between religions to see who makes someone
more "saved" in the shortest number of sermons. Nothing wrong with
doing comparative religions, but a lot wrong with organizing that as a
way of evangelizing one religion over another by dazzling the
uninformed with confusing numbers. It doesn't lead to communities full
of enhanced tolerance, more choice, greater enlightenment. More often
it leads to people afraid to think about alternatives for fear they will
be embarrassed to even mention that they considered them.
From: Don Geddis
Subject: Re: Design Patterns and Functional programming
Date:
Message-ID: <87y7h6g7ru.fsf@geddis.org>
Kent M Pitman <······@nhplace.com> wrote on 22 Jul 2007 23:1:
> Here are a few quick opinions from one Lisp programmer:
I agree with most of what you wrote. But as that is generally uninteresting
in a continuing discussion, let me focus instead on the one minor point that
I quibble with:
> Second, directly to your question of verbosity, one of the reasons I
> reject the implied notion of aesthetics in global line counts is that
> I discount a small fixed amount of code that is often done in Lisp to
> let you "climb out of" Lisp's initial syntax and mold a syntax you
> like for the domain in question. Counting that information is like
> adding O(n) + O(1) and getting something bigger than O(n), since the
> complexity of the code is a function of how hard it is to write on a
> rolling basis, not how hard it is to set up that basis. Yet other
> languages often offer no mechanism for climbing out of their syntax,
> and there are lots of examples of tedious notation that you're forced
> to repeat because you can't overcome it.
It seems to me that your two examples actually contradict each other.
I assume that the first example was using Lisp's macro system to first
construct a domain-specific language, and then programming the solution to
the original problem in that new language.
The result of that is generally _less_ total amount of code, although I admit
that a sufficiently complex (and general) "domain-specific" language might be
a lot of code.
But then you go on to suggest that (non-macro?) languages force you to repeat
code. Surely that makes their "lines of code" count increase?
Anyway, I agree with both the observations, but at the same time they don't
seem like strong arguments to shoot down a suggested "global line count"
evaluation across languages.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
The quickest way to a man's heart is through his chest, with an axe.
From: Kent M Pitman
Subject: Re: Design Patterns and Functional programming
Date:
Message-ID: <ud4yizj9h.fsf@nhplace.com>
Don Geddis <···@geddis.org> writes:
> It seems to me that your two examples actually contradict each other.
>
> I assume that the first example was using Lisp's macro system to first
> construct a domain-specific language, and then programming the solution to
> the original problem in that new language.
>
> The result of that is generally _less_ total amount of code, although I admit
> that a sufficiently complex (and general) "domain-specific" language might be
> a lot of code.
Yes.
> But then you go on to suggest that (non-macro?) languages force you to repeat
> code. Surely that makes their "lines of code" count increase?
Yes.
> Anyway, I agree with both the observations, but at the same time they don't
> seem like strong arguments to shoot down a suggested "global line count"
> evaluation across languages.
My point was that in a small program, non-statistically-interesting
variation can dwarf the interesting part and make it hard to see
what's really winning. In the first case because the O(1) might be
O(1000) but is still a constant. In the second case because the O(n)
involved in repeating stuff that should have been macrofied in other
languages isn't apparent and appears to be reasonable and appropriate
in-the-small.