9 ms·

It is not hard to write code in Racket or Clojure; what's hard is maintaining it! I've written a small Clojure project, maybe 3k loc. It was great fun. But whe

It is not hard to write code in Racket or Clojure; what's hard is maintaining it! I've written a small Clojure project, maybe 3k loc. It was great fun. But when I go back to add small features I find it quite tricky. Bugs often sneak in.

biesnecker 12y ago
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/
Adrock 12y ago
How many lines were tests?
- Adrock 12y ago
  I'll just assume that the answer to the question is expressed in points it earned.
s_kilk 12y ago
I tend to agree. I've had great fun banging out programs in Clojure, but the lack of types makes coming back to fix bugs or extend the program quite unpleasant. I'm doing a lot more Scala these days, which feels a lot easier to work with in the long run.
- Jare 12y ago
  That has been my very limited experience as well, but with Scala I'm still things will get out of hand. The only "new" language I feel confident would not disappoint or surprise me negatively down the road is Golang.
  - ibebrett 12y ago
    What makes you think that? I have had the opposite experience with Scala/Haskell
    - Jare 12y ago
      The language is large, supports multiple paradigms and in general allows many different ways to express the same thing. That's great for short term productivity and/or small and tightly knit teams, but I worry about less ideal conditions. In theory a strict and well defined style guide should take care of that (I have used them successfully in C++), but I feel with Scala that will not be enough. Expressed differently: Scala is a great language for smart and careful programmers, but a ticking bomb for the less talented masses. Golang, in comparison, is very transparent, WSYIWYG.
  - ibebrett 12y ago
    What makes you think that? I have had the opposite experience with Scala/Haskell
TeMPOraL 12y ago
I have an opposite experience with Common Lisp. Yes, I tend to make bugs in it, but I tend to fix them so quickly I don't really mind. SLIME is godsend.

biesnecker 12y ago

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/

Adrock 12y ago

How many lines were tests?

Adrock 12y ago
I'll just assume that the answer to the question is expressed in points it earned.

s_kilk 12y ago

I tend to agree. I've had great fun banging out programs in Clojure, but the lack of types makes coming back to fix bugs or extend the program quite unpleasant. I'm doing a lot more Scala these days, which feels a lot easier to work with in the long run.

Jare 12y ago
That has been my very limited experience as well, but with Scala I'm still things will get out of hand. The only "new" language I feel confident would not disappoint or surprise me negatively down the road is Golang.
- ibebrett 12y ago
  What makes you think that? I have had the opposite experience with Scala/Haskell
  - Jare 12y ago
    The language is large, supports multiple paradigms and in general allows many different ways to express the same thing. That's great for short term productivity and/or small and tightly knit teams, but I worry about less ideal conditions. In theory a strict and well defined style guide should take care of that (I have used them successfully in C++), but I feel with Scala that will not be enough. Expressed differently: Scala is a great language for smart and careful programmers, but a ticking bomb for the less talented masses. Golang, in comparison, is very transparent, WSYIWYG.
- ibebrett 12y ago
  What makes you think that? I have had the opposite experience with Scala/Haskell

TeMPOraL 12y ago

I have an opposite experience with Common Lisp. Yes, I tend to make bugs in it, but I tend to fix them so quickly I don't really mind. SLIME is godsend.