Re: [Caml-list] Estimating the size of the ocaml community

Re: [Caml-list] Estimating the size of the ocaml community

[Ernesto Posse]

I'd like to put my 2 cents on this thread. The original subject was the
size of the O'Caml community. By comparison with some major languages,
namely C/C++, Java, Python, the community is still smaller. The question
is why is that? So far the answer in this thread has been focused on
language features. More specifically about the pros and cons of the type
system.

  The type system is at the core of all languages in the ML family, as
well as many others. Personally I am a types-guy. While I do recognize
that untyped languages have a high "elasticity," useful in certain
contexts, I found that most applications do not benefit from that kind
of power, and that the structure imposed by a (strong) type system, as
well as its usefulness in developing correct code, outweight by far the
limitations and constraints imposed. Types are not just for
error-correction. They are a tool for designing a correct
conceptualization of a system.

  Then again, all this depends on the application. I am a firm believer of
using the right tool for the job.

  But language features such as the type system, are by no means the only
determinant of a language's popularity. There are a few key other
issues, such as:

1) Availability of development tools (IDE's) specially in different
plataforms
2) Size and usability of libraries, particularly those for GUI development
3) Existing codebase
4) Learning curve for
  a) Experienced programmers comming from other languages
  b) New programmers

  I think that unfortunately O'Caml is lagging in these issues, at least
from my personal experience. I have been a long-time user of O'Caml
(back from the Caml Light days,) and I try to use it when I can, but
sometimes it just takes too much time to get a project started. Spending
too much time on the preliminaries is a big deterrent for managers, and
without their support, projects won't be done in the language.

  Recently I started a small project, and I wanted to develop it in
O'Caml, but after a while I gave up, and did it in Java. My first
concern was choosing an IDE. Normally under Linux I use Emacs+Tuareg.
Fine, but my project had to be done on Windows.  I find Emacs under
Windows a bit annoying, and I wanted to have something similar to the
popular Java IDE's for O'Caml. So I had two options: Eclipse or
Cameleon. The Eclipse mode for O'Caml is still an alpha version, and not
very usable or customizable. Writing your own Eclipse mode is a dawnting
task on its own. So I tried compiling Cameleon on MinGW. After a week of
trying to figure out how to do it I gave up. I didn't find any concise
installation instructions, other than the typical "configure-make-make
install" routine, which should be enough, if there was no need to
install LablTK. I was never able to do that. This brings me to 4.a)
above. You cannot ask a student learning to program for the first time
to do any of these things, whether it is Emacs or installing one of
these IDEs, might be fine for a seasoned programmer, but not for a
rookie (I can testify that after teaching programming to non-programmers
for several years now.)

  The second point was the library. For most purposes I find the library
satisfying enough, except when it comes to GUIs. I have to admit that
using Swing on Java got me far in no time, and it looks very good. And
best of all, there are great tutorials for it. I wasn't able to find
good tutorials for GUIs in O'Caml.

  The third point, well, the hump is growing, but unfortunately languages
such as Python which are "younger," have sadly outpaced O'Caml. Then
again, we cannot really change that.

  The fourth point is fundamental. For seasoned programmers, learning a
new language in some cases is easier, but you always have some baggage.
You always come with some preconceptions about how things work or should
work, and this is an impediment. The older the programmer, the less
likely he is to learn a new language.

  Teaching it to new programmers is better, and I hope more people teach
O'Caml. Here at McGill (in Montreal) we teach Java. I am pushing for
O'Caml, but it is an uphill battle. Changing the base language has a big
logistics problem: you have to adapt the rest of the courses somehow,
either by changing them, or creating some additional language courses on
the side. Either way it is difficult to implement. But this is
fundamental. Teaching O'Caml only at the level of compilers courses, or
theory of programming languages, or other advanced courses, will keep
the user-base small. To really increase the O'Caml community we have to
push for introductory courses in O'Caml, and this will also require more
texts (beyond O'Reilly's) translated to different languages.

  Now, the point of increasing the community, and teaching O'Caml, should
not be simply that we like the language, and we think it is cool. No,
the point is that we believe it is a very good tool for a very diverse
number of applications and audience, and that it promotes a better
approach to programming.

  So, if you are a teacher or student, try promote it in your school. If
you work in industry, talk about it with your boss and colleagues. If
you are part of the O'Caml development team: please, more tools!
specially good IDE's, and CASE tools! Maybe some of the industries that
have used it could fork some money to help build better development
support tools.


-- 
Ernesto Posse
Modelling, Simulation and Design Lab - School of Computer Science
McGill University - Montreal, Quebec, Canada
url: http://moncs.cs.mcgill.ca/people/eposse

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 02:36:08PM -0500, Ernesto Posse wrote:
[...]
>   The second point was the library. For most purposes I find the library
> satisfying enough, except when it comes to GUIs. I have to admit that
> using Swing on Java got me far in no time, and it looks very good. And
> best of all, there are great tutorials for it. I wasn't able to find
> good tutorials for GUIs in O'Caml.
[...]


Ciao,
  Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Sat, 2005-02-05 at 06:36, Ernesto Posse wrote:

>   Recently I started a small project, and I wanted to develop it in
> O'Caml, but after a while I gave up, and did it in Java. My first
> concern was choosing an IDE. 

Why do you need that stuff? What's wrong with a plain
old text editor and couple of batch files to build
the code?

Seems to me you wasted a heap of time trying to build
something (an IDE) that you didn't need in the first place.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] Estimating the size of the ocaml community

[Michael Walter]

I like IDEs as well. Nice project management, code completion,
integrated debugging, etc.. all integrated + without explicit
configuration.. mhm.

Michael Walter


On Fri, 04 Feb 2005 18:32:20 -0800 (PST), skaller
<skaller@users.sourceforge.net> wrote:
> On Sat, 2005-02-05 at 06:36, Ernesto Posse wrote:
> 
> >   Recently I started a small project, and I wanted to develop it in
> > O'Caml, but after a while I gave up, and did it in Java. My first
> > concern was choosing an IDE.
> 
> Why do you need that stuff? What's wrong with a plain
> old text editor and couple of batch files to build
> the code?
> 
> Seems to me you wasted a heap of time trying to build
> something (an IDE) that you didn't need in the first place.
> 
> --
> John Skaller, mailto:skaller@users.sf.net
> voice: 061-2-9660-0850,
> snail: PO BOX 401 Glebe NSW 2037 Australia
> Checkout the Felix programming language http://felix.sf.net
> 
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Estimating the size of the ocaml community

[Ernesto Posse]

> On Sat, 2005-02-05 at 06:36, Ernesto Posse wrote:
>
>>   Recently I started a small project, and I wanted to develop it in
>> O'Caml, but after a while I gave up, and did it in Java. My first
>> concern was choosing an IDE.
>
> Why do you need that stuff? What's wrong with a plain
> old text editor and couple of batch files to build
> the code?

  There is nothing wrong with a plain old editor, but for many projects an
IDE can improve development time significantly.


> Seems to me you wasted a heap of time trying to build
> something (an IDE) that you didn't need in the first place.

  Of course I wasted time! That is precisely the point: I shouldn't have
had to look for such tools. My point is not about my personal project.
That was just to illustrate the general point: to attract more
programmers, there is a need for more development tools, in particular
user-friendly, and dare I say, Windows-based tools. There is a need for
such tools, specially if one wants to attract two key players:
first-time programmers, and managers of software development projects.
Without them, there is not much chance to make the O'Caml community grow
significantly.


-- 
Ernesto Posse
Modelling, Simulation and Design Lab - School of Computer Science
McGill University - Montreal, Quebec, Canada
url: http://moncs.cs.mcgill.ca/people/eposse

Re: [Caml-list] Estimating the size of the ocaml community

[Christopher A. Watford]

On Fri, 04 Feb 2005 18:34:25 -0800 (PST), skaller
<skaller@users.sourceforge.net> wrote:
> Why do you need that stuff? What's wrong with a plain
> old text editor and couple of batch files to build
> the code?
> 
> Seems to me you wasted a heap of time trying to build
> something (an IDE) that you didn't need in the first place.

OCaml needs an IDE or atleast a (more) functioning Win32 toplevel.
Working with OCaml as a new language was a pain in the ass, which is
why I took to fixing the numerous bugs in the win32 toplevel. A nice
plugin for Eclipse or even sufficient fixes to the toplevel would make
learning OCaml, which to me was a highly interactive process, much
easier. Besides, having a solid IDE lowers the bar for gaining
corporate acceptance. (And yes I know not everyone uses Win32, just
what a lot of people use)

> --
> John Skaller, mailto:skaller@users.sf.net
> voice: 061-2-9660-0850,
> snail: PO BOX 401 Glebe NSW 2037 Australia
> Checkout the Felix programming language http://felix.sf.net

-- 
Christopher A. Watford
christopher.watford@gmail.com
http://dorm.tunkeymicket.com

Re: [Caml-list] Estimating the size of the ocaml community

[Kenneth Knowles]

On Fri, Feb 04, 2005 at 02:36:08PM -0500, Ernesto Posse wrote:
>   But language features such as the type system, are by no means the only
> determinant of a language's popularity. There are a few key other
> issues, such as:

