I use an eerily similar stack with clojure, ring/compojure, http-kit, java.jdbc + c3p0, timbre and I have to say it's fantastic.
I created a kind of a template with how to organize namespaces around that and how to address and automatically parse the URL/form parameters depending on the URL and send a "missing param" or "malformed param" back in the appropiate cases. It also deals with optional params
The app basically only abstracts away the HTTP Server stuff and calls the appropriate call in an API namespace (where someone else could hook in if he wants to use his own server).
Also, I now save all DDL in a separate resources/SQL folder and parse it if I need to rewrite the DB from clojure (e.g., at initialization after deploy). In the folder there is a schema.sql in which all other DDL is called via \ir.
Checking whether the current version is the most up to date I still do manually (so if I add an index to some table in the DB, I add checking for this index via postgres native tables in the migrated? function) but this will be automated as well some time in the future.
The reason why I use org.clojure/java.jdbc is because I can use all native postgres features (arrays, jsonb, tsvector, ...) without using the very weird java.sql constructors. This is also one of the major points against any current library.
Semi off-topic, but might helps others as well: What should an experienced OO dev read to better understand how dynamic FP languages, like Clojure, alleviate the aforementioned cons of OO in the architecture of large-scale agile projects? In other words: I know from experience what's the downside of OO, but I don't know how dynamic FP languages would help without sacrificing the benefits of OO?
I might just be confused, but from what read/understand I don't think FP vs OO is a proper comparison.
I think the right question should be FP vs imperative languages? As far as I know even functional languages can have OO features, but functional programming is more about getting away from an imperative style of programming.
Maybe someone who knows more can chime in though.
But in my personal experience, using a functional language just helps me write correct code. Using an imperative language makes it easy to be sloppy and include bugs
For me understanding the greatness of FP was build on the understanding that there are no "benefits of OO".
Once I realized that the "abstractions of classes and inheritance" and "encapsulations of state in objects" (and other OO-paradigm pillars) where harmful, I started truly researching the alternatives.
I could go back to C --imperative, state-all-over-the-place, self-managed memory-- but it seemed like an impossible step in web development.
Quickly I found promise in languages like Clojure and Haskell. High-level enough for web development, yet faster them my trusted Ruby code, and seemingly more maintainable.
The main benefit of OO I know experience is it's popularity. Going from Java to Ruby is a lot easier then from Ruby to Clojure or Haskell. The good news: many OO languages are incorporating FP'isms, and allowing a functional approach to solve problems, this helps FP like myself newcomers quite a bit.
TL;DR: I came to the realisation that the benefits of OO where mainly theoretical and did not hold in practice. Main 'real' benefit of OO is its popularity.
What are the benefits of OO? I normally think of encapsulation, but this isn't that big of a deal in Clojure (or many other functional languages) as you normally can't mutate objects anyway.
How did you handle refactorings? Like, changing userAddress's "type" from Address to Maybe Address?
This is what scares me the most in Clojure and all other dynamic languages - that early on in the project, I'd make an unfortunate decision which I wouldn't be able to go back on once the project goes over 2-3kloc... without introducing hundreds of potential runtime errors, that is.
We made heavy use of Primastic's schema when we felt we needed guarantees about the shape of the data, this help in areas where you want the extra checking and documentation.
In practice refactorings such as changing Address->MaybeAddress didn't hurt us so much. With good test coverage also, it's not a huge issue.
Clojure code-bases tend to be more much concise and well organised, so refactoring based on expected data and output doesn't bite as much as people often fear.
The "Clojurians don't like testing" meme probably has more to do with Rich Hickey's famous "guard rail programming" [1] comment than anything else. Of course, even at the time, the joke within the community was, "Yes, Rich Hickey doesn't need to write tests....you do!"
[+] [-] hackbinary|10 years ago|reply
https://www.onthemarket.com/
Not sure why he just didn't say it, that information is available elsewhere anyway.
https://juxt.pro/
http://blog.juxt.pro/posts/otm.html
[+] [-] dmichulke|10 years ago|reply
I created a kind of a template with how to organize namespaces around that and how to address and automatically parse the URL/form parameters depending on the URL and send a "missing param" or "malformed param" back in the appropiate cases. It also deals with optional params
The app basically only abstracts away the HTTP Server stuff and calls the appropriate call in an API namespace (where someone else could hook in if he wants to use his own server).
Also, I now save all DDL in a separate resources/SQL folder and parse it if I need to rewrite the DB from clojure (e.g., at initialization after deploy). In the folder there is a schema.sql in which all other DDL is called via \ir.
Checking whether the current version is the most up to date I still do manually (so if I add an index to some table in the DB, I add checking for this index via postgres native tables in the migrated? function) but this will be automated as well some time in the future.
The reason why I use org.clojure/java.jdbc is because I can use all native postgres features (arrays, jsonb, tsvector, ...) without using the very weird java.sql constructors. This is also one of the major points against any current library.
[+] [-] yenda|10 years ago|reply
[+] [-] pwm|10 years ago|reply
[+] [-] rifung|10 years ago|reply
I think the right question should be FP vs imperative languages? As far as I know even functional languages can have OO features, but functional programming is more about getting away from an imperative style of programming.
Maybe someone who knows more can chime in though.
But in my personal experience, using a functional language just helps me write correct code. Using an imperative language makes it easy to be sloppy and include bugs
[+] [-] cies|10 years ago|reply
For me understanding the greatness of FP was build on the understanding that there are no "benefits of OO".
Once I realized that the "abstractions of classes and inheritance" and "encapsulations of state in objects" (and other OO-paradigm pillars) where harmful, I started truly researching the alternatives.
I could go back to C --imperative, state-all-over-the-place, self-managed memory-- but it seemed like an impossible step in web development.
Quickly I found promise in languages like Clojure and Haskell. High-level enough for web development, yet faster them my trusted Ruby code, and seemingly more maintainable.
The main benefit of OO I know experience is it's popularity. Going from Java to Ruby is a lot easier then from Ruby to Clojure or Haskell. The good news: many OO languages are incorporating FP'isms, and allowing a functional approach to solve problems, this helps FP like myself newcomers quite a bit.
TL;DR: I came to the realisation that the benefits of OO where mainly theoretical and did not hold in practice. Main 'real' benefit of OO is its popularity.
[+] [-] pjmlp|10 years ago|reply
What do you mean, given that Smalltalk, JavaScript, SELF, Ruby, Python, Dart, Dylan, Common Lisp, Julia, StrongTalk ....
Are all dynamic languages with OOP features.
[+] [-] Skinney|10 years ago|reply
[+] [-] g8gggu89|10 years ago|reply
Are the comparisons are hard to find online, or are they not addressing your exact issue? What benefits of OO do you think you'd be losing?
[+] [-] pka|10 years ago|reply
This is what scares me the most in Clojure and all other dynamic languages - that early on in the project, I'd make an unfortunate decision which I wouldn't be able to go back on once the project goes over 2-3kloc... without introducing hundreds of potential runtime errors, that is.
[+] [-] jonpither|10 years ago|reply
In practice refactorings such as changing Address->MaybeAddress didn't hurt us so much. With good test coverage also, it's not a huge issue.
Clojure code-bases tend to be more much concise and well organised, so refactoring based on expected data and output doesn't bite as much as people often fear.
[+] [-] mateuszf|10 years ago|reply
[+] [-] donjigweed|10 years ago|reply
[1] http://www.infoq.com/presentations/Simple-Made-Easy (15:30)
[+] [-] sheepmullet|10 years ago|reply
And Rich Hickey isn't against testing. He was having a jab at test driven design.
[+] [-] khgvljhkb|10 years ago|reply
[+] [-] jonpither|10 years ago|reply