5 ms·

I've spent the last 3 years developing in Clojure and found I was quite happy not having an all encompassing framework. It forced me to learn all these issues

by whyme 12y ago

I've spent the last 3 years developing in Clojure and found I was quite happy not having an all encompassing framework. It forced me to learn all these issues and understand them well enough to be able to customize each and align them with a products design. Sure it's more work, but in my mind, it's worth it.

phillmv 12y ago
> It forced me to learn all these issues and understand them well enough to be able to customize each and align them with a products design. This is a standard developer response - I recall when Sinatra was a fresh kid on the block, and the same arguments people used against Rails - but just because something is more fun doesn't mean you're going to get all these details right. The attack surface in modern web apps can be such a large search space that the majority of people will never get it right. The point behind frameworks is that you can engage in efficiencies in scale when it comes to sensible defaults; even the most well seasoned and security paranoid developer can drown in the cornucopia of details that all have to be done right.
- whyme 12y ago
  > This is a standard developer response vs. a what? I've worn many hats in my day, the least of which has been a developer hat. There's equal risk in relying on a code base incorporating features with underlying concepts that you or your team does not understand. I'm all for having a framework, where you can review the code and be comfortable with what you're relying on, but in the absence of having a good one, well then build one. The benefits Clojure brings to the table more than make up for the work in either case. There's just no excuse for not knowing the concepts and not knowing if your product needs them.
  - phillmv 12y ago
    >The benefits Clojure brings to the table more than make up for the work in either case. No one's saying "stop using clojure". The argument here is "build a clojure framework lots of people use". >There's equal risk in relying on a code base incorporating features with underlying concepts that you or your team does not understand. You do this all the time. I mean, I understand on a high level what my computer does but I can't describe to you the exact tree balancing algorithm my filesystem uses, how my CPU performs cache invalidation and branch prediction or even how exactly the JVM works. Computers are too complex to not rely on underlying concepts you or your team doesn't understand. The point is, within just the context of a web developer developing a web application there is too much stuff to know to always get it right. We need to reduce the number of things people have to think about, or else we'll always miss something.
    - whyme 12y ago
      > The argument here is "build a clojure framework lots of people use. The argument I am addressing is that people are deploying products with poor security because a great, all encompassing, framework does not exist. There's no excuse for doing that. This is not about having to understand cryptography, it's about knowing when and where you need to use it and making sure it's included when you do. The issues outlined in the video are trivial.
      - phillmv 12y ago
        The excuse is precisely that there isn't a great, all encompassing framework. Setting up a scenario where everyone has to get everything right all of the time is setting everyone up for a lot of heartbreak. Having bad password management and opening everyone up to CSRF and XSS is not "trivial". They're gotchas, and looking out for gotchas is a waste of everyone's time.
        whyme 12y ago
        When I make mistakes, which I often do, I don't go around thinking oh, darn, they should have known that for me. That goes for using a bad framework or lack thereof. As I said, I'm all for having a great framework, but I would not excuse the mistakes being made here, and I'm simply saying that I believe that my products and my knowledge level benefited by not having one. > Having bad password management and opening everyone up to CSRF and XSS is not "trivial". I'm not suggesting everyone should need to be aware of these issues, I'm saying someone on your team should be. And if you're a team of one, be prepared to make mistakes (which will not be limited to the issues outlined here).
        phillmv 12y ago
        >When I make mistakes, which I often do, I don't go around thinking oh, darn, they should have known that for me. Well, you should! These are mind numbing details that are best taken care of by other people. I am too concerned with building a good product to want to spend too much time going over mind numbing details. The argument from "I become a more well rounded developer" is valid, but these should be things you learn once and then stop worrying about forever. There's a lot of magic in Rails, but it all goes away given enough time. Better abstractions are our bread and butter and we'll get nothing done if we continue to shy away from them.
