Why I hate frameworks (2005)(discuss.joelonsoftware.com)
discuss.joelonsoftware.com
Why I hate frameworks (2005)
http://discuss.joelonsoftware.com/default.asp?joel.3.219431
71 comments
http://web.archive.org/web/20180927070411/http://discuss.joe...
This stood the test of time.
After ten years we still struggle with the same issue.
Of course now we have containers to store these factory factory factories. Which makes it easier to store and handle and now you can deploy the factory factory factory containers next to the resources held in containers as well so you don't have to pay for the shipping cost of the said resources. Of course the finished hammer, wood and everything else still has to be shipped to you.
And if that wasn't enough, we created a self-contained mini factory for your home, which takes the packaged hammer, nail and wood components and assembles them real time. Just for your convenience.
Of course this mini factory has to be assembled as well by your factory factory factory containers before it will be shipped to you.
See how easy it is?
Of course now we have containers to store these factory factory factories. Which makes it easier to store and handle and now you can deploy the factory factory factory containers next to the resources held in containers as well so you don't have to pay for the shipping cost of the said resources. Of course the finished hammer, wood and everything else still has to be shipped to you.
And if that wasn't enough, we created a self-contained mini factory for your home, which takes the packaged hammer, nail and wood components and assembles them real time. Just for your convenience.
Of course this mini factory has to be assembled as well by your factory factory factory containers before it will be shipped to you.
See how easy it is?
Is this only a problem with Java frameworks? (The hammer-factory-building-factory talk leads me to believe that).
I stared learning Django a few years ago and have never looked back, it has increased my productivity loads. Admittedly its reasonably opinionated about the style of app you are building (but it covers the majority of apps and you don't need to use every part of the framework).
I stared learning Django a few years ago and have never looked back, it has increased my productivity loads. Admittedly its reasonably opinionated about the style of app you are building (but it covers the majority of apps and you don't need to use every part of the framework).
No, not just Java (really J2EE). The actual problem can manifest itself anywhere where dogmatic design principles are allowed to trump pragmatism.
I don't know if it's only Java, but I agree whole-heartedly about the general health of the Python framework community. I love Django, but it's also pretty easy to excise parts you don't need for a particular project, while being opinionated enough to get things done quickly and allow folks on the internet to help debug things.
Then of course there's Flask for lightweight API projects, which can get trotted out if Django is being TOO opinionated :)
Don't get me wrong, there are plenty of criticisms to level at frameworks-as-a-solution mindsets, but in the context of the OP, I think Joel's rant doesn't really apply to Python web development at the moment.
Then of course there's Flask for lightweight API projects, which can get trotted out if Django is being TOO opinionated :)
Don't get me wrong, there are plenty of criticisms to level at frameworks-as-a-solution mindsets, but in the context of the OP, I think Joel's rant doesn't really apply to Python web development at the moment.
> Is this only a problem with Java frameworks?
No, but Java is notable for this problem. I think the root issue is that it is of course possible to write flexible software in Java, but in order to do so you must write all the dynamic bits in this static language, which ends up meaning that everything you write has to conform to an external statically–implemented-dynamism framework, and if you're going to have a framework then you might as well add to it, and … you end up with a standard Java app.
I haven't programmed in some of the cooler/reputed-to-be-better static languages like Haskell or the ML family (not beyond a few simple exercises, anyway), so I can't say to what extent they would suffer from this same problem if they enjoyed the same popularity.
I think that from the perspective of two decades on, Java turned out to have been a failure, not with respect to popularity but to quality. It turns out that it enabled mediocre software architects to spend great quantities of corporate money coming up with mediocre designs to be implemented by mediocre programmers, resulting in mediocre software and mediocre return on investment. That doesn't mean that it's impossible to write high-quality Java, just that that's not the norm: the entire Java ecosystem militates against quality, because quality is risk, and Java is not about risk: Java and Java-using organisations prefer predictable mediocrity to excellence. That's not even necessarily bad — sometimes predictable mediocrity is preferable to risk — but it's certainly not inspiring.
I too used to really like Django; I spent about six years using it for one project and another. Were I going to do Python web development again, I'd probably use Flask or Bottle, but Django definitely taught me a lot.
But I'd prefer not to do Python web development in the future.
No, but Java is notable for this problem. I think the root issue is that it is of course possible to write flexible software in Java, but in order to do so you must write all the dynamic bits in this static language, which ends up meaning that everything you write has to conform to an external statically–implemented-dynamism framework, and if you're going to have a framework then you might as well add to it, and … you end up with a standard Java app.
I haven't programmed in some of the cooler/reputed-to-be-better static languages like Haskell or the ML family (not beyond a few simple exercises, anyway), so I can't say to what extent they would suffer from this same problem if they enjoyed the same popularity.
I think that from the perspective of two decades on, Java turned out to have been a failure, not with respect to popularity but to quality. It turns out that it enabled mediocre software architects to spend great quantities of corporate money coming up with mediocre designs to be implemented by mediocre programmers, resulting in mediocre software and mediocre return on investment. That doesn't mean that it's impossible to write high-quality Java, just that that's not the norm: the entire Java ecosystem militates against quality, because quality is risk, and Java is not about risk: Java and Java-using organisations prefer predictable mediocrity to excellence. That's not even necessarily bad — sometimes predictable mediocrity is preferable to risk — but it's certainly not inspiring.
I too used to really like Django; I spent about six years using it for one project and another. Were I going to do Python web development again, I'd probably use Flask or Bottle, but Django definitely taught me a lot.
But I'd prefer not to do Python web development in the future.
I think part problem is also that many programmers tend to gravitate towards abstraction and reusable code before there is a clear need for it.
Just today I read about this project https://github.com/primus/primus and it's a point in case. A "universal wrapper for real-time frameworks" with the main benefit being "Effortless switching between real-time frameworks by changing one single line of code."
Because clearly, I often need to switch between WebSockets and BrowserChannel... or wait, do I?
Just today I read about this project https://github.com/primus/primus and it's a point in case. A "universal wrapper for real-time frameworks" with the main benefit being "Effortless switching between real-time frameworks by changing one single line of code."
Because clearly, I often need to switch between WebSockets and BrowserChannel... or wait, do I?
The documentation is more lines than the actual code is. Essentially it provides a uniform interface to multiple socket libraries. Why you would need this... I have no idea
" It turns out that it enabled mediocre software architects to spend great quantities of corporate money coming up with mediocre designs to be implemented by mediocre programmers, resulting in mediocre software and mediocre return on investment."
But most people are mediocre. That's just how the world works.
But most people are mediocre. That's just how the world works.
> But most people are mediocre. That's just how the world works.
Sure, but I choose to pursue excellence.
And, in the marketplace, excellence wins. Maybe not technical excellence (sadly, it's often marketing excellence which wins), but mediocrity loses in the end.
Sure, but I choose to pursue excellence.
And, in the marketplace, excellence wins. Maybe not technical excellence (sadly, it's often marketing excellence which wins), but mediocrity loses in the end.
Not really. I try to produce good clean code (its a lot better than the last two projects I have inherited). No one seems bothered by that, they just want new features done as soon as possible.
We build complicated software with simple tools where I work using Clojure. There's even a talk about Java:Powertools::Clojure:Handtools! [1]
[1] - https://www.youtube.com/watch?v=ShEez0JkOFw
[1] - https://www.youtube.com/watch?v=ShEez0JkOFw
Interesting that this post seems to be dated right around when Rails was just getting popular and starting the "next-generation" web frameworks trend.
This article really clarified it for me when I first read it (along with another I can't find, about libraries & frameworks; all the ones I've googled are too recent to be right), and helped me realise that what I want to do is write code that calls, not code that is called. I want to own main().
As an aside, I really miss Joel on Software and the similar high-quality blogs which existed in the mid-2000s. It seems like Twitter, Facebook and Medium have sucked all the air, the life, the joy and the quality out of online presence and discussion. I know that there are still a few holdouts trying to keep things going, but … it seems to be a losing battle.
As an aside, I really miss Joel on Software and the similar high-quality blogs which existed in the mid-2000s. It seems like Twitter, Facebook and Medium have sucked all the air, the life, the joy and the quality out of online presence and discussion. I know that there are still a few holdouts trying to keep things going, but … it seems to be a losing battle.
Yes, and the BoS forums had something great going as well.
The ones from this list at some point were great: http://blog.fogus.me/2011/03/27/the-long-lost-art-of-thought...
The ones from this list at some point were great: http://blog.fogus.me/2011/03/27/the-long-lost-art-of-thought...
I too miss BoS forums, never really found another community like it, HN and /r/programming are ok but they don't quite cover the "programmer AND in business" demographic that BoS captured so well.
I'm right there with you, missing this blog. I sometimes see it on my bookmarks bar and click it just to see if something has been added, but nothing ever is. I didn't find his blog until towards the end of its life, but it taught me so much, and was a joy to read.
I hope nobody minds if I run with your "aside" a bit.
I miss the JOS blog a lot as well. It influenced me a lot over a decade ago. It presented a very optimistic view of the field and career path of a programmer, with good writing, interesting tech viewpoints, and humor. There was also less tech blogging back then.
I really liked Joel's vision of what a software developer should be, especially what the working conditions should be. I feel he embraced the concept of being both a professional and, frankly, an adult.
http://www.joelonsoftware.com/articles/FieldGuidetoDeveloper...
My lament is that I really do think tech instead doubled down on what I feel is kind of a childish, "young people are just smarter" attitude, with giant open offices, back visibility, low autonomy,
The vision JOS presented is one that I can embrace. I'd encourage young people to go into software development if I thought they had a future similar to the one presented in this blog. That version of a tech career is still there, to an extent, but unfortunately, tech seems to have moved more strongly away from it over the last 15 years. I can't encourage young people to go into a field with giant open offices, back visibility, limited autonomy, office retreats to dave n busters. I suppose there's a subset who like this, but my impression is that a huge number of developers, a group that most certainly includes developers recently out of college in their 20s, find this cultural world to be a disappointment.
I miss the JOS blog a lot as well. It influenced me a lot over a decade ago. It presented a very optimistic view of the field and career path of a programmer, with good writing, interesting tech viewpoints, and humor. There was also less tech blogging back then.
I really liked Joel's vision of what a software developer should be, especially what the working conditions should be. I feel he embraced the concept of being both a professional and, frankly, an adult.
http://www.joelonsoftware.com/articles/FieldGuidetoDeveloper...
My lament is that I really do think tech instead doubled down on what I feel is kind of a childish, "young people are just smarter" attitude, with giant open offices, back visibility, low autonomy,
The vision JOS presented is one that I can embrace. I'd encourage young people to go into software development if I thought they had a future similar to the one presented in this blog. That version of a tech career is still there, to an extent, but unfortunately, tech seems to have moved more strongly away from it over the last 15 years. I can't encourage young people to go into a field with giant open offices, back visibility, limited autonomy, office retreats to dave n busters. I suppose there's a subset who like this, but my impression is that a huge number of developers, a group that most certainly includes developers recently out of college in their 20s, find this cultural world to be a disappointment.
I definitely see where you're coming from when saying the tech /startup industry has moved away from being "adult". I get not wanting to be an Office Space cubicle farm, but there's a good balance between that and what we have now.
I read Joel's blog back in university, this must have been around 2010. I was very inspired and I remember binge-reading his archives during several late night coursework sessions in the CS lab.
This seems to have been around the time the hipster-tech culture started taking off in a big way. I graduated right in the middle of it, and looking back, I realise I'd taken for granted that the professional tech world would follow Joel's more adult way of thinking. Instead we have a cult of youth. No planning (under a misguided interpretation of "lean"), minimum processes (under a misguided interpretation of "agile"), no knowledge of design patterns (TDD supposedly makes this obsolete), weird fake hipster quirkiness (but omg don't make any jokes about killing ex-girlfriends, or Anil Dash will put you on an industry blacklist).
This seems to have been around the time the hipster-tech culture started taking off in a big way. I graduated right in the middle of it, and looking back, I realise I'd taken for granted that the professional tech world would follow Joel's more adult way of thinking. Instead we have a cult of youth. No planning (under a misguided interpretation of "lean"), minimum processes (under a misguided interpretation of "agile"), no knowledge of design patterns (TDD supposedly makes this obsolete), weird fake hipster quirkiness (but omg don't make any jokes about killing ex-girlfriends, or Anil Dash will put you on an industry blacklist).
> I want to own main().
You can say the same in an article on "Why I hate compilers", or OSes, or web servers.
This article is more about a way to design software than about frameworks in general. It just happened that Java web frameworks were all designed that way by the time.
You can say the same in an article on "Why I hate compilers", or OSes, or web servers.
This article is more about a way to design software than about frameworks in general. It just happened that Java web frameworks were all designed that way by the time.
I don't think that you deserve to be downvoted; you make an interesting point. Obviously an OS is a sort of framework; so too is a web server which calls one's code (I'll be honest, I don't quite get your point about compilers — can you elaborate?).
But good examples of both OSes & webservers offer pretty simple interfaces (I'm thinking of Plan 9 as an example of a good OS, and Go's http.Handler as an example of a decent HTTP interface). In both cases there's one entry point (a single designated function), with a reasonably well-defined API to query the environment in which it's called.
But good examples of both OSes & webservers offer pretty simple interfaces (I'm thinking of Plan 9 as an example of a good OS, and Go's http.Handler as an example of a decent HTTP interface). In both cases there's one entry point (a single designated function), with a reasonably well-defined API to query the environment in which it's called.
A compiler will also rewrite the entry point of your program, and probably just call your main() from another place.
Yes, it's all about reasonable, documented and well defined APIs. If your framework has those, it won't get in your way.
If you framework lacks those, it will get in your way with an intensity that libraries just can't match. But frameworks do not pose a completely new level of problems, your compiler, server or OS will create just as much trouble.
Yes, it's all about reasonable, documented and well defined APIs. If your framework has those, it won't get in your way.
If you framework lacks those, it will get in your way with an intensity that libraries just can't match. But frameworks do not pose a completely new level of problems, your compiler, server or OS will create just as much trouble.
> and helped me realise that what I want to do is write code that calls, not code that is called. I want to own main().
It took me a while to clarify this in my head, but I feel exactly what you wrote here - I want to own main(). A framework is something that calls your code. A library is something you call. I avoid frameworks whenever possible.
It took me a while to clarify this in my head, but I feel exactly what you wrote here - I want to own main(). A framework is something that calls your code. A library is something you call. I avoid frameworks whenever possible.
I like this definition of libraries vs frameworks by who owns main() too.
I've always said that libraries add functionality to the language, whereas frameworks are half-assed DSLs.
I've always said that libraries add functionality to the language, whereas frameworks are half-assed DSLs.
Ah, yes that clarifies a problem I've had trouble with too. I work with a complicated framework, and I often end up having to explain why a seemingly simple change to x is actually complicated, even if I'm looking at the code for doing x right now and could trivially make the change.
x is at the bottom of a framework, the top of which I didn't code or fully understand, so I'm not sure exactly who's calling this code under what conditions - I have to read and analyse an edifice of code to make sure the change is safe. Or just do the change and hope the integrated tests catch any breakage.
x is at the bottom of a framework, the top of which I didn't code or fully understand, so I'm not sure exactly who's calling this code under what conditions - I have to read and analyse an edifice of code to make sure the change is safe. Or just do the change and hope the integrated tests catch any breakage.
I also very much agree with this. I think it might be a sign of something deeper, though. When I design a library, I keep in mind that it might be used in a variety of contexts applied in a multitude of styles. In contrast, when I author a framework I expect the users to adhere to the principles of the framework. Whoever owns main() gets to dictate the terms.
For a beginner or intermediate developer, this might be a relief. Once you reach the level where you have a good intuition for how to do things well, your primary focus will be the minimizing of complexity, and I can never shake the feeling that frameworks stand in contradiction to this goal. After all, they were designed for maximum generality, but are the abstractions envisioned really the ones you require?
That's not to say that everyone should embark on a journey to build their own 50kloc framework. You might want to consider skipping the framework if 500 lines of compact, well-designed and thoroughly documented code can do the same job, though. And you can still use libraries for the truly complex parts.
For a beginner or intermediate developer, this might be a relief. Once you reach the level where you have a good intuition for how to do things well, your primary focus will be the minimizing of complexity, and I can never shake the feeling that frameworks stand in contradiction to this goal. After all, they were designed for maximum generality, but are the abstractions envisioned really the ones you require?
That's not to say that everyone should embark on a journey to build their own 50kloc framework. You might want to consider skipping the framework if 500 lines of compact, well-designed and thoroughly documented code can do the same job, though. And you can still use libraries for the truly complex parts.
What about frameworks that let you keep main, but require to take over your build system? I admit I'm guilty of one of those as well [1], but only because I don't see a more simple solution in terms of usage.
[1] https://github.com/muellermichel/Hybrid-Fortran
[1] https://github.com/muellermichel/Hybrid-Fortran
To me this looks closer to library than framework, by the virtue of augmenting your code instead of hijacking the control flow completely.
The worst part about Medium is that it helps make terrible "Why You Should Use X Tech and Tech Y is Dead" posts by inexperienced people actually be read and posted on HN. In the mid 2000s no one paid attention to those.
This is really a critique of J2EE. This was the dominant approach when Rails came out and helped make Rails so successful.
Making specific critiques of specific eco-systems is valid. E.g. Java back then was awful. JS right now is complex (though I think there is some great stuff in there). Making sweeping critiques of all frameworks is pretty stupid. Unless, of course, you build everything on an OS you wrote yourself in assembler. Frameworks are just a form of abstraction. Abstraction can be done well or poorly, but to make a blanket claim that abstraction is bad is to ignore the huge efficiency gains we've make from abstractions like operating systems, web browsers, HTTP servers, and so on, which are all frameworks of a kind.
Making specific critiques of specific eco-systems is valid. E.g. Java back then was awful. JS right now is complex (though I think there is some great stuff in there). Making sweeping critiques of all frameworks is pretty stupid. Unless, of course, you build everything on an OS you wrote yourself in assembler. Frameworks are just a form of abstraction. Abstraction can be done well or poorly, but to make a blanket claim that abstraction is bad is to ignore the huge efficiency gains we've make from abstractions like operating systems, web browsers, HTTP servers, and so on, which are all frameworks of a kind.
Interesting you should mention this. I've really enjoyed and really hated programming over the course of the last 15+ years. A low point for me was Java, Spring, Struts, Struts 2, Wicket, Tiles, Hibernate, JPA, iBatis, Ant, Maven...
Interestingly, Rails (along with a few other really good technologies, such as django) came along and, with a loud crashing sound, swept everything off the table. It's been a lesson for me. First, have the conviction to keep doing things the "old" way if the new way seems to be a churning mess. Second, realize that things may not settle down, they may be completely swept aside instead.
This is how I feel about javascript for the moment. I actually don't think the churn will resolve. It's more of a feeling, so I can't blame anyone for dismissing the rest of what I have to say... but I just sense that, like the J2EE world, that something is going to sweep this all aside.
To go even further out on a limb, I believe that (buzzword alert) languages transpiled to isomorphic javascript will play a huge role in this.
I truly don't believe that because Javascript runs so well in the browser, and if you have to use javascript you may as well write the backend in javascript, means that languages like ruby and python are destined for legacy or niche status. It is immensely reasonable to prefer to code web apps in ruby or python. I think that the dominance of JS will be a temporary situation, and that various technologies that allow people to code for the web in a consistent, relatively simple, straightforward way, in languages that are not JS, is likely to emerge over the next 5 years.
I'm only keeping a toe dipped in the JS waters right now, because I really do need it for some things. But I've decided to drop out of the JS churn (I do recognize that for the next few years, there will be amazing opportunities for people who are willing and able to keep up with it). Just like I wish I'd had the conviction to stay out of the nuttiness of J2EE a decade ago, I'm trying hard to position myself so that I don't have to get swept up into the JS vortex.
Interestingly, Rails (along with a few other really good technologies, such as django) came along and, with a loud crashing sound, swept everything off the table. It's been a lesson for me. First, have the conviction to keep doing things the "old" way if the new way seems to be a churning mess. Second, realize that things may not settle down, they may be completely swept aside instead.
This is how I feel about javascript for the moment. I actually don't think the churn will resolve. It's more of a feeling, so I can't blame anyone for dismissing the rest of what I have to say... but I just sense that, like the J2EE world, that something is going to sweep this all aside.
To go even further out on a limb, I believe that (buzzword alert) languages transpiled to isomorphic javascript will play a huge role in this.
I truly don't believe that because Javascript runs so well in the browser, and if you have to use javascript you may as well write the backend in javascript, means that languages like ruby and python are destined for legacy or niche status. It is immensely reasonable to prefer to code web apps in ruby or python. I think that the dominance of JS will be a temporary situation, and that various technologies that allow people to code for the web in a consistent, relatively simple, straightforward way, in languages that are not JS, is likely to emerge over the next 5 years.
I'm only keeping a toe dipped in the JS waters right now, because I really do need it for some things. But I've decided to drop out of the JS churn (I do recognize that for the next few years, there will be amazing opportunities for people who are willing and able to keep up with it). Just like I wish I'd had the conviction to stay out of the nuttiness of J2EE a decade ago, I'm trying hard to position myself so that I don't have to get swept up into the JS vortex.
> This is how I feel about javascript for the moment. I actually don't think the churn will resolve.
I still hope we'll see large adoption of WebAssembly (or WebAsm, or something like that) and get actually good frameworks for creating pages, that actually integrates the frontend with backend (instead of just using the same language), interpreting our templates into something dynamic.
I hope in a few years we can start retiring JS like we are doing wit PHP now.
I still hope we'll see large adoption of WebAssembly (or WebAsm, or something like that) and get actually good frameworks for creating pages, that actually integrates the frontend with backend (instead of just using the same language), interpreting our templates into something dynamic.
I hope in a few years we can start retiring JS like we are doing wit PHP now.
WebAssembly does seem to have a promising future, with the caveat that it needs to get traction beyond the web to really take off (which is the goal - https://github.com/WebAssembly/design/issues/249#issuecommen...).
It's an interesting goal, but I'll disagree on that "needs" part. It can be widely successful just by being some VM you cross-compile to when you want your code to run on a browser.
This is the hope I have too. Nicely put.
I have been coding in JS since JS landed in a browser and right now it's just too much, with a new build system every six months, to new libraries and frameworks. This continous evolution is necessary because JS wasn't designed to do the things people are using it for 21 years later.
So I've been looking at Elm. A lot of people really don't like the syntax. But if you get past that, there's a lot of things there. There's a great architecture, a sane package manager, static typing, and all the other things people bolt on. And it sounds like while it currently builds JS, it's going to move towards WebAssembly when that's more widespread.
Even if Elm doesn't become "the next big thing", maybe it'll spawn something that is.
I hope Elm, or something like it, does sweep the table clean.
I have been coding in JS since JS landed in a browser and right now it's just too much, with a new build system every six months, to new libraries and frameworks. This continous evolution is necessary because JS wasn't designed to do the things people are using it for 21 years later.
So I've been looking at Elm. A lot of people really don't like the syntax. But if you get past that, there's a lot of things there. There's a great architecture, a sane package manager, static typing, and all the other things people bolt on. And it sounds like while it currently builds JS, it's going to move towards WebAssembly when that's more widespread.
Even if Elm doesn't become "the next big thing", maybe it'll spawn something that is.
I hope Elm, or something like it, does sweep the table clean.
I'm mostly agreed with you. I believe that functional programming is the next paradigm shift in programming, and that shift is happening now. I'm not sure if something like Purescript or Elm will be the future of JS, or some bastard combination of Typescript and future enhancements to JS. History suggests the latter, unfortunately.
You can get quite far with TypeScript. RxJS, Cycle, and xstream (all functional libraries) are built on it and its source code doesn't use classes at all. It's no PureScript but there's no need to conflate it with OOP.
Frameworks are not the only form of abstraction. You should also not confuse frameworks with libs. They are kind of opposites. With a fw you comform to a rule imposed on you and have less work to do while using a lib you are free to do whatever you want but you have to write the "glue". There are tradeoffs on both sides but I like the freedom more.
Is anyone else bothered by the repeated, completely out of context reference to murdering women with a hammer?
The author was being cheeky, but it definitely dates the piece. People are a lot more sensitive about that sort of thing today than they were 10 years ago. Back then it just came off as dark and sort of funny.
I think the last ten years, unfortunately, accentuated the need for reasonable men to actively distinguish themselves from the openly, violently misogynistic people online.
So comments and jokes that were never before conceived of as having any serious import, even subliminally, now map so closely onto serious threats and harassment, that they seem completely inappropriate.
People in relationships killing each other has always been a subject of humour, exactly because it really happened. In a way that hasn't really changed. What's changed is what is OK in specific mediums: especially in online written form (twitter, comments, blogs) where the context is full of the real hateful deal.
So comments and jokes that were never before conceived of as having any serious import, even subliminally, now map so closely onto serious threats and harassment, that they seem completely inappropriate.
People in relationships killing each other has always been a subject of humour, exactly because it really happened. In a way that hasn't really changed. What's changed is what is OK in specific mediums: especially in online written form (twitter, comments, blogs) where the context is full of the real hateful deal.
That's an incredibly enlightened way to reconcile that, while it sounds wrong today, it doesn't nesscesitate that Joel is a misogynist.
I've never really understood it as an increasing impetous to distinguish ourselves from the morons that, once the light has been increasingly shown on misogyny, hold firm to it.
Thanks for that, it's really help me better grok how to feel about these increasingly more common situations.
I've never really understood it as an increasing impetous to distinguish ourselves from the morons that, once the light has been increasingly shown on misogyny, hold firm to it.
Thanks for that, it's really help me better grok how to feel about these increasingly more common situations.
The post isn't even by Joel. It's a forum (or more precisely an ex-forum). Random people were allowed to post there...
Wait... you do know we're not all Paul Graham... right?
Wait... you do know we're not all Paul Graham... right?
Nice try, PG.... You still haven't replied to my emails btw
Is there any evidence that "hateful" (by whatever metric) comments have actually increased, as opposed to people just becoming more sensitive? Subjectively it seems like a lot more of the latter.
Yup.
I just assumed the author had split up with his girlfriend, she turned out to be insane (poisoned his cat, set fire to his car, accused him of all manner of unspeakable things, etc.), and he was still a bit sore about it.
[deleted]
Joel Spolsky is openly gay so I think it's just a dated joke
Sure, but the post is by some random guy on his forum.
I thought it was a reference to the Beatles song Maxwell's Silver Hammer[1] from the Abbey Road Album.
[1] https://en.wikipedia.org/wiki/Maxwell%27s_Silver_Hammer
[1] https://en.wikipedia.org/wiki/Maxwell%27s_Silver_Hammer
In the past 10 years the definition to humor changed a lot. What is considered to be acceptable AND funny today is a very small subset with an increasingly self-censored filtering.
With different words, you have no sense of humor.
In the context of his post, it seemed like a pretty obvious joke to me. Maybe not that funny, but killing your girlfriend is so far out of the bounds of remotely reasonable that I didn't register it in the broader conversation about gender in society.
Maybe in order to update the joke to today's sensibilities you might say "killing your ex" instead, but it's still so clearly out of the bounds of reasonable that it's clearly just a joke about how you don't really see ball peen hammers used for anything else in movies/TV.
Maybe in order to update the joke to today's sensibilities you might say "killing your ex" instead, but it's still so clearly out of the bounds of reasonable that it's clearly just a joke about how you don't really see ball peen hammers used for anything else in movies/TV.
Too bad building software isn't at all like building a spice rack unless you're taking about continually rebuilding a spice rack and replacing its components constantly till it turns into a house (as 99% of software is wont to do).
Maybe it should be more like building a spice rack instead of a house. The whole UNIX philosophy of simple programs that do one thing well was successful for a reason.
Or it would have been if the programs really were simple, and not a wild mix of itty bitty trivial doodads and monsters with a huge collection of switches for special cases and extra features, many of which were added and used by exactly one person, collected into non-standardised toolkits which differ significantly across every single variant, and often between versions of the same variant.
And if they really did one thing well. Which - not infrequently - they don't. (See also: critical bugs in ssh, etc.)
And if they didn't have unintuitive names that are impossible to guess.
UNIX isn't just not a spice rack, it's an entire industrial area of tool sheds, grouped with absolutely no foresight or consistency, and impossible to get around without expert assistance.
It kind of works if nine square miles of warehouses connected by bicycle paths with free paper maps of small disconnected areas is your idea of a fun thing. But it's a bit of a stretch to call it an unqualified success.
And if they really did one thing well. Which - not infrequently - they don't. (See also: critical bugs in ssh, etc.)
And if they didn't have unintuitive names that are impossible to guess.
UNIX isn't just not a spice rack, it's an entire industrial area of tool sheds, grouped with absolutely no foresight or consistency, and impossible to get around without expert assistance.
It kind of works if nine square miles of warehouses connected by bicycle paths with free paper maps of small disconnected areas is your idea of a fun thing. But it's a bit of a stretch to call it an unqualified success.
[deleted]
Pretty funny but I think that the article is overcomplicating it. In reality, each framework is more like a toolbox; and each toolbox is suited for a specific range of jobs.
Building an app without a framework can sometimes feel like buying a nailgun and nails separately - It may be difficult to find the right kinds of nails which are compatible with that specific nailgun (if they exist at all)!
If you use a framework, you'll get the nailgun with compatible nails and a bunch of other related tools... You might not use all the tools from the toolbox, but at least all the tools work well with each other.
Of course, if you have to perform a double heart bypass surgery on someone and you come equipped with a carpenter's toolbox; the outcome will be disappointing... Regardless of how good a surgeon you are.
Building an app without a framework can sometimes feel like buying a nailgun and nails separately - It may be difficult to find the right kinds of nails which are compatible with that specific nailgun (if they exist at all)!
If you use a framework, you'll get the nailgun with compatible nails and a bunch of other related tools... You might not use all the tools from the toolbox, but at least all the tools work well with each other.
Of course, if you have to perform a double heart bypass surgery on someone and you come equipped with a carpenter's toolbox; the outcome will be disappointing... Regardless of how good a surgeon you are.
I think the article overcomplicating things a bit was a meta joke on the topic itself.
The whole killing girlfriend thing is not so cool. I would remove those pieces, they don't add much to the story.
Those parts detract from an otherwise clever story. Among the many reasons women might be uncomfortable in software -- dudes who joke about killing them.
Even the unspoken assumption that the reader is male (okay, or lesbian) and will furthermore chucklingly identify with having a bitch ex to kill with a hammer is gross.
[deleted]
I have no doubt that is true. Utterly unnecessary and somewhat jarring!
I can remember being made to feel uncomfortable and quite unwelcome upon witnessing a renowned female* developer and entrepreneur joke about killing a group of men who had offered advice on suitable materials for makeshift bottle openers.
* Or "chick" shudder, if we're accepting that "dude" is holding the appropriate tone for this conversation.
I can remember being made to feel uncomfortable and quite unwelcome upon witnessing a renowned female* developer and entrepreneur joke about killing a group of men who had offered advice on suitable materials for makeshift bottle openers.
* Or "chick" shudder, if we're accepting that "dude" is holding the appropriate tone for this conversation.
[deleted]
After 11 years, I can say Why I hate frameworks and Why I love Go (www.golang.org) \o/
sofaking right on, especially these days.
This article has been a pivotal point in my life. It was years ago when I read this that I started looking out "how to develop a webapp without a framework", my journey took me to Django, RoR, node and finally to Go.
I did learn on my own by reading a few books and countless videos about how to write a webapp without a framework. The result was that I wrote an introductory book for my own reference, the link is here.
https://github.com/thewhitetulip/web-dev-golang-anti-textboo...
I do not know the author, but I would like to thank him/her, it is because of their article that I went on to learn Go.
Thank You!!
I did learn on my own by reading a few books and countless videos about how to write a webapp without a framework. The result was that I wrote an introductory book for my own reference, the link is here.
https://github.com/thewhitetulip/web-dev-golang-anti-textboo...
I do not know the author, but I would like to thank him/her, it is because of their article that I went on to learn Go.
Thank You!!
I first learned to code by following those lovely, magical Ruby on Rails videos back in the day.
A few years later I discovered Sinatra and felt liberated.
A few years later I discovered Sinatra and felt liberated.