Hacker News Reader

Comment by wdkrnls | Hacker News Reader

I don't know if I would call knowledge of regulations"deep". But I agree with the rest of what you are saying. I'm just want to point out that the problems most effectively aided by LISP are those that require orders of magnitude more domain knowledge about hard, subtle concepts like quantum mechanics, synthetic chemistry and abstract algebra. Those are where Domain Specific Languages become extremely useful. But, thankfully, mundane things like regulations absolutely don't need that overkill.

View on HN

I don’t know if I would call regulations mundane work. In fact regulations are one of the most convoluted and more often than not ad-hoc pieces of requirements that could most certainly benefit from a DSL.

On the other hand, linear algebra or “quantum mechanics” (not sure what exactly you mean in computational context) do not require DSL. For example, at least in computational chemistry and fluid dynamics things are very much FORTRAN (or C/++) under the hood (see Gaussian, GAMESS). I believe most of the linear algebra is already available for use through higher level APIs/language bindings (see BLAS/Atlas). I am not sure why one may want to learn a programming language for synthetic chemistry unless we have futuristic robo labs doing the grunt work. Perhaps I misunderstood your comment?

I was thinking about:

Synthetic chemistry language MC search language (which does use GAMESS under the hood): https://github.com/drmeister/cando

And this Mathematica plugin: http://iopscience.iop.org/article/10.1088/1742-6596/698/1/01...

The sheer quantity of edge cases, special cases and normal use cases when dealing with these "mundane" entities is a quality all its own. These use cases we automate or help automate are not by themselves all that complex normally. This is where they differ from quantum mechanics, synthetic chemistry, etc., in that use cases in those fields are usually not as accessible to the layperson.

Yes, go deeply enough into those "mundane" entities and you will eventually hit a abstraction strata high enough where it makes sense to apply a Lisp/functional language/<<insert favorite abstraction tool here>>.

But in the meantime, many times even the domain experts themselves don't realize there even exist higher abstraction levels of their domain. Incrementally getting there with the lower-abstraction-capable languages often better fit their organizations' staffing budgets today. Lisp programmers by and large I've found are scary-category smart. Consistently staffing that kind of smart takes bigger payroll budgets than most organizations are willing to stump up.

Today, the tooling around getting "good enough" results in most fields for most projects tends to even out whatever programmer productivity efficiencies Lisps brought to the table, enough to the point where most managers don't want to tackle the higher complexity of managing a Lisp team.

I just listed regulations, but it's not just regulations. It's regulations, business knowledge, various social aspects.

And I doubt there's anything we work more complex than human society. Even the most complex scientific models pale in comparison to real human interactions, business or otherwise.

I'd be happy to be proven wrong once we have an AI to take care of other pesky humans :)

A concrete example of a use case is F#, which is being used in the structured products business, where complex financial derivatives agreements need to be expressed mathematically in order to be valued.

Reply on news.ycombinator.com