4 ms·

Over the years, I've been leaning more and more this way. Designing, writing, developing software using the Unix Philosophy [0], the suckless philosophy [1], c

by oso2k 8y ago

Over the years, I've been leaning more and more this way. Designing, writing, developing software using the Unix Philosophy [0], the suckless philosophy [1], cat -v [2], Write Small and Fast Software [3], DJB and libdjb derivatives [4][5] as sources for inspiration, IMO, will lead me to writing more comprehensible, more performant, more secure software. I mention these inspirations when ever I can. And I think software is overdue for a reboot on how we design, write, develop software. [0] https://en.wikipedia.org/wiki/Unix_philosophy#Doug_McIlroy_on_Unix_programming https://en.wikipedia.org/wiki/Unix_philosophy#Doug_McIlroy_o... [1] http://suckless.org/philosophy/ http://suckless.org/philosophy/ [2] http://harmful.cat-v.org/software/ http://harmful.cat-v.org/software/ [3] https://www.fefe.de/dietlibc/diet.pdf https://www.fefe.de/dietlibc/diet.pdf [4] https://www.fefe.de/djb/ https://www.fefe.de/djb/ [5] https://www.fefe.de/libowfat/ https://www.fefe.de/libowfat/

sureaboutthis 8y ago
I find the bloat of recent software comes mainly from the web development area which consists of far too many kids who want to make cat web sites cause they now know "computers and stuff". This trend has led those with small businesses to think anyone can slap together a web site in two weeks and "What does it matter if it's a 10MB download?". This has led to people like me who are strong followers of such philosophies and methods who want more time to analyze the real needs of the business and the technical needs of a web site to get beat down by managers who claim they've never known anyone to take more than two weeks to do anything. (A recent true story.)
- alunchbox 8y ago
  That's unfortunately the harsh reality of a business. They always want it done yesterday, never mind arguing the time needed for writing unit tests / E2E or performance & load testing as those don't give "business value". oh, don't even mention refactoring. * can this button do action A? yes move on to B. etc... (don't even look at A anymore) I completely feel you with this one.
lmm 8y ago
I don't think more than a tiny fraction of programmers are capable of writing secure software under such an approach; unix's reliance on unstructured interfaces means misunderstandings and "confused deputy" style attacks are inevitable. IMO our industry fetishizes performance to an absurd degree in proportion to how bad we are at correctness and basic security. I do think we're due a reboot (and to a certain extent we already have one in the (typed) functional programming revolution), but one that focuses on writing software that does what was intended, rather than obsessing over shaving pennies-worth of cycles off program runtimes.
- maccard 8y ago
  > IMO our industry fetishizes performance to an absurd degree in proportion to how bad we are at correctness and basic security. I completely disagree. Our industry (or at least parts of it) have absolutely no concern for performance or power consumption (electron is one of the main culprits here, but the issue existed with Java/swing before,and im sure it existed before that too). For the most part, our industry is just as bad at security though, you're right. I disagree about correctnesd though - correctnesd isnt a binary thing, it's a scale. Some things matter more for correctness (it's ok if we miss an animation transition, it's not ok if we have bad rounding in our financial software). Overall we have a decent grasp of the severity of issues and in prioritising what to ensure is correct.
- pjmlp 8y ago
  I think we need an increase in software refunds and lawsuits due to security exploits in cloud and IoT deployments for companies to start paying attention.
lboasso 8y ago
Another excellent resource is "A Philosophy of Software Design" [0], from John Ousterhout (known for Tcl/Tk, Raft, RAMCloud, Log-Structured File System). Like Niklaus Wirth, he is striving for designs that fight complexities and yield simple and powerful abstractions. This book is so much better than overrated books like "Code Complete" and "Clean Code" for a fraction of the page count. [0] https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201 https://www.amazon.com/Philosophy-Software-Design-John-Ouste...
- tmaly 8y ago
  What section of the book did you enjoy the most?
  - lboasso 8y ago
    I enjoyed most of it. In particular: * Ch. 4 "Modules Should Be Deep" * Ch. 10 "Define Errors Out Of Existence" * Ch. 20 "Designing for Performance"

by oso2k 8y ago

sureaboutthis 8y ago

I find the bloat of recent software comes mainly from the web development area which consists of far too many kids who want to make cat web sites cause they now know "computers and stuff". This trend has led those with small businesses to think anyone can slap together a web site in two weeks and "What does it matter if it's a 10MB download?". This has led to people like me who are strong followers of such philosophies and methods who want more time to analyze the real needs of the business and the technical needs of a web site to get beat down by managers who claim they've never known anyone to take more than two weeks to do anything. (A recent true story.)

alunchbox 8y ago
That's unfortunately the harsh reality of a business. They always want it done yesterday, never mind arguing the time needed for writing unit tests / E2E or performance & load testing as those don't give "business value". oh, don't even mention refactoring. * can this button do action A? yes move on to B. etc... (don't even look at A anymore) I completely feel you with this one.

lmm 8y ago

I don't think more than a tiny fraction of programmers are capable of writing secure software under such an approach; unix's reliance on unstructured interfaces means misunderstandings and "confused deputy" style attacks are inevitable. IMO our industry fetishizes performance to an absurd degree in proportion to how bad we are at correctness and basic security. I do think we're due a reboot (and to a certain extent we already have one in the (typed) functional programming revolution), but one that focuses on writing software that does what was intended, rather than obsessing over shaving pennies-worth of cycles off program runtimes.

maccard 8y ago
> IMO our industry fetishizes performance to an absurd degree in proportion to how bad we are at correctness and basic security. I completely disagree. Our industry (or at least parts of it) have absolutely no concern for performance or power consumption (electron is one of the main culprits here, but the issue existed with Java/swing before,and im sure it existed before that too). For the most part, our industry is just as bad at security though, you're right. I disagree about correctnesd though - correctnesd isnt a binary thing, it's a scale. Some things matter more for correctness (it's ok if we miss an animation transition, it's not ok if we have bad rounding in our financial software). Overall we have a decent grasp of the severity of issues and in prioritising what to ensure is correct.
pjmlp 8y ago
I think we need an increase in software refunds and lawsuits due to security exploits in cloud and IoT deployments for companies to start paying attention.

lboasso 8y ago

Another excellent resource is "A Philosophy of Software Design" [0], from John Ousterhout (known for Tcl/Tk, Raft, RAMCloud, Log-Structured File System). Like Niklaus Wirth, he is striving for designs that fight complexities and yield simple and powerful abstractions. This book is so much better than overrated books like "Code Complete" and "Clean Code" for a fraction of the page count. [0] https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201 https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

tmaly 8y ago
What section of the book did you enjoy the most?
- lboasso 8y ago
  I enjoyed most of it. In particular: * Ch. 4 "Modules Should Be Deep" * Ch. 10 "Define Errors Out Of Existence" * Ch. 20 "Designing for Performance"