A plea for lean software (1995) [pdf]
cr.yp.to
cr.yp.to
[0] https://en.wikipedia.org/wiki/Unix_philosophy#Doug_McIlroy_o...
[1] http://suckless.org/philosophy/
[2] http://harmful.cat-v.org/software/
[0] https://www.amazon.com/Philosophy-Software-Design-John-Ouste...
In particular:
* Ch. 4 "Modules Should Be Deep"
* Ch. 10 "Define Errors Out Of Existence"
* Ch. 20 "Designing for Performance"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.)
* 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.
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.
20180720 - Update compiler: ORP.Mod.txt and ORG.Mod.txt
Cash for base adr of global variables "curSB" has been removed from ORG.Mod.
Removal of this optimization makes compiler simpler.
As far as github mirrors, I'm not sure there is one. But this looks interesting: https://github.com/Spirit-of-Oberon/ProjectOberon2013
But you may just want to get the original code and read through the books at http://www.projectoberon.com/
It was a very nice experience interacting with him.
But no. You cannot ask for all to be understood like that.
Trust is a different matter.
I mean, it's just a forum; it bloody well should be; but it could so easily not be.
I want my browser to be served marked up text with the occasional embedded hypermedia, that's it.
I don't need fancy layout, I don't need transition effects and I don't need updated data without making another request to the server. If I wanted all those things I'd install an app like I do on my phone.
Of course, that spells doom for advertisers and those that rely on advertising dollars to generate content. But I'd rather pay for content if I think is worth paying for, like the Wall Street Journal for example.
How would you build a big rocket or an OS that way?
EDIT: A good principle would be that every software author should understand his own code in detail. This is often not the case.
A single module with well-defined interfaces that abstract away its internals for its consumers? Yes, that metric is appropriate for a module like this.
You have to distinguish between inherent complexity that is necessary to solve the problem at hand and needless complexity that arises from not having the resources for building a simpler solution.
Nobody understands how a processor is made. Hell, I bet there's almost nobody that truly understands how a plastic cup is made. Do you know how complex the equipment for exploration and drilling oil is, refining, polymerizing, injection molding etc? Do you really think you can find a single man that's able to do this from scratch? And that's an easy case.
No system can be understood in it's entirety by anyone. This is because there's no absolute truth to be known, only approximations of varying degrees.
It's not how much disk space or ram it takes up.
It's certainly not the amount of dollars/megabyte it burns.
It's how much mind space of both the user and the developer it takes up.
Alas, mindspace is the one thing utterly untouched by Moore's Law for millenia.
To take his example of Word, I don't think it really affects users negatively that there are tons of features they don't use. If all you want to do is use it like Wordpad, nothing's stopping you, and many users do just that. But if you want to start automating features with VBA, doing extremely complex mail merges, building a bibliography, or all sorts of other great features, they're there for you. And any reasonably-designed software should be designed so that you don't have to know the whole thing inside and out to work on one feature.
When I think of software I use often, quite of a lot of it is very complex, fully-featured software, and I'm sure there are many features I never use (e.g., IntelliJ, Chrome, Office, JDownloader). In this respect I really don't believe in the "Unix philosophy," at least for GUI programs.
So on one hand, a full-featured extensible program whose size barely changes over 35 years, and one the other hand, a single purpose application, somewhat extensible, whose size grows exponentially over 25 years (and it's very much NOT limited to the 163 MB on disk space, since if you want to show or run anything in a browser window, you have basically to download it from the Internet, and since the least web page is 300 KB download size...).
At one point, we have to address the question of the programming language. C++ with its templates, and its baroque syntax and typing rules, multiplies the the size of the sources and the object files. Even the lighter C, when used with modern programming techniques (the older ways would lead to too many bugs and security holes), involves a lot of (by-hand!) code duplication (even with _Generic in C11). On the other hand, emacs written (mostly) in lisp uses a programming language that is basically generic. Since types are not checked at compilation-time, but at run-time, any function is essentially a generic function by default, and this leads to a lot of reusability and avoids a lot of code duplication. In addition, the use of a garbage collector (and in some cases, run-time checks for immutable data) means that you can avoid a lot of data duplication; this is not possible in C or C++, therefore you can witness a lot of data copying and duplication in those programs, to ensure manually memory and "const" safety.
Article: https://www.washingtonpost.com/wp-srv/tech/reviews/finder/re...
Site: http://www.yeahwrite.com/
Win 3.1/95; free, or $15 for more powerful registered version.
It even has a Facebook page: https://www.facebook.com/Yeah-Write-38276039100/
Now that's persistence! Kudos to whoever made it.
Here's another analogy:
"This car seats twice as many people, and accelerates twice as fast, but sadly will require twice as much motor oil when it's time for an oil change. We could have optimized and improved the car's design, but you would have had to wait two more months and it would've added $10,000 to the unit cost. It would've been madness to do."
We could sit here all day arguing about which analogy captures the actual situation correctly, or we could just talk about the actual situation.
It just happens that the cost of fixing an automotive defect (i.e., with a recall) is generally way higher than the cost of fixing a software defect (i.e., by shipping an update). So the automotive industry invests more heavily in eliminating defects.
If gas did get cheaper as fast as memory and storage, that would be a correct argument.
> Not saying Joel is necessarily wrong, but it would be nice if software design had some sense of craft....
I'd actually say the opposite: too much sense of craft is the problem with a lot of software development these days.
I wouldn't call this style of writing 'pretty good'. Asserting that anyone who worries about something he doesn't worry about has a mental health problem is pretty arrogant.
Wirth made a bunch of languages that were based on the "right" way to do things: Pascal, Modula, Modula-2, Oberon. The languages either were used and became massively fragmented (see Pascal) or were not used much. Other than Borland (Turbo Pascal and Delphi) no other large company really embraced any of the Wirth languages.
Stroustrup, on the other hand, was more pragmatic, and released a language aimed at professional programmers. In addition, instead of creating new languages, he has spent decades evolving C++. As a result, C++ has been in the top 5 of most used programming languages for years (decades?) and forms the critical infrastructure of many of the largest tech companies. In addition, I bet the evolution between C with Classes, and C++17 is pretty comparable in scope to that between Pascal and Oberon.
[1] https://en.wikipedia.org/wiki/X86_calling_conventions#stdcal...
I don't know half of it half as well as I should like; and
I like less than half of it half as well as it deserves.
-- B.B.do you also use all the classes of Python or Java's standard library ? C++17's spec is ~1400 pages (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n471...) but the actual language spec stops at page 406, the remaining 1000 pages are the specifications for the standard library. And in these 400 pages of specs, there are a lot of examples, grammars... just look at the chapter on templates: it's ~80 pages but more than half are valid & invalid code examples.
Had Java and .NET do the proper thing, by following up on Oberon, Modula-3 and Eiffel, by having proper AOT compilation since day one, and on Java's case value types as well, developers would feel less pressured to turn to C and C++.
Basically if they had been released the same way Go was.
PalmOS was also basically a simplified clone of MacOS; I don't know if it was itself written in Pascal, but it kept the same internal Pascal data structures IIRC.
http://www.smashcompany.com/business/the-worst-software-proj...
1. They recently rolled out an update to GMail that they had worked on for some years. Were these years spent figuring out how to make it fill available memory and processing? No. They were spent figuring out how to streamline.
Today, if you visit mail.google.com, the page loads in about the same time as a ping: that is because they got the login page down to just 56 bytes after compression. That is the size of a ping packet. This is an astounding achievement.
After logging in, 56 bytes isn't enough to present much of a view, but it does the next best thing: in the space of the absolute limit for a single TPC/IP packet, which is 64KB, the interface is rendered enough to see the latest unread emails, and to make the Compose button active. After a single packet! In my tests this took less than 7 milliseconds. This is enough to render both of the main things one would like to do: compose a new mail, or view the latest mail. In other words, after a single packet is received, a fully functional inbox is presented, and a fully functional Compose link. The TCP/IP packets that follow then load some javascript, but you wouldn't know it from the interface, which stays the same as it loads. I've tried manually throttling the interface after the single packet, when it was bare HTML, and could still click to request a view of mail or compose new mail, getting the result instantly. In all, it is possible to enter and exit gmail while consuming a grand total of 2 KB. To put this into perspective, this represents approximately 0.016% of 1 second of a 100 megabit connection. Wow.
2. The other example I have from Google is Google Chrome. In an era of heavyweight desktop apps like Firefox, Adobe Creative Suite, or text editors like Atom (which uses up to 3 GB just to open a text file)[1], Chrome does the insanely impossible: it uses less than 2 megabytes of memory to fully open, and less than 1 kilobyte of memory on each open tab. Since Chrome has a 32-bit version, I tried running it on an old Pentium I that I had running windows 95. It is a 300 Megahertz computer. While not fast, it was able to open a hundred tabs in about 15 seconds. That is 0.15 seconds for a new tab on a Pentium I. On a modern quad core computer, a new tab is ready by the next screen refresh. And it scales: opening ten thousand tabs takes less than 4.5 seconds and ended up eating 10 megabytes. Wow.
To think about the low-level engineering that must have gone into this is just astounding. Firefox chokes on a few dozen tabs. Windows can't even render a window that fast - they must have literally written more efficient low-level code than the built-in window manager for Windows.
In a world where software struggles to somehow use up all precious 16 gigabytes of RAM that you have, and eat up every cycle like it's some buffet, it's nice to know that there is some serious capability put behind behind small and lean.
It is clearly the right thing.
See for your yourself: https://web.archive.org/web/20090330212446/http://www.google...
Isn't this the way things should be?
[1] https://discuss.atom.io/t/excessive-memory-problem-seems-to-...
-------------
EDIT: three people read what I wrote literally (even though I linked an archive.org link). I was kidding. Unfortunately, I don't have access to a magic GMail. I have to wait 15-45 seconds for the new GMail to load. It is literally the slowest site I use on the entire Internet. The above represents my expression of what I know Google engineers would be capable of. They're smart enough. I believe in them. They can do it!
>If there's any way.
Hard work by very talented engineers.
I believe you're thinking of Google engineers circa ~2001
I doubt the current crop of engineers working on things like GMail refresh are anywhere near having that kind of skills.
They must. GMail has 1.2 billion users.
The very talented people that built it have long since moved on to sexier things.
Since this was published the bloat went on.
Why? My take is, most people don't care about small software as much as they care about UX, availability and features.
How else would you explain the rise of HTML/JS/Electron and the fall of C++/Qt in the UI world?
In my current role I work on a very large build chain for a very large software product. I have pushed and chipped away at that build chain over the last three years, and at current measure a clean build now takes an hour and a half, where it used to take eight hours.
Why do I care so much about things being lean and small? There are a plethora of tangible benefits, but... maybe eight years ago or so I stumbled across Niklaus Wirth's (author of this article) works, and they struck a chord with me. But I had questions. So... I emailed him.
I'm nobody special. I wasn't expecting a reply. But he wrote me back a wonderful reply to my questions, and that, too, has stuck with me over the years.
So, I'd like you to keep in mind that that 'plea from a purist removed from reality' had a strong impact in at least the reality for one large software product.
Does this "fall" really exist though, or is it just the byproduct of extremely intense marketing from the HTML/JS/Electron software authors ? I'm pretty confident that there are more desktop software being written today in Qt than in Electron - but most of the time they don't end up plastered all over the interwebs for the simplest todo-list app.
I'm pretty confident that this is not the case.
There may be a huge amount of legacy software still based on Qt, but new stuff? Only if it is performance critical.
I mean, who wants to pay a C++ dev for something a web-dev can do?
I know a bunch of civil engineers who also know some C++.
Probably the reason for all these strange UIs in cars these days, hehe.
I'd also wager there are more C++ pitfalls than JS pitfalls (or at least the JS ones are less severe/obscure). A less experienced engineer would be able to better maintain the web app than the C++ one IMO. This increases the bus factor.
The people who make the decisions care more about those things than the layers and layers of expensive abstractions that prop up web technologies, and how much electricity/battery life that consumes in aggregate.
I'm working in game dev. Most of our tools are native UI or in-engine. The heaviness of web apps frustrates me a great deal, but I get why things exist the way they do.