5 ms·

I agree. The fraction of programmers that are tackling really challenging problems that push the limits of what's possible has probably always been small, but i

I agree. The fraction of programmers that are tackling really challenging problems that push the limits of what's possible has probably always been small, but it has only gotten (much) smaller. Mainstream programmers don't do those things. They make websites for CRUD apps and maintain COBOL and other "obsolete" systems, solving the same well understood problems over and over. I see people writing compilers for quantum computers in LISP, compilers for automatically synthesizing complex chemicals in LISP, writing a TeX-looking, but completely dynamic scientific/math editor (TeXmacs) with LISP, writing a computer algebra system built on abstract algebra and types with LISP (Axiom/FriCAS), and writing a hyper fast scientific programming language with LISP (Julia). Mainstream programmers are just trying to maintain (and maybe modernize) systems built by their parents and grandparents. They don't need the tools that LISP offers to do that. They (or at least the people that pay them) need tools that turn themselves into easily replaceable cogs.

oblio 8y ago
> need tools that turn themselves into easily replaceable cogs. Sort of but not really. Even though this mantra is repeated often, the greatest "cogs" actually have deep domain knowledge. That's how most mainstream programmers "level up". They become experts in the application they're developing and what it does functionally. Or in the domain in which the application operates (after having worked on several applications in the same field, for various companies). HackerNews folks don't work in this kind of field, but in that domain Lisp is a liability. You want a plain and simple programming language, no meta programming, dumb albeit repeated code that does just what it needs to do. The rest of the brain cycles are needed to understand the often convoluted business logic ("due to this regulation the employee needs to be X", "the account is Y because our partner Zs", etc.).
- wdkrnls 8y ago
  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.
  - oblio 8y ago
    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 :)
    - vt100 8y ago
      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.
  - yourapostasy 8y ago
    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.
  - wadkar 8y ago
    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?
- workinfunk 8y ago
  Where I work, one of the benefits of Clojure is precisely how concise and accessible storing densely layered business logic is. We're able to have a faith that the code does what it looks like that just isn't approachable in any other language I know of.
infinite8s 8y ago
In other words, they are equivalent to the people in the 1500s and 1600s using the new Gutenberg presses to reproduce Bibles. Still waiting for the explosion in computational literacy that has yet to take hold.

oblio 8y ago

> need tools that turn themselves into easily replaceable cogs. Sort of but not really. Even though this mantra is repeated often, the greatest "cogs" actually have deep domain knowledge. That's how most mainstream programmers "level up". They become experts in the application they're developing and what it does functionally. Or in the domain in which the application operates (after having worked on several applications in the same field, for various companies). HackerNews folks don't work in this kind of field, but in that domain Lisp is a liability. You want a plain and simple programming language, no meta programming, dumb albeit repeated code that does just what it needs to do. The rest of the brain cycles are needed to understand the often convoluted business logic ("due to this regulation the employee needs to be X", "the account is Y because our partner Zs", etc.).

wdkrnls 8y ago
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.
- oblio 8y ago
  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 :)
  - vt100 8y ago
    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.
- yourapostasy 8y ago
  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.
- wadkar 8y ago
  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?
workinfunk 8y ago
Where I work, one of the benefits of Clojure is precisely how concise and accessible storing densely layered business logic is. We're able to have a faith that the code does what it looks like that just isn't approachable in any other language I know of.

infinite8s 8y ago

In other words, they are equivalent to the people in the 1500s and 1600s using the new Gutenberg presses to reproduce Bibles. Still waiting for the explosion in computational literacy that has yet to take hold.