4 ms·

From my point of view, Lisp gives programmers too much power. No company wants giving a programmer so much concentrated power, they want it distributed around t

From my point of view, Lisp gives programmers too much power. No company wants giving a programmer so much concentrated power, they want it distributed around the workforce, and people disposable. Replace them whenever is needed. With lisp you can modify your development platform to suit your needs, In practice, over time you create your own programming language. You create your DSP(Domain specific language) with your own systems. This is not standard. You are dependent on the programmer. Companies prefer to buy "solutions"(packages,environments) from companies and depend on those solutions. They are standard and you can hire people trained on them. Replace them if needed and make people continue the work that someone else left. That is because "solutions" have open documentation, designed by people that are able to draw beautiful diagrams, lots of books, videos on the Internet, but lisp gurus have all the info in their heads. Bugs are way easier(orders of magnitude) to find with meta programming. In fact you can create a subsystem that finds all bugs so you don't have to.

fctorial 7y ago
> Bugs are way easier(orders of magnitude) to find with meta programming. In fact you can create a subsystem that finds all bugs so you don't have to. This needs some explanation.
- jiggawatts 7y ago
  In homoiconic languages like Lisp or Mathematica the program is just "data" and can be transformed arbitrarily, even at runtime. This allows you to write utility functions that transform programs in all sorts of useful ways to find bugs. A simple example is to just transform the program so that it traces whatever you want to a log, much like Visual Studio Intellitrace, but completely flexible. You can do things like replace all floating point numbers with a "dual number" (a 2-number tuple) where the first number is always rounded down when operated on, and the second number is always rounded up. This then lets you robustly determine if your numerical accuracy is guaranteed to be within a certain range (due to floating point error, at any rate). You can symbolically evaluate programs involving random variables using their distributions instead, symbolically working out the products of functions instead of scalar values. This allows things like video poker or lottery programs to be robustly evaluated for average payout even if some of the plays are rare, such as jackpots. A friend of mine did this using Mathematica back in the early 2000s. It goes on and on...
maliker 7y ago
The parent comment got downvoted, but I have definitely experienced this "too much power" issue at work in other languages. E.g. one programmer on the team chooses to use powerful abstractions, but then other folks have trouble modifying the code. Usually we give the respect that is due and ask for a simpler rewrite. When the abstractions or tools are powerful and also simpler, and we can all pick them up and use them, that's the happiest outcome.
- anentropic 7y ago
  > one programmer on the team chooses to use powerful abstractions, but then other folks have trouble modifying the code doesn't this kind of mean they were bad abstractions though? (am guilty of this myself of course...)
zbentley 7y ago
> gurus have all the info in their heads. Whichever word you put before "gurus" in that sentence, I don't want to work somewhere which values that dynamic. Programming is very occasionally a solitary and purely technical task. The rest of the time it's a collaborative and human task. Eschewing documentation and presentation in favor of "fits in one genuis's head" is not a good thing if the task at hand is collaborative/involves multiple humans.

fctorial 7y ago

> Bugs are way easier(orders of magnitude) to find with meta programming. In fact you can create a subsystem that finds all bugs so you don't have to. This needs some explanation.

jiggawatts 7y ago
In homoiconic languages like Lisp or Mathematica the program is just "data" and can be transformed arbitrarily, even at runtime. This allows you to write utility functions that transform programs in all sorts of useful ways to find bugs. A simple example is to just transform the program so that it traces whatever you want to a log, much like Visual Studio Intellitrace, but completely flexible. You can do things like replace all floating point numbers with a "dual number" (a 2-number tuple) where the first number is always rounded down when operated on, and the second number is always rounded up. This then lets you robustly determine if your numerical accuracy is guaranteed to be within a certain range (due to floating point error, at any rate). You can symbolically evaluate programs involving random variables using their distributions instead, symbolically working out the products of functions instead of scalar values. This allows things like video poker or lottery programs to be robustly evaluated for average payout even if some of the plays are rare, such as jackpots. A friend of mine did this using Mathematica back in the early 2000s. It goes on and on...

maliker 7y ago

The parent comment got downvoted, but I have definitely experienced this "too much power" issue at work in other languages. E.g. one programmer on the team chooses to use powerful abstractions, but then other folks have trouble modifying the code. Usually we give the respect that is due and ask for a simpler rewrite. When the abstractions or tools are powerful and also simpler, and we can all pick them up and use them, that's the happiest outcome.

anentropic 7y ago
> one programmer on the team chooses to use powerful abstractions, but then other folks have trouble modifying the code doesn't this kind of mean they were bad abstractions though? (am guilty of this myself of course...)

zbentley 7y ago

> gurus have all the info in their heads. Whichever word you put before "gurus" in that sentence, I don't want to work somewhere which values that dynamic. Programming is very occasionally a solitary and purely technical task. The rest of the time it's a collaborative and human task. Eschewing documentation and presentation in favor of "fits in one genuis's head" is not a good thing if the task at hand is collaborative/involves multiple humans.