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
Me: zooms in so I can read the tiny ascii webpage
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
It's a hard-wrapped text file, which is objectively worse than simple HTML because there's no reliable way to reflow it for different screen sizes. You have to apply heuristics to guess if line breaks are semantic or not.
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's mail. Parsing mail is undecidable, this is known, it's an ancient
format (I use that term in the loosest sense) and can only be handled
on a best-effort basis.
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.
They are serving a raw text file from the endpoint of an http server. In case you don't know what http stands for: Hypertext Transfer Protocol.
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.
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.
Hard line breaks aren't even technically right, though - they're obviously and completely wrong.
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.
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.
It's just a better alternative for pdf. At least on desktop. I can imagine that it is not that friendly on phones, that's why Apple is killing it deliberately.
A brutalist might now argue that rendering wrong in safari is obviously right.
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 doesn't have anything to do with technical capabilities.
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.
This is a very bad argument. The 1975 terminal literally had about 72-80 physical columns, and you couldn't adjust the font, and most terminals were like this - these are the circumstances that enabled hard-wrapping and made picking a specific value (72/80) reasonable.
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.
> Maybe like the original Brutalism, which was loved by architects and often hated by the people who had to spend time in the buildings
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.
If that word choice annoys you, I'm rather glad I chose it.
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.
The good thing about serving plaintext is that the reader can view it any way they want. Want to read it using text-to-speech? Sure. Want to replace the font with Comic Sans size 30? Sure. Want to make the background turquoise? You also can :)
This text has line breaks, which will be wack if you try to wrap them. So, you MUST open it on a screen that is wide enough to show the whole line at a comfortable font size. This is not code. I should not have to struggle to read this shit on my phone (which surely counts as "any modern computer) when even the most rudimentary HTML would fix the problem.
> We do not create abstractions for abstraction's sake but to simplify our current task
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.
The point is that there are a lot of other things which easily become a problem if you do them by yourself instead of using known good implementations.
That's completely possible. I'm struggling with what I see as the internal inconsistencies. Do `X`, Do `NOT-X`, Do not `X`. All possible points of view seem to be there. Was that the point? I reread it and I'm still not clear about that.
Wait, so you can "dunk" on the authors of title article, but cannot be dunked on yourself?
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.
You're just name-calling; it's juvenile and unprovoked.
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.
I would just flag their comments and move on. Their behavior is clearly against the HN guidelines, and until they start getting downvoted, flagged, or have dang show up, I don't think that their attitude will change.
Nah I'm good, thanks anyway. I prefer to preserve the commenting culture by gently ridiculing people who don't get it. Downvotes and flags don't discourage nearly as well.
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.
This is a mix of amazing and really bad advice. And the problem with it is that it is a series of advices / philosophy instead of explanation.
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).
I find appropriations of the term "brutalist" strange in software contexts. In the architectural sense of brutalism wouldn't it mean limiting software construction to a single material (type,class,whatever) and leveraging that limitation to enhance other parts of the design (flow, modularity). In this way I think shell scripts are the most brutalist way of programming, ironically the author would probably agree.
> We never take a software methodology, school of programming or
some random internet dude's "manifesto" at face value. Rules
must be broken, when necessary.
In this specific case it seems particularly necessary. I don't think I will take this manifesto at face value.
As someone who strives for simplicity, some things from this resonate with me, but there are many others that are just bad advice or wishful thinking.
> 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 eschew all visual gimmicks, animations and eye-candy.
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.
If I'm so brutal and don't give a damn why do I care if I use every library under the sun?
Simple you say? Then I'm rewriting code some other poor sods have written 100 times, which sounds a lot like not-invented-here ornamentation to me.
They should rename this screed Arrogant Programming :P
Anyone who has to put up with Brutalist architecture in London (Hayward Gallery for example, or the NT, but there are many, many others) may think that being brutal to Brutalists is the only answer.
And anyone who’s been to the Brazilian federal capital, Brasília, may think that being nice and having admiration for brutalists is the appropriate answer!
It is a txt file, not a tiny ascii webpage.
If you can't read a txt file, that's more or less a you problem.
It's a hard-wrapped text file, which is objectively worse than simple HTML because there's no reliable way to reflow it for different screen sizes. You have to apply heuristics to guess if line breaks are semantic or not.
C'mon you really don't. Two newlines in a row isn't even a regex, let alone a heuristic.
Here's some Stack Overflow discussion showing why it's a non-trivial problem:
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's mail. Parsing mail is undecidable, this is known, it's an ancient format (I use that term in the loosest sense) and can only be handled on a best-effort basis.
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.
Your "existence proof" is no such thing; you simply moved the deleted information to the metadata by telling us which reconstruction algorithm to use.
They are serving a raw text file from the endpoint of an http server. In case you don't know what http stands for: Hypertext Transfer Protocol.
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.
> They are serving a raw text file from the endpoint of an http server. In case you don't know what http stands for: Hypertext Transfer Protocol.
???
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.
If you're using a http sever to serve plain text files you're doing internet wrong.
https://developer.mozilla.org/en-US/docs/Web/HTTP/MIME_types...
Not sure if wrong, but definitely gimmick instead of Brutalism.
It renders wrong in iPhone Safari because of the hard line breaks.
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.)
Hard line breaks aren't even technically right, though - they're obviously and completely wrong.
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.
> 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.
It's just a better alternative for pdf. At least on desktop. I can imagine that it is not that friendly on phones, that's why Apple is killing it deliberately.
A brutalist might now argue that rendering wrong in safari is obviously right.
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.
If your setup cannot properly show text which conforms to the 72 column rule, it represents the serious regression in display capability.
This should be a test case: can our browser, on our device, in portrait mode comfortably display 80 column monospaced pre formatted text.
This doesn't have anything to do with technical capabilities.
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.
No PDFs or books for you I guess.
Well yes, PDFs suck for the same reason.
> It renders wrong in iPhone Safari because of the hard line breaks.
If your device fails to display a 70-column text file, then your device is broken.
Immediately 60% of the devices most be broken.
Maybe so, but the fact remains.
It’s a very common format for large amounts of older information, almost anything online from prior to the mid-1990’s.
Fact remains but breaks manifesto:
'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.
Except for the title, the material stays well within the 72 column rule.
Your device cannot properly show text that can be easily read on a terminal from 1975.
This is a very bad argument. The 1975 terminal literally had about 72-80 physical columns, and you couldn't adjust the font, and most terminals were like this - these are the circumstances that enabled hard-wrapping and made picking a specific value (72/80) reasonable.
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.
My device is physically narrower than a terminal, so it doesn’t make sense to use the same width.
I can't think of anything more Brutalist than a text document formatted for an 80 column terminal like it's still the 1970s.
> Maybe like the original Brutalism, which was loved by architects and often hated by the people who had to spend time in the buildings
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.
If that word choice annoys you, I'm rather glad I chose it.
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.
The good thing about serving plaintext is that the reader can view it any way they want. Want to read it using text-to-speech? Sure. Want to replace the font with Comic Sans size 30? Sure. Want to make the background turquoise? You also can :)
I want text that wraps within a paragraph. Also all of that is extremely possible with HTML.
Plain text has text wrapping built in on any modern computer.
Line breaks don't play along with that though. You must represent each paragraph as one giant line, using two line breaks to separate paragraphs.
(The problem with that is that excessive line widths are bad.)
This text has line breaks, which will be wack if you try to wrap them. So, you MUST open it on a screen that is wide enough to show the whole line at a comfortable font size. This is not code. I should not have to struggle to read this shit on my phone (which surely counts as "any modern computer) when even the most rudimentary HTML would fix the problem.
> any way they want
Except for the line breaks.
It zooms in just fine for me? https://i.postimg.cc/PJpz8xBn/image.png
Try making your window skinnier.
> We do not create abstractions for abstraction's sake but to simplify our current task
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.
A strange straw man to pick a fight with, since the text agrees with you:
> Avoid cryptography, if possible, as you should write all the code yourself and doing your own cryptography is a well known mistake.
The point is that there are a lot of other things which easily become a problem if you do them by yourself instead of using known good implementations.
I think you might of missed the point of this one!
That's completely possible. I'm struggling with what I see as the internal inconsistencies. Do `X`, Do `NOT-X`, Do not `X`. All possible points of view seem to be there. Was that the point? I reread it and I'm still not clear about that.
It's not tiny, it's not any size.
If you have your browser configured to use a tiny font by default, that is entirely on you genius.
If you're going to miss the point this substantially, you should be a little more humble about it.
If you don't want to be called genius, don't say genius things.
Your compulsion to belittle strangers doesn't affect me one way or the other.
I do wonder why you don't feel embarrassed posting weak dunks like this under what is apparently your real name.
Wait, so you can "dunk" on the authors of title article, but cannot be dunked on yourself?
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.
You're just name-calling; it's juvenile and unprovoked.
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.
I would just flag their comments and move on. Their behavior is clearly against the HN guidelines, and until they start getting downvoted, flagged, or have dang show up, I don't think that their attitude will change.
Nah I'm good, thanks anyway. I prefer to preserve the commenting culture by gently ridiculing people who don't get it. Downvotes and flags don't discourage nearly as well.
Yeah, looks like they failed to apply the manifesto to the manifesto's website...
> IV. Do everything yourself
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.
Now I wonder if there is a way to make a webpage look like very nicely laid out HTML.
Well, other than "view source", you can set the CSS "before" and "after" properties of every tag to display the actual start and closing tags.
There is; the degree of complexity varies, from minimal[1], through less minimal[2], to very complex[3] and anything in between.
[1]: https://motherfuckingwebsite.com
[2]: http://bettermotherfuckingwebsite.com
[3]: https://getbootstrap.com/docs/5.0/examples/product/
I meant a way to make the tags visible without being too intrusive and ugly.
That's a cool idea; someone implemented that, also in the context of brutalism, here: https://startr.style/brutalism/
This is a mix of amazing and really bad advice. And the problem with it is that it is a series of advices / philosophy instead of explanation.
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).
ahem... XII. Do not listen to others
This can be read to support just any position about programming for which you want to advocate. It's not even internally consistent.
> 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.
> We do not use libraries, frameworks or third party packages << unless we are absolutely forced to do so. >>
Seriously, don't wrap with line breaks, whether it's a git commit message or a freaking blog post.
I find appropriations of the term "brutalist" strange in software contexts. In the architectural sense of brutalism wouldn't it mean limiting software construction to a single material (type,class,whatever) and leveraging that limitation to enhance other parts of the design (flow, modularity). In this way I think shell scripts are the most brutalist way of programming, ironically the author would probably agree.
> We never take a software methodology, school of programming or some random internet dude's "manifesto" at face value. Rules must be broken, when necessary.
In this specific case it seems particularly necessary. I don't think I will take this manifesto at face value.
No mention of coupling or cohesion: https://www.geeksforgeeks.org/software-engineering-coupling-...
As someone who strives for simplicity, some things from this resonate with me, but there are many others that are just bad advice or wishful thinking.
> 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"
They probably wrote their own spellchecker. QED.
> We eschew all visual gimmicks, animations and eye-candy.
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
If I'm so brutal and don't give a damn why do I care if I use every library under the sun? Simple you say? Then I'm rewriting code some other poor sods have written 100 times, which sounds a lot like not-invented-here ornamentation to me.
They should rename this screed Arrogant Programming :P
Anyone who has to put up with Brutalist architecture in London (Hayward Gallery for example, or the NT, but there are many, many others) may think that being brutal to Brutalists is the only answer.
And anyone who’s been to the Brazilian federal capital, Brasília, may think that being nice and having admiration for brutalists is the appropriate answer!
I think calling Brutalism a crime against humanity would not be an exaggeration.
Cool, so this is nonsense through and through. These are either obvious or downright weapons grade idiotic:
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.