4 ms·

You're completely right. Clojure enables an incredible amount of productivity. It lets an engineer compose just the things they need, quickly and powerfully, to

by Kalium 8y ago

You're completely right. Clojure enables an incredible amount of productivity. It lets an engineer compose just the things they need, quickly and powerfully, to ship something complete and functioning rapidly. With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the ecosystem incredibly immature. It's somewhere beyond arrogant - reckless comes to mind - for most engineers to do all their own plumbing for a web service. The odds that they'll manage to design someone easily long-term maintainable are slim. The chances of authorization, authentication, potential SQL injection, and a thousand other security things being handled well is effectively none - the Clojure ecosystem seems wildly ignorant of such things. The core philosophy of just composing the libraries you need into Ring means that anything you don't actively think of will be entirely neglected. This is a dangerous and unprofessional way to ship code that will be facing the real internet. This stands in stark contrast to the level of consideration around maintenance and security that has gone into a modern, mature framework. Or a modern language where SAST is an option. Again, you're completely correct. Doing low-level stuff feels absolutely amazing! The sense of control, of having your hands in the guts and the ability to do what you need without wasting time on bullshit magic, is heady and glorious. It's just perhaps worth considering that that magic can sometimes be incredibly valuable, well worth the tradeoff against the feeling of freedom.

tombert 8y ago
I threw Clojure in as an example, but my point is that if I avoid the ceremony, and stick to a few slightly-lower-level libraries, I end up with a lot less code that I feel was overall, easier to write and maintain.
- Kalium 8y ago
  Again, you're completely right. You will get something easier to fit into your head. Is it perhaps possible that there might be some room to question if the goal of something that fits neatly it one person's head is really the best one? For professional applications, some might opine that there could be other considerations. Certainly most of my comments about Clojure apply to any tools that work from the same mindset. But perhaps I merely misunderstand an elegantly made point of yours - can you help me?
  - tombert 8y ago
    Sure, it's possible that my mentality is totally wrong, and that having a large amount of cruft is necessary for a lot of big projects. I even built my own framework to experiment with these ideas [1][2] (forewarned that I think I swore a lot in the codebase and READMEs if that's a problem). I can see that there's probably a case to be made for "forced-best-practices", which a lot of frameworks kind of entail, and I think that if you don't trust yourself (or coworkers) to write quality code, then having the guardrails for that Rails and ASP.NET MVC give you probably feel nice. However, I think a case can be made that these same guardrails can feel restrictive and noisy to more experienced developers (or people with large-enough egos like me). I have no desire to ever touch J2EE ever again in my life, no matter how much I could get paid doing it, because it felt like getting anything done was about as much fun as filing my taxes. Rails is certainly not as terrible as J2EE, so I'm not trying to draw a direct equivalence, and maybe a balance can be struck...Personally, I find that the "give me a server and I'll set up some middleware on top" approach like Express (for Node), and the aforementioned Ring/HTTP-Kit for Clojure give me the best balance. Clearly there's a middle-ground -- I certainly wouldn't suggest that most people go and reimplement TCP and HTTP from scratch for a project, unless they're severely masochistic, or they just want to learn more about TCP or HTTP. [1] https://gitlab.com/tombert/frameworkeyPromiseEdition https://gitlab.com/tombert/frameworkeyPromiseEdition [2] https://gitlab.com/tombert/Frameworkey-Erlang https://gitlab.com/tombert/Frameworkey-Erlang
    - Kalium 8y ago
      I've personally watched experienced, mature, and very senior developers build sophisticated systems with Clojure, Ring, and http-kit. And blink at me owlishly when I ask them how they sanitize their inputs to guard against SQL injection. They'd been intensely focused on the core logic, architecture, system design, and business functions. Everything else received cursury consideration. My takeaway from that is that it's unreasonable to expect even the best of developers to remember every detail every time. Even the best forget or make mistakes. If our tools don't take this into account and protect us from ourselves, we're going to get burned.
      - 8y ago

by Kalium 8y ago

tombert 8y ago

I threw Clojure in as an example, but my point is that if I avoid the ceremony, and stick to a few slightly-lower-level libraries, I end up with a lot less code that I feel was overall, easier to write and maintain.

Kalium 8y ago
Again, you're completely right. You will get something easier to fit into your head. Is it perhaps possible that there might be some room to question if the goal of something that fits neatly it one person's head is really the best one? For professional applications, some might opine that there could be other considerations. Certainly most of my comments about Clojure apply to any tools that work from the same mindset. But perhaps I merely misunderstand an elegantly made point of yours - can you help me?
- tombert 8y ago
  Sure, it's possible that my mentality is totally wrong, and that having a large amount of cruft is necessary for a lot of big projects. I even built my own framework to experiment with these ideas [1][2] (forewarned that I think I swore a lot in the codebase and READMEs if that's a problem). I can see that there's probably a case to be made for "forced-best-practices", which a lot of frameworks kind of entail, and I think that if you don't trust yourself (or coworkers) to write quality code, then having the guardrails for that Rails and ASP.NET MVC give you probably feel nice. However, I think a case can be made that these same guardrails can feel restrictive and noisy to more experienced developers (or people with large-enough egos like me). I have no desire to ever touch J2EE ever again in my life, no matter how much I could get paid doing it, because it felt like getting anything done was about as much fun as filing my taxes. Rails is certainly not as terrible as J2EE, so I'm not trying to draw a direct equivalence, and maybe a balance can be struck...Personally, I find that the "give me a server and I'll set up some middleware on top" approach like Express (for Node), and the aforementioned Ring/HTTP-Kit for Clojure give me the best balance. Clearly there's a middle-ground -- I certainly wouldn't suggest that most people go and reimplement TCP and HTTP from scratch for a project, unless they're severely masochistic, or they just want to learn more about TCP or HTTP. [1] https://gitlab.com/tombert/frameworkeyPromiseEdition https://gitlab.com/tombert/frameworkeyPromiseEdition [2] https://gitlab.com/tombert/Frameworkey-Erlang https://gitlab.com/tombert/Frameworkey-Erlang
  - Kalium 8y ago
    I've personally watched experienced, mature, and very senior developers build sophisticated systems with Clojure, Ring, and http-kit. And blink at me owlishly when I ask them how they sanitize their inputs to guard against SQL injection. They'd been intensely focused on the core logic, architecture, system design, and business functions. Everything else received cursury consideration. My takeaway from that is that it's unreasonable to expect even the best of developers to remember every detail every time. Even the best forget or make mistakes. If our tools don't take this into account and protect us from ourselves, we're going to get burned.
    - 8y ago