Lisping at JPL (2002) | Hacker News Reader

Lisping at JPL (2002)

flownet.com

120 pointsluu19 comments

". . . 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.

i.e. ISHYGDDT

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.

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

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.

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 for it. No wonder the Higgs boson hasn't been discovered yet (or has it?)

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://linuxfr.org/nodes/18919/comments/632920

https://linuxfr.org/nodes/19928/comments/698692

Isn't CINT being replaced by Cling?

http://root.cern.ch/drupal/content/cling

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...

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.

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

Global variables begin with g

http://root.cern.ch/root/htmldoc/guides/users-guide/GettingS...

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

I thought it was created to increase job security? http://harmful.cat-v.org/software/c++/I_did_it_for_you_all

That's brilliant.

C++ was originally developed to make it easier for a mathematician to do complex numeric variables in C. It has been downhill ever since.

One of the USPs of FORTRAN for a long time was the easy, native handling of complex numbers. Faced with that problem, I would have shrugged and said, use FORTRAN for that bit and bind it to C, easy.

yep it has, though as a guy who earns his living doing C++ I whole heartedly agree with your viewpoint

If one day we all get sucked into some black hole and pop out on the far side of the universe, we will know that it was due to some null pointer exception in some C++ code at CERN.

I wish I could tweet that.

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

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

Reply on news.ycombinator.com