The Brutalist Programming Manifesto
call-with-current-continuation.org
call-with-current-continuation.org
II. Solve problems instead of creating them
We want to solve concrete problems, not anticipate the tasks
others might have in the future, so we create applications
instead of frameworks. We write editors, not text-editing
II. Solve problems instead of creating them
We want to solve concrete problems, not anticipate the
tasks
others might have in the future, so we create
applications
instead of frameworks. We write editors, not
text-editing
If you can't read a txt file, that's more or less a you problem.
This is a fine example of how you can be technically right and simultaneously obviously wrong for a large part of your audience.
(Maybe like the original Brutalism, which was loved by architects and often hated by the people who had to spend time in the buildings.)
If your device fails to display a 70-column text file, then your device is broken.
It’s a very common format for large amounts of older information, almost anything online from prior to the mid-1990’s.
'V. Strive for robustness'
Using http server to serve hard-wrapped txt.
That is just ornament.
True Brutalism would be unwrapped text.
This is just gimmick.
Exactly like that. Brutalism was an attempt to apply the principles of socialism to architecture. Like all 1:1 transpositions of theory into practice, it missed a lot of nuance and consciously ignored the contingencies of history -those discoveries made by trial and error that don't necessarily fit neatly into theory - resulting in terrible buildings.
This attitude amusingly mirrors the shift from early to late brutalist architecture. Where early brutalist architects were reacting against the inhumainty of the internationalist style, and concerned with recreating the monumentality of historic buildings in line with modernist principles. Like human spacial organisation, function over form, honesty in materials, and lack of ornamentation.
of course that quickly gave way to cheap concrete and poorly built units. The problems that surfaced with these buildings of course became the selling point. You should be shivering in the cold and dark and damp, cowering before the might of the state. Architecture found it's responsibility was to express frugality and indifference towards the populace.
So now, brutalist web design is no longer finding a level of simplicity which works for both creator and user, it is about fucking with your bloated browser. You should, after all, just be using a Teletype.
This should be a test case: can our browser, on our device, in portrait mode comfortably display 80 column monospaced pre formatted text.
Hard-wrapped text is just completely and obviously incorrect. The 72/80-column "rule" was valid in probably the 90's at the latest, and now is pure downside.
The odds that the user's font choice and physical screen size will exactly line up with whatever width you decided to impose on them is very small. And if they don't align, then you waste space at best (when display lines are longer than hard-wrapped lines), and cause massive reading headaches (because when your hard-wrapped lines are longer than display lines, you alternate between full lines and those with a few extra spillover characters) at worst.
There's also no correct algorithm to reverse hard-wrapping.
And it has the potential to cause accessibility problems.
Putting hard-wrapped content on the web like this is inexcusable. Don't do it. It actively makes the lives of your readers worse.
Your device cannot properly show text that can be easily read on a terminal from 1975.
Today, we have a massive variety of different screen sizes, and we can pick different font sizes to accommodate users' eyesight and preferences. These differences make hard-wrapping an extremely bad idea.
There's zero excuse for hard-wrapping - it actively makes the lives of readers worse. Safari is doing the sane and normal thing - soft-wrapping text, because most sane people do not hard-wrap their text, for obvious reasons.
It breaks poems, code, ascii art, emails, man page, and probably much more that I can't think of. It is only the right choice for plain text books. But you are right in that Safari on iPhone should choose a behaviour, and it will be bad for some things, since plain text is used for a wide variety of things.
To be noted, on windows + touchpad, you have 2 different zooms (in Edge and in Firefox at least): a font zoom and a pinch zoom. So on notebooks, both fixed-length text files, and both book type text files are readable.
Which almost always have short lines and are almost never actually broken by soft-wrapping for any reasonable viewport size
> code
Which shouldn't be hard-wrapped in the first place
> ascii art
Which usually also have short lines, and if it gets wrapped, you can zoom out (which you usually want to in order to see the ASCII art anyway)
> emails
Which shouldn't be hard-wrapped in the first place either
> man page
Which also shouldn't be hard-wrapped in the first place
Half of the things that you're talking about are not broken by Safari, they're broken by hard wrapping (and the other two are unlikely to be broken in the first place and make up a tiny minority of content). As stated upwards, hard-wrapping is incorrect almost everywhere. (poems and ASCII art are not "hard wrapping" because the linebreaks are part of the content, and adding the required newlines is not "hard wrapping" any more than adding a newline between paragraphs is "hard wrapping")
> It is only the right choice for plain text books.
It's always the right choice, because it wastes screen space and causes reading headaches because you do not have a crystal ball and you do not know the user's screen dimensions and font size.
If you hard-wrap to 80 characters and the user's viewport size (whether for web browsers or terminals, doesn't matter) is 160 characters, you are wasting 50% of their screen space by hard-wrapping. If you hard-wrap to 80 and their viewport is 79, you are also wasting 50% of their screen because every other line will have a lone character on it, which also causes massive reading problems. These statements are factual.
> To be noted, on windows + touchpad, you have 2 different zooms (in Edge and in Firefox at least): a font zoom and a pinch zoom. So on notebooks, both fixed-length text files, and both book type text files are readable.
This is a useful feature in general - but it does not excuse hard-wrapping. Not all platforms have these features (and they're unavailable in terminals), and imposes the author's column width on the user. If I want more than 80 columns of text, I should be able to get it.
If by "hard-wrapped" you mean having a fixed-style, then all poems, code, emails, ascii-art should be hard-wrapped, and are hard-wrapped. If not, then I don't have any idea what are you talking about.
This is confusing and meaningless.
The only reasonable definition of "hard wrapping" is "you insert linebreaks were not previously present into content in order to fit a specific number of columns", and under that nothing should be hard-wrapped. People never call ASCII art or poems "hard-wrapped", or say that code is "hard-wrapped" when you add natural line breaks at the ends of lines (e.g. "if (cond) {\n" or on web "<p>if (cond) {</p>") because that's not how people use that term.
Poems and ASCII-art aren't hard-wrapped by definition because the line-breaks are already present as part of the content itself. For the code and emails, I already conclusively showed why those are bad.
>> There's zero excuse for hard-wrapping - it actively makes the lives of readers worse. Safari is doing the sane and normal thing - soft-wrapping text, because most sane people do not hard-wrap their text, for obvious reasons.
> It breaks poems, code, ascii art, emails, man page, and probably much more that I can't think of.
The alternative of safari's soft wrapping is not "hard wrapping" (which, since Safari is a display, would be the same as soft wrapping), but not wrapping at all, letting the line to go out. Which would be the right thing for poems, code, ascii art, emails, man pages, letters, any structured text, and probably much more.
The user's device is responsible for deciding what the width of the content should be - not the content.
As a very trivial example of why - if you hard-wrap your text to 80 characters, and someone has a window that fits 100 characters at their desired text size - you're wasting 20% of their screen space. If they have a narrow viewport that's only 70 (either because it's a physically small device, or because they've vertically split their display/terminal), then you get the extremely terrible experience of having lines that alternate between full and having 10 characters.
There is no excuse for hard-wrapping text.
How else are you going to write a poem, or an address, in a text file?
> if you hard-wrap your text to 80 characters, and someone has a window that fits 100 characters at their desired text size - you're wasting 20% of their screen space.
No. Long text lines are unreadable. Hard-wrapping text at 60 or 70 characters is perfectly appropriate and does not waste anybody's screen space. I'd go further and say that publishing or sending non-hard-wrapped text files is terrible bad taste. Wraps are part of the content and should not be messed with.
You'll take hard wraps from my cold, dead hands.
You don't understand what "hard-wrapping text" is, then, because neither of those things involve hard-wrapping in the sense that we're discussing.
Hard-wrapping (in the context that we're clearly using it) is where you add a newline in the middle of content to manually fit it to a terminal window or some other container. In poems or addresses, the newline is part of the formatting, just like when you're writing two paragraphs you separate them with a newline. That's categorically different than the hard-wrapping being discussed anywhere in this thread, where non-content linebreaks are being added to fit a specific width. You may want to re-read the surrounding comments, because you clearly missed something.
> No.
This is factually incorrect, because my statement "if you hard-wrap your text to 80 characters, and someone has a window that fits 100 characters at their desired text size - you're wasting 20% of their screen space." is factually correct. You are wasting their screen space.
> Long text lines are unreadable.
That's why we have soft-wrapping. Are you using a computer from the past few decades? All of them have the ability to soft-wrap text.
> Hard-wrapping text at 60 or 70 characters is perfectly appropriate and does not waste anybody's screen space.
Factually incorrect. If you hard-wrap at 60 characters and someone has a viewport that's 59 characters, then you waste close to 50% of their screen space due to the overflow and cause massive viewing headaches. If you hard-wrap at 60 characters and someone has a viewport that's 120 characters (which is a very reasonable value - mine is 173 normally or 147 on a bad-eyes day), you also waste 50% of their screen space. This is not an opinion - this is a fact.
You should stop saying things that are objectively false, and especially advocating for harmful practices based on them.
Speaking of "you problems", I assumed that most people are using web browsers to read this. We can hardly be blamed for this. But contrarian that you are, I won't be surprised if you try anyway.
https://stackoverflow.com/questions/400359/algorithm-for-re-...
Modern LLMs could probably do a better job, but there's no perfect solution. Hard wrapping text loses information. There's no guarantee you can reconstruct the original.
That is not a property of plain text files, of the sort we see above. The rule there is very simple: single newlines are wrapping, double newlines are paragraph breaks. Yes, you want to put a tiny bit more effort into it to do a good job, someone might be sloppy about trimming tailing whitespace on empty lines and so on, it would be silly to let your parser break on three newlines, and so on.
> Hard wrapping text loses information.
Nonsense.
Spoiler alert: I hard-wrapped every paragraph in the reply above. So that's the existence proof: no it doesn't.
Hacker News, not known for the immense sophistication of its markup, is, somehow, mysteriously, able to tell the difference between one newline (still a paragraph) and more than one (new paragraph).
I don't know how they do it with all the deleted metadata reconstruction algorithm undecidable problems you're sure exist. Perhaps they use an LLM, to do a better job. We may never know for sure.
here is a free verse poem with lines of unknown
length and deliberate lack of uppercase or
punctuation
Hard wrapping plain text loses information because it inserts non-semantic line breaks using the same character as already used for semantic line breaks. There is no way reliable way to distinguish the two, so the transformation is not reversible in the general case. The best you can do is guess from context, which, as the poem demonstrates, is not always possible.
This is very much a _them_ problem. They want the ease of use of the www with the simplicity of the early internet.
You can't have both.
Back in the day you'd use an ftp server for textfiles. Of course in this day and age I doubt even 20% of the people on here can fire up an ftp client, connect to an ftp server, download a text file, open it in a text editor, read it and not get lost somewhere along the way.
???
It has the valid http content type: text/plain
If your browser can't display text/plain properly, then it should open an app to do that, or offer it for a download.
I am not sure what do you want with this http = html.
Common MIME types
This topic lists the most common MIME types with corresponding document types,
ordered by their common extensions.
The following two important MIME types are the default types:
text/plain is the default value for textual files. A textual file should be human-readable and must not contain binary data.(The problem with that is that excessive line widths are bad.)
Except for the line breaks.
So far, so good.
> We are not smarter than others, others are usually not smarter
Nope. That's _almost_ a non-statement. I'll readily admit that there are many more people smarter than I am. They've done good prior work, why would I not use it? Yeah sure, let's write our own crypto code. Guaranteed recipe for disaster.
> Avoid cryptography, if possible, as you should write all the code yourself and doing your own cryptography is a well known mistake.
If you have your browser configured to use a tiny font by default, that is entirely on you genius.
I do wonder why you don't feel embarrassed posting weak dunks like this under what is apparently your real name.
They didn't even say anything stupid as you did. And voluntarily and unsolicited. No one made you or asked you, you just volunteered this thought to the public.
Well the public has heard it and some have judged it. It's all on you if you don't like it.
I speak under my real name because I'm not ashamed of what I say. Or when I am occasionally, I honestly accept it.
Like, I'd muster some respect for your efforts here if they were substantive and responsive to the actual point. But you choose to make a different first impression.
This is not very brutalist, considering that brutalist architecture would never exist if it followed this rule.
> VIII. Avoid all ornaments
How about: "don't hide the way you made it"? Brutalist buildings often have the look of bare concrete and metal because they are not trying to hide the way they were built. This would mean disclosing sources and tools, making buttons look like buttons, showing the actual errors, shaping the UI to reflect the underlying process or model rather than trying to abstract it.
[1]: https://motherfuckingwebsite.com
Reading the original Rise of Worse is better article ( https://www.jwz.org/doc/worse-is-better.html ) gave me a huge appreciation of programming implementariin simplicity, and improved my pace of coding a lot. It shows a real example of why C won over Lisp (a much cleaner interface) 50 years ago.
The funny part is that right now I'm programming in something that may be closer to Lisp (Python), but happy to rewrite parts of it in C in the future when it gets practical.
The amount of features I can add in a small time just because I always pick the smaller implementation surface (while still moving forward) is amazing.
Regarding dependencies: I may want to move to lower level libraries in the future when my project is in a more advanced state, but again they are great as training wheels (lower level would help with customization, but I'm waiting until I _need_ it).
> We do not use libraries
seems a definitive position at least, whether one agrees or not
> If you need additional libraries ...
Hold on, I thought we weren't using libraries. Shrug.
The whole piece is plagued with dissonant inconsistencies like that.
In this specific case it seems particularly necessary. I don't think I will take this manifesto at face value.
> Solve problems instead of creating them
Whenever you write code, you inherently create problems. For every line of code you write to solve any problem, you create bugs, technical debt and maintenance problems for someone in the future. The only way to not create problems is to not write code, and therein lies the challenge.
> Do everything yourself
Yeah... no. A modern developer relies on _mountains_ of code just to use an editor. Will you write your own editor, networking stack, kernel, firmware and OS as well? If the answer is "no", take the same approach with the software you write. Don't liberally import any dependency you find, and certainly try to reduce the amount of 3rd party code that you use, but also be pragmatic and don't reinvent the wheel if there's a perfectly good one someone else built for you. The best you can do is take a glance at how it was built, and try to follow and understand updates when they happen, but this DIY/NIH obsession is ludicrous.
> Code that we didn't write we do not understand.
Have you tried reading it?
> Avoid all ornaments. We eschew all visual gimmicks, animations and eye-candy.
Awful advice. Good UIs are accessible and enjoyable to use. Just because you prefer your UIs to be spartan, doesn't mean your users will as well. You are building software for other people, right? If anything, make your software configurable so that your users have the option of configuring it to their needs and preferences.
> Do not listen to others. We never take a software methodology, school of programming or some random internet dude's "manifesto" at face value.
I will gladly disregard this "manifesto" as well then. :)
Also, the least you could do is use a spellchecker for such an enlightening document, or maybe write your own?
- "we often evade our responsibilty"
- "True mastery transcendends"
- "Forcing others do upgrade"
Restructuring text to fixed length is eye-candy, and one that causes problems (e.g. when zooming in). A less ornamental approach would be to serve free flowing text and let the user adjust the browser window to their preference. Better yet, return semantic html as opposed to a single pre block.
An alternative brutalist website template, one that promotes semantic html, is: https://motherfuckingwebsite.com
They should rename this screed Arrogant Programming :P
1: Simplicity is better than complexity all things being equal. Guess how often that happens. (Hint: for any non-trivial problem it doesn't.)
2: Yes, it's better to solve problems than to create them. Also water is wet.
3: Spoken like someone who wouldn't recognize true mastery if it bit them on their bony behind.
4: Yeah design your own CPU while you are at it.
5: Just... no.
6: You can certainly make computing less secure though. By doing everything yourself for example.
7: Cool. And nobody except people who have a keyboard and a mouse will every use whatever shit you produce.
8: Welcome to North Korea. I'll stick to juicing things up and making sure people have a great experience.
9: Cool. Tools are tools. Whoever wrote this is a tool too.
10: Ok humblebrag Inc.
11: Wow. Really?
12: Cool. This is really a special kind of weapons grade stupid.