5 ms·

I think maintaining old software is a known problem, regardless of the language. What about lisps make them more challenging in this regard?

bitwize 12y ago
For one, static typing is optional in Lisp -- if it's even there at all. If you want to write maintainable code and catch bugs early, that pretty much rules out dynamically typed languages.
- ayrx 12y ago
  Are you implying that it's impossible to write maintainable code in any dynamic language?
  - GreaterFool 12y ago
    In lisp you have the power to easily invent abstractions. Strip things down to a bare minimum and you can see that your code is good. And write some tests just in case. OTOH in strongly typed languages with rich type systems the actual code might be uglier and more complicated because you're constructing a proof of something. The property might be week (tests needed!) or strong (tests? what tests). Depends how far the rabbit hole you want to go. At least that's my view on this.
    - kd0amg 12y ago
      uglier and more complicated because you're constructing a proof of something It's rare for the programmer to actually produce proofs that a piece of code meets the spec given by its type[1]. Those proofs are generally produced by the type checker, possibly with occasional hints from the programmer. 1: Even in Coq, detailed specs for some code are typically given (and proven) separate from the code itself rather than in that code's own type.
  - mpdehaan2 12y ago
    Type errors in programs don't come up nearly enough to warrant languages completely dwelling on them so much. Now, say, consistent argument order does help a lot if you are writing your own libraries, but I wouldn't place the blame there on the language.
    - rkrzr 12y ago
      Type errors come in more shapes than the obvious one: e.g. Untyped data structures like dictionaries are a frequent source of error in Python (KeyError e.g.) or non-uniform lists. These are pretty common bugs, I'd argue, which simply cannot happen in statically typed languages like Haskell.
  - pjc50 12y ago
    Dynamic languages rely on test suites to catch bugs. The test suite is also software that must be maintained. Statically typed languages apply typechecking as a "test" to the entire program at load time. People have written and maintained code in typeless assembler, including for mission-critical systems. It's just more work and requires a different kind of rigor. The larger and more complex your system gets, the more useful typechecking becomes. "Maintainable" is not a boolean, it's a cost function.
  - s_kilk 12y ago
    Not impossible, but in my experience it takes disproportionately more work than if you have a decent type-system to help you out. In a dynamically typed system, every expression and line of code is a liability, and requires a large weight of tests to have any confidence that it might work.
  - bitwize 12y ago
    No, but depending on the size of your code base and your available budget, it can get prohibitively expensive really quickly. Static typing eliminates entire classes of bugs. The cost of the up-front inconvenience to the programmer is tiny compared to the ongoing maintenance costs of possibly-incorrect, we-won't-know-for-sure-until-that-code-path-executes-in-production dynamically-typed code. This is dependent on many variables but a good rule of thumb is that for any project bigger than a doddle, it's a safe bet to just fucking use a statically typed language.
GreaterFool 12y ago
Lack of types. I don't want to start a discussion here on typed vs untyped so please consider everything I say to be qualified "It is only my personal opinion and experience". I'm writing Haskell in my day job, Clojure for fun side project, OCaml because it's a nice language that's a bit underused and C++ because it's useful to know and not so evil as most people say (and it's progressing fast!). I should throw Rust into the mix because it might have a bright future. WARNING: personal opinions and anecdotal evidence ahead! Maybe there's a level of lisp enlightenment that I haven't reached yet but I can't just get by with writing lisp without writing tests. On the other hand I can get by with writing Haskell and OCaml without writing tests. This is particularly true when I'm coming back to a project that I haven't touched for a few weeks. I change something and something breaks. In Haskell and OCaml I change something and compiler complains. Maybe we'll see HaLispML one day.
- swah 12y ago
  At some point, I thought OCaml would be the NBL since the writing part was fun and easy due to type inference (mostly, I hate using +.) and the refactoring felt safe. BUT those guys are much smarter than us... so creating a language that combines the qualities of dynamic and static languages is probably a hard problem.
  - cwyers 12y ago
    F# isn't exactly OCaml, but it's a close relative and... I don't know if it's the next big language, but it feels like it's one of them.
    - swah 12y ago
      Haven't you heard? Javascript is the NBL :(
- bmh100 12y ago
  Have you tried typed Clojure [1]? It seems promising for bringing in types. [1]: https://github.com/clojure/core.typed/ https://github.com/clojure/core.typed/

