5 ms·

Well, in lisp languages you just write an abstraction layer to account for such problem areas. It's really no different than the OO argument. If one wants OO f

by tahssa 11y ago

Well, in lisp languages you just write an abstraction layer to account for such problem areas. It's really no different than the OO argument. If one wants OO functionality in lisp it can be implemented with the introduction of a few functions. But by using an OO only language you have just forced that abstraction to the surface leaving you with only one way to write your code even when it's not suitable for the problem space. So the same could be said for Types. Without Type Inference you're locking yourself in to model/framework that has a list of disadvantages too. I think the real problem is when people don't recognize they need to account for those problem areas, and they don't take the time to write the abstraction layer when needed and naturally they end up with bad results and feel like it's just hacking, because, well, they are.

catnaroek 11y ago
Implementing statically checked abstractions in Lisp or Clojure using `defmacro` is a royal pain in the rear hole. Error messages from macros being used wrong range from "confusing" at best, to "WTF is this %#$&%#$&?" at worst. Racket supports your argument much better. And Racket is not Lisp: https://news.ycombinator.com/item?id=10763584 https://news.ycombinator.com/item?id=10763584
- tahssa 11y ago
  I wouldn't go that far. The problem outlined was in dealing with data model changes. So the problem as I see is in managing the alignment of parameter types used in code with database field types. For that I've written a schema-template abstraction that manages that relationship. This template engine is about 100 lines of code and for every point the code intersect to/from the data it goes through the engine, looks up the a template and uses that for access/processing (a hook if you will). This allows automation for finding all the code entry spots. Bottom line is I don't hit these issues because I identified the problem and wrote an abstraction layer to handle it and for the rest of my code I can happily rely on type inference.
  - catnaroek 11y ago
    What exactly are you calling "type inference"? It cannot be ML-like type reconstruction, because doing that requires either whole program analysis or a prohibition from interacting with untyped code.
    - tahssa 11y ago
      You're correct. A late night slip, I meant dynamic typing.

by tahssa 11y ago

catnaroek 11y ago

Implementing statically checked abstractions in Lisp or Clojure using `defmacro` is a royal pain in the rear hole. Error messages from macros being used wrong range from "confusing" at best, to "WTF is this %#$&%#$&?" at worst. Racket supports your argument much better. And Racket is not Lisp: https://news.ycombinator.com/item?id=10763584 https://news.ycombinator.com/item?id=10763584

tahssa 11y ago
I wouldn't go that far. The problem outlined was in dealing with data model changes. So the problem as I see is in managing the alignment of parameter types used in code with database field types. For that I've written a schema-template abstraction that manages that relationship. This template engine is about 100 lines of code and for every point the code intersect to/from the data it goes through the engine, looks up the a template and uses that for access/processing (a hook if you will). This allows automation for finding all the code entry spots. Bottom line is I don't hit these issues because I identified the problem and wrote an abstraction layer to handle it and for the rest of my code I can happily rely on type inference.
- catnaroek 11y ago
  What exactly are you calling "type inference"? It cannot be ML-like type reconstruction, because doing that requires either whole program analysis or a prohibition from interacting with untyped code.
  - tahssa 11y ago
    You're correct. A late night slip, I meant dynamic typing.