Re: Alternatives 4

JonathanSmith415@xxxxxxxxx wrote:
On Nov 14, 2:42 pm, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
http://schwarzwald.infogami.com/blog/lispocaml

The lisp can be rewritten as a 3 liner in that example,
however I will admit it wouldn't be as optimized.

This does show something interesting about lisp, however.
What you have there is a hand rolled version of Ocaml's int_of_string
function in the flet.
This inadvertently show's one of lisp's powers...
You can feasibly work at either a very high level or a very low level.
(Optimize what you need to).
It could be just as easily done with (read-from-string (read-line
*standard-input* nil "nil")).

And the OCaml code demonstrates how other languages can provide both
performance and brevity at the same time, which is the power of OCaml.

I don't believe that. I personally find it much harder to read code that
uses extremely verbose identifiers (let alone inherently verbose
languages).

It is a very subjective claim either way.

I'd have thought there would be good agreement in some cases though. Pattern
matching is an obvious example where convention dictates the use of:

h::t

or:

x::xs

instead of:

the_first_element :: the_remaining_elements

The reason being that pattern matching lets you reflect the structure of a
data structure in your code but that is impossible to read if you use long
identifiers.

If i can skim through the functions and get the gist of what each does
by function name, it seems to be a greater return on my extra typing
investment when I get into the debug-compile-test phase (as that is
where most programming time is spent?).

No. Programmers only spend a significant amount of time debugging when
they don't have a modern static type system.

Honestly I keep track of typing pretty well in my head (remembering
lisp is dynamically typed), it is second nature at this point...

With >1 programmer, that breaks down.

Inferred types are also very useful when teaching.

http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html

# let d f x =
let eps = sqrt epsilon_float in
((f (x +. eps)) -. (f (x -. eps))) /. (2. *. eps);;
val d : (float -> float) -> float -> float = <fun>

The inferred type immediately tells you that this is a higher-order "d"
function, "f" is its function argument etc.

You might say that documentation achieves the same effect in Lisp but it is
not machine verified and it does not compose. For example, the type of the
following expression immediately tells us that it is also a combinator:

# nest 3 d;;
- : (float -> float) -> float -> float = <fun>

What I worry about more are logic errors that effect the actual
behavior of the program.
Until someone writes a mind-reading IDE, I doubt very much that that
type of bug will be eliminated...

Sure.

For example, OCaml has a sophisticated "time travel" debugger but I've
never used it in four years of writing commercial OCaml code. I simply
have no use for a debugger any more.

Obviously this isn't an argument for or against any language, if we
tried to argue which language has the best semantics in terms
readability, we'd get into all sorts of 'angels on the head of a pin'
arguments... as readability is difficult (perhaps impossible) to
measure.

Languages are still highly relevant to this though. For example, you can
often tell what an OCaml or F# function does by looking at its type
signature. In OCaml and F#, the compiler infers function signatures
automatically. In Lisp, the compiler cannot. So the OCaml and F#
languages give you a lot more information to go on by design. Moreover,
modern development environments like F#'s Visual Studio mode give you
interactive graphical throwback of inferred types and documentation.

I don't know enough about F# or Ocaml to disagree with you, however I will
say it would be cool to have access to a visual studio-like environment
for lisp.

Same for OCaml. Emacs is the best there is as far as an IDE for OCaml goes
but it could barely suck any more than it does. There is really nothing
worth having outside the Linux world in this respect. There are some pretty
amazing domain-specific non-Windows IDEs though:

http://unity3d.com/

IDEs were discussed on the OCaml mailing list recently. Linux desperately
needs equivalents of the CLR and WPF if people are going to develop those
kinds of applications for it. Language-specific tools like Qt are worse
than useless because they're dragging Linuxers back to C++ for no decent
reason.

If OCaml gets its parallel GC, I think I'll start work on a new GUI toolkit
written in OCaml...

Perhaps you cannot measure readability but we can certainly measure
development speed:

http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/59...

Fortunately for me, I'm extremely productive in lisp. :)

We'll have to agree to disagree. :-)

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
.

Relevant Pages

  • Re: Lisp and OCaml, why?
    ... > interpreted languages as possible over time, if not to use them at ... > lisp and OCaml though - why would someone use them in preference to ... Strong, static typing catches type errors at compile time, reducing ...
    (comp.programming)
  • Re: a LISP raytracer
    ... > None of the free Lisp compilers come close to the capabilities of Stalin. ... > OCaml does has camlp4 macros. ... My languages professor right now is a huge fan ... on OCaML, and not so much with LISP. ...
    (comp.graphics.rendering.raytracing)
  • Re: Very poor Lisp performance
    ... >> not opt for OCaml quickly. ... but hugely expressive languages like Mathematica and "fast" but archaic ... > slower than the slowest lisp programs). ... All this makes any given benchmark or set of benchmarks suspect ...
    (comp.lang.lisp)
  • Re: Flamebait if I ever saw it
    ... Since a couple of months, we have a guy spamming this newsgroup with advertisements for his F# and OCaml "expertise", in the form of books, websites, what have you. ... Apparently that guy has picked Lisp as one of his favorite competitors, ... The fact that you narrowed down your question to the two languages that are typically at the center of that guy's attention is a strong evidence in favor of this assumption. ...
    (comp.lang.lisp)
  • Re: Lisp as laughing stock
    ... What's the difference between Lisp and most other languages? ... Maybe it's time to get away from programming languages as primary, ... with IDEs as mere user conveniences, ...
    (comp.lang.lisp)