On the other hand its mind blowing how many new programs we have and the capabilities we see in modern software. What would have taken a year to build in C now takes a few months in modern...
On the other hand its mind blowing how many new programs we have and the capabilities we see in modern software. What would have taken a year to build in C now takes a few months in modern languages even if the result does require more resources.
So many commercial programs (and a good selection of FOSS programs, of course) are built to be 'pretty', and it feels like nobody ever takes the time to ask if it's worth the performance penalty.
So many commercial programs (and a good selection of FOSS programs, of course) are built to be 'pretty', and it feels like nobody ever takes the time to ask if it's worth the performance penalty.
You can build nice programs that run well, you just have to put in the work. It takes a lot more work to build a C++ GUI that will load in an instant than to distribute an Electron app, and CSS...
You can build nice programs that run well, you just have to put in the work. It takes a lot more work to build a C++ GUI that will load in an instant than to distribute an Electron app, and CSS animations take longer to make (and are more limited) than if you use a JS animation library.
I agree anything is better than electron, but never use JS animations if you make a desktop app (or web app for that matter). If you can accomplish what you're doing can be done in a CSS...
I agree anything is better than electron, but never use JS animations if you make a desktop app (or web app for that matter). If you can accomplish what you're doing can be done in a CSS transition, it will always be faster than a JS one. And if you can't use CSS transitions, you should probably be thinking about if you really need this transition as all.
I was just thinking about this yesterday. I saw someone at work using evernote and noticed how modern and flat it is compared to Zim wiki but I can't help but thinking how much I like the old ui...
I was just thinking about this yesterday. I saw someone at work using evernote and noticed how modern and flat it is compared to Zim wiki but I can't help but thinking how much I like the old ui look of zim. The 2000s grey UI represents software purity in my mind. Its fast, its efficient, it keeps my data stored locally and it isn't constantly trying to get me to pay for a subscription.
I gave Evernote a try, but it was lacking critical features and while the UI might have been "pretty" it was very, very bright. Zim inherited my system's dark theme and I didn't even have to edit...
I gave Evernote a try, but it was lacking critical features and while the UI might have been "pretty" it was very, very bright. Zim inherited my system's dark theme and I didn't even have to edit anything.
Great rebuttals to this in the Lobsters thread: https://lobste.rs/s/s5lxfu/why_i_use_old_hardware Using old hardware regularly, sure, the reasoning makes some sense. But developing software...
Using old hardware regularly, sure, the reasoning makes some sense. But developing software primarily on old hardware? Assuming one's financial situation(, environmental waste efforts, etc.) don't necessitate it, the author's arguments for it don't hold much weight.
One of the stronger rebuttals on Lobsters is that a powerful workstation can run virtual machines which can simulate a plethora of different device configurations, often simultaneously, for ease of testing and debugging. Whereas old hardware can only run a single configuration. If the goal is to reach a wider, lower common denominator of users, you're already limiting yourself here.
Additionally, modern languages (say, Rust) have powerful and intelligent compilers that will run like molasses on old hardware. Yet the resulting executables can be extremely performant; a smart compiler will always out-optimize a human. Using old hardware makes this a huge pain, and forces you decide if you want to settle for outdated compilers/languages and a potentially buggier/slower end product, or suffer through extremely long compilation cycles.
The author's argument might make sense in a very narrow set of circumstances that he happens to be in: the language/compiler is already decided for him by the ecosystem; the software is capable of running on machines like his development machine; the programs make sense to dogfood daily; and he's satisfied with 20-minute compile cycles (mentions the Linux kernel in the post).
For developers in general, I'd suggest giving some thought to whether upgrading to better hardware helps you get things done faster and with potentially better end results, researching what modern possibilities this can open up before dismissing the idea.
While I agree with your conclusion, I don't agree with the VM idea. The idea here is that running old hardware is useful because it makes you sensitive to the performance of the application you...
While I agree with your conclusion, I don't agree with the VM idea. The idea here is that running old hardware is useful because it makes you sensitive to the performance of the application you are working on. If you are not using it regularly, you will not experience as much empathy. But the main reason why I disagree with the VM idea is that I seriously doubt a significant number of devs are using their VMs this way.
I think it's important to realize that the author of this piece doesn't use this laptop as his daily driver - note where he talks about prepping it for a trip. Overall, I think the piece is more of a defense of his practice than it is an attempt to change how people develop software.
Actually, the author expands on the piece in his comments on Lobsters: "For many people, poor hardware is their life. Unless you’re constantly enduring the limitations of poor hardware yourself,...
Actually, the author expands on the piece in his comments on Lobsters:
"For many people, poor hardware is their life. Unless you’re constantly enduring the limitations of poor hardware yourself, you’re going to be constantly making life worse for those who do."
So he goes beyond the original defense, and attempts to position himself above developers who lack the insight and empathy to use old hardware. His is a stance that clearly a lot of other developers disagree with.
No, he is just telling something that is totally correct. Many software out there is produced in and for latest hardware, while most people cannot afford that. And id he is really considerate of...
So he goes beyond the original defense, and attempts to position himself above developers who lack the insight and empathy to use old hardware.
No, he is just telling something that is totally correct. Many software out there is produced in and for latest hardware, while most people cannot afford that. And id he is really considerate of that, he is above those who don't, anyways. Developers are enjoying an extreme liberty to be lazy about these things.
For an example, I'd love to try my hand at developing Android apps b/c I need a couple and maybe I could make some money which as a soon-to-be postgrad student I would more than appreciate. But my computer, at four core 1.8 something i3 CPU and 4Gb of RAM, cannot deal with Android SDK or Studio, so I can't, even when I use a spare phone to test the app instead of a VM. The wastefulness of Android devtools is a shame.
It is possible to develop Android apps with a text editor and command line. In fact, Android Studio is a great example supporting my point. With modern hardware you can run powerful fancy IDEs...
It is possible to develop Android apps with a text editor and command line.
In fact, Android Studio is a great example supporting my point. With modern hardware you can run powerful fancy IDEs that do neat things for you, like continuously running static analysis on your code as you're typing it, code indexing for fast search-all-files behavior, advanced graphical layout editors. And take full advantage of emulators to test on many different configurations.
Calling that "wasteful" is hard for me to understand. Implying you, or anyone, can do better? Good luck writing that level of advanced IDE targeting a 4 GB RAM development machine. This is exactly my point- development is possible on old hardware but it can be unnecessarily painful.
BULLSHIT. So b/c I am poor I need to hand-write UI XML? And then, gradle helps you with making your work totally unproductive anyways, in fact, that is the main horrible pile of shit that messes...
BULLSHIT.
So b/c I am poor I need to hand-write UI XML? And then, gradle helps you with making your work totally unproductive anyways, in fact, that is the main horrible pile of shit that messes everything up. I wrote Flutter when pom.xml was still supported.
Also, I can use full intellisense and a great debugger for many languages on my computer, using only a few megabytes of RAM, doing all the static analysis necessary. I can do all with Emacs and Flycheck, or VSCode and language servers, etc... I can even run Eclips without much trouble. And don't make me laugh when it comes to indexing&search or VMs. VirtualBox or QEMU runs smooth on my machine even when running a VM with a graphical distro and using up 3Gb RAM, even with Emacs and Firefox open along with it. Android emulator is obscenely poorly built. It is this blind ignorance if developers that causes software to be piss poor these days.
As to whether I could build something similar, well, I could definitely do better, but why bother when Google can't build an IDE for their most important product ever but write a dumb ass plugin for IntelliJ Idea, or pick a pile of shit like gradle for their build system when all that is necessary is to download a few .jars and run a compiler on things.
But hey! I can hand write XML all day and rewrite the build system for my project while at it and imagine what my app looks like and how it behaves so that devs out there don't need to really bother deserve their earnings! What a wonderful world!
I wasn't intending to offend you or insult your situation. Sorry if it came across that way. I did say in my first comment, "Assuming one's financial situation(, environmental waste efforts, etc.)...
I wasn't intending to offend you or insult your situation. Sorry if it came across that way.
I did say in my first comment, "Assuming one's financial situation(, environmental waste efforts, etc.) don't necessitate it." If the blog author had simply admitted, "I can't justify splurging on a high end computer due to my current financial situation," that would be completely understandable. He could have then added, "but it turns out I get by just fine on my older hardware, and here is an unintended side benefit."
However, he tries to spin it into some kind of virtuous heroic thing, painting himself a better and more understanding developer because of the older machine he uses, under the pretense that it was a proactive decision. And he is completely dismissive of people who can afford and choose to buy newer hardware: "most have better things to spend their money on." I just don't buy it; good developers care about performance and optimization regardless of the machine they are currently typing on.
Agreed, its one thing to quickly test something but once you start really using something you see it in a big way. I developed a feature at work and gave it a test and it was all good. Then later...
Agreed, its one thing to quickly test something but once you start really using something you see it in a big way. I developed a feature at work and gave it a test and it was all good. Then later I had to test something else that required using this other feature heavily. After using this feature heavily I noticed that the drop down not being alphabetically sorted was super annoying and slowing me down so I fixed it. In my quick test I didn't pick that up as an annoyance and if I didn't have to use it for an extended time it would have gone out and users would struggle with it without me knowing.
People certainly do use VMs this way (I mean, I do - but I'm the same guy who wrote the rebuttal on lobste.rs so that isn't really surprising). I know I didn't come up with it, and I know that I'm...
People certainly do use VMs this way (I mean, I do - but I'm the same guy who wrote the rebuttal on lobste.rs so that isn't really surprising). I know I didn't come up with it, and I know that I'm not the only one out there who does it.
There are other things one can do to figure out execution time - I only wrote one example. I also strongly disagree with the idea that the only way to have empathy for crap hardware is to have crap hardware.
I think about having crap hardware all the time. I'm happy that I don't, but that doesn't mean that I don't write as if I do, or as if someone who uses what I'm writing does.
I also think about having disabilities all the time. I don't have a disability, and I'm happy that I don't, but that doesn't mean that I don't write as if I do, or as if someone who uses what I'm writing does.
I also think about any number of other things, and I write software appropriately. I don't only use my keyboard, but I write software that can be used with only a keyboard. I don't have an iPhone, but I write software that can be used on one. It's just part of being a good developer.
It's not particularly difficult to have empathy, and it's part of why we do things like write user stories and have user experience interviews and actually do user testing - so we can write software that works for the people that are using it.
I agree that a lot of people don't do that, though, but I don't think that opting in to bad hardware will actually make you better as a developer. If you don't try to consider things that other people experience, then you're not a great coder, and using a limitation to make yourself consider something likely means that you won't consider other limitations that people have.
I'm actually glad you came over here to say this because it gives me a chance to address the source directly. Thank you for stopping by. Please note that the operative term in my arguement...
I'm actually glad you came over here to say this because it gives me a chance to address the source directly. Thank you for stopping by.
Please note that the operative term in my arguement regarding testing in a VM is "significant number". While I am sure there are a number of developers using VMs for their work, I don't believe that they make up a very large portion of them.
The thing you have to understand is that, from reading your arguements, you are a really great dev! But most people simply aren't, and they are the type of people I don't think would spend the extra time testing in this way.
Happy to be here (I'm new to Lobste.rs actually, but old hat around Tildes, and spend more time here), and happy to continue the conversation here. I fully agree that most people don't do this. I...
Thank you for stopping by.
Happy to be here (I'm new to Lobste.rs actually, but old hat around Tildes, and spend more time here), and happy to continue the conversation here.
While I am sure there are a number of developers using VMs for their work, I don't believe that they make up a very large portion of them.
most people simply aren't, and they are the type of people I don't think would spend the extra time testing in this way.
I fully agree that most people don't do this. I don't think that it's a requirement to be a great dev either, but the main point that I'm trying (probably ineffectively) to make is that hampering yourself isn't going to make you a better developer, or somehow give you some kind of empathy that you don't already have. If you're the sort of person who doesn't consider things like execution time, then limiting your hardware isn't going to make you a better developer. It may help you understand one particular issue, but it'll hinder you in many more.
There are ways to solve the issues that Drew solves through using an older computer that don't require an older computer, and learning those ways is probably going to serve people better than just opting into making their development more hostile to themselves.
I mean, he's not exactly fond of Rust (rightfully so, IMO) either, so I'm not sure what your point is here.
Additionally, modern languages (say, Rust) have powerful and intelligent compilers that will run like molasses on old hardware. Yet the resulting executables can be extremely performant; a smart compiler will always out-optimize a human. Using old hardware makes this a huge pain, and forces you decide if you want to settle for outdated compilers/languages and a potentially buggier/slower end product, or suffer through extremely long compilation cycles.
I mean, he's not exactly fond of Rust (rightfully so, IMO) either, so I'm not sure what your point is here.
There could be other benefits to programming under extra constraints. One night, in a state of hazy insomnia, I used my smartphone (and a touch keyboard) to write a small language interpreter....
There could be other benefits to programming under extra constraints.
One night, in a state of hazy insomnia, I used my smartphone (and a touch keyboard) to write a small language interpreter. Reading through it the next morning, I found that I had naturally kept to ~30 columns, uncramped spacing, and crystal clear data structures. I'm sure I have never written better C.
Iterating on a problem gives you new views of the problem that are increasingly well suited to your tools. If there are two equally clear ways to solve a problem, then the solution using more primitive tools is probably better.
Edit. I should complete this argument.
If you use older hardware or tools, besides creating more widely usable software, you might very well create better software. The development process will refine your conception of the problem past what is natural for more powerful tools. It will also make scope creep less sustainable. Constraints are good.
My 11 years old laptop didn't age well though. Heat pipes lost containment and the thing throttles hard while blowing out lukewarm air. Diverting some of the heat transfer to the bottom mounted...
My 11 years old laptop didn't age well though. Heat pipes lost containment and the thing throttles hard while blowing out lukewarm air. Diverting some of the heat transfer to the bottom mounted metal plate didn't help much. But it's still a backup machine with zero additional cost, and that's the great part. Also using old hardware instead of buying new one reduces waste. And provides some nostalgia
My old laptop had the fan fail. I opened it up to try and replace it but it was really embedded in there and idk where I would get a new one. I wish our devices were made with repair in mind.
My old laptop had the fan fail. I opened it up to try and replace it but it was really embedded in there and idk where I would get a new one. I wish our devices were made with repair in mind.
Once you start looking around and realizing how capable modern hardware really is, it becoming mind blowing just how slow most modern programs are.
On the other hand its mind blowing how many new programs we have and the capabilities we see in modern software. What would have taken a year to build in C now takes a few months in modern languages even if the result does require more resources.
Wirth's law, often stated as 'What Intel giveth, Microsoft taketh away'.
ahahahaha
So many commercial programs (and a good selection of FOSS programs, of course) are built to be 'pretty', and it feels like nobody ever takes the time to ask if it's worth the performance penalty.
You can build nice programs that run well, you just have to put in the work. It takes a lot more work to build a C++ GUI that will load in an instant than to distribute an Electron app, and CSS animations take longer to make (and are more limited) than if you use a JS animation library.
I agree anything is better than electron, but never use JS animations if you make a desktop app (or web app for that matter). If you can accomplish what you're doing can be done in a CSS transition, it will always be faster than a JS one. And if you can't use CSS transitions, you should probably be thinking about if you really need this transition as all.
I was just thinking about this yesterday. I saw someone at work using evernote and noticed how modern and flat it is compared to Zim wiki but I can't help but thinking how much I like the old ui look of zim. The 2000s grey UI represents software purity in my mind. Its fast, its efficient, it keeps my data stored locally and it isn't constantly trying to get me to pay for a subscription.
I gave Evernote a try, but it was lacking critical features and while the UI might have been "pretty" it was very, very bright. Zim inherited my system's dark theme and I didn't even have to edit anything.
Great rebuttals to this in the Lobsters thread: https://lobste.rs/s/s5lxfu/why_i_use_old_hardware
Using old hardware regularly, sure, the reasoning makes some sense. But developing software primarily on old hardware? Assuming one's financial situation(, environmental waste efforts, etc.) don't necessitate it, the author's arguments for it don't hold much weight.
One of the stronger rebuttals on Lobsters is that a powerful workstation can run virtual machines which can simulate a plethora of different device configurations, often simultaneously, for ease of testing and debugging. Whereas old hardware can only run a single configuration. If the goal is to reach a wider, lower common denominator of users, you're already limiting yourself here.
Additionally, modern languages (say, Rust) have powerful and intelligent compilers that will run like molasses on old hardware. Yet the resulting executables can be extremely performant; a smart compiler will always out-optimize a human. Using old hardware makes this a huge pain, and forces you decide if you want to settle for outdated compilers/languages and a potentially buggier/slower end product, or suffer through extremely long compilation cycles.
The author's argument might make sense in a very narrow set of circumstances that he happens to be in: the language/compiler is already decided for him by the ecosystem; the software is capable of running on machines like his development machine; the programs make sense to dogfood daily; and he's satisfied with 20-minute compile cycles (mentions the Linux kernel in the post).
For developers in general, I'd suggest giving some thought to whether upgrading to better hardware helps you get things done faster and with potentially better end results, researching what modern possibilities this can open up before dismissing the idea.
While I agree with your conclusion, I don't agree with the VM idea. The idea here is that running old hardware is useful because it makes you sensitive to the performance of the application you are working on. If you are not using it regularly, you will not experience as much empathy. But the main reason why I disagree with the VM idea is that I seriously doubt a significant number of devs are using their VMs this way.
I think it's important to realize that the author of this piece doesn't use this laptop as his daily driver - note where he talks about prepping it for a trip. Overall, I think the piece is more of a defense of his practice than it is an attempt to change how people develop software.
Actually, the author expands on the piece in his comments on Lobsters:
"For many people, poor hardware is their life. Unless you’re constantly enduring the limitations of poor hardware yourself, you’re going to be constantly making life worse for those who do."
So he goes beyond the original defense, and attempts to position himself above developers who lack the insight and empathy to use old hardware. His is a stance that clearly a lot of other developers disagree with.
No, he is just telling something that is totally correct. Many software out there is produced in and for latest hardware, while most people cannot afford that. And id he is really considerate of that, he is above those who don't, anyways. Developers are enjoying an extreme liberty to be lazy about these things.
For an example, I'd love to try my hand at developing Android apps b/c I need a couple and maybe I could make some money which as a soon-to-be postgrad student I would more than appreciate. But my computer, at four core 1.8 something i3 CPU and 4Gb of RAM, cannot deal with Android SDK or Studio, so I can't, even when I use a spare phone to test the app instead of a VM. The wastefulness of Android devtools is a shame.
It is possible to develop Android apps with a text editor and command line.
In fact, Android Studio is a great example supporting my point. With modern hardware you can run powerful fancy IDEs that do neat things for you, like continuously running static analysis on your code as you're typing it, code indexing for fast search-all-files behavior, advanced graphical layout editors. And take full advantage of emulators to test on many different configurations.
Calling that "wasteful" is hard for me to understand. Implying you, or anyone, can do better? Good luck writing that level of advanced IDE targeting a 4 GB RAM development machine. This is exactly my point- development is possible on old hardware but it can be unnecessarily painful.
BULLSHIT.
So b/c I am poor I need to hand-write UI XML? And then, gradle helps you with making your work totally unproductive anyways, in fact, that is the main horrible pile of shit that messes everything up. I wrote Flutter when pom.xml was still supported.
Also, I can use full intellisense and a great debugger for many languages on my computer, using only a few megabytes of RAM, doing all the static analysis necessary. I can do all with Emacs and Flycheck, or VSCode and language servers, etc... I can even run Eclips without much trouble. And don't make me laugh when it comes to indexing&search or VMs. VirtualBox or QEMU runs smooth on my machine even when running a VM with a graphical distro and using up 3Gb RAM, even with Emacs and Firefox open along with it. Android emulator is obscenely poorly built. It is this blind ignorance if developers that causes software to be piss poor these days.
As to whether I could build something similar, well, I could definitely do better, but why bother when Google can't build an IDE for their most important product ever but write a dumb ass plugin for IntelliJ Idea, or pick a pile of shit like gradle for their build system when all that is necessary is to download a few .jars and run a compiler on things.
But hey! I can hand write XML all day and rewrite the build system for my project while at it and imagine what my app looks like and how it behaves so that devs out there don't need to really bother deserve their earnings! What a wonderful world!
I wasn't intending to offend you or insult your situation. Sorry if it came across that way.
I did say in my first comment, "Assuming one's financial situation(, environmental waste efforts, etc.) don't necessitate it." If the blog author had simply admitted, "I can't justify splurging on a high end computer due to my current financial situation," that would be completely understandable. He could have then added, "but it turns out I get by just fine on my older hardware, and here is an unintended side benefit."
However, he tries to spin it into some kind of virtuous heroic thing, painting himself a better and more understanding developer because of the older machine he uses, under the pretense that it was a proactive decision. And he is completely dismissive of people who can afford and choose to buy newer hardware: "most have better things to spend their money on." I just don't buy it; good developers care about performance and optimization regardless of the machine they are currently typing on.
Agreed, its one thing to quickly test something but once you start really using something you see it in a big way. I developed a feature at work and gave it a test and it was all good. Then later I had to test something else that required using this other feature heavily. After using this feature heavily I noticed that the drop down not being alphabetically sorted was super annoying and slowing me down so I fixed it. In my quick test I didn't pick that up as an annoyance and if I didn't have to use it for an extended time it would have gone out and users would struggle with it without me knowing.
People certainly do use VMs this way (I mean, I do - but I'm the same guy who wrote the rebuttal on lobste.rs so that isn't really surprising). I know I didn't come up with it, and I know that I'm not the only one out there who does it.
There are other things one can do to figure out execution time - I only wrote one example. I also strongly disagree with the idea that the only way to have empathy for crap hardware is to have crap hardware.
I think about having crap hardware all the time. I'm happy that I don't, but that doesn't mean that I don't write as if I do, or as if someone who uses what I'm writing does.
I also think about having disabilities all the time. I don't have a disability, and I'm happy that I don't, but that doesn't mean that I don't write as if I do, or as if someone who uses what I'm writing does.
I also think about any number of other things, and I write software appropriately. I don't only use my keyboard, but I write software that can be used with only a keyboard. I don't have an iPhone, but I write software that can be used on one. It's just part of being a good developer.
It's not particularly difficult to have empathy, and it's part of why we do things like write user stories and have user experience interviews and actually do user testing - so we can write software that works for the people that are using it.
I agree that a lot of people don't do that, though, but I don't think that opting in to bad hardware will actually make you better as a developer. If you don't try to consider things that other people experience, then you're not a great coder, and using a limitation to make yourself consider something likely means that you won't consider other limitations that people have.
I'm actually glad you came over here to say this because it gives me a chance to address the source directly. Thank you for stopping by.
Please note that the operative term in my arguement regarding testing in a VM is "significant number". While I am sure there are a number of developers using VMs for their work, I don't believe that they make up a very large portion of them.
The thing you have to understand is that, from reading your arguements, you are a really great dev! But most people simply aren't, and they are the type of people I don't think would spend the extra time testing in this way.
Happy to be here (I'm new to Lobste.rs actually, but old hat around Tildes, and spend more time here), and happy to continue the conversation here.
I fully agree that most people don't do this. I don't think that it's a requirement to be a great dev either, but the main point that I'm trying (probably ineffectively) to make is that hampering yourself isn't going to make you a better developer, or somehow give you some kind of empathy that you don't already have. If you're the sort of person who doesn't consider things like execution time, then limiting your hardware isn't going to make you a better developer. It may help you understand one particular issue, but it'll hinder you in many more.
There are ways to solve the issues that Drew solves through using an older computer that don't require an older computer, and learning those ways is probably going to serve people better than just opting into making their development more hostile to themselves.
I mean, he's not exactly fond of Rust (rightfully so, IMO) either, so I'm not sure what your point is here.
There could be other benefits to programming under extra constraints.
One night, in a state of hazy insomnia, I used my smartphone (and a touch keyboard) to write a small language interpreter. Reading through it the next morning, I found that I had naturally kept to ~30 columns, uncramped spacing, and crystal clear data structures. I'm sure I have never written better C.
Iterating on a problem gives you new views of the problem that are increasingly well suited to your tools. If there are two equally clear ways to solve a problem, then the solution using more primitive tools is probably better.
Edit. I should complete this argument.
If you use older hardware or tools, besides creating more widely usable software, you might very well create better software. The development process will refine your conception of the problem past what is natural for more powerful tools. It will also make scope creep less sustainable. Constraints are good.
My 11 years old laptop didn't age well though. Heat pipes lost containment and the thing throttles hard while blowing out lukewarm air. Diverting some of the heat transfer to the bottom mounted metal plate didn't help much. But it's still a backup machine with zero additional cost, and that's the great part. Also using old hardware instead of buying new one reduces waste. And provides some nostalgia
My old laptop had the fan fail. I opened it up to try and replace it but it was really embedded in there and idk where I would get a new one. I wish our devices were made with repair in mind.