bitwize 12y ago

For one, static typing is optional in Lisp -- if it's even there at all. If you want to write maintainable code and catch bugs early, that pretty much rules out dynamically typed languages.

ayrx 12y ago
Are you implying that it's impossible to write maintainable code in any dynamic language?
- GreaterFool 12y ago
  In lisp you have the power to easily invent abstractions. Strip things down to a bare minimum and you can see that your code is good. And write some tests just in case. OTOH in strongly typed languages with rich type systems the actual code might be uglier and more complicated because you're constructing a proof of something. The property might be week (tests needed!) or strong (tests? what tests). Depends how far the rabbit hole you want to go. At least that's my view on this.
  - kd0amg 12y ago
    uglier and more complicated because you're constructing a proof of something It's rare for the programmer to actually produce proofs that a piece of code meets the spec given by its type[1]. Those proofs are generally produced by the type checker, possibly with occasional hints from the programmer. 1: Even in Coq, detailed specs for some code are typically given (and proven) separate from the code itself rather than in that code's own type.
- mpdehaan2 12y ago
  Type errors in programs don't come up nearly enough to warrant languages completely dwelling on them so much. Now, say, consistent argument order does help a lot if you are writing your own libraries, but I wouldn't place the blame there on the language.
  - rkrzr 12y ago
    Type errors come in more shapes than the obvious one: e.g. Untyped data structures like dictionaries are a frequent source of error in Python (KeyError e.g.) or non-uniform lists. These are pretty common bugs, I'd argue, which simply cannot happen in statically typed languages like Haskell.
- pjc50 12y ago
  Dynamic languages rely on test suites to catch bugs. The test suite is also software that must be maintained. Statically typed languages apply typechecking as a "test" to the entire program at load time. People have written and maintained code in typeless assembler, including for mission-critical systems. It's just more work and requires a different kind of rigor. The larger and more complex your system gets, the more useful typechecking becomes. "Maintainable" is not a boolean, it's a cost function.
- s_kilk 12y ago
  Not impossible, but in my experience it takes disproportionately more work than if you have a decent type-system to help you out. In a dynamically typed system, every expression and line of code is a liability, and requires a large weight of tests to have any confidence that it might work.
- bitwize 12y ago
  No, but depending on the size of your code base and your available budget, it can get prohibitively expensive really quickly. Static typing eliminates entire classes of bugs. The cost of the up-front inconvenience to the programmer is tiny compared to the ongoing maintenance costs of possibly-incorrect, we-won't-know-for-sure-until-that-code-path-executes-in-production dynamically-typed code. This is dependent on many variables but a good rule of thumb is that for any project bigger than a doddle, it's a safe bet to just fucking use a statically typed language.

GreaterFool 12y ago

Lack of types. I don't want to start a discussion here on typed vs untyped so please consider everything I say to be qualified "It is only my personal opinion and experience". I'm writing Haskell in my day job, Clojure for fun side project, OCaml because it's a nice language that's a bit underused and C++ because it's useful to know and not so evil as most people say (and it's progressing fast!). I should throw Rust into the mix because it might have a bright future. WARNING: personal opinions and anecdotal evidence ahead! Maybe there's a level of lisp enlightenment that I haven't reached yet but I can't just get by with writing lisp without writing tests. On the other hand I can get by with writing Haskell and OCaml without writing tests. This is particularly true when I'm coming back to a project that I haven't touched for a few weeks. I change something and something breaks. In Haskell and OCaml I change something and compiler complains. Maybe we'll see HaLispML one day.

swah 12y ago
At some point, I thought OCaml would be the NBL since the writing part was fun and easy due to type inference (mostly, I hate using +.) and the refactoring felt safe. BUT those guys are much smarter than us... so creating a language that combines the qualities of dynamic and static languages is probably a hard problem.
- cwyers 12y ago
  F# isn't exactly OCaml, but it's a close relative and... I don't know if it's the next big language, but it feels like it's one of them.
  - swah 12y ago
    Haven't you heard? Javascript is the NBL :(
bmh100 12y ago
Have you tried typed Clojure [1]? It seems promising for bringing in types. [1]: https://github.com/clojure/core.typed/ https://github.com/clojure/core.typed/