3 ms·

> Many of the quotes makes me question the authors experience Do you have enough experience that you dare to judge him? > Compared to modern languages (say, H

> Many of the quotes makes me question the authors experience Do you have enough experience that you dare to judge him? > Compared to modern languages (say, Haskell), not so much. I disagree. I was in a lot of languages, in all different programming styles. Lisp still is the language with a maximum of freedom of programming, probably also regarding productivity. Only Nim comes close. Haskell may look elegant at the surface, regarding productivity however I don't recommend it except for DSL and compiler construction. If you are not a world class expert in Haskell then in most cases Haskell takes a lot more time for development than other languages (say Lisp, Python, C++, even Rust).

dmytrish 9y ago
> in most cases Haskell takes a lot more time for development than other languages - and takes negligible maintenance/refactoring time compared to Lisp/Python/C++. Maintenance timesink might easily outweigh the gain in development time. That's the promise of strong type systems: preventing bugs from happening before you have to debug them in production and it does not come absolutely free.
- lispm 9y ago
  In Lisp you can change the programs while they are running, in ways not possible in Haskell. The time Haskell needs to recompile the code to machine code, I have fixed the Lisp bug already.
  - dmytrish 9y ago
    ...and introduced two new bugs.
    - lispm 9y ago
      and tested and fixed them, too.
    - junke 9y ago
      Are you fighting the Hydra?
  - bhnmmhmd 9y ago
    Could you elaborate on how we can change Lisp programs while they're running? Sounds interesting. I actually had heard something similar about how JPL used Lisp and they could just debug the satellite remotely from the earth.
    - lispm 9y ago
      Take for example an Emacs editor written in Lisp, like for example GNU Emacs. The language used (here Emacs Lisp) is capable enough for a wide range of programming tasks. If you want to change the behavior of the editor, you can just load Lisp code into it. That could add new functionality or replace old. If you need an extension module, you can just load it. No need to restart the editor. Hard then is unloading. The editor includes a Lisp interpreter and a Lisp compiler to byte code of a virtual machine. It can also load new source and compiled code at runtime. Function calls often go through a symbol table and you can register new functions, delete them or replace them. There are lists of functions often used to be triggered at some point. You can add/remove functions to these lists. In something like Common Lisp you can do changes to the object-system at runtime, both to the program and the programming language. For example you can load a patch, which changes the class hierarchy, adds slots, ... Also existing objects can be changed - they can change their class or the list of slots, etc.
- progman 9y ago
  > Maintenance timesink might easily outweigh the gain in development time. That is correct. However, in Haskell you need a lot of discipline to guide a big project in the right direction. Maintenance can quickly became a nightmare due to very dense code. If maintenance is the main issue I would choose Ada than Haskell. I have no problem to understand my own Ada code written 10 years ago, even without documentation. In Haskell however I had problems to understand my own code which was just some weeks old :-)
  - tome 9y ago
    > That is correct. However, in Haskell you need a lot of discipline to guide a big project in the right direction. Maintenance can quickly became a nightmare due to very dense code. Have you worked with Haskell professionally? Your observations do not match my experience of approx. 3 years of professional Haskell development across 3 different companies. Guiding the growth of Haskell codebases is trivial compared to Python, which is the other language I have professional experience of.
    - progman 9y ago
      > Have you worked with Haskell professionally? Not yet. I was seriously interested in Haskell. The cabal hell however put me back. Stack is interesting but installation from source is still troublesome. I always want to be able to install my developer tools from scratch (by source only) since I want to make sure that I can port my software to new systems. Haskell's and Rust's way of installation (curl | sh) is convenient but inacceptable for porting. Nim's bootstrap from source (no dependencies except a C compiler) is the right way how it should be.
      - dom96 9y ago
        That's cool to hear. Except that we now offer an install method similar to Rust via a tool called choosenim.

dmytrish 9y ago

> in most cases Haskell takes a lot more time for development than other languages - and takes negligible maintenance/refactoring time compared to Lisp/Python/C++. Maintenance timesink might easily outweigh the gain in development time. That's the promise of strong type systems: preventing bugs from happening before you have to debug them in production and it does not come absolutely free.

lispm 9y ago
In Lisp you can change the programs while they are running, in ways not possible in Haskell. The time Haskell needs to recompile the code to machine code, I have fixed the Lisp bug already.
- dmytrish 9y ago
  ...and introduced two new bugs.
  - lispm 9y ago
    and tested and fixed them, too.
  - junke 9y ago
    Are you fighting the Hydra?
- bhnmmhmd 9y ago
  Could you elaborate on how we can change Lisp programs while they're running? Sounds interesting. I actually had heard something similar about how JPL used Lisp and they could just debug the satellite remotely from the earth.
  - lispm 9y ago
    Take for example an Emacs editor written in Lisp, like for example GNU Emacs. The language used (here Emacs Lisp) is capable enough for a wide range of programming tasks. If you want to change the behavior of the editor, you can just load Lisp code into it. That could add new functionality or replace old. If you need an extension module, you can just load it. No need to restart the editor. Hard then is unloading. The editor includes a Lisp interpreter and a Lisp compiler to byte code of a virtual machine. It can also load new source and compiled code at runtime. Function calls often go through a symbol table and you can register new functions, delete them or replace them. There are lists of functions often used to be triggered at some point. You can add/remove functions to these lists. In something like Common Lisp you can do changes to the object-system at runtime, both to the program and the programming language. For example you can load a patch, which changes the class hierarchy, adds slots, ... Also existing objects can be changed - they can change their class or the list of slots, etc.
progman 9y ago
> Maintenance timesink might easily outweigh the gain in development time. That is correct. However, in Haskell you need a lot of discipline to guide a big project in the right direction. Maintenance can quickly became a nightmare due to very dense code. If maintenance is the main issue I would choose Ada than Haskell. I have no problem to understand my own Ada code written 10 years ago, even without documentation. In Haskell however I had problems to understand my own code which was just some weeks old :-)
- tome 9y ago
  > That is correct. However, in Haskell you need a lot of discipline to guide a big project in the right direction. Maintenance can quickly became a nightmare due to very dense code. Have you worked with Haskell professionally? Your observations do not match my experience of approx. 3 years of professional Haskell development across 3 different companies. Guiding the growth of Haskell codebases is trivial compared to Python, which is the other language I have professional experience of.
  - progman 9y ago
    > Have you worked with Haskell professionally? Not yet. I was seriously interested in Haskell. The cabal hell however put me back. Stack is interesting but installation from source is still troublesome. I always want to be able to install my developer tools from scratch (by source only) since I want to make sure that I can port my software to new systems. Haskell's and Rust's way of installation (curl | sh) is convenient but inacceptable for porting. Nim's bootstrap from source (no dependencies except a C compiler) is the right way how it should be.
    - dom96 9y ago
      That's cool to hear. Except that we now offer an install method similar to Rust via a tool called choosenim.