[Haskell-cafe] Wow Monads!

[David McClain]

> What happened with these OCaml programs?
> I do see quite a few deficits in OCamls practices, but I don't know how relevant they are or if they are even related to your experience, so that would be interesting to me.

Hi Joachim,

Not sure what you are asking here? Do you mean, are they still extant? or do you want to know the failure mechanisms?

The biggest program of the lot still remains, although I have not used it in nearly 10 years. It was a compiler for a math analysis language called NML (Numerical Modeling Language, Not ML, …). It borrowed the syntax of OCaml, was coded in OCaml, but was a vectorized math language with dynamic binding. For me, at the time, the biggest gain was treating all arrays as toroidal, so that I could easily play with FFT’s in multiple dimensions, and reach things like the tail of the array with negative indices. That, and the automatic vectorizing of overloaded math operators.

That particular program began to fail as a result of the continual evolution of OCaml. It became a chore to constantly adapt to ever changing syntax patterns, on again / off again preprocessing of AST trees etc. But it did serve me well for about 5 years. About 20 KLOC of OCaml and 3 KLOC of supporting C glue code for access to BLAS, FFT’s, plotting graphics, etc.

That NML effort was launched shortly after my initial success in the nonlinear optimization that I mentioned. This was also a huge success for me, because I had tried repeatedly over the previous 5 years to construct an NML in C, then C++, and I always crapped out when the line count reached around 100 KLOC. Being able to produce a fully working system in 20 KLOC was a huge win.

The other programs compiled properly, and yet failed in execution, but my recall is fuzzy. One of them had the job of trying to watch automobile traffic through several cameras, day and night, and try to give consistent identity to the images seen through separate cameras, their motion patterns, and so forth. The cameras did not have overlapping fields of view. Not an easy problem, especially on rainy nights with street reflections from headlights. I don’t recall the exact failures, but things like data structure Maps started to fail with Address Faults. That should not ever happen, according to theory, but it really does.

On and off, I did have quite a bit of success with OCaml. But getting clients to accept OCaml in the code base, c.a. 2000-2005 was a major problem. They all had their in-house experts telling them that C++ and Java was the way to go… (I managed to avoid Java in my career).

Another major project was an Embedded Scheme compiler aimed at DSP’s c.a. 2008. That worked quite well for me, no failures to speak of. But I did learn during that effort that pattern matching has its limits. You often want to match subtrees and stubs, and just writing them out becomes an exercise in write-only code. A fallback effort done later in Lisp succeeded even better, but that’s probably because of the lower impedance mismatch between Lisp / Scheme, compared to OCaml / Scheme.

I never learned nor made use of the OOP in OCaml. Never seemed necessary. But then they started implementing syntax sugar to represent optional args, etc. and quite frankly the effort looks really cheesy and difficult to read. You might as well just use Common Lisp and be done with it.

Then around 2008 I got invited to speak at the European Common Lisp Meeting in Hamburg, and they made their preferences for Lisp be strongly known. Despite whatever I had in OCaml, that would be of no interest to them. So I began reentry into Lisp in a serious way, and I have been there since. Lisp for me had been on/off since about 1985. There were side diversions into Forth, C, Objective-C-like compilers, Smalltalk, and lots of DSP coding in bare-metal DSP Assembly. Transputers and Occam for a while. Massively parallel computing on a 4096 processor SIMD DAP Machine, 46 node MIMD machines based on DSP / Transputers for airborne LIDAR underwater mine detection systems. Lots of history…

- DM


> On Apr 17, 2017, at 23:56, Joachim Durchholz <jo at durchholz.org> wrote:
> 
> Am 17.04.2017 um 21:26 schrieb David McClain:
>> And BTW… the breakthrough had absolutely nothing to do with typing
>> and type inference. The success arose because of clean versus unclean
>> control-flow. So you could say that OCaml adhered to “Structured
>> Programming” in a better manner, which corresponds entirely to a fad
>> cycle 2 layers back in time.
> 
> That's not the first time I hear such statements.
> One other instance is Erlang users writing that it's not the functional
> aspect that is making it effective (Erlang isn't particularly strong in
> that area anyway), it's garbage collection (i.e. no invalid pointers to
> dereference).
> 
>> But then after several years of pushing forward with OCaml, in
>> writing math analysis compilers and image recognition systems, I
>> began to find that, despite proper typing and clean compiles, system
>> level issues would arise and cause my programs to fail. The holy
>> grail of provably correct code came tumbling down in the face of
>> practical reality.
> 
> What happened with these OCaml programs?
> I do see quite a few deficits in OCamls practices, but I don't know how relevant they are or if they are even related to your experience, so that would be interesting to me.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.