Hacker News Reader

Comment by mpalmer | Hacker News Reader

    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

Brutalism 0, Problems 1

View on HN

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 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.)

> 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.

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.

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.

This is one of the reasons that PDFs are bad (in addition to forced pagination, which is spiritually similar to hard line wraps) and I prefer to read things in HTML or ePUB (HTML with glasses and a fake mustache) instead. See a previous comment by mine about ArXiV defaulting to PDF renders of papers[1].

[1] https://news.ycombinator.com/item?id=41481309

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.

> 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.

> It breaks poems

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.

> Which shouldn't be hard-wrapped in the first place

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.

> you mean having a fixed-style

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.

I see. Then what I wrote, still stands, that is:

>> 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.

Oh, I misunderstood - you're right, "not wrapping"/"scrolling" is indeed the right option in this case. I forgot that that was an option. My apologies!

My device is physically narrower than a terminal, so it doesn’t make sense to use the same width.

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.

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.

> 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.

> How else are you going to write a poem, or an address, in a text file?

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.

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.

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.

As far as I am able to parse it, this sentence is meaningless.

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

It's plain text. "Plain text" does not impose any restrictions on formatting. Was the poem two lines or three?

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.

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.

Not sure if wrong, but definitely gimmick instead of Brutalism.

https://developer.mozilla.org/en-US/docs/Web/HTTP/MIME_types...

    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 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 :)

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.)

Thank goodness if you don't have hard line breaks you can choose your preferred line length yourself.

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.

I want text that wraps within a paragraph. Also all of that is extremely possible with HTML.

> 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.

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.

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.

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...

Reply on news.ycombinator.com