
Lisping at JPL (2002) - luu
http://www.flownet.com/gat/jpl-lisp.html
======
vfclists
C++ was promoted by the Illuminati under the advice of a secret group of
aliens to slow down the development of human progress. It achieves this via
insanely long compile times whose purpose is stop anyone from getting shit
done in good time.

I mean, how do you iterate and refine if it takes ages to compile stuff? The
flow of your of thoughts has probably gone to shit before the compile is over.

Apparently the guys at CERN love it so much they created an interpreter
[http://root.cern.ch/drupal/content/cint](http://root.cern.ch/drupal/content/cint)
for it. No wonder the Higgs boson hasn't been discovered yet (or has it?)

~~~
Create
first the practicalities: CINT cannot and is unlikely to ever properly
interpret ANSI/ISO C++.

In my experience, many people who use ROOT at least have vague feelings that
it is making their life more difficult then it rightly should. Nearly everyone
I know that writes code that other people use feel even more strongly that
ROOT's poor design leads to productivity losses.

[http://www.insectnation.org/howto/problems-with-
root](http://www.insectnation.org/howto/problems-with-root)

[http://linuxfr.org/nodes/18919/comments/632920](http://linuxfr.org/nodes/18919/comments/632920)

[https://linuxfr.org/nodes/19928/comments/698692](https://linuxfr.org/nodes/19928/comments/698692)

~~~
igouy
Isn't CINT being replaced by Cling?

[http://root.cern.ch/drupal/content/cling](http://root.cern.ch/drupal/content/cling)

~~~
Create
ROOT can't be said to be OO because it breaks the encapsulation in the guts.
There is a massive usage of "g" global pointers : gROOT, gDirectory, gTree,
gEnv, gSystem, gPad, etc... Around one hundred in v5-18-00, a disaster. And
this definitely breaks the fundamental OO principle of encapsulation.

Then since ROOT violates three basic principles of OO (encapsulation,
inheritance, virtuality) we are compelled to conclude that ROOT can't be
considered as an OO software. ROOT is a bright example of people having jump
to C++ but missed totally the point of OO. At least it will probably stay in
the history of software because of that.

What could be the improvements in a ROOT major revision ?

o at least fix the name ! Is it ROOT, Root, root ? (Hell, we are pretty sure
that any Bazaar model software have at least converged on that !)

o have then a correct namespacing of classes and libs.

o restore encapsulation (then get rid of the g pointers).

o revisit the inheritances. At least have a good histogram class. And arrange
the storage area to be stable (then "fix" the TTree). And please, have an
introspection class that looks like an introspection class.

o use pure abstract interfaces to separate domains. And stick strongly to the
idea to have them pure.

o etc, etc, etc, etc, etc, etc, etc, etc, etc, etc,...

[http://openscientist.lal.in2p3.fr/osc_web_16.11/html/faq.htm...](http://openscientist.lal.in2p3.fr/osc_web_16.11/html/faq.html#faq_ROOT)

~~~
hga
Given that this is a topic nominally about Lisp, I'd like to point out that
the CLOS crowd (Common Lisp Object System) would strongly disagree that
encapsulation of the restricting access kind is a basic principle of OO.
That's not in Lisp's DNA.

~~~
Create
_restore encapsulation (then get rid of the g pointers)._

Global variables begin with g

[http://root.cern.ch/root/htmldoc/guides/users-
guide/GettingS...](http://root.cern.ch/root/htmldoc/guides/users-
guide/GettingStarted.html#coding-conventions)

While it's true that indiscriminate use of global variables can turn code into
spaghetti nearly as quickly as unrestrained use of goto, global variables do
have legitimate uses and exist in one form or another in almost every
programming language.

Lisp's version of global variables, dynamic variables, are both more useful
and more manageable.

Common Lisp provides two ways to create global variables: DEFVAR and
DEFPARAMETER.

[http://www.gigamonkeys.com/book/variables.html](http://www.gigamonkeys.com/book/variables.html)

------
patrickmay
". . . we're confusing best practice with standard practice. The two are not
the same."

I'm going to print this on a Louisville Slugger and bring it to architecture
and design meetings.

~~~
frou_dh
i.e. ISHYGDDT

------
kazinator
Funny thing: some C and C++ programmers who swear they could never work with
the parenthesized expressions of Lisp somehow have no trouble churning out
complicated GNU makefiles with cruft like $(filter-out $(patsubst %,%/d,$(foo
foo bar, xyzzy) ...) ad nauseum. Note how the parenthesis is outside the
function name. It must be the dollar sign somehow softens it, plus the comma
separators that are required after the second argument.

------
dalke
There are also a number of comments in an older thread at
[https://news.ycombinator.com/item?id=304736](https://news.ycombinator.com/item?id=304736)
.

------
shams93
I'm a product of that cookie cutter system, its really horrible, in this case
c# rather than c++ or java, I never got exposed to lisp until recently, but if
you look at ruby as a kind of lisp or close to it when it comes to the web and
startups the lispy coder as artist approach has won over the "software
engineering" coder as inter-changeable component coder paradigm.

------
wedesoft
Thanks for posting this. I wrote a whole thesis about computer vision using
Ruby instead of C/C++ [1]. Now I am working on computer vision with GNU Guile
(Scheme) [2]. Not that I have convinced many people apart from myself about it
;)

[1] [http://www.wedesoft.de/ruby-computer-vision-
thesis.html](http://www.wedesoft.de/ruby-computer-vision-thesis.html)

[2] [https://github.com/wedesoft/aiscm](https://github.com/wedesoft/aiscm)