The mainstream languages are that way for two reasons: 
(1) They filled a niche at a key moment.  This happens about once a decade, and
by no means selects the "best" language.
(2) They are entrenched (by #1).  When this happens to your language it freezes
and you have to look elsewhere for the cutting edge.

So it all depends on your goals.  Personally, I would prefer for something like
SML to become mainstream, because it is already a relic.  I'd like to see O'Caml
continue as it is - an enormous advantage for those small companies and
individuals who are nimble and adventurous enough to use it, and a reasonably
researchful language.

- Kenn

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Sat, Feb 05, 2005 at 12:57:20AM +0100, Oliver Bandel wrote:
> On Fri, Feb 04, 2005 at 02:36:08PM -0500, Ernesto Posse wrote:
> [...]
> >   The second point was the library. For most purposes I find the library
> > satisfying enough, except when it comes to GUIs. I have to admit that
> > using Swing on Java got me far in no time, and it looks very good. And
> > best of all, there are great tutorials for it. I wasn't able to find
> > good tutorials for GUIs in O'Caml.
> [...]
> 
> 
> Ciao,
>   Oliver


Ooops, forgot the text...

I want to say: Yes, a binding to a GUI would be nice, and
for commercial applications essential.

I'm looking for a COCOA-binding for OCaml.
Is there something?
Need it on Mac OS-X.


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 10:07:41PM -0500, Ernesto Posse wrote:
> 
> > On Sat, 2005-02-05 at 06:36, Ernesto Posse wrote:
> >
> >>   Recently I started a small project, and I wanted to develop it in
> >> O'Caml, but after a while I gave up, and did it in Java. My first
> >> concern was choosing an IDE.
> >
> > Why do you need that stuff? What's wrong with a plain
> > old text editor and couple of batch files to build
> > the code?
> 
>   There is nothing wrong with a plain old editor, but for many projects an
> IDE can improve development time significantly.

I personally prefer using vi/vim and cli-tools.
But if there would be an IDE, that would be nice
for developers that like to use IDEs.

[...]
> Without them, there is not much chance to make the O'Caml community grow
> significantly.

Well, I'm not sure if I really want to have grown the
OCaml-programmers significantly. It's enough, when I get a
job, where I can do things in OCaml.
If the other people write applications in Assembler,
I don't have a problem with that. ;-)

But what I'm looking for, is to have a COCOA-binding.

(and other GUI-bindings too... the graphics-Modlue is nice,
 but it does not work on OS-X (?!) and to have a true
 GUI-interface to the platform I'm developing on,
 that is what I'm looking for)


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 11:13:08PM -0800, Kenneth Knowles wrote:
[...]
> The mainstream languages are that way for two reasons: 
> (1) They filled a niche at a key moment.  This happens about once a decade, and
> by no means selects the "best" language.
> (2) They are entrenched (by #1).  When this happens to your language it freezes
> and you have to look elsewhere for the cutting edge.
> 
> So it all depends on your goals.  Personally, I would prefer for something like
> SML to become mainstream, because it is already a relic.  I'd like to see O'Caml
> continue as it is - an enormous advantage for those small companies and
> individuals who are nimble and adventurous enough to use it, and a reasonably
> researchful language.

Yes, I agree here.
Better to have - as small company or especially as single developer -
the advantage of a growing, excellent language and not have many
others who also use it.

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[William D.Neumann]

On Feb 5, 2005, at 6:31 AM, Oliver Bandel wrote:

> But what I'm looking for, is to have a COCOA-binding.

It would be wonderful to have one of those -- currently one doesn't 
exist, and I haven't seen any indications that anyone is working on 
one.  I tried to look into starting one up a while back, but I was 
never able to figure out where to start (I'm a little slow, eh...).

> (and other GUI-bindings too... the graphics-Modlue is nice,
>  but it does not work on OS-X (?!) and to have a true
>  GUI-interface to the platform I'm developing on,
>  that is what I'm looking for)

Huh?  It works just fine under OS X's X11 distribution.  And if you 
want to do graphics under Aqua, you can look at this package 
<http://www.pps.jussieu.fr/~henry/ter/>.  Additionally, the labltk 
module (granted, it's not "graphics", but it can be used for not quite 
beautiful GUIs) can be used under Aqua using the directions found here 
<http://wiki.cocan.org/getting_started_with_ocaml_on_mac_os_x>.  
Finally, for a quick 'n' dirty cocoa-esque interface for scripting 
purposes, you might want to look into Pashua 
<http://www.bluem.net/downloads/pashua_en/> it's easy enough to get 
rolling with it on your own, but I've got a basic module lying around 
somewhere for interfacing with Pashua if anyone wants it.

None of these are as nice as a set of bindings to Cocoa would be, but 
they can come in handy

William D. Neumann

"You've got Rita Marlowe in the palm of your hand."
"Palm of my hand?  You haven't seen Rita Marlowe..."

		-- Will Success Spoil Rock Hunter?

Re: [Caml-list] Estimating the size of the ocaml community

[Martin Willensdorfer]

> On Sat, 2005-02-05 at 06:36, Ernesto Posse wrote:
> >   Recently I started a small project, and I wanted to develop it in
> > O'Caml, but after a while I gave up, and did it in Java. My first
> > concern was choosing an IDE.

I have never used it, but isn't Cameleon an IDE?
http://pauillac.inria.fr/~guesdon/Tools/cameleon/cameleon.html

MW

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Sat, Feb 05, 2005 at 02:31:48PM +0100, Oliver Bandel wrote:
> But what I'm looking for, is to have a COCOA-binding.

It might be feasible (if not particularly pleasant) to go via Perl:

http://sourceforge.net/projects/camelbones/
http://merjis.com/developers/perl4caml

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Erik de Castro Lopo]

On Mon, 21 Feb 2005 02:07:44 +0000
Jon Harrop <jon@ffconsultancy.com> wrote:

> On Sunday 20 February 2005 16:18, Diego Olivier Fernandez Pons wrote:
> > Part of the 27 ML projects are in fact Caml projects.
> 
> Indeed, the following twelve seem to be written in OCaml:
> 
> Unison, FFTW, MATHPLOT, WDialog, PXP, GeneWeb, SwiftSurf, FaCiLe, pxpvalidate, 
> Camlserv, Lazy-L and JSON.

For FFTW, only a small part is written in O'Caml, a program which generates
optimized C codelets for the FFT butterflys.

The vast majority of FFTW is written in C.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I'll just say that having programmed in Lisp the shortcomings
of Java are glaringly obvious." -- Erann Gat

Re: [Caml-list] Estimating the size of the ocaml community

[Jon Harrop]

On Sunday 20 February 2005 16:18, Diego Olivier Fernandez Pons wrote:
> Part of the 27 ML projects are in fact Caml projects.

Indeed, the following twelve seem to be written in OCaml:

Unison, FFTW, MATHPLOT, WDialog, PXP, GeneWeb, SwiftSurf, FaCiLe, pxpvalidate, 
Camlserv, Lazy-L and JSON.

I just had a look at sourceforge, which has far more projects (14,325 C, 
14,813 C++ and 14,074 Java) by comparison, and the accredited language seems 
to be wrong much more often. Assuming that all of the 132 SML projects are 
actually in OCaml, this gives 155 projects OCaml, i.e. about two orders of 
magnitude less common that the most popular languages.

Also, I think that web searches for "resume" and "CV" are likely to be 
inaccurate. Searching for "written in *" seems more reasonable. This gives:

792,000 Java
636,000 C
424,000 Perl
312,000 C++
221,000 Python
92,900 C#
30,100 Ruby
20,300 Lisp
11,700 Scheme
5,240 ocaml
974 caml

Again, OCaml is about two orders of magnitude below the most popular 
languages.

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

Re: [Caml-list] Estimating the size of the ocaml community

[Diego Olivier Fernandez Pons]

    Bonjour

Jon Harrop a écrit :

> Checking freshmeat now, OCaml is the 24th most popular language with 52
> projects. Here's the full {language, projects} list:

[...]

> {OCaml, 52}, {Emacs-Lisp, 51}, {Pascal, 48}, {Haskell, 48}, {Awk,
> 46}, {Zope, 41}, {Smalltalk, 33}, {ASP, 33}, {Visual Basic, 31},
> {Basic, 30}, {Eiffel, 28}, {ML, 27}

Part of the 27 ML projects are in fact Caml projects.

        Diego Olivier

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Sun, 20 Feb 2005, Jon Harrop wrote:

> Considering that C# is pushed by Microsoft, Objective C is pushed by Apple and 
> LISP is pushed by Thomas Fischbacher ;-), I think this is very impressive.

I don't think this mirrors the state of affairs in the LISP community 
pretty well. ;-) At least, if you look at the authors of all the cl-* 
packages in debian.

But of course, "fashion languages" that are pushed by companies primarily 
for market share purposes - and not out of a deeper need - are an issue. 
So to speak, every language tries to fix some problem. One barely can 
resist the impression that the primary "problem" that C# tries to fix is 
that Java is not controlled by Microsoft...

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Jon Harrop]

I was just reading this presentation and stumbled upon some figures it 
contains of the number of freshmeat projects written in different languages:

http://www.uclan.ac.uk/facs/destech/gradschool/autumnschool/thu11built-karlin2.pdf

According to this, just over a year ago (09/2003), OCaml was the 31st most 
popular language with 22 projects.

Checking freshmeat now, OCaml is the 24th most popular language with 52 
projects. Here's the full {language, projects} list:

{{C, 7066}, {Java, 3769}, {C++, 3523}, {Perl, 3300}, {PHP, 2947}, {Python, 
    1763}, {Unix Shell, 721}, {Tcl, 421}, {JavaScript, 409}, {SQL, 
    405}, {Objective C, 260}, {Other, 221}, {Assembly, 220}, {Ruby, 219}, {C#,
     155}, {Other Scripting Engines, 125}, {Scheme, 111}, {Lisp, 81}, {PL/SQL,
     78}, {Delphi, 74}, {Fortran, 62}, {Ada, 56}, {Common Lisp, 54}, {OCaml, 
    52}, {Emacs-Lisp, 51}, {Pascal, 48}, {Haskell, 48}, {Awk, 46}, {Zope, 
    41}, {Smalltalk, 33}, {ASP, 33}, {Visual Basic, 31}, {Basic, 30}, {Eiffel,
     28}, {ML, 27}, {YACC, 24}, {Forth, 23}, {Cold Fusion, 
    20}, {Object Pascal, 19}, {Prolog, 18}, {Erlang, 18}, {Pike, 11}, {Lua, 
    11}, {Rexx, 10}, {Modula, 9}, {Groovy, 5}, {Logo, 4}, {Euphoria, 4}, {APL,
     3}, {PROGRESS, 2}, {Pliant, 2}, {Dylan, 2}, {XBasic, 1}, {Simula, 
    1}, {REALbasic, 1}, {Euler, 1}}

I also computed the fractional increase in the number of projects for each 
language to determine how rapidly languages have been adopted over the past 
year. C# is 1st and OCaml is 2nd:

{{C#, 3.44444}, {OCaml, 2.36364}, {Objective C, 1.91176}, {Common Lisp, 
    1.86207}, {JavaScript, 1.74043}, {Haskell, 1.71429}, {Ruby, 
    1.71094}, {Java, 1.57304}, {Emacs-Lisp, 1.54545}, {Delphi, 1.48}, {Ada, 
    1.47368}, {Python, 1.47162}, {PHP, 1.43058}, {C++, 1.41999}, {Scheme, 
    1.40506}, {SQL, 1.38225}, {Fortran, 1.37778}, {Unix Shell, 
    1.30144}, {Other Scripting Engines, {}}, {PL/SQL, 1.27869}, {C, 
    1.28077}, {ASP, 1.26923}, {Pascal, 1.26316}, {Assembly, 1.24294}, {Lisp, 
    1.22727}, {Zope, 1.20588}, {Perl, 1.19392}, {Tcl, 1.17927}, {Awk, 
    1.15}, {Other, 0.840304}}

Considering that C# is pushed by Microsoft, Objective C is pushed by Apple and 
LISP is pushed by Thomas Fischbacher ;-), I think this is very impressive.

I've also checked the number of unique posters to caml-list per month, which 
has continued to rise exponentially since 1992, currently weighs in at 300 
and is set to hit 1,000 in the year 2008.

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

Re: [Caml-list] Estimating the size of the ocaml community

[Johann Spies]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> 
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?

Do you know about any university which offers distant learning courses
in Programming or Computer Science and also teaches Ocaml?

In Souh Africa, where I am, Ocaml is a largely unkown language.

Regards
Johann
-- 
Johann Spies          Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch

     "But the LORD is in his holy temple; let all the earth 
      keep silence before him."           Habakkuk 2:20 

Re: [Caml-list] Estimating the size of the ocaml community

[Sven Luther]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> I've been trying to come up with some estimates on the size of the ocaml
> community, and I'm wondering if others have come up with anything better.
> Here's what I have so far:

I don't know if it is interesting for what you need, but the debian popularity
contest :

  http://popcon.debian.org/

shows ocaml starting at position 1858 :

  #rank name                            inst  vote   old recent no-files (maintainer)
  1858  ocaml-base-nox                   743   238   396   109     0 (Sven Luther)                   

But this may be biased by the split of ocaml between different packages,
ocaml-base-nox is the runtime without X related libraries. The most used
packages (adduser for the per inst sorting) is around 6000, so this would mean
that about 10% install ocaml stuff, since inst is : 

  #<inst> is the number of people who installed this package;

Naturally, the results are probably biased by the way popularity contest is
run. popularity contest (popcon) is a package which you can install but which
is not installed by default, and where you can opt-in into the mechanism,
which sends (weekly ?) emails about the installed packages to the debian
popularity-contest. Still, this means that at least 743 people have it
installed, that 238 "use this package regularly", and 109 have recently
upgraded it. No idea about how the "use this package regularly" numbers are
calculated though.

Hope this kind of info is helpful to your estimates ?

Friendly,

Sven Luther

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Sat, 5 Feb 2005, Oliver Bandel wrote:

> > Well, there is something for opaque binary data, but the problem is that 
> > not all functions one would like to have on them are readily available.
> [...]
> 
> What and where?

One can abuse bigarray for this.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 11:02:49PM +0100, Thomas Fischbacher wrote:
> 
> On Fri, 4 Feb 2005, Oliver Bandel wrote:
> 
> > On Thu, Feb 03, 2005 at 10:16:33PM +0100, Thomas Fischbacher wrote:
> > [...]
> > > (3) The type system is annoying. People claim it helps catching errors, 
> > > but my impression is it only catches those which I would never make 
> > > anyway.
> > [...]
> > 
> > Well if it catches only errors you never make, you should
> > never had any warnings nor error messages from the type
> > system.
> > So, why is it annoying, if you never get a warning/error message?
> > 
> > Normally you should not be aware of the type system, because you
> > do not make type-system-errors.
> 
> Because the type system occasionally forces me to write code in funny 
> ways, as I cannot "sometimes return an integer, sometimes a symbol" from a 
> function, say. I would have to wrap this up.
> 
[...]

...well....

type sometimes_t = Integer of int | One_symbol | Another_symbol

let look_inside thing = match thing with
      Integer i      -> print_endline ("Got an int! " ^ string_of_int i)
    | One_symbol     -> print_endline "Got ONE symbol"
    | Another_symbol -> print_endline "Got ANOTHER symbol"


...isn't that nice?!


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 11:01:02PM +0100, Thomas Fischbacher wrote:
> 
> On Fri, 4 Feb 2005, Oliver Bandel wrote:
> 
> > > Oh, by the way, there is one more thing which I consider a really
> > > grave issue, which gave us quite a lot of grey hair already: Ocaml 
> > > strings have this stupid limitation to 16 MB, which means in particular 
> > > that if you serialize a truly large intermediate state of, say, a long 
> > > and complicated calculation which accidentally got a bit larger than this 
> > > limit (while you did not expect that), well...
> > 
> > Well, maybe there should be a BigStrings- or LongStrings-Module
> > introduced into OCaml-stdlib?
> 
> Well, there is something for opaque binary data, but the problem is that 
> not all functions one would like to have on them are readily available.
[...]

What and where?

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Sat, 2005-02-05 at 03:12, Oliver Bandel wrote:

> > 
> > (a) interfacing to C isn't trivial
> [...]
> 
> Well, compared to Perl, this task IS trivial in OCaml.

But it is very difficult compared to C++, where basically
you can just write

	extern "C" { .. }

or Felix where you bascially just write

	sin: double -> double;

to interface the 'sin' function. In Ocaml, the
Ocaml code is just like that too, but you have to
write wrapper glue (in Felix you don't usually),
and the glue goes in another file and is written
in C not Ocaml.

All of this makes 'trivial' interfacing rather
cumbersome, and 'extensive' interfacing a lot
of work.

So this is a downside whose impact depends on
how much C code you need for your application.

Typically with Ocaml, a lot of C libraries
are a waste of time, since you can do
the same code in Ocaml quite easily.
EG why bother with a lame XML parser library
done for C .. when Ocaml is so good at parsers
anyhow, it is probably easier to write your
own XML parser in Ocaml than bother interfacing
to a C library -- besides which you'd want
to think about making your application much simpler
using (C/X)Duce anyhow .. :)

Nevertheless a large issue in *adopting* a new
language is how to handle migration and with an
existing large code base binding to C is a
real industrial issue. The problem is that
for small apps, where a complete rewrite in
Ocaml makes sense, there's no great incentive
to use a better language. It is only for large
scale applications where the superiority of
strong typing, GC, HOFs etc etc really count
that you'd consider a complete technology
change and it is precisely in those cases that
migration paths do matter. Catch 22 :)


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Sat, 2005-02-05 at 03:00, Oliver Bandel wrote:

>     Explanation: Pattern matches are like nested if's now in OCaml. The Pattern
>     that matches first in the code, will be executed!!!
>     This is NOT functional, this is imperative behaviour!

No. If chains are perfectly functional .. in fact control
transfer is little more than lazy evaluation.

What you are *actually* complaining about is loss of transparency.
When you write

	if A then .. else if B then ..

the *actual* guard on the  second case isn't B, but

	B and not A

therefore the order of writing matters. So you cannot
transparently reorder the branches.

What you're *actually* asking for is probably a match construction
that guarrantees the branches are mutually exclusive so that
the order of writing is irrelevant.

In particular, there is a related construction that
executes *all* matching cases, and the mutually exclusive
branches match is a special case of that which only
takes one branch. In particular, a parallel match,
which executes all the branches, possibly concurrently,
would work well when the branches are exclusive..
(since no concurrency is required .. :)

In fact, Ocaml 'match' syntax is chosen to do 20 quite
distinct operations with one syntax: i.e. it is just
a convenience. The compiler tries to unravel it
to produce better code -- but the programmer
does not actually know how well it will perform
without heavy analysis.

More discrete constructions would give the programmer
much more idea of the actual semantics and implementation,
BUT it would then be much harder -- less transparent --
to modify the code.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Christophe TROESTLER wrote:

> On Fri, 4 Feb 2005, Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE> wrote:
> > 
> > > > Erm, what do you do if you want to quickly debug-print a list of
> > > > vectors of pairs?
> 
> What's wrong with camldebug ?

There are many different aspects to debugging, and not all of them are 
related to a debugger.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Oliver Bandel wrote:

> On Thu, Feb 03, 2005 at 10:16:33PM +0100, Thomas Fischbacher wrote:
> [...]
> > (3) The type system is annoying. People claim it helps catching errors, 
> > but my impression is it only catches those which I would never make 
> > anyway.
> [...]
> 
> Well if it catches only errors you never make, you should
> never had any warnings nor error messages from the type
> system.
> So, why is it annoying, if you never get a warning/error message?
> 
> Normally you should not be aware of the type system, because you
> do not make type-system-errors.

Because the type system occasionally forces me to write code in funny 
ways, as I cannot "sometimes return an integer, sometimes a symbol" from a 
function, say. I would have to wrap this up.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Oliver Bandel wrote:

> > Oh, by the way, there is one more thing which I consider a really
> > grave issue, which gave us quite a lot of grey hair already: Ocaml 
> > strings have this stupid limitation to 16 MB, which means in particular 
> > that if you serialize a truly large intermediate state of, say, a long 
> > and complicated calculation which accidentally got a bit larger than this 
> > limit (while you did not expect that), well...
> 
> Well, maybe there should be a BigStrings- or LongStrings-Module
> introduced into OCaml-stdlib?

Well, there is something for opaque binary data, but the problem is that 
not all functions one would like to have on them are readily available.

> But: When you mean with "a long and complicated calculation"
> using larger int/float-values you may use
> the num-library.

No, I actually meant serializing an approximation-to-a-continuation in 
long running symbolic calculations that accumulate quite a sizable heap of 
expressions representing terms, say for checkpointing.

> E.g. in module Num there is a  string_of_num-function.
> Do you really think, the results will be larger than 16MB?