- mantrax3 12y ago
  > "This is a standard developer response - I recall when Sinatra was a fresh kid on the block, and the same arguments people used against Rails" And the more time passes, the more problems with Rails are being discovered that have to be altered in a non-BC way. A library makes no assumptions. It's just there and you decide how to use it. In the right hands it's more powerful than a rigid framework. A framework that tries to teach you how to do things is by definition a pair of training wheels. Not the best setup for competing in Tour De France. The solution to incompetent developers isn't a bigger, more rigid framework. It's education and training.
  - stcredzero 12y ago
    The solution to incompetent developers isn't a bigger, more rigid framework. It's education and training. In aerospace, it's understood that better training can be part of the solution, but often better instruments and interfaces and well designed automated tools can be lifesaving as well.
    - mantrax3 12y ago
      Of course, and in software development we call these instruments, interfaces and well designed automated tools libraries. A framework in aerospace would be more akin to a pre-built airplane with a bunch of holes where you put seats, in-flight entertainment consoles and other auxiliary non-critical equipment (because remember, airplanes are scary and you were told you can't do it yourself). Then you paint it and stick your logo on it. Which is all fine, if it does the job for you, but you're not designing the airplane, anymore than microwaving TV lunch is you cooking. And just like warming up TV lunch doesn't make your job title a "chef", I don't believe people relying on frameworks to do the hard thinking for them deserve the title "architect" or even "senior developer". Which, again, is all fine, unless you or your boss are kidding yourselves about it. And then one day the military, say, realize they now have a bunch of useless "military jets" built on top of a "passenger airplane framework". And NASA's space mission based on that framework isn't going too well, either. Whoops. Turns out frameworks aren't one-size-fits-all. In a nutshell, apps have to be architected by competent architects, using simple, modular, does-one-thing-well libraries. These people know how to achieve scalability and security taking the particular needs of the app at hand. The presenter in that video said that making assumptions is dangerous. There's no greater assumption than the fact a framework is right for your app, without understanding what this framework does under the hood. And there's no type of component making more assumptions for your app than a framework. Rails calls it "opinionated". I call it: you're the framework's slave, not the other way around. There's no way around it. I know when Rails came out the hype was so huge, that everyone believed they and their dog can write big complex web apps. Nope. The only result of the framework mentality is a bunch of people making beginner mistakes and getting hacked all over the web.

by whyme 12y ago

phillmv 12y ago

> It forced me to learn all these issues and understand them well enough to be able to customize each and align them with a products design. This is a standard developer response - I recall when Sinatra was a fresh kid on the block, and the same arguments people used against Rails - but just because something is more fun doesn't mean you're going to get all these details right. The attack surface in modern web apps can be such a large search space that the majority of people will never get it right. The point behind frameworks is that you can engage in efficiencies in scale when it comes to sensible defaults; even the most well seasoned and security paranoid developer can drown in the cornucopia of details that all have to be done right.

whyme 12y ago
> This is a standard developer response vs. a what? I've worn many hats in my day, the least of which has been a developer hat. There's equal risk in relying on a code base incorporating features with underlying concepts that you or your team does not understand. I'm all for having a framework, where you can review the code and be comfortable with what you're relying on, but in the absence of having a good one, well then build one. The benefits Clojure brings to the table more than make up for the work in either case. There's just no excuse for not knowing the concepts and not knowing if your product needs them.
- phillmv 12y ago
  >The benefits Clojure brings to the table more than make up for the work in either case. No one's saying "stop using clojure". The argument here is "build a clojure framework lots of people use". >There's equal risk in relying on a code base incorporating features with underlying concepts that you or your team does not understand. You do this all the time. I mean, I understand on a high level what my computer does but I can't describe to you the exact tree balancing algorithm my filesystem uses, how my CPU performs cache invalidation and branch prediction or even how exactly the JVM works. Computers are too complex to not rely on underlying concepts you or your team doesn't understand. The point is, within just the context of a web developer developing a web application there is too much stuff to know to always get it right. We need to reduce the number of things people have to think about, or else we'll always miss something.
  - whyme 12y ago
    > The argument here is "build a clojure framework lots of people use. The argument I am addressing is that people are deploying products with poor security because a great, all encompassing, framework does not exist. There's no excuse for doing that. This is not about having to understand cryptography, it's about knowing when and where you need to use it and making sure it's included when you do. The issues outlined in the video are trivial.
    - phillmv 12y ago
      The excuse is precisely that there isn't a great, all encompassing framework. Setting up a scenario where everyone has to get everything right all of the time is setting everyone up for a lot of heartbreak. Having bad password management and opening everyone up to CSRF and XSS is not "trivial". They're gotchas, and looking out for gotchas is a waste of everyone's time.
      - whyme 12y ago
        When I make mistakes, which I often do, I don't go around thinking oh, darn, they should have known that for me. That goes for using a bad framework or lack thereof. As I said, I'm all for having a great framework, but I would not excuse the mistakes being made here, and I'm simply saying that I believe that my products and my knowledge level benefited by not having one. > Having bad password management and opening everyone up to CSRF and XSS is not "trivial". I'm not suggesting everyone should need to be aware of these issues, I'm saying someone on your team should be. And if you're a team of one, be prepared to make mistakes (which will not be limited to the issues outlined here).
        phillmv 12y ago
        >When I make mistakes, which I often do, I don't go around thinking oh, darn, they should have known that for me. Well, you should! These are mind numbing details that are best taken care of by other people. I am too concerned with building a good product to want to spend too much time going over mind numbing details. The argument from "I become a more well rounded developer" is valid, but these should be things you learn once and then stop worrying about forever. There's a lot of magic in Rails, but it all goes away given enough time. Better abstractions are our bread and butter and we'll get nothing done if we continue to shy away from them.
mantrax3 12y ago
> "This is a standard developer response - I recall when Sinatra was a fresh kid on the block, and the same arguments people used against Rails" And the more time passes, the more problems with Rails are being discovered that have to be altered in a non-BC way. A library makes no assumptions. It's just there and you decide how to use it. In the right hands it's more powerful than a rigid framework. A framework that tries to teach you how to do things is by definition a pair of training wheels. Not the best setup for competing in Tour De France. The solution to incompetent developers isn't a bigger, more rigid framework. It's education and training.
- stcredzero 12y ago
  The solution to incompetent developers isn't a bigger, more rigid framework. It's education and training. In aerospace, it's understood that better training can be part of the solution, but often better instruments and interfaces and well designed automated tools can be lifesaving as well.
  - mantrax3 12y ago
    Of course, and in software development we call these instruments, interfaces and well designed automated tools libraries. A framework in aerospace would be more akin to a pre-built airplane with a bunch of holes where you put seats, in-flight entertainment consoles and other auxiliary non-critical equipment (because remember, airplanes are scary and you were told you can't do it yourself). Then you paint it and stick your logo on it. Which is all fine, if it does the job for you, but you're not designing the airplane, anymore than microwaving TV lunch is you cooking. And just like warming up TV lunch doesn't make your job title a "chef", I don't believe people relying on frameworks to do the hard thinking for them deserve the title "architect" or even "senior developer". Which, again, is all fine, unless you or your boss are kidding yourselves about it. And then one day the military, say, realize they now have a bunch of useless "military jets" built on top of a "passenger airplane framework". And NASA's space mission based on that framework isn't going too well, either. Whoops. Turns out frameworks aren't one-size-fits-all. In a nutshell, apps have to be architected by competent architects, using simple, modular, does-one-thing-well libraries. These people know how to achieve scalability and security taking the particular needs of the app at hand. The presenter in that video said that making assumptions is dangerous. There's no greater assumption than the fact a framework is right for your app, without understanding what this framework does under the hood. And there's no type of component making more assumptions for your app than a framework. Rails calls it "opinionated". I call it: you're the framework's slave, not the other way around. There's no way around it. I know when Rails came out the hype was so huge, that everyone believed they and their dog can write big complex web apps. Nope. The only result of the framework mentality is a bunch of people making beginner mistakes and getting hacked all over the web.