5 ms·

As to namespaced keywords, I was skeptical at first, and all my spec definitions used unqualified keywords. But as usual, if Rich does things a certain way, the

by jwr 8y ago

As to namespaced keywords, I was skeptical at first, and all my spec definitions used unqualified keywords. But as usual, if Rich does things a certain way, there are good reasons behind it, even if they don't immediately seem apparent. As my code base has grown, I found that namespaced keywords make a lot of sense, not just because of clojure.spec. They give you a convenient way of naming things uniquely, which lets you have data structures that combine several kinds of data without worrying about naming clashes. You don't notice their utility in code examples, or small projects, but in large projects they are very useful.

iorekz 8y ago
The only issue I thought about would be when using json as I guess this would lose the namespace infos. Did you have issue with that ?
- lvh 8y ago
  Sorta! Cheshire gives you a key-fn entry point. For small JSON objects you may just want the same namespace and then that is sufficient. Otherwise you can look up the right namespace in that fn or walk that tree (I’ve used specter for this) to correctly annotate.
- escherize 8y ago
  Here's some valid json that might be useful: {"signup/username": "John", "signup/password": "pg4pres"} Then, because you can pass in a function to get called on the keys, just check for a regex like (.+)/(.+) and turn it into a keyword. Here I'll write a function like that real quick using a repl with a nice ux: https://s3-us-east-2.amazonaws.com/photoblobs/Screen_Recording_2018-10-07_at_1.53.55_PM.mov https://s3-us-east-2.amazonaws.com/photoblobs/Screen_Recordi...
- jwr 8y ago
  I keep my data in a JSON database (RethinkDB). This is not a problem at all: namespaced keywords are converted to strings and the conversion is well-defined in both directions.
tigershark 8y ago
From what I have seen in this article, and hn thread, and every time in general when there is a discussion about clojure or dynamic typed languages, you are only speaking about tiny examples and even more tiny projects. I can’t really imagine myself working on a million line project written in clojure or another language without any type safety. Happy to be wrong, but I’d like to hear the experiences of people actually working on this kind of big projects rather than pointing to toy projects less than 10k lines maintained by tens of people... From my experience dynamic typing can be awesome for small prototypes, but to be production ready you need to spend much more energy for testing. More on the topic I can say that I don’t really see anything compelling that you can’t easily do in F# with a lot more safety in this article...
- deleted 8y ago
  [deleted]
- cageface 8y ago
  I haven't worked on any significant Clojure codebases but I have worked in large codebases in other dynamic languages and it's a nightmare. Maintaining a Rails app, for example, after it gets beyond a certain size is just punishing.
  - pankajdoharey 8y ago
    Its a nightmare to modify a moderately large Rails App.
  - christophilus 8y ago
    The problem with Rails isn’t so much its dynamic nature as much as it is how everything is implicit, and it’s really hard to track down where certain functionality is happening. I doubt Clojure would be so bad, as it’s explicit. Immutability also helps.
- bunderbunder 8y ago
  The article does address this, though maybe not authoritatively, under the "Refactoring" header. > I’ve felt this pain a few times and the only conclusions I’ve drawn are to use clojure.spec for non-trivial code, especially around domain boundaries, and try even harder to solve very small problems in ways that can compose to solve larger ones. This seems reasonable to me. A lot of where refactoring gets painful is when you have bits of code being reused across wide swaths of the program. Keeping modules small limits the opportunity for that to happen, and makes the scope of impact for a change easier to conceptualize without leaning on a compiler. The problem I see there is, it seems to be exceedingly rare that you can get a whole team of developers to be so disciplined - and all it takes is one lapse in discipline for it all to fall apart.

by jwr 8y ago

iorekz 8y ago

The only issue I thought about would be when using json as I guess this would lose the namespace infos. Did you have issue with that ?

lvh 8y ago
Sorta! Cheshire gives you a key-fn entry point. For small JSON objects you may just want the same namespace and then that is sufficient. Otherwise you can look up the right namespace in that fn or walk that tree (I’ve used specter for this) to correctly annotate.
escherize 8y ago
Here's some valid json that might be useful: {"signup/username": "John", "signup/password": "pg4pres"} Then, because you can pass in a function to get called on the keys, just check for a regex like (.+)/(.+) and turn it into a keyword. Here I'll write a function like that real quick using a repl with a nice ux: https://s3-us-east-2.amazonaws.com/photoblobs/Screen_Recording_2018-10-07_at_1.53.55_PM.mov https://s3-us-east-2.amazonaws.com/photoblobs/Screen_Recordi...
jwr 8y ago
I keep my data in a JSON database (RethinkDB). This is not a problem at all: namespaced keywords are converted to strings and the conversion is well-defined in both directions.

tigershark 8y ago

From what I have seen in this article, and hn thread, and every time in general when there is a discussion about clojure or dynamic typed languages, you are only speaking about tiny examples and even more tiny projects. I can’t really imagine myself working on a million line project written in clojure or another language without any type safety. Happy to be wrong, but I’d like to hear the experiences of people actually working on this kind of big projects rather than pointing to toy projects less than 10k lines maintained by tens of people... From my experience dynamic typing can be awesome for small prototypes, but to be production ready you need to spend much more energy for testing. More on the topic I can say that I don’t really see anything compelling that you can’t easily do in F# with a lot more safety in this article...

deleted 8y ago
[deleted]
cageface 8y ago
I haven't worked on any significant Clojure codebases but I have worked in large codebases in other dynamic languages and it's a nightmare. Maintaining a Rails app, for example, after it gets beyond a certain size is just punishing.
- pankajdoharey 8y ago
  Its a nightmare to modify a moderately large Rails App.
- christophilus 8y ago
  The problem with Rails isn’t so much its dynamic nature as much as it is how everything is implicit, and it’s really hard to track down where certain functionality is happening. I doubt Clojure would be so bad, as it’s explicit. Immutability also helps.
bunderbunder 8y ago
The article does address this, though maybe not authoritatively, under the "Refactoring" header. > I’ve felt this pain a few times and the only conclusions I’ve drawn are to use clojure.spec for non-trivial code, especially around domain boundaries, and try even harder to solve very small problems in ways that can compose to solve larger ones. This seems reasonable to me. A lot of where refactoring gets painful is when you have bits of code being reused across wide swaths of the program. Keeping modules small limits the opportunity for that to happen, and makes the scope of impact for a change easier to conceptualize without leaning on a compiler. The problem I see there is, it seems to be exceedingly rare that you can get a whole team of developers to be so disciplined - and all it takes is one lapse in discipline for it all to fall apart.