In my case, I indeed had precisely this problem of some serializations 
failing due to data breaking the 16MB limit.

Oh, by the way, I also have indications that at least for 3.07, there is a 
bug in serializing and re-serializing hash tables. Unfortunately, my test 
case is quite complicated, and I so far could not strip it down to 
something more useful for debuggers.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Basile STARYNKEVITCH]

Le Thu, Feb 03, 2005 at 07:34:15PM +0100, Frédéric Gava écrivait/wrote:
> Hi,
> 
> > Anyway, this leaves us with a very interesting question: how many people
> > actually do believe in the value of Ocaml? I, for myself, use it whenever
> > it is the most appropriate tool for a job (usually, when portability is
> > an issue). This is sometimes the case, but more often than not, LISP
> > turned out to be a better choice for what I do.

> What kinds of programs code with LISP could not be implemented (easely)
> using Ocaml ?

The main feature of Lisp that Ocaml does not have is the
meta-programming ability. This not only includes the powerful macro
system of Common Lisp (but Ocaml has Camlp4) but above all the ability
to genreate code at runtime.

The MetaOcaml extension of Ocaml (see http://metaocaml.org/ for
details) has a typeful meta-programming ability (which should be
stronger than that of Common Lisp, mostly because its type system
guarantee types of generated programs): howevefr the current
implementation does not garbage-collect the generated programs, which
make using it awkward.

I hope I am grossly right  - I may be wrong in the details, not being
a MetaOcaml expert.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Re: [Caml-list] Estimating the size of the ocaml community

[Karl Zilles]

Christophe TROESTLER wrote:

 > What's wrong with camldebug ?


Since we're bitching about everything anyway, how about:

*) No conditional breakpoints
*) No watch expressions

ocamldebug works very well for debugging unexpected exceptions in my 
code, but when I wanted to trace the behavior of a specific function 
running on specific data, it was very painful to get to the right place.

1) set breakpoint
2) run
3) p variable
4) if not there yet, goto 2

yuck.  Am I missing something?  What do other people do?  Besides adding 
a conditional to their program to give them a place to set a breakpoint.

Re: [Caml-list] Estimating the size of the ocaml community

[Christophe TROESTLER]

On Fri, 4 Feb 2005, Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE> wrote:
> 
> > > Erm, what do you do if you want to quickly debug-print a list of
> > > vectors of pairs?

What's wrong with camldebug ?

ChriS

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 06:32:00PM +0100, sejourne_kevin wrote:
> Oliver Bandel a écrit :
> >9.: Pattern matching, that *really* is functional (seems to be necessary 
> >that it works
> >    like it is done in logical programming languages like Prolog or 
> >    similar?
> 
> Something like this could be fun (just like Prolog):
> 
> (*caml way*)
> let test = function
>     [(1,a);b;(3,c);(4,d)] ->Printf.printf "%d %d %d \n" a c d; b
>   | _ -> failwith "Unification Impossible"
> ;;
> (*half-prolog way*)
> let test [(1,a);b;(3,c);(4,d)] =  Printf.printf "%d %d %d \n" a c d; b
> and test _ = failwith "Unification Impossible"
> ;;

The second one ("half-prolog way") looks a littlebid like Haskell's
syntax.

What I mean is, that your

 (*caml way*)
 let test = function
     [(1,a);b;(3,c);(4,d)] ->Printf.printf "%d %d %d \n" a c d; b
   | _ -> failwith "Unification Impossible"
 ;;

would work equally for all input data, if written in the opposite order
of pattern-match code-lines:

 (*caml way*)
 let test = function
     _ -> failwith "Unification Impossible"
   | [(1,a);b;(3,c);(4,d)] ->Printf.printf "%d %d %d \n" a c d; b
 ;;

And this, because in a functional setting it does not matter,
which expression comes first: it's always the same result
for the same input data, independent of the order of lines of code.


Now (but in Haskell it's the same) it is NOT independent
of which comes first.

This was a mayjor problem of understanding Pattern Matches,
especially because all people said (in books and papers too!)
that pattern matching belongs to the functional world.

I now can use OCaml pattern matches without problems,
but in the first time I was very annoyed about saying
that this is a functional language feature, when it
really not is.

So, maybe the documentation and the papers and books
should not call it functional pattern matching, but
pattern matching (or imperative pattern matching).

As OCaml has in it's concept that it also uses OO-features and imperative
features, there is no problem for me to accept the
pattern matching features as they are now.
But I like it to say it, how it is (not, how people want to
show it, even if it is differently).

And IMHO such a lmatch (logical match) or fmatch (functional match)
should be added to the OCaml-Core. (If possible.)


[...]
> With a logic match, Ocaml could be functionnal, imperative, object and 
> logic.

Yes, that's fine. :)

I think only Oz can compete here (but as far as I know it
is not as efficient/performant as OCaml).


> Just need a dynamic syntax to have the power of Prolog with the 
> power of OCaml... cool. The problem with the logic
> match (* | "prefix"^str -> *) is that ^ isn't a constructor but a 
> function. I think, the logic match can't be determinist. IHMO, Prolog 
> can do it just because all data are term(s) as all 'function'.

Hmhhh, so you think there are theoretical problems to implement such thing?!


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 06:27:11PM +0100, Damien Doligez wrote:
> 
> 
> >On Thu, Feb 03, 2005 at 11:39:50PM +0000, Richard Jones wrote:
> >>Got to agree with you on this one ...  At least we'll soon all be
> >>using 64 bit computers where OCaml doesn't suffer this limitation.
> 
> On Feb 4, 2005, at 11:58, Oliver Bandel wrote:
> >Well, but even on those computers will be restrictions in the size.
> 
> On 64-bit computers, the maximum string length is 2^56-9 bytes.

OK, that's enough until next summer (I mean 2006) ;-)


[...]
> 
> If Moore's law holds until then, and starting from a gigabyte now,
> it will take about 40 years before you get a machine powerful enough
> to run into that limit.  And the transistors of that machine will be
> smaller than protons.

Well, Quarks and subQuarks or something?

> 
> I hope we'll get 128-bit machines before then.

Well... it's some decades ago (I think in the mid-80ies), there was an article
about a 128-Bit-processor, very soon to be available on the chip-market.
But I don't know if that article was on an april issue of the magazine.


Ciao,
   Oliver


> 
> -- Damien
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
"Here at michigan state university, my computational linguistics professor
 had us learn ocaml for the class and we used it exclusively. I like it so
 much better than c++! Hope this helps." (Jeff Shaw on caml-list)

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 06:21:15PM +0100, Frdric Gava wrote:
> Hi,
> 
> is it this paper ?
> http://icwww.epfl.ch/publications/documents/IC_TECH_REPORT_200244.pdf
> 

Yes, I think that's the paper I meant.


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Andreas Rossberg wrote:

> > (1) Prevent the programmer from "accidentally plugging an electrical 
> > shaver into a power high-voltage outlet".
> 
> In my personal experience, this is absolutely essential when you go 
> higher-order in non-trivial ways - dynamic type errors won't give you 
> the slightest clue when you screw up some combinator plugging. 

Here, I might disagree. Pretty much of what I've been doing in LISP 
so far involved higher order functions in nontrivial ways, to the extent 
of passing anonymous functions which are themselves passed into anonymous 
functions. I never experienced any serious difficulty with it.

But that might perhaps be just because I previously got used to deep 
higher-order programming by doing a lot of SML/NJ.

> (Incidentally, Lisp also isn't very well suited for higher-order 
> programming, because of its syntax issues: no light-weight application 
> syntax and currying.)

Yes, it required some getting used to it, and ML syntax looks somewhat 
nicer here. But this I do not experience as a big issue. Whatever I can do 
in terms of currying in ML I can just as well do in Lisp.

> > (2) Give the compiler hints how to optimize certain manipulations in terms 
> > of machine instructions.
> 
> The latter is actually the least important point. More significant are:

Depends. For quite many applications, speed is an issue. After all, many 
people today go in the direction of doing low-level stuff in C, 
implementing functionality in form of a library, and using Perl or Python
as a high level scripting language for flexibility.

Of course, it's somewhat more convenient not to have such an artificial 
barrier in the system. This can be achieved, with a language that is both 
highly performant and flexible. Both Lisp and Ocaml satisfy this 
criterion, and hence are quite cool systems.

> Type abstraction may not be powerful enough to fully capture units, but 
> it goes a long way. And you cannot seriously argue that something is 
> useless because it does not cover everything.

I don't say it's useless. I just say that as it is it's useless _for me_
personally. I don't want to speak for anyone else here. I'm pretty sure 
many people out there will benefit from ocaml's type system. I, however, 
do not.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[sejourne_kevin]

Oliver Bandel a écrit :
> 9.: Pattern matching, that *really* is functional (seems to be necessary that it works
>     like it is done in logical programming languages like Prolog or similar?

Something like this could be fun (just like Prolog):

(*caml way*)
let test = function
     [(1,a);b;(3,c);(4,d)] ->Printf.printf "%d %d %d \n" a c d; b
   | _ -> failwith "Unification Impossible"
;;
(*half-prolog way*)
let test [(1,a);b;(3,c);(4,d)] =  Printf.printf "%d %d %d \n" a c d; b
and test _ = failwith "Unification Impossible"
;;

The second isn't allow, but it isn't a partial match.

With a logic match, Ocaml could be functionnal, imperative, object and 
logic. Just need a dynamic syntax to have the power of Prolog with the 
power of OCaml... cool. The problem with the logic
match (* | "prefix"^str -> *) is that ^ isn't a constructor but a 
function. I think, the logic match can't be determinist. IHMO, Prolog 
can do it just because all data are term(s) as all 'function'.

Regards,
Kévin

Re: [Caml-list] Estimating the size of the ocaml community

[Damien Doligez]

> On Thu, Feb 03, 2005 at 11:39:50PM +0000, Richard Jones wrote:
>> Got to agree with you on this one ...  At least we'll soon all be
>> using 64 bit computers where OCaml doesn't suffer this limitation.

On Feb 4, 2005, at 11:58, Oliver Bandel wrote:
> Well, but even on those computers will be restrictions in the size.

On 64-bit computers, the maximum string length is 2^56-9 bytes.

> And I'm sure that with more powerful computers, there will be
> more ressource-needing applications/calculations/computations
> and so maybe there will be another problem then (maybe it needs
> some decades to reach that limit?).

If Moore's law holds until then, and starting from a gigabyte now,
it will take about 40 years before you get a machine powerful enough
to run into that limit.  And the transistors of that machine will be
smaller than protons.

I hope we'll get 128-bit machines before then.

-- Damien

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

Hi,

is it this paper ?
http://icwww.epfl.ch/publications/documents/IC_TECH_REPORT_200244.pdf

> ... why not re-implementing the Lists as those vlists?
> (Maybe as a module, if it is too much effort to change the OCaml-core)
Vlist mixed arrays and list (if I have understand the paper, it is a list of
arrays) and are a thus another data structure. but a powerfull data
structure and many ideas could be taken from this paper. I think we could
code this data-structure in Ocaml.

Frédéric

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 01:43:04PM +0000, Richard W. M. Jones wrote:
 
[...]
> Actually, I wouldn't want to change lists.  Those currently have a tag
> = 0, and it would important to leave those untouched for exactly the
> reason you described.
[...]

Some months ago I googled for Ocaml ans lists (or something similar)
and found a paper on OCaml's list implementation, compared to
"vlists" (whatever a vlist may be).
I didn't read the paper completely, but at a glance - if I remember correctly -,
the vlists would be about 10 times faster than OCaml's current list-implementation...

... why not re-implementing the Lists as those vlists?

(Maybe as a module, if it is too much effort to change the OCaml-core)


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 01:51:36PM +0100, Gerd Stolpmann wrote:
[...] 
> If one wanted really to improve the situation, it would be better to change
> the representation of strings, and to encode the string length in the
> first word after the header. This wastes much less memory (except in the
> special case when you have many small strings), and is probably neutral
> for the execution speed.

Well, what is done inside the Buffer-module?
I have not looked inside, but appending strings
with Buffer-module is about 11 times faster than
using "^"-operator in a small program, that
uses string-append-operator ^in a lexer file (ocamllex);
as switching to Buffer-module this speedup was amazing...

Ciao,
   oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 11:11:02AM +0100, Olivier Andrieu wrote:
>  > Frédéric Gava [Fri, 4 Feb 2005]:
>  > > On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher
>  > > wrote:
>  > > > Oh, by the way, there is one more thing which I consider a
>  > > > really grave issue, which gave us quite a lot of grey hair
>  > > > already: Ocaml strings have this stupid limitation to 16 MB,
>  > > > which means in particular that if you serialize a truly large
>  > > > intermediate state of, say, a long and complicated calculation
>  > > > which accidentally got a bit larger than this limit (while you
>  > > > did not expect that), well...
>  > >
>  > > Got to agree with you on this one ...  At least we'll soon all be
>  > > using 64 bit computers where OCaml doesn't suffer this
>  > > limitation.
>  > >
>  > > Rich.
>  > > Richard Jones, CTO Merjis Ltd.
>  > 
>  > Also agree with you.  This limitation is sometime a problem for
>  > me. I code a library in Ocaml for parallel computing, thus I always
>  > serialize values and I could not bench programs which put on the
>  > networks, very big values. 
> 
> AFAIK Marshal.{to,from}_channel isn't limited by the maximum string
> length.

Some weeks ago I explored the Marshal-Module.
While doing some first-steps experiments form within the
toplevel, I got a crash with a SegFault.

IMHO Marshal-module should be removed from the Stdlib.
Or if it is intended to stay, it should be reimplemented,
so that it never can crash in this way!

It's too ugly to rely uon unreliable stuff...


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 07:06:13AM +1100, skaller wrote:
> On Fri, 2005-02-04 at 05:06, Thomas Fischbacher wrote:
> 
> > Anyway, this leaves us with a very interesting question: how many people 
> > actually do believe in the value of Ocaml? I, for myself, use it whenever 
> > it is the most appropriate tool for a job (usually, when portability is 
> > an issue). This is sometimes the case, but more often than not, LISP 
> > turned out to be a better choice for what I do.
> 
> Well ..
> 
> [skaller@pelican] ~/links/flx/src>wc *.ml
>   89737  342248 3223570 total
> 
> 90K Camls here speak for themselves ..
> 
> Ocaml has four downsides from my viewpoint:
> 
> (a) interfacing to C isn't trivial
[...]

Well, compared to Perl, this task IS trivial in OCaml.

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Gerd Stolpmann]

Richard W. M. Jones said:
>> If one wanted really to improve the situation, it would be better to
>> change the representation of strings, and to encode the string length
>> in the first word after the header. This wastes much less memory
>> (except in the special case when you have many small strings), and is
>> probably neutral for the execution speed.
>
> But then you'd need a special case to handle values-containing-
> strings, vs. values-not-containing strings, because you'd always want
> to have the size attribute of the header reflect the size of the data
> in the value.

AFAIK, only the garbarge collector accesses the size attribute in a
generic way. So a special case for strings would be needed. I guess
it is already there, because strings must be handled as opaque data.

Gerd
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 09:41:29AM +0000, Richard Jones wrote:
> On Fri, Feb 04, 2005 at 02:33:40AM +0000, Jon Harrop wrote:
> > 5. More pattern matching: [|1; 2; ...|] and [|...; 2; 1|]. (expressivity)
> 
> And this pattern which could be used all the time in web programming:
> 
>  | "prefix" ^ str ->
> 
> 8. Regular expressions in the language!
> 

9.: Pattern matching, that *really* is functional (seems to be necessary that it works
    like it is done in logical programming languages like Prolog or similar?
    I'm not familiar with Prolog, and maybe I'm wrong here to compare with these languages,
    so I will explain more elaborated what I mean...).

    Explanation: Pattern matches are like nested if's now in OCaml. The Pattern
    that matches first in the code, will be executed!!!
    This is NOT functional, this is imperative behaviour!
    If I change the pattern-matches in the code, the program may behave
    differently (depending on the data that will be matched)!
    
    Maybe there should be ANOTHER kind of pattern match, that does not rely
    on "which matching pattern comes first in the code executes", leaving the
    old/current pattern matching possibilities inside the language.
    But maybe something like "lmatch" (logical match), which does not executes
    the first matching pattern in the code but executes 
    "the ONLY ONE pattern that can match" (because otherwise it should be given an
    pattern match compilation error (where "match" instead of "lmatch" only gives a warning)).

    This also means that, when a general pattern is used twice, and one of them
    uses guards ("when"-clause in a pattern match), then the other pattern does
    only match, when the guard does NOT.
    (Or if there are more than one guard, that they will be checked too, or that a
    guard may be disallowed in such a kind of match.)
    And that it does not has any effect, if one of those pattern
    comes first in the source code (before the other pattern in the code appears).
    This also means to have a more powerful pattern-check on completeness.
    (Now it is not possible to check completelym when using "when" in a pattern match.)

I hope that this would be possible to integrate into OCaml (regarding the code as well
as theoretical aspects of the type-system itself).

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 10:29:53AM +0100, Thomas Fischbacher wrote:

[...]
> If I multiply a speed (in m/s) with a mass (in kg),
> I get a momentum (in kg m/s), which I neither can sensibly add to a 
> speed, or a mass. If I further consider a change in momentum with time, I 
> automatically get something with units kg m/s^2, that is, a force.
> 
> Of course, I could introduce types for all intermediate quantities which I 
> will encounter in a problem statically. However, there are many problems 
> where I do not know a priori which quantities will appear with which 
> powers, hence I would like to have this with full dynamical flexibility. 

So, you have to decide, what you want: Flexibility or not?
If you want clearly typed values, you can use a language
that supports it. If not, use a language that ignores types.

But as you said above: Yes, it's necessary to have distinct types that
doesn't match and are clearly distinct and incompatible to
avoid problems where mixing up different types would be a problem.

In your example: "a momentum (in kg m/s), which I neither can sensibly
 add to a speed, or a mass."

So strictly checking types is really helpful here.

In OCaml you can use the module system to be helpful here (abstract data types).
It is possible to define incompatible types, which are also can be restricted
by value and to raise exceptions from within that types.
And because of functors it's also possible to use the same structure
but by using signatures it can be done that the types are differing.

There is an example on this in the Ocaml-book from O'Reilley.
Look for subsection "Hiding Type Implementations" in section
"Modules and Information Hiding" in Chapter 14 ("Programming with Modules").


The type system of OCaml has helped me a lot in even smaller
programs to avoid problems that would be there, when using
languages like C, where the "type system" is very loosely,
would have caused many problems. Especially when using pointer-stuff,
many Segfaults may would have appeared in the program run
(and hopefully in the testing phase), where the type system has
stopped me.

How much more helpful will it be in larger/large projects!

I didn't believe that the type system really supports the programmer
until I have worked a while with it, and especially (as mentioned
by others here), when changing code that is older (and where you
may have forgotten a lot of the program's structure because it's too
long ago, when you touched the code the last time).

In the beginning I similar to you thought: "Well, people say it might
help, and so it might help... but I really find it annoying!".
Now I see: Well, it might be annoying, when you are new to it, but
I now can see *through experience* that it DOES help in programming.
Even in small programs it is helpful!


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Richard W. M. Jones]

On Fri, Feb 04, 2005 at 01:51:36PM +0100, Gerd Stolpmann wrote:
> Sure, this is an option, but I think the price is quite high. A number of
> frequently used data structures would need a lot more memory, and would
> become slower. For example lists. Currently, every list element needs
> three words (header + contents + reference to next element). If the
> variant tag is not part of the header, another word is needed = 33 %
> more space. There are similar effects for many basic data
> structures, including options, trees and hash tables.

Actually, I wouldn't want to change lists.  Those currently have a tag
= 0, and it would important to leave those untouched for exactly the
reason you described.

Of course, now you've pointed out the flaw in my argument, which is
that lists would be handled differently from constructs :-)

