Re: Verbose functional languages?

On Wed, 2 Jan 2008 03:38:51 -0800 (PST), Dr Jon D Harrop
<jon@xxxxxxxxxxxxxxxxx> wrote:

On Jan 2, 10:06 am, Joachim Durchholz <j...@xxxxxxxxxxxxx> wrote:
Seriously, Linux would never have taken off unless Linus hadn't been an
extremely nice guy. I once tried one of the early versions (FTP download
via modem, a 0.something version), had a problem, mailed him, and got a
friendly, to-the-point, useful answer; had I had the proper compilers
and other tools needed to participate in the project, who knows, I might
still be working on Linux right now.

I shall endeavour to mimic Linus' success here then.

Perhaps I am underestimating the amount of work required but I do not
believe it will be difficult to surpass the practical success of OCaml
and Haskell, although it will take at least two years.

I think you are. Look at any of the existing successful languages - PHP,
Perl, Python, Ruby. Each took at least half a decade to gain enough
traction to have useful libraries. Ruby was restricted to Japan for
quite some time before it became an international success (of sorts,
Perl still surpasses all the other languages, combined - not because the
language is great, which it isn't, but because a huge number of people
are writing good libraries for it).
Java is the exception that took off even before good libraries were
available, because the language was pushed with marketing money. (It
seems IT workers are just as gullible as the unwashed masses if
marketing money has such an effect. Cf. the ongoing Microsoft hype.)

That's the projects that worked. Nobody has counted how many competing
languages failed left and right.

Yes. That is why I think it is essential to steal existing libraries
and make FFI as easy as possibly everywhere else.

Scala and F# do exactly this by building on the JVM and .NET and, for
this reason alone, they will shoot past OCaml and Haskell in terms of
popularity in the near future. However, their performance and language
features are crippled by the platforms they are caged within.

Existing FPL implementations like OCaml and Haskell bask in the glory
of highly-optimized custom implementations but fall down in terms of
libraries. They have too few tested library bindings and (at least in
OCaml's case) a truly hideous FFI. This is going to start stifling
OCaml soon and although I can and would fix all of these things
myself, licensing issues and the maintainers prevent anyone outside
INRIA from doing so.

Building on the JVM or .NET certainly gets you a huge amount of
library code but the interfaces are hideous (look at WPF, for example)
and most of the libraries are irrelevant for my target market
(technical users). So I'm looking for OpenGL 2, LAPACK and FFTW for
starters and then GTK+ or Qt later. I think a top-quality C interface
and minimal documentation would go a long way here.

If I could afford to work on this full time, I'm sure I could make
serious inroads and garner a thousand users in a year.

Regardless, I shall make the platform completely free and open source
and release as often as I can in the hope that other people will join
in. IMHO, the two most important things absent from current generation
FPL implementations are: killer demos and easy documentation.

Cheers,
Jon.

Targeting .NET or JVM for the libraries is a smart idea. I know
you're looking at using LLVM. Keep in mind that at least for now, you
can't rely on the JIT compilers to do much heavy lifting - if you want
well optimized code you will still need to do a whole lot of analysis
and optimization in your own compiler before rendering bytecode. Also
keep in mind that absolutely none of those VMs are going to help you
with anything parallel - if you want your language to inherently
support multi-cores or parallel CPUs (and more importantly, scale
well), you have to realize that you are on your own.

A decent compiler for a sequential implementation of a realistic
Turing-powerful programming language is going to require a couple of
man-years of effort - don't delude yourself that because you have
tools (F#, Ocaml, etc.) that let you quickly code something that works
that the job will be simple ... a lot of effort will go into detecting
and handling garbage input, particularly garbage that is syntactically
legal but that your type checker just can't figure out (good error
messages are a must). Even more effort will go into optimizations - a
good many of which will need to be tailored to the target platform.

And gods help you if you are implementing a GC from scratch (have you
finished reading Jones & Lins yet?). LLVM has good hooks for a single
threaded implementation, but is insufficient for a parallel one.
Again think multi-cores and why they might be important in the future.

Given that you are not yet a seasoned compiler writer or a language
runtime expert, it will likely take _much_ longer than you expect to
achieve something that really isn't an exaggerated toy.

I wish you good luck, but if you have anything else on your plate for
the next few years I really think you're kidding yourself with your
timeline.

George
--
for email reply remove "/" from address
.

Relevant Pages

  • Re: How Common Lisp sucks
    ... Common Lisp the language + readily available libraries + ... The criterion is that the process have an identifiable resolution. ... If enough implementations support Gray ...
    (comp.lang.lisp)
  • Re: Statically AND Dynamically Typed Language ??
    ... implementations, has come a lot further a lot faster in recent years than ... OCaml is basically an undead language implementation now. ... F# is designed from the ground up to make money for Microsoft at ...
    (comp.lang.misc)
  • Re: Re: Learning functional programming
    ... language but I cannot think of any practical use that OCaml isn't already ... of interest for me and I learned a lot by comparing and contrasting OCaml ... e.g. allowing pattern matching directly over .NET's OOP ... building upon existing frameworks with many libraries. ...
    (comp.lang.functional)
  • Re: For performance, write it in C - Part 3, Source code now available
    ... That all the implementations had to use the same Perl pre compute phase. ... Despite the Ruby Ocaml and C++ versions not doing this. ... different language won't make what you're trying to do any more ...
    (comp.lang.ruby)
  • Re: Statically AND Dynamically Typed Language ??
    ... like Haskell and many other language ... implementations, has come a lot further a lot faster in recent years than ... OCaml is basically an undead language implementation now. ...
    (comp.lang.misc)
Loading