> If one wanted really to improve the situation, it would be better to change
> the representation of strings, and to encode the string length in the
> first word after the header. This wastes much less memory (except in the
> special case when you have many small strings), and is probably neutral
> for the execution speed.

But then you'd need a special case to handle values-containing-
strings, vs. values-not-containing strings, because you'd always want
to have the size attribute of the header reflect the size of the data
in the value.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Gerd Stolpmann]

Richard Jones said:
> I've been thinking about this a bit more, and I'm not sure I
> understand why the tag needs to be so large.  If you look at the "tag
> space" now, it's something like this:
>
> 0	used for tuples, arrays, records
> 1-251	used for constructors (eg. Some, None)
> 252	marks strings
> 253 	marks floats
> 254	marks float arrays
> 255	marks structures with custom ops (lots of stuff, like Int32.t)
>
> It's not clear to me why so much "tag space" is used for constructed
> values, at the same time limiting you to around 250 different
> constructors in a type definition.  Couldn't the constructor number be
> encoded in the first field in the value (obviously shifting all the
> subsequent fields along one, and making constructed values 4 bytes
> larger)?  Then the tag could be reduced to a few bits, making strings a
> few orders larger.

Sure, this is an option, but I think the price is quite high. A number of
frequently used data structures would need a lot more memory, and would
become slower. For example lists. Currently, every list element needs
three words (header + contents + reference to next element). If the
variant tag is not part of the header, another word is needed = 33 %
more space. There are similar effects for many basic data
structures, including options, trees and hash tables.

>From a practical point of view, the non-polymorphic variants are still
part of the language because they are more efficient than the polymorphic
counterparts (which could fully replace the former, and for which there
is no limit for the number of constructors).

If one wanted really to improve the situation, it would be better to change
the representation of strings, and to encode the string length in the
first word after the header. This wastes much less memory (except in the
special case when you have many small strings), and is probably neutral
for the execution speed.

Gerd
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

Re: [Caml-list] Estimating the size of the ocaml community

[Marcin 'Qrczak' Kowalczyk]

Richard Jones <rich@annexia.org> writes:

> 0	used for tuples, arrays, records
> 1-251	used for constructors (eg. Some, None)
> 252	marks strings
> 253 	marks floats
> 254	marks float arrays
> 255	marks structures with custom ops (lots of stuff, like Int32.t)
>
> It's not clear to me why so much "tag space" is used for constructed
> values, at the same time limiting you to around 250 different
> constructors in a type definition.  Couldn't the constructor number be
> encoded in the first field in the value (obviously shifting all the
> subsequent fields along one, and making constructed values 4 bytes
> larger)?  Then the tag could be reduced to a few bits, making strings
> a few orders larger.

If all constructed values were larger, it would be a noticeable
overhead. For example a list of ints would take 4/3 times more space
than currently.

IMHO a better design would distinguish fixed size blocks from variable
length blocks and enlarge only the latter. For example:
- fixed size blocks: 15 bits of the tag, 15 bits of the size
  (assuming a 32-bit platform)
- variable size blocks (arrays and strings): a special value in the
  header, the actual length is in the next field

As for unifying strings with char arrays, it would make all array
accesses slower. They already have a performance hit because of float
arrays; in particular almost all functions from the Array module make
a conditional jump for float arrays in their inner loops.

IMHO it would be better if float arrays were a separate type, and the
type system would somehow allow writing code which is generic wrt. the
type of the sequence. Then more kinds of arrays could be added without
increasing the overhead for plain arrays, e.g. bool arrays as packed
bits.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Re: [Caml-list] Estimating the size of the ocaml community

[Olivier Andrieu]

 > Frédéric Gava [Fri, 4 Feb 2005]:
 > > AFAIK Marshal.{to,from}_channel isn't limited by the maximum
 > > string length.
 > >...
 > >    Olivier
 > 
 > OK. Right but you can not all the time used channels... For TCP/IP,
 > that is possible, but for low level libraries (as MPI, PVM, PUB
 > etc...) you need strings and you are blocked by this limitation
 > (except if you read the values from a file but in this case it is
 > not a fast solution).

If you're interfacing with a C library you have yet another option :
serialize to a malloc block. That's what these low level libraries
should use. 

,----[ intext.h ]
| CAMLextern void caml_output_value_to_malloc(value v, value flags,
|                                             /*out*/ char ** buf,
|                                             /*out*/ long * len);
| CAMLextern value caml_input_value_from_malloc(char * data, long ofs);
`----

-- 
   Olivier

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Fri, Feb 04, 2005 at 12:14:31PM +0100, Fr?d?ric Gava wrote:
> >It's a problem of the implementation, but one which looks hard to
> >change.  The reason it arises is because each OCaml value has a 4
> >byte[*] header, divided into a 1 byte tag, 2 bits for the GC, and the
> >remaining 22 bits to store the size of the value in words.  Since
> >strings are stored directly in the value (which is very efficient),
> >they are limited to 4 * (2^22 - 1) bytes ~ 16 MB in size.
> Sure it is a hard problem. But I thinks that in the futur (now my bench are
> not bench of true applications but bench of the limits of the language,
> values that exceed 16Mo are rare), true scientific applications will need to
> serialize big values...(big graphs for example)

I've been thinking about this a bit more, and I'm not sure I
understand why the tag needs to be so large.  If you look at the "tag
space" now, it's something like this:

0	used for tuples, arrays, records
1-251	used for constructors (eg. Some, None)
252	marks strings
253 	marks floats
254	marks float arrays
255	marks structures with custom ops (lots of stuff, like Int32.t)

It's not clear to me why so much "tag space" is used for constructed
values, at the same time limiting you to around 250 different
constructors in a type definition.  Couldn't the constructor number be
encoded in the first field in the value (obviously shifting all the
subsequent fields along one, and making constructed values 4 bytes
larger)?  Then the tag could be reduced to a few bits, making strings
a few orders larger.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

> AFAIK Marshal.{to,from}_channel isn't limited by the maximum string
> length.
>...
>    Olivier

OK. Right but you can not all the time used channels... For TCP/IP, that is
possible, but for low level libraries (as MPI, PVM, PUB etc...) you need
strings and you are blocked by this limitation (except if you read the
values from a file but in this case it is not a fast solution).

>It's a problem of the implementation, but one which looks hard to
>change.  The reason it arises is because each OCaml value has a 4
>byte[*] header, divided into a 1 byte tag, 2 bits for the GC, and the
>remaining 22 bits to store the size of the value in words.  Since
>strings are stored directly in the value (which is very efficient),
>they are limited to 4 * (2^22 - 1) bytes ~ 16 MB in size.
>...
>Richard Jones, CTO Merjis Ltd.
Sure it is a hard problem. But I thinks that in the futur (now my bench are
not bench of true applications but bench of the limits of the language,
values that exceed 16Mo are rare), true scientific applications will need to
serialize big values...(big graphs for example)


Frédéric Gava

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Thu, Feb 03, 2005 at 11:39:50PM +0000, Richard Jones wrote:
> On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
> > Oh, by the way, there is one more thing which I consider a really
> > grave issue, which gave us quite a lot of grey hair already: Ocaml 
> > strings have this stupid limitation to 16 MB, which means in particular 
> > that if you serialize a truly large intermediate state of, say, a long 
> > and complicated calculation which accidentally got a bit larger than this 
> > limit (while you did not expect that), well...
> 
> Got to agree with you on this one ...  At least we'll soon all be
> using 64 bit computers where OCaml doesn't suffer this limitation.

Well, but even on those computers will be restrictions in the size.
And I'm sure that with more powerful computers, there will be
more ressource-needing applications/calculations/computations
and so maybe there will be another problem then (maybe it needs
some decades to reach that limit?).

Is the 16MB string-length really a hardware-dependency?
Maybe changing string-representation could help even
on 32 Bit machines to have not such a problem.
But maybe a BigStrings/LongStrings-module would do that
better (because changing the string-representation in the OCaml-core
may be a harder problem...?!)

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
[...] 
> Oh, by the way, there is one more thing which I consider a really
> grave issue, which gave us quite a lot of grey hair already: Ocaml 
> strings have this stupid limitation to 16 MB, which means in particular 
> that if you serialize a truly large intermediate state of, say, a long 
> and complicated calculation which accidentally got a bit larger than this 
> limit (while you did not expect that), well...

Well, maybe there should be a BigStrings- or LongStrings-Module
introduced into OCaml-stdlib?

But: When you mean with "a long and complicated calculation"
using larger int/float-values you may use
the num-library.
E.g. in module Num there is a  string_of_num-function.
Do you really think, the results will be larger than 16MB?

Or what kind of computation do you think about?

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Thu, Feb 03, 2005 at 10:16:33PM +0100, Thomas Fischbacher wrote:
[...]
> (3) The type system is annoying. People claim it helps catching errors, 
> but my impression is it only catches those which I would never make 
> anyway.
[...]

Well if it catches only errors you never make, you should
never had any warnings nor error messages from the type
system.
So, why is it annoying, if you never get a warning/error message?

Normally you should not be aware of the type system, because you
do not make type-system-errors.

?!


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Andreas Rossberg]

Thomas Fischbacher wrote:
> 
> One issue with the type system is that, looking closely, there are at 
> least two (perhaps three) very different tasks it tries to do, which 
> superficially look like being the same, but actually are very different, 
> and indeed, in many situations, it may be much more appropriate to 
> address them specifically and individually than with an unified approach.
> 
> (1) Prevent the programmer from "accidentally plugging an electrical 
> shaver into a power high-voltage outlet".

In my personal experience, this is absolutely essential when you go 
higher-order in non-trivial ways - dynamic type errors won't give you 
the slightest clue when you screw up some combinator plugging. 
(Incidentally, Lisp also isn't very well suited for higher-order 
programming, because of its syntax issues: no light-weight application 
syntax and currying.)

> (2) Give the compiler hints how to optimize certain manipulations in terms 
> of machine instructions.

The latter is actually the least important point. More significant are:

(3) Verified documentation. Provide a stylised language for describing 
interfaces, and have the compiler actually check these "comments", so 
that they never get out of date.

(4) Maintenance. Provide guidance when modifying a program non-locally 
by letting the compiler point out the locations of the minimum set of 
obliged changes.

(5) Abstraction. Enable the programmer to define her own abstract types, 
for compile-time encapsulation and invariant enforcement.

The latter is also known as "typeful programming" (cf. Luca Cardelli's 
seminal article of the same name). That is where advanced type systems 
really start to score, and what people with arguments of the sort "a 
type system only catches trivial errors" usually overlook completely.

Type abstraction may not be powerful enough to fully capture units, but 
it goes a long way. And you cannot seriously argue that something is 
useless because it does not cover everything.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

Re: [Caml-list] Estimating the size of the ocaml community

[Olivier Andrieu]

 > Frédéric Gava [Fri, 4 Feb 2005]:
 > > On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher
 > > wrote:
 > > > Oh, by the way, there is one more thing which I consider a
 > > > really grave issue, which gave us quite a lot of grey hair
 > > > already: Ocaml strings have this stupid limitation to 16 MB,
 > > > which means in particular that if you serialize a truly large
 > > > intermediate state of, say, a long and complicated calculation
 > > > which accidentally got a bit larger than this limit (while you
 > > > did not expect that), well...
 > >
 > > Got to agree with you on this one ...  At least we'll soon all be
 > > using 64 bit computers where OCaml doesn't suffer this
 > > limitation.
 > >
 > > Rich.
 > > Richard Jones, CTO Merjis Ltd.
 > 
 > Also agree with you.  This limitation is sometime a problem for
 > me. I code a library in Ocaml for parallel computing, thus I always
 > serialize values and I could not bench programs which put on the
 > networks, very big values. 

AFAIK Marshal.{to,from}_channel isn't limited by the maximum string
length.

-- 
   Olivier

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Richard Jones wrote:

> 8. Regular expressions in the language!

There's a library for it. And indeed, looking at the evolution of perl, I 
would say that the way how regexps are integrated there is a mistake.

The problem is that they are static in original perl.


Last time I gave a course on perl, I found out that there is a very nice 
and convenient way to systematically explore many of its design mistakes: 
take language feature X (arrays, regexps, functions, whatever), and ask 
to yourself the question: how would you write a function that takes as 
argument a number N and generates N entities of the thingy under 
consideration that are provably different (and actually does prove this).

Perl's arrays are very different from arrays in almost any other language 
- they try to catch a natural-language "plural" concept. But when one 
wants to address "this collection" directly, instead of just "those 
values", one needs a different handle.

Original attempts to address such questions involved some - I'd say highly 
misguided - "symbolic reference to variable name" approaches. They more or 
less have been abandoned now, for good ("use strict"). By now, perl has 
an anonymous array constructor [].


Concerning regexps, one originally could make them dynamical only via

/$interpolation/

...but then, they have to be recompiled every time they are executed. 
Hence, people "added state to locations in the code" (as they 
previously did with ".." and such) and provided /o.

Of course, this also turned out to be stupid! Think about passing 
different regexps into a function.

So, by now, we *in addition* have

qr()

and some further quite ugly compiled-regexp-interpolation mechanism.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Fri, Feb 04, 2005 at 02:33:40AM +0000, Jon Harrop wrote:
> 5. More pattern matching: [|1; 2; ...|] and [|...; 2; 1|]. (expressivity)

And this pattern which could be used all the time in web programming:

 | "prefix" ^ str ->

8. Regular expressions in the language!

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Fri, Feb 04, 2005 at 10:04:20AM +0100, Fr?d?ric Gava wrote:
> But this problem is a problem of the implementation and not a
> problem of language design. Maybe in the futur, this limitation
> would be deleted.

It's a problem of the implementation, but one which looks hard to
change.  The reason it arises is because each OCaml value has a 4
byte[*] header, divided into a 1 byte tag, 2 bits for the GC, and the
remaining 22 bits to store the size of the value in words.  Since
strings are stored directly in the value (which is very efficient),
they are limited to 4 * (2^22 - 1) bytes ~ 16 MB in size.  Any other
representation would penalise the common case (short strings) - for
example, having strings represented as a (length, pointer) tuple would
cause an extra indirection; and having long strings represented with a
special "all 1s" length would penalise the code all over the place.

So not easy to fix.

Rich.

[*] On 32-bit platforms.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Ville-Pertti Keinonen wrote:

> > (2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
> > any language besides LISP (or rather, Scheme).
> 
> Usually what someone considers "unnecessary cruft" is defined by what
> they're used to.  People are used to the annoyances of the languages
> they use the most and don't tend to notice them, but when using a less
> familiar language, pay a lot of attention to anything that seems more
> cumbersome.
> 
> As an obvious example, neither Common Lisp or Scheme have
> pattern-matching.  Accessing data via pattern matching is often far more
> convenient than via c[ad]+r, slot accessors etc.

Sure! But Lisp gives me the freedom to add it via a library. Which also 
kind of says that it's unnecessary to complicate the core language by 
putting in such a conceptually ad-hoc feature.

Of course, from the LISP point of view, virtually anything that's done by 
other languages is conceptually ad-hoc, and can easily be added by 
extending the language. ;-)

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Jon Harrop wrote:

> > (3) The type system is annoying. People claim it helps catching errors,
> > but my impression is it only catches those which I would never make
> > anyway.
> 
> Static type checking is completely fundamental to OCaml. Consequently, I think 
> that's a really silly thing to say here but your next comment implies that 
> you don't know what static type checking is for:

Well, I might want to differ here, but I should perhaps also add that I 
indeed do only know about as much about the structure of the 
Hindley-Milner-like type system of Ocaml as is the common subset of 
Haskell, SML/NJ and Ocaml.

Yes, it's fundamental to those languages, and indeed I originally thought 
this would be a great thing, years ago, when I came to SML/NJ from C++. 
Right now, after a few years of Lisp experience, my personal impression is 
that actually, it is more a hindrance than a help. But of course, one may 
always say that we Lisp hackers just are spoilt by our language in this 
aspect. By the way, Paul Graham seems not to like the ML family for about 
precisely the same reason.

One issue with the type system is that, looking closely, there are at 
least two (perhaps three) very different tasks it tries to do, which 
superficially look like being the same, but actually are very different, 
and indeed, in many situations, it may be much more appropriate to 
address them specifically and individually than with an unified approach.

(1) Prevent the programmer from "accidentally plugging an electrical 
shaver into a power high-voltage outlet".

(2) Give the compiler hints how to optimize certain manipulations in terms 
of machine instructions.

Concerning (1), from the machine point of view, there is no difference 
between a floatingpoint number representing a length in meters and a 
floatingpoint number representing a length in feet. Nevertheless, one 
should not blindly add the one to the other, as NASA by now surely can 
tell you. And indeed, the system of physical units, be it SI or something 
even more elaborate, exists precisely to prevent such problems, yet there 
are aspects of this "type system", which has proven its value, which can 
not be mapped to Hindley-Milner.

If I multiply a speed (in m/s) with a mass (in kg),
I get a momentum (in kg m/s), which I neither can sensibly add to a 
speed, or a mass. If I further consider a change in momentum with time, I 
automatically get something with units kg m/s^2, that is, a force.

Of course, I could introduce types for all intermediate quantities which I 
will encounter in a problem statically. However, there are many problems 
where I do not know a priori which quantities will appear with which 
powers, hence I would like to have this with full dynamical flexibility. 
Please prove me wrong if I am missing something here, but to me it seems 
that even for this simple "real-world type system" example, there is no 
way to directly map this to H.M. in the way explained here.

And this is only *one* example. There are many more, of structures that 
morally qualify as type systems, but cannot be related to H.M.

> > (4) There are a few other minor issues, such as a lack of
> > multiple-value-bind, which I personally find slightly annoying, but
> > not essential.
> 
> I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1, 
> 2, 3".

Let's take a specific example.

* (/ 1234 100)

617/50
* (round 1234 100)

12
34

The division function in LISP returns one value. The ROUND function 
returns two. If I use it as in 

* (+ 5 (round 1234 100))

17

it behaves as if it were a function that gives me only the primary value. 
But if I want it, I also can bind and process the secondary (or even 
higher) extra values returned by that function.

So it's even more than "just returning more than one value without having 
to cons" (which already is quite nice - but this essentially can always be 
emulated via going to CPS, which establishes full call/return symmetry). 
It's about giviny gou extra choice. Either: "Nice that you can also 
provide me extra information, but I really don't care here", or: "I can 
as well make use of this other piece of information which you 
already obtained anyway." Same function, same call.

> > (9) It really annoys having +, +., and +/.
> 
> There is a trade-off between type checking and operator overloading. This has 
> been discussed at great length before and a lot of interesting information 
> can be found by perusing the mailing list archives.

Sure. I don't quite know what to think about Haskell's type classes, but 
superficially it feels quite much more convenient. Anyway, it may as well 
be here that the impression which one gets by working heavily with it is 
a different one, so I'll keep an eye on that but surely not take it as the 
only True Revelation.

> > > I don't see how this and Printf are substantially different (except that
> > > Printf is type safe),
> > > could you elaborate?
> >
> > Erm, what do you do if you want to quickly debug-print a list of vectors
> > of pairs?
> 
> Use the top-level.

That entirely misses the point!

I talked about getting debug traces from an involved run.

> Anyhow, despite these few and minor shortcomings, OCaml is by far the best 
> language I have ever come across.

Nice if it suits you well. I personally experience some friction with 
it, however.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

> On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
> > Oh, by the way, there is one more thing which I consider a really
> > grave issue, which gave us quite a lot of grey hair already: Ocaml
> > strings have this stupid limitation to 16 MB, which means in particular
> > that if you serialize a truly large intermediate state of, say, a long
> > and complicated calculation which accidentally got a bit larger than
this
> > limit (while you did not expect that), well...
>
> Got to agree with you on this one ...  At least we'll soon all be
> using 64 bit computers where OCaml doesn't suffer this limitation.
>
> Rich.
> Richard Jones, CTO Merjis Ltd.

Also agree with you.  This limitation is sometime a problem for me. I code a
library in Ocaml
for parallel computing, thus I always serialize values and I could not bench
programs which put on the networks, very big values. But this problem is a
problem of the implementation and not a problem of language design. Maybe in
the futur, this limitation would be deleted. "Int" are also limited (except
using num.cma) and so "string" are limited for  an access reason. Peraps in
the futur, we could serialize values to another things than string (another
data structure) and unmarshaled those sepcial data structures to
values....and having  only 4 functions:
to_channel: out_channel -> 'a -> extern_flags list -> unit
from_channel: in_channel -> 'a
to_serialize: 'a -> extern_flags list -> t
from_serialize: t -> 'a
where t is an abstract data type of marshaled values....

Regards,
Frédéric Gava

Re: [Caml-list] Estimating the size of the ocaml community

[Ville-Pertti Keinonen]

On Thu, 2005-02-03 at 22:16 +0100, Thomas Fischbacher wrote:

> There are quite a few things which I don't like at all about ocaml:

I hope you don't mind getting yet another set of comments...

> (1) I by far do not have the flexibility in extending the language with 
> own syntax which I have in Lisp.

This is true.

> (2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
> any language besides LISP (or rather, Scheme).

Usually what someone considers "unnecessary cruft" is defined by what
they're used to.  People are used to the annoyances of the languages
they use the most and don't tend to notice them, but when using a less
familiar language, pay a lot of attention to anything that seems more
cumbersome.

As an obvious example, neither Common Lisp or Scheme have
pattern-matching.  Accessing data via pattern matching is often far more
convenient than via c[ad]+r, slot accessors etc.  While many Scheme
implementations do have pattern matching as an extension, the syntax is
more verbose and it doesn't give you the nice symmetry between
constructing and deconstructing values.

In my experience, unless you're using a lot of "ad hoc" data structures
or not checking for errors, OCaml is usually less verbose than Scheme.
When comparing to Common Lisp...it depends on how much magic you're
using.

> (6) I cannot easily COMPILE a function to fast machine code from the REPL.

A runtime for OCaml that would be more like Common Lisp implementations
or SML/NJ would be an interesting project.

I don't think it would be too difficult, either (based on experimenting
with replacing the asmcomp back-end).

> (7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).

This could also be addressed by a more advanced runtime that always
included the top-level.

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Fri, 2005-02-04 at 07:50, chris.danx wrote:

> > (b) native code compiler on x86 can't make a shared library

> I didn't realise the native code compiler on x86 couldn't do this.  What 
> exactly is the problem?

Xavier doesn't rate the work involved a high priority.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

[Caml-list] Estimating the size of the ocaml community

[Michael Walter]

On Fri, 4 Feb 2005 02:33:40 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > On the other hand, I cannot just have e.g. a function like
> > POSITION-IF that returns a number or nil. (Either one has to work with
> > exceptions, or wrap things up using the Maybe monad. Exception techniques
> > may interfere badly with tail recursion in some cases.)
>
> I think you will find that "int option" does exactly what you want whilst also
> statically type checking the result.
Although you can certainly disagree with the judgement (which I will
freely paraphrase with "using Maybe is inelegant"), I cannot see how
you are able to judge Thomas' knowledge of the usefulness of static
type checking based on a statement which you comment by partly
repeating what he said ;-)

> Let me recite my personal experience with static type checking. A couple of
> years ago, C++ was my latest language. I developed a significant project in
> C++ until I realised that the core of my implementation was fundamentally
> flawed and needed rewriting in order to achieve my objectives. This rewrite
> would have taken over a month. Thus, I gave up. Later, I decided to learn
> ocaml and porting my project seemed like a worthy task. The ported code was
> 1/4 as long and almost as fast. I've made two more fundamental changes since
> then, both of which would have been infeasible in C++.
Interesting. In my experience it's similarly simple to refactor in C++
as in languages with more sophisticated type systems (to answer the
obligatory question, yes, I'm working on large projects). I've had
similar experiences with dynamic languages like Scheme and Python,
though (compared to statically typed ones).

> When using C++, I always had to restrain myself from making major changes, as
> they were bound to break the program and were often irreparable. In contrast,
> when I make a fundamental change to the ocaml implementation, the static type
> checker immediately leads me to all of the new misuses of the altered code.
> This allows me to make much deeper changes without having to worry about
> spending months debugging the surrounding code. The last time I made such a
> change it took a day to get the program working again, rather than a month.
Are you using heavy casting and such without proper abstractions in
your C++ code? Pr what kind of changes did you want to make? How did
you feel that the static type checker of C++ didn't provide you with
similar help?

> Thanks to all these major changes, the latest ocaml version is vastly faster
> than the old C++. :-)
>
> > (4) There are a few other minor issues, such as a lack of
> > multiple-value-bind, which I personally find slightly annoying, but
> > not essential.
>
> I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1,
> 2, 3".
It's a macro in Common Lisp (see [1]). In O'caml-ish syntax, it also
does "let a, b = 1, 2, 3" (3 is discarded) and "let a, b, c = 1, 2" (c
is bound to nil).

> > (9) It really annoys having +, +., and +/.
>
> There is a trade-off between type checking and operator overloading. This has
> been discussed at great length before and a lot of interesting information
> can be found by perusing the mailing list archives.
>
> I shall remain skeptical that GCaml improves upon this solution this until I
> get to write a decent-sized project in GCaml. I am keen to see GCaml though.
FWIW, I find this works lovely in Haskell. :-)

Michael

[1] http://www.lisp.org/HyperSpec/Body/mac_multiple-value-bind.html

Re: [Caml-list] Estimating the size of the ocaml community

[Jon Harrop]

On Thursday 03 February 2005 21:16, Thomas Fischbacher wrote:
> (3) The type system is annoying. People claim it helps catching errors,
> but my impression is it only catches those which I would never make
> anyway.

Static type checking is completely fundamental to OCaml. Consequently, I think 
that's a really silly thing to say here but your next comment implies that 
you don't know what static type checking is for:

> On the other hand, I cannot just have e.g. a function like 
> POSITION-IF that returns a number or nil. (Either one has to work with
> exceptions, or wrap things up using the Maybe monad. Exception techniques
> may interfere badly with tail recursion in some cases.)

I think you will find that "int option" does exactly what you want whilst also 
statically type checking the result.

Let me recite my personal experience with static type checking. A couple of 
years ago, C++ was my latest language. I developed a significant project in 
C++ until I realised that the core of my implementation was fundamentally 
flawed and needed rewriting in order to achieve my objectives. This rewrite 
would have taken over a month. Thus, I gave up. Later, I decided to learn 
ocaml and porting my project seemed like a worthy task. The ported code was 
1/4 as long and almost as fast. I've made two more fundamental changes since 
then, both of which would have been infeasible in C++.

When using C++, I always had to restrain myself from making major changes, as 
they were bound to break the program and were often irreparable. In contrast, 
when I make a fundamental change to the ocaml implementation, the static type 
checker immediately leads me to all of the new misuses of the altered code. 
This allows me to make much deeper changes without having to worry about 
spending months debugging the surrounding code. The last time I made such a 
change it took a day to get the program working again, rather than a month.

Thanks to all these major changes, the latest ocaml version is vastly faster 
than the old C++. :-)

> (4) There are a few other minor issues, such as a lack of
> multiple-value-bind, which I personally find slightly annoying, but
> not essential.

I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1, 
2, 3".

> (9) It really annoys having +, +., and +/.

There is a trade-off between type checking and operator overloading. This has 
been discussed at great length before and a lot of interesting information 
can be found by perusing the mailing list archives.

I shall remain skeptical that GCaml improves upon this solution this until I 
get to write a decent-sized project in GCaml. I am keen to see GCaml though.

> Furthermore, it seems a bit 
> inconsistent, as on the other hand, we have e.g. < and not </.

The arithmetic operators have types '_a -> '_a -> '_a for some 'a whereas the 
comparisons have types 'a -> 'a -> bool for all 'a. This is because 
arithmetic operators are well-defined for some types (e.g. int and float) but 
there are well-defined comparison operators for all but some types (i.e. 
except closures). Hence the use of monomorphic and polymorphic types (and 
exceptions), respectively.

Again, this has already been discussed at length on the mailing list.

On Thursday 03 February 2005 23:22, Thomas Fischbacher wrote:
> > type position = Position of int | None;;
>
> That is isomorphic to a straightforward application of the Maybe monad,
> I'd say. After all, you are just boxing up your int here. Furthermore, you
> have to define that particular type globally, as far as I understand it.

Use the "'a option" type defined in Pervasives.

> > I don't see how this and Printf are substantially different (except that
> > Printf is type safe),
> > could you elaborate?
>
> Erm, what do you do if you want to quickly debug-print a list of vectors
> of pairs?

Use the top-level.

On Thursday 03 February 2005 23:39, Richard Jones wrote:
> On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
> > Oh, by the way, there is one more thing which I consider a really
> > grave issue, which gave us quite a lot of grey hair already: Ocaml
> > strings have this stupid limitation to 16 MB, which means in particular
> > that if you serialize a truly large intermediate state of, say, a long
> > and complicated calculation which accidentally got a bit larger than this
> > limit (while you did not expect that), well...
>
> Got to agree with you on this one ...  At least we'll soon all be
> using 64 bit computers where OCaml doesn't suffer this limitation.

Yes. In the mean time, I'm using lists of O(1)-length strings, which is 
working well.

I'd obviously like more comprehensive standard library and bindings to other 
libraries but, as far as the core language goes, I vote for (for these 
reasons):

1. Arbitrary-length strings and arrays. (robustness)
2. Version- and type-safe marshalling. (robustness)
3. Compiler warnings when run-time type errors may occur, e.g. when 
marshalling a data structure which might contain a closure. (robustness)
4. Extensible strings and arrays. (asymptotic complexity)
5. More pattern matching: [|1; 2; ...|] and [|...; 2; 1|]. (expressivity)
6. Dynamic code generation. (to ease compiler writing)
7. More optimisation, e.g. inlining across functors built-in to the compiler. 
(performance)

If there were a redesign, I'd ask for "string" as "char array" and 
monomorphisation of polymorphic functions. Perhaps the latter can be achieved 
with a preprocessor?

Anyhow, despite these few and minor shortcomings, OCaml is by far the best 
language I have ever come across.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Re: [Caml-list] Estimating the size of the ocaml community

[Michael Walter]

On Fri, 4 Feb 2005 00:22:47 +0100 (CET), Thomas Fischbacher wrote:
> When I first encountered Lisp, I also found it "ugly", due to the
> parentheses. Only later, I learned to understand. One cannot and
> should not judge this peculiarity of Lisp from the viewpoint of an
> outsider.
> 
> I'm pretty sure (1) musical notation, (2) heavy-handed uses of tensor
> notation in supergravity, (3) any other comparable highly specialized
> notational system must look exceedingly scary to the uninitiated as well.

I think part of the problem is that those are domain-specific
notations, whereas S-expressions are used for general purpose (in the
domain of expressing programs = data).

Differently put, in that they are syntax they try to cover a "broader"
(not in the "there are xxx musicians and yyy coders" sense) domain
than in what they are useful (the domain of generically representing
expressions).

A naive and not quite matching example of what I mean is that musical
notation isn't used for encoding sample data.

Some ex-developer of the Dylan language makes some interesting points
about S expressions in a response to Arc (in the feedback on Arc text
file on paulgraham.com).

Michael

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
> Oh, by the way, there is one more thing which I consider a really
> grave issue, which gave us quite a lot of grey hair already: Ocaml 
> strings have this stupid limitation to 16 MB, which means in particular 
> that if you serialize a truly large intermediate state of, say, a long 
> and complicated calculation which accidentally got a bit larger than this 
> limit (while you did not expect that), well...

Got to agree with you on this one ...  At least we'll soon all be
using 64 bit computers where OCaml doesn't suffer this limitation.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[sejourne_kevin]

thx for the troll.

Kévin.
Regards.

Re: [Caml-list] Estimating the size of the ocaml community

[Sylvain LE GALL]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> 
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?
> 

Hello,

I know that a lot of course of Ecole Polytechnique ( X ) in IT use OCaml
as a support ( maybe it comes from the fact that some OCaml developper are
teaching here : Didier Remy, Luc Maranget... ). I learn OCaml there, and
i still use it on a daily basis / but not at work.

Regard
Sylvain Le Gall

ps : i don't have any problems concerning OCaml, i think it is a great
programming language, i thank the INRIA for giving us such a good tool.

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Thu, 3 Feb 2005, Bardur Arantsson wrote:

> > >(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" 
> > >bla).
> 
> > I don't quite follow; is there something wrong with Printf?
> 
> It can only print simple values, not compound values such as records,
> objects, etc... Well, alright, it can use a custom printer, but there
> shouldn't really be any need to have to write custom printers for
> e.g. records when it's patently obvious how they should be printed (in
> the absence of a more specific format).

Boy, it *does* suck if you just discovered a hairy problem and have to put 
all your time and energy into resolving this and then are 
annoyed/distracted/slowed down by the necessity to work on "ballast code",
like writing special-purpose debug-printing functions ad-hoc.

In Perl, one can at least use Data::Dumper for that purpose, as a 
substitute for Lisp's print/read consistency of structured data(*). 
Whenever I give a perl course, I make sure all my students do know how to 
use it for good.

(*) Which, by the way, is already 95% of what people recently 
"re-discovered" as XML, modulo unnecessarily cluttered syntax and the 
inability to serialize networked, self-referencing values on the one side, 
and i18n on the other.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Thu, Feb 03, 2005 at 10:16:33PM +0100, Thomas Fischbacher wrote:
> (7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).

IIRC that dumps out the variable 'bla', right?  I wrote a trivial
little library to print out OCaml structures, which I've just checked
in and uploaded here:

http://merjis.com/developers/dumper

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Thu, 3 Feb 2005, josh wrote:

> Thomas Fischbacher wrote:
> 
> > There are quite a few things which I don't like at all about ocaml:
> 
> >(1) I by far do not have the flexibility in extending the language with 
> >own syntax which I have in Lisp.
> >  
> >
> But you do with camlp4.

Well, I don't quite think so. But this would need a more detailed 
discussion. Maybe later, when I find time for this... But I think, at 
least the power of macrolet is a good point in favor of Lisp.

> >(2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
> >any language besides LISP (or rather, Scheme).
> >  
> >
> I'm going to leave this alone,  Lisp derived languages all have the 
> Parenthesis problem that makes
> them "ugly" as defined by a lot of people.

When I first encountered Lisp, I also found it "ugly", due to the 
parentheses. Only later, I learned to understand. One cannot and 
should not judge this peculiarity of Lisp from the viewpoint of an 
outsider.

I'm pretty sure (1) musical notation, (2) heavy-handed uses of tensor 
notation in supergravity, (3) any other comparable highly specialized 
notational system must look exceedingly scary to the uninitiated as well.

> >(3) The type system is annoying. People claim it helps catching errors, 
> >but my impression is it only catches those which I would never make 
> >anyway. On the other hand, I cannot just have e.g. a function like 
> >POSITION-IF that returns a number or nil. (Either one has to work with 
> >exceptions, or wrap things up using the Maybe monad. Exception techniques 
> >may interfere badly with tail recursion in some cases.)
> >  
> >
> My response is contrived, but does not require monads or exceptions and 
> does basically what you're asking for ( I think):
> 
> type position = Position of int | None;;

That is isomorphic to a straightforward application of the Maybe monad, 
I'd say. After all, you are just boxing up your int here. Furthermore, you 
have to define that particular type globally, as far as I understand it.

> >(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).
> 
> I don't see how this and Printf are substantially different (except that 
> Printf is type safe),
> could you elaborate?

Erm, what do you do if you want to quickly debug-print a list of vectors 
of pairs?

> >(8) There are quite some instances where Ocaml's syntax is 
> >counter-intuitive to the extent of becoming a source of ugly mistakes, 
> >due to interference with conventions people are used to from other 
> >languages. I do not talk about (p,q) as x vs. x as (p,q) (or x@(p,q)) - 
> >as everyone else (e.g. SML, Haskell) does it, but rather about issues 
> >like for x=0 to 3 counting 0,1,2,3, or "\010" meaning "\x0a" instead of 
> >"\x08", and such.
> >
> This is an idiomatic issue.   I find presence of gender specific 
> suffixes in French to be a problem for me
> because I'm used to the conventions of English.  That does not mean 
> French is wrong,  it means I need to
> learn French better.   

But there is no reason for it to be there in this case.

In contrast, the other camel (perl) goes to great lengths to just behave 
the way people expect it, to the point of being somewhat inconsistent 
(e.g. > print "OK" while 0 < vs. > do{print "OK"} while 0 <).

> >(9) It really annoys having +, +., and +/. Furthermore, it seems a bit 
> >inconsistent, as on the other hand, we have e.g. < and not </.
> >  
> >
> I agree with you here.   This is an issue, but I don't know that it is a 
> major problem.  Also,
> sometimes I do find that it helps to think about the effects of working 
> with floats vs. ints
> especially wrt rounding problems and what not.

Well, yes, as I said, it's just annnoying, not a grave problem. Not having 
closures I would consider as a really grave and really bad thing. But the 
more such small annoyances a language has the less fun it will be.

> I think you've brought up your issues very succinctly and clearly.   I 
> don't agree with all of them,  but you have
> put forward issues that should be addressed (even if it is with 
> documentation rather than language changes).

Well, I'm not a seasoned ocaml expert, but rather a casual user with some 
real-world ocaml battlefield experience (who, accidentally, once learned 
SML and somehow perceives ocaml as kind of a funny dialect, such as 
austrian in comparison to german.) Hence, it may well be the case that I 
just did not know about a few key points I should have a closer look at, 
and I'm quite grateful for all comments that point me in the right 
direction.


Oh, by the way, there is one more thing which I consider a really
grave issue, which gave us quite a lot of grey hair already: Ocaml 
strings have this stupid limitation to 16 MB, which means in particular 
that if you serialize a truly large intermediate state of, say, a long 
and complicated calculation which accidentally got a bit larger than this 
limit (while you did not expect that), well...


-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Bardur Arantsson]

On Thu, Feb 03, 2005 at 01:58:33PM -0800, Paul Snively wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1


> On Feb 3, 2005, at 1:16 PM, Thomas Fischbacher wrote:
> >(1) I by far do not have the flexibility in extending the language with
> >own syntax which I have in Lisp.

> I have to respectfully disagree with this: IMHO, entirely too much is 
> made of Lisp's macros (as distinct from Scheme's hygenic macros)! With 
> camlp4, I have the ability to go from any concrete syntax I have an 
> expander for to O'Caml's AST and back. This is used to good effect in 
> Graydon Hoare's One Day Compiler presentation.

<rant>
Camlp4 has its own problems which I discovered when writing a parser
generator:


- When using quotations to construct the AST there is often only one (and
usually quite counterintuitive) way to construct a particular AST
fragment. The error messages are incredibly obtuse and when the line
numbers don't work properly this can be a royal PITA to get right.


- There is AFACT no way to "generate" identifiers in generated code so
that they are guaranteed not to clash with identifiers in outer/inner
scopes.


- You cannot verify that the generated AST will actually be valid OCaml
(e.g. free of references to unbound variables) until the generated AST is
compiled. It's not a huge problem, but it means you have to test more for
syntactical(!) corner cases.


Personally, I'm hoping that MetaOCaml (or something similar) will make it
into standard OCaml... but I'm not holding my breath. Of course that
"only" solves the problem of how to generate code in a sane manner. It
doesn't really provide for an easier way to extend the syntax as such.
</rant>


> >(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" 
> >bla).

> I don't quite follow; is there something wrong with Printf?

It can only print simple values, not compound values such as records,
objects, etc... Well, alright, it can use a custom printer, but there
shouldn't really be any need to have to write custom printers for
e.g. records when it's patently obvious how they should be printed (in
the absence of a more specific format).

-- 
Bardur Arantsson
<bardur@imada.sdu.dk>
<bardur@scientician.net>

- That which does not kill you only makes you stranger.
                                MisterQueue | http://kuro5hin.org

Re: [Caml-list] Estimating the size of the ocaml community

[josh]

Thomas Fischbacher wrote:

> There are quite a few things which I don't like at all about ocaml:

>(1) I by far do not have the flexibility in extending the language with 
>own syntax which I have in Lisp.
>  
>
But you do with camlp4.

>(2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
>any language besides LISP (or rather, Scheme).
>  
>
I'm going to leave this alone,  Lisp derived languages all have the 
Parenthesis problem that makes
them "ugly" as defined by a lot of people.

>(3) The type system is annoying. People claim it helps catching errors, 
>but my impression is it only catches those which I would never make 
>anyway. On the other hand, I cannot just have e.g. a function like 
>POSITION-IF that returns a number or nil. (Either one has to work with 
>exceptions, or wrap things up using the Maybe monad. Exception techniques 
>may interfere badly with tail recursion in some cases.)
>  
>
My response is contrived, but does not require monads or exceptions and 
does basically what you're asking for ( I think):

type position = Position of int | None;;

let position-if pos = match pos with
    Position x ->  if (x > 10) then
          Position x
    else
       None
|   None -> None;;

The type system is a tool that has many uses,  it has a side effect of 
catching errors.  The above type 'position' 
can be used by anyone and the developer would then know the range of 
possible values and code accordingly. 

>(4) There are a few other minor issues, such as a lack of 
>multiple-value-bind, which I personally find slightly annoying, but 
>not essential.
>  
>
You say yourself this is not essential. 

>(5) It does not behave as expected wrt module interfaces, as these include 
>md5 sums over source.
>  
>
I'm not sure your point on this one.

>(6) I cannot easily COMPILE a function to fast machine code from the REPL.
>  
>
This is true.

>(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).
>  
>

I don't see how this and Printf are substantially different (except that 
Printf is type safe),
could you elaborate?

>(8) There are quite some instances where Ocaml's syntax is 
>counter-intuitive to the extent of becoming a source of ugly mistakes, 
>due to interference with conventions people are used to from other 
>languages. I do not talk about (p,q) as x vs. x as (p,q) (or x@(p,q)) - 
>as everyone else (e.g. SML, Haskell) does it, but rather about issues 
>like for x=0 to 3 counting 0,1,2,3, or "\010" meaning "\x0a" instead of 
>"\x08", and such.
>  
>
This is an idiomatic issue.   I find presence of gender specific 
suffixes in French to be a problem for me
because I'm used to the conventions of English.  That does not mean 
French is wrong,  it means I need to
learn French better.   

>(9) It really annoys having +, +., and +/. Furthermore, it seems a bit 
>inconsistent, as on the other hand, we have e.g. < and not </.
>  
>
I agree with you here.   This is an issue, but I don't know that it is a 
major problem.  Also,
sometimes I do find that it helps to think about the effects of working 
with floats vs. ints
especially wrt rounding problems and what not.

>I know quite well that some people will consider some of these points 
>actually as "good" features, and think the "problems" I face can be traced 
>back to me being quite misguided about programming in general. For sure, I 
>should not expect Ocaml to be LISP, as it isn't. But I don't do that. :-)
>
>It's only that I experienced a few things in LISP as quite nice, and am a 
>little bit annoyed when I cannot use them. But only a little bit. ;-) 
>Still, Ocaml also has a few niceties that are missing in LISP. After all, 
>it is still among my favourite languages. C++, Java, JavaScript certainly 
>are not.
>
>  
>
I think you've brought up your issues very succinctly and clearly.   I 
don't agree with all of them,  but you have
put forward issues that should be addressed (even if it is with 
documentation rather than language changes).

Thank you.

-jbs

Re: [Caml-list] Estimating the size of the ocaml community

[Bardur Arantsson]

On Thu, Feb 03, 2005 at 09:34:53PM +0000, chris.danx wrote:

> >http://caml.inria.fr/camlidl/

> I looked at it awhile ago, but it didn't seem maintained so I thought 
> no one used it.  Does anyone use it?  If so, how do you find it?

For wrapping trivial or almost-trivial C library interfaces it's great.

I've also *tried* (seriously) to use it for quite a few wrapper libraries
I've created, but invariably it ends up being too much work to get it to
act right, and I just end up writing custom C code (usually with a few
macros to cut down on copy&paste code).

Now I just don't bother anymore and go straight to C.

-- 
Bardur Arantsson
<bardur@imada.sdu.dk>
<bardur@scientician.net>

- "It was the best of times, it was the *blurst* of times?" You
stupid monkey!
                                  Montgomery Burns | The Simpsons

Re: [Caml-list] Estimating the size of the ocaml community

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 3, 2005, at 1:16 PM, Thomas Fischbacher wrote:
> (1) I by far do not have the flexibility in extending the language with
> own syntax which I have in Lisp.
>
I have to respectfully disagree with this: IMHO, entirely too much is 
made of Lisp's macros (as distinct from Scheme's hygenic macros)! With 
camlp4, I have the ability to go from any concrete syntax I have an 
expander for to O'Caml's AST and back. This is used to good effect in 
Graydon Hoare's One Day Compiler presentation.

> (2) Speaking of syntax, there's a lot of unnecessary cruft in virtually
> any language besides LISP (or rather, Scheme).
>
Well, sure, given that in Lisp you're writing the AST by hand. :-)

> (3) The type system is annoying. People claim it helps catching errors,
> but my impression is it only catches those which I would never make
> anyway. On the other hand, I cannot just have e.g. a function like
> POSITION-IF that returns a number or nil. (Either one has to work with
> exceptions, or wrap things up using the Maybe monad. Exception 
> techniques
> may interfere badly with tail recursion in some cases.)
>
I guess I don't see the problem with "option" or variants.

> (4) There are a few other minor issues, such as a lack of
> multiple-value-bind, which I personally find slightly annoying, but
> not essential.
>
I would agree with this.

> (5) It does not behave as expected wrt module interfaces, as these 
> include
> md5 sums over source.
>
This is a pain, yes, but given how powerful the module system is, and 
the fact that, e.g. inlining is done across modules, I'm willing to 
accept this.

> (6) I cannot easily COMPILE a function to fast machine code from the 
> REPL.
>
You may wish to try "Nativize." It's in the Humps.

> (7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" 
> bla).
>
I don't quite follow; is there something wrong with Printf?

> (8) There are quite some instances where Ocaml's syntax is
> counter-intuitive to the extent of becoming a source of ugly mistakes,
> due to interference with conventions people are used to from other
> languages. I do not talk about (p,q) as x vs. x as (p,q) (or x@(p,q)) -
> as everyone else (e.g. SML, Haskell) does it, but rather about issues
> like for x=0 to 3 counting 0,1,2,3, or "\010" meaning "\x0a" instead of
> "\x08", and such.
>
I was thrown by it for a while, too, but now I find it quite natural, 
and everything else doesn't seem to fit. Having said that, in my day 
job, "everything else" means C++. Enough said. :-)

> (9) It really annoys having +, +., and +/. Furthermore, it seems a bit
> inconsistent, as on the other hand, we have e.g. < and not </.
>
I think we all eagerly await G'Caml, don't we?

> I know quite well that some people will consider some of these points
> actually as "good" features, and think the "problems" I face can be 
> traced
> back to me being quite misguided about programming in general. For 
> sure, I
> should not expect Ocaml to be LISP, as it isn't. But I don't do that. 
> :-)
>
> It's only that I experienced a few things in LISP as quite nice, and 
> am a
> little bit annoyed when I cannot use them. But only a little bit. ;-)
> Still, Ocaml also has a few niceties that are missing in LISP. After 
> all,
> it is still among my favourite languages. C++, Java, JavaScript 
> certainly
> are not.
>
Amen, and thanks for the thorough, well-articulated points.

> -- 
> regards,               tf@cip.physik.uni-muenchen.de              (o_
>  Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
> (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
> (if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian 
> GNU)
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
Best regards,
Paul Snively

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iEYEARECAAYFAkICnpIACgkQO3fYpochAqLGqgCgopwZLe/i0GycSvfwSgRdTXPr
b0oAnAk4latQbVfuHO/lchmm96rI7xA4
=gLb/
-----END PGP SIGNATURE-----

Re: [Caml-list] Estimating the size of the ocaml community

[Nicolas Cannasse]

> > For interfacing to C would it be helpful to create a tool for handling
> > all the underlying stuff.
>
> Do you mean like CamlIDL:
>
> http://caml.inria.fr/camlidl/
>
> -- 
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.

IMHO, OCaml GC lacks C stack scanning. Is there a specific reason why it's
not implemented ? I would be happy to get rid of CAMLparams, CAMLlocals and
CAMLreturns...

Nicolas Cannasse

Re: [Caml-list] Estimating the size of the ocaml community

[chris.danx]

Jon Harrop wrote:
> On Thursday 03 February 2005 20:50, chris.danx wrote:
> 
>>For interfacing to C would it be helpful to create a tool for handling
>>all the underlying stuff.
> 
> 
> Do you mean like CamlIDL:
> 
> http://caml.inria.fr/camlidl/

I looked at it awhile ago, but it didn't seem maintained so I thought 
no one used it.  Does anyone use it?  If so, how do you find it?

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Thu, 3 Feb 2005, Frédéric Gava wrote:

> > Anyway, this leaves us with a very interesting question: how many people
> > actually do believe in the value of Ocaml? I, for myself, use it whenever
> > it is the most appropriate tool for a job (usually, when portability is
> > an issue). This is sometimes the case, but more often than not, LISP
> > turned out to be a better choice for what I do.

> What kinds of programs code with LISP could not be implemented (easely)
> using Ocaml ?

There are quite a few things which I don't like at all about ocaml:

(1) I by far do not have the flexibility in extending the language with 
own syntax which I have in Lisp.

(2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
any language besides LISP (or rather, Scheme).

(3) The type system is annoying. People claim it helps catching errors, 
but my impression is it only catches those which I would never make 
anyway. On the other hand, I cannot just have e.g. a function like 
POSITION-IF that returns a number or nil. (Either one has to work with 
exceptions, or wrap things up using the Maybe monad. Exception techniques 
may interfere badly with tail recursion in some cases.)

(4) There are a few other minor issues, such as a lack of 
multiple-value-bind, which I personally find slightly annoying, but 
not essential.

(5) It does not behave as expected wrt module interfaces, as these include 
md5 sums over source.

(6) I cannot easily COMPILE a function to fast machine code from the REPL.

(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).

(8) There are quite some instances where Ocaml's syntax is 
counter-intuitive to the extent of becoming a source of ugly mistakes, 
due to interference with conventions people are used to from other 
languages. I do not talk about (p,q) as x vs. x as (p,q) (or x@(p,q)) - 
as everyone else (e.g. SML, Haskell) does it, but rather about issues 
like for x=0 to 3 counting 0,1,2,3, or "\010" meaning "\x0a" instead of 
"\x08", and such.

(9) It really annoys having +, +., and +/. Furthermore, it seems a bit 
inconsistent, as on the other hand, we have e.g. < and not </.

I know quite well that some people will consider some of these points 
actually as "good" features, and think the "problems" I face can be traced 
back to me being quite misguided about programming in general. For sure, I 
should not expect Ocaml to be LISP, as it isn't. But I don't do that. :-)

It's only that I experienced a few things in LISP as quite nice, and am a 
little bit annoyed when I cannot use them. But only a little bit. ;-) 
Still, Ocaml also has a few niceties that are missing in LISP. After all, 
it is still among my favourite languages. C++, Java, JavaScript certainly 
are not.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Jon Harrop]

On Thursday 03 February 2005 20:50, chris.danx wrote:
> For interfacing to C would it be helpful to create a tool for handling
> all the underlying stuff.

Do you mean like CamlIDL:

http://caml.inria.fr/camlidl/

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Re: [Caml-list] Estimating the size of the ocaml community

[chris.danx]

Yaron Minsky wrote:
> I've been trying to come up with some estimates on the size of the ocaml
> community, and I'm wondering if others have come up with anything better.
> Here's what I have so far:


It is also used it TPL by Pierce and possibly the new advanced follow up 
book.  We use this book as a reference text on our Type Theory course at 
uni, but use Java and SableCC for our assignments.

Re: [Caml-list] Estimating the size of the ocaml community

[chris.danx]

skaller wrote:
> On Fri, 2005-02-04 at 05:06, Thomas Fischbacher wrote:
> 
> 
>>Anyway, this leaves us with a very interesting question: how many people 
>>actually do believe in the value of Ocaml? I, for myself, use it whenever 
>>it is the most appropriate tool for a job (usually, when portability is 
>>an issue). This is sometimes the case, but more often than not, LISP 
>>turned out to be a better choice for what I do.
> 
> 
> Well ..
> 
> [skaller@pelican] ~/links/flx/src>wc *.ml
>   89737  342248 3223570 total
> 
> 90K Camls here speak for themselves ..
> 
> Ocaml has four downsides from my viewpoint:
> 
> (a) interfacing to C isn't trivial
> (b) native code compiler on x86 can't make a shared library
> 
> To a large extent these two factors are not only
> the reason for those 90K lines (which implement a 
> compiler) but also the reason I'll probably have to
> bootstrap the compiler away from Ocaml.


I didn't realise the native code compiler on x86 couldn't do this.  What 
exactly is the problem?

For interfacing to C would it be helpful to create a tool for handling 
all the underlying stuff.  In Ada, binding to C is done through special 
compiler directives and it's pretty trivial to do.  OCaml isn't Ada or 
as close to C as Ada is, but I was thinking of something that allows 
descriptions in OCaml augmented with directives telling the tool how to 
handle C.  Running the tool over a script would generate the appropriate 
C code for interfacing with OCaml.

I'm not 100% sure of the details or the benefit, but it might be worth 
considering.


Regards,
Chris

Re: [Caml-list] Estimating the size of the ocaml community

[chris.danx]

Thomas Fischbacher wrote:
> Yes, indeed. I even learned to know a few people who did an Ocaml-related 
> PhD which afterwards got totally absorbed by the idea that C were the 
> only true and proper programming language.
> 
> Huh.

Eww...

> 
> Anyway, this leaves us with a very interesting question: how many people 
> actually do believe in the value of Ocaml? I, for myself, use it whenever 
> it is the most appropriate tool for a job (usually, when portability is 
> an issue). This is sometimes the case, but more often than not, LISP 
> turned out to be a better choice for what I do.

Sometimes it's Ocaml, sometimes it's Erlang or Oz, sometimes  it's Ruby, 
etc.  Very rarely do I find C a good match for the problem - it takes a 
certain level of skill to not screw up with C, a level I don't currently 
possess.

I use OCaml as my language of choice for graphics work and some general 
purpose tasks.  It's got several benefits over some languages, the 
compiler is pretty good and the community is fairly substantial.  It has 
good library support and some decent tutorials, references.



Chris

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Fri, 2005-02-04 at 05:06, Thomas Fischbacher wrote:

> Anyway, this leaves us with a very interesting question: how many people 
> actually do believe in the value of Ocaml? I, for myself, use it whenever 
> it is the most appropriate tool for a job (usually, when portability is 
> an issue). This is sometimes the case, but more often than not, LISP 
> turned out to be a better choice for what I do.

Well ..

[skaller@pelican] ~/links/flx/src>wc *.ml
  89737  342248 3223570 total

90K Camls here speak for themselves ..

Ocaml has four downsides from my viewpoint:

(a) interfacing to C isn't trivial
(b) native code compiler on x86 can't make a shared library

To a large extent these two factors are not only
the reason for those 90K lines (which implement a 
compiler) but also the reason I'll probably have to
bootstrap the compiler away from Ocaml.

(c) the Cathedral+Bazaar development
model of the language, about which I have mixed feelings.
This seems to be good for the core compiler, but gets in
the way of improving the other tools and the library.

(d) Not many Open Source developers know Ocaml,
so it is hard to get help on Open Source projects

However none of these factors relate to Ocaml as a *language*
on its own, they're all industrial concerns.

I also use C/C++ (for C/C++ compatibility -- lol!) 
and Python (for rapid development/scripting).

Felix aims to replace all of them (high performance
functional and procedural code with rapid 
prototyping/scripting harness and C/C++ compatibility),
but I wouldn't dream of building it without a high
level language such as Ocaml as the bootstrap.

So apart from being the build tool for the current
version, Ocaml is also the principle inspiration
for the design, which is another 'value' of Ocaml
that should not be discounted, and in keeping
with its role as a combined academic/research and
industrial language. Other languages (JoCaml, C/XDuce ..
many more see the Humps) would also credit Ocaml
not only as the build tool, but also a key source
of inspiration, and many use the Ocaml runtime
even though the source language is distinct.

On the flip side, a huge industrial user base
might be a signicant impediment to improvements
to Ocaml -- at present the INRIA team can assume
a client base fairly receptive to changes and willing
to give the implementors considerably latitude
in many areas.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] Estimating the size of the ocaml community

[ronniec95]

On Thu, Feb 03, 2005 at 07:06:30PM +0100, Thomas Fischbacher wrote:
>
snip...
> 
> Anyway, this leaves us with a very interesting question: how many people 
> actually do believe in the value of Ocaml? I, for myself, use it whenever 

snip...
>

I use Ocaml at work for writing test harnesses for our 'real'
applications that are in C++/Java. Perhaps a special case, but our main
tools are distributed servers (based on middleware messaging) that perform 
various pricing calculations. Using the native C interface for
themessaging combined with the correctness guaranteed by doing things in
a purely functional manner, gives us a prototype, a test
harness and a correctly implemented 'real' app typically quicker than
writing the whole thing in C++ first and then finding out certain assumptions
are completely wrong!

Of course it helps me become more proficient at Ocaml too :)

Ronnie

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

Hi,

> Anyway, this leaves us with a very interesting question: how many people
> actually do believe in the value of Ocaml? I, for myself, use it whenever
> it is the most appropriate tool for a job (usually, when portability is
> an issue). This is sometimes the case, but more often than not, LISP
> turned out to be a better choice for what I do.
What kinds of programs code with LISP could not be implemented (easely)
using Ocaml ?

Regards,
Frédéric Gava

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Thu, 3 Feb 2005, Erik de Castro Lopo wrote:

> On 03 Feb 2005 14:58:48 +1100
> skaller <skaller@users.sourceforge.net> wrote:
> 
> > AFAIK Barry Jay teaches Ocaml for FP at University of 
> > Technology, Sydney (in Oz).
> 
> Unfortunately, someone teaching a language in a course doesn't
> always translate into the students using that language after 
> the course is over :-(.

Yes, indeed. I even learned to know a few people who did an Ocaml-related 
PhD which afterwards got totally absorbed by the idea that C were the 
only true and proper programming language.

Huh.

Anyway, this leaves us with a very interesting question: how many people 
actually do believe in the value of Ocaml? I, for myself, use it whenever 
it is the most appropriate tool for a job (usually, when portability is 
an issue). This is sometimes the case, but more often than not, LISP 
turned out to be a better choice for what I do.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Olivier Pérès]

Erik de Castro Lopo a écrit :
> Unfortunately, someone teaching a language in a course doesn't
> always translate into the students using that language after 
> the course is over :-(.

    If this can cheer you up a bit, last year in University of Nantes 
the two fourth year projects that got the joint best mark were written 
in OCaml (one was a spell checking framework for African languages and 
the other was a library for parallel programming, there's a link to it 
in the Humps). So you see teaching a language *can* convince people to 
use it later...

    Olivier.

Re: [Caml-list] Estimating the size of the ocaml community

[Olivier Pérès]

sejourne_kevin a écrit :
> In my master the only students who know a functional language are those 
> which come from the 'université de Paris XI'.

    This is not quite true. As it turns out I am a student in the very 
same master and was taught Caml during my previous years in universities 
of Brest and Nantes (both are in France). One of our fellow students 
from ENS Lyon also "speaks" Caml.

    See you,

    Olivier.

Re: [Caml-list] Estimating the size of the ocaml community

[Stefano Zacchiroli]

On Wed, Feb 02, 2005 at 10:54:11PM +0100, Frédéric Gava wrote:
> I also heard that Ocaml is sometime teach in Italian Universities but I am
> not sure.

Yes, at least here at the Computer Science Department of the University
of Bologna it was teached in the past and used for students projects in
the compiler course, but this is no longer the case.  Still, it is used
as a programming language in some research projects.

I'm aware of the university of Urbino, in which OCaml is teached as a
part of the compiler course.

Hope this helps.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-

Re: [Caml-list] Estimating the size of the ocaml community

[Matthieu Brucher]

sejourne_kevin wrote:
> Frédéric Gava a écrit :
> 
>> Hi,
> 
> [...]
> 
>>
>> I think that "all" French Universities use OCaml to teach
>> functional programming  (some of them use Scheme or SML depending of the
>> years and/or the teachers). Ocaml is also used in "Classe préparatoires",
>> special schools in France to be engineers.
>>
>> I also heard that Ocaml is sometime teach in Italian Universities but 
>> I am
>> not sure.
>>
>> Regards,
>> Frédéric Gava
> 
> 
> In my master the only students who know a functional language are those 
> which come from the 'université de Paris XI'. Even the engineer which 
> has make a preparatory class are unaware of this kind of language.
> But there is only an half of students who are french and 5 on 98 who 
> come from 'université de Paris XI'.
> 
> 
> Regards,
> Kévin.

In the French classes préparatoires, those who learn CaML have taken the 
option IT. Few people are selected to choose between IT and engineer 
sciences.
But those who could choose IT know about CaML.

Matthieu

Re: [Caml-list] Estimating the size of the ocaml community

[sejourne_kevin]

Frédéric Gava a écrit :
> Hi,
[...]
> 
> I think that "all" French Universities use OCaml to teach
> functional programming  (some of them use Scheme or SML depending of the
> years and/or the teachers). Ocaml is also used in "Classe préparatoires",
> special schools in France to be engineers.
> 
> I also heard that Ocaml is sometime teach in Italian Universities but I am
> not sure.
> 
> Regards,
> Frédéric Gava

In my master the only students who know a functional language are those 
which come from the 'université de Paris XI'. Even the engineer which 
has make a preparatory class are unaware of this kind of language.
But there is only an half of students who are french and 5 on 98 who 
come from 'université de Paris XI'.


Regards,
Kévin.

Re: [Caml-list] Estimating the size of the ocaml community

[Eric Stokes]

The two places I work both use Ocaml

California State University Northridge
Most of our middleware infrastructure is written in Ocaml (except the
directory server; for now), this includes both web pages using Wdialog,
and traditional middleware layers such as messaging and identity
management, to more low level things such as libraries implementing the
LDAP wire protocol. Remote middleware daemon is a project we started to
solve some of the problems of using ldap directly for identity
management, and ocamldap is a pretty nice ldap library.

http://ocamldap.sourceforge.net
http://www.csun.edu/~eric/ncc-website/opensource/rmwd/rmwd-description.html

Symas Inc.
We use Wdialog for our portal web site

Re: [Caml-list] Estimating the size of the ocaml community

[Evan Martin]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?

The grad-level programming languages class at the University of
Washington used O'Caml throughout.

-- 
Evan Martin
martine@danga.com
http://neugierig.org

Re: [Caml-list] Estimating the size of the ocaml community

[Erik de Castro Lopo]

On 03 Feb 2005 14:58:48 +1100
skaller <skaller@users.sourceforge.net> wrote:

> AFAIK Barry Jay teaches Ocaml for FP at University of 
> Technology, Sydney (in Oz).

Unfortunately, someone teaching a language in a course doesn't
always translate into the students using that language after 
the course is over :-(.

However, you, me and Barry, should make it at least 3 people
here in Sydney.au that use O'caml :-).

> Two jobs in a row being paid to write Ocaml by
> an employer is not bad.. I wish I could get
> another one :)

I'll let you have first shot at any o'caml jobs, but if you
need another hand, let me know :-).

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I believe C++ instills fear in programmers, fear that the interaction
of some details causes unpredictable results. Its unmanageable complexity
has spawned more fear-preventing tools than any other language, but the
solution _should_ have been to create and use a language that does not
overload the whole goddamn human brain with irrelevant details."
-- Erik Naggum

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Thu, 2005-02-03 at 08:54, Frédéric Gava wrote:

> I think that "all" French Universities use OCaml to teach
> functional programming  (some of them use Scheme or SML depending of the
> years and/or the teachers). 

AFAIK Barry Jay teaches Ocaml for FP at University of 
Technology, Sydney (in Oz).

The text book isn't Ocaml though .. I mean there isn't
one in English other than the online translation of
the French O'Reilly one.

I also had two Ocaml jobs in Australia, one with
Barry at UTS, where I learned it, and an industrial
one where I specified it myself, and then used it
(the company was a telco, the use was for a language
translator for telco service logic, which has
inspired my open source language Felix)

Two jobs in a row being paid to write Ocaml by
an employer is not bad.. I wish I could get
another one :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

RE: [Caml-list] Estimating the size of the ocaml community

[Don Syme]

Microsoft has used OCaml for SLAM (http://research.microsoft.com/slam/)
and other amazing tools that find really deep bugs in the C code
implementing device drivers. Byron Cook spoke about this at INRIA
recently.  So when Windows doesn't crash when you pull your PCMCIA card
out at the very moment your machine goes into "hibernate" mode (roughly
speaking one of the bugs they found, though I've probably got the
details wrong) then remember that OCaml made a big contribution to that
:-)

Don

P.S. All opinions my own.

-----Original Message-----
From: caml-list-admin@yquem.inria.fr
[mailto:caml-list-admin@yquem.inria.fr] On Behalf Of Yaron Minsky
Sent: 02 February 2005 21:31
To: Caml Mailing List
Subject: [Caml-list] Estimating the size of the ocaml community

I've been trying to come up with some estimates on the size of the ocaml
community, and I'm wondering if others have come up with anything
better.
Here's what I have so far:

- The mailing list is supposed to have about 500 subscribers[1].  Hard
to know
  if this number is up-to-date.  I wonder if that number has changed
over
  time, and what it is today.

- The OCaml Humps contributors page[2] has about 200 members.

- If you type OCaml into google, you get about 800k hits.  This compares
with
  29 million for C++.  "python programming" (without the quotes) gets
about 5
  million

- If you type "ocaml resume", you get about 5.5k hits.  If you type
"python
  resume", you get about 270k hits.  If you type "C++ resume", you get
almost
  1m hits.

- Some schools teach ocaml.  Brown and Caltech apparently have intro
ocaml
  courses.  Any other places that teach the language?  Any ideas on how
many
  students go through these courses?

- A few companies use ocaml, including Baretta DE&IT, Dassault Aviation,
  LexiFi, Artisan (which has been bought up by AMD?)  Anyone know of
other
  such companies?  It would be interesting to get a list togther of
companies
  that use ocaml significantly.

I'd be interested of any evidence people have of the size and vibrancy
of the
ocaml community.  I'd be particularly interested in evidence of ocaml
use in
the United States, since it seems like a majority of ocaml use is
outside of
the US.

[1] http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
[2] http://caml.inria.fr/humps/index_contributors.html

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Estimating the size of the ocaml community

[Nicolas Cannasse]

> - A few companies use ocaml, including Baretta DE&IT, Dassault Aviation,
>   LexiFi, Artisan (which has been bought up by AMD?)  Anyone know of other
>   such companies?  It would be interesting to get a list togther of
companies
>   that use ocaml significantly.

As Richard answered, the OCaml Alliance website at http://wiki.cocan.org is
a good place for all people in the industry to reference themselves and
learn about each other. Any people who is using ocaml quite intensively is
welcome to register on the website.

Nicolas Cannasse

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

The COCAN (Ocaml Alliance Network) at:

http://wiki.cocan.org/

has had between 60 and 120 unique visitors per week since it was
launched, (mid 2004).  There are more detailed stats here:

http://www.merjis.com/rocketstats/wiki.cocan.org/

Rich.

PS. We are still offering to do something for free with ocaml.org,
caml.inria.fr, involving a wiki which can be updated, but with
mailback so that people in charge can monitor changes.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Michael Jeffrey Tucker]

On Wed, 2 Feb 2005, Yaron Minsky wrote:
>
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?

Although there are no courses that I know of at Harvard which set out to
teach OCaml, it has made appearances in a few classes that I have taken.
Specifically, a graduate-level Artificial Intelligence course on
Computational Game Theory that is offered periodically asks its students
to complete its problem sets using OCaml. Also, Prof.  Norman Ramsey's
course on Programming Languages last year included a lecture on "Classes
and Modules in Objective Caml", though I don't think that the students
were asked to write any code in OCaml for that course.

Mike

Re: [Caml-list] Estimating the size of the ocaml community

[Kenneth Knowles]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?

Here at UC Santa Cruz, my graduate programming language theory course used
O'Caml, though programming was a very small portion of the course content.  The
undergraduates are taught in C and Java, I think.

- Kenn

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

Hi,

> On Wed, 2 Feb 2005 16:31:28 -0500, Yaron Minsky <yminsky@gmail.com> wrote:
> > - Some schools teach ocaml.  Brown and Caltech apparently have intro
ocaml
> >  courses.  Any other places that teach the language?  Any ideas on how
many
> >  students go through these courses?

I think that "all" French Universities use OCaml to teach
functional programming  (some of them use Scheme or SML depending of the
years and/or the teachers). Ocaml is also used in "Classe préparatoires",
special schools in France to be engineers.

I also heard that Ocaml is sometime teach in Italian Universities but I am
not sure.

Regards,
Frédéric Gava

Re: [Caml-list] Estimating the size of the ocaml community

[Christopher A. Watford]

On Wed, 2 Feb 2005 16:31:28 -0500, Yaron Minsky <yminsky@gmail.com> wrote:
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>  courses.  Any other places that teach the language?  Any ideas on how many
>  students go through these courses?

The University of Illinois at Urbana-Champaign uses OCaml to teach
programming language theory classes. This is where I was introduced to
OCaml for the first time. Basically we built parsers, lexers, and type
checkers. Function programming was included in the coursework, but
mainly to show its strong suits. Haskell is also taught in these
classes.

-- 
Christopher A. Watford
christopher.watford@gmail.com
http://dorm.tunkeymicket.com