Some developers can see adding layer upon layer when developing software as bad. However, this essay gives examples of how these kinds of "bloated" solutions can be more efficient than more direct ones with fewer layers of abstraction. This is why I liked it, it seems a bit counterintuitive, but it makes sense.
> Shortly after, the tides changed and we were all using spaces.
Very interesting. Thanks for sharing this information! What do you think might have caused this though?
> Who cares about grep?
I do care. I find it much easier to work with a codebase that has logs and error messages that can be easily searched. Similarly, working on a blog with searchable text makes more sense to me. Before switching to soft-wrapping, I used hard-wrapping, and sometimes I would notice a typo or an issue in one of the essays. When I tried to quickly search for a nearby word, it wouldn’t find it because the text had been hard-wrapped. I think it also makes it far easier for outsiders to navigate a repo which they are not familiar with.
Can you detail a bit more what you mean by extraneous material? Is it something like "you now also need tools that can do soft-wrapping"? Even if that's the case, I think it is easier to wrap a text than to unwrap it (programmatically). So, if you need hard-wrapping, you can just do it.
Wrapping is just as simple as; `fold -s -w 80 input.txt`
Unwrapping usually turns out to be harder according to my experiences. [1]
> You also can't grep for things "at the beginning of the line", which is often an important indicator. When I did a lot of plain C programming, I would put function names at the start of a line, below their return type to make it easy to grep for a function definition, rather than just uses.
I see what you mean. But I don’t think your approach conflicts with my recommendation for soft-wrapping. You can still soft-wrap regular text files while choosing to separate certain lines of code for clarity. What you’re doing might not even be considered "hard-wrapping" in the typical sense—it's not like you're breaking a 240-character line into multiple lines. You're simply formatting the definition in a way that suits your style, and it's perfectly ok!
For the last one, you can simply use `git diff --word-diff`. Also, platforms like GitHub already highlight word-based diffs, so it usually is very easy to spot the changes.
Extraneous material in my example would be potentially the rest of a large paragraph if I change one word. The example would be the diffs of a "Word" doc: the whole paragraph shows as a diff. Folding after the "git diff" would just mean visually picking the diff out of a lot of text.
I do a lot of Go programming these days, and there's a conventional format for code that ends up with a lot of hard wrapped lines, so my C example is just that, an example.
Maybe Markdown would be a better example. When I edit markdown, I move around phrases, clauses and sentences. It's certainly possible to do this with a gigantic soft wrapped chunk of text, but it's much easier with one clause or even phrase per hard wrapped (at 74 characters or less) line. Grepability and diffability and even running text through sed or awk are easier. You're not relying on text coloring. Editing with vim is easier, it has commands to move the cursor to next word, previous paragraph etc etc.
This is one of those things like tabs or spaces and byte order marks. We're unlikely to convince each other.
That doesn't sound like soft or hard wrapping, though, that sounds like semantic wrapping, which is a separate concept entirely. With semantic wrapping you put each sentence (or similar) on a new line, which helps with diffing. But if that sentence runs over e.g. 80 characters, you still need to decide whether you're going to hard wrap or soft wrap that sentence. And in the inverse direction, if you don't do semantic wrapping, you'll have similar issues with diffs regardless of whether you use hard wraps or soft wraps.
So I think that's a good argument for doing semantic wrapping of code and text (I guess semantic wrapping for code is just not writing everything in one long line separated by semicolons), but once you've put in semantic line breaks, you still need to decide how to handle text that spans multiple lines.
> This is a sentence that includes the word "Lopadotemachoselachogaleokranioleipsanodrimhypotrimmatosilphiokarabomelitokatakechymenokichlepikossyphophattoperisteralektryonoptekephalliokigklopeleiolagoiosiraiobaphetraganopterygon" in it.
> How should it be wrapped semantically?
This is a psychological case to demonstrate how semantic wrapping does not by itself solve the "hard vs soft" wrapping question. If the answer is that the word should remain as a single word, then you are using soft wraps (or no wraps at all). If the answer is that the word should be split into 80 character chunks, then you're using hard wraps.
I have no idea what the semantics of that word are, which is information that is required in order to properly semantically wrap it. (Inherently, since conveying such semantics is one of the major pointer of semantic wrapping.)
However, you included embedded control characters (C2 AD aka 'SOFT HYPHEN'; below replaced with '-') that encode less semantic information than is necessary for proper semantic wrapping, but not none:
The fact that you included soft hyphens rather concedes the point that hard and soft[0] wrapping is incorrect[1].
0: Or rather, non-semantic, which is what we're actually arguing over. Technically, semantic wrapping is a subset of hard wrapping, but it's a specific subset that isn't what is expressed by just saying "hard wrapping". Kind of like how birds aren't what anyone means when they just say "dinosaurs".
1: Granted, to be fair, a lot of the time we just don't care. But (contra your original comment) we never need to resort to non-semantic wrapping; we just sometimes (often) decide to be lazy because it doesn't matter.
I think this a valid approach to semantic wrapping, but I don't think this is the only one, and specifically I think it has significant flaws: (1) We've lost grepability unless I write rather complex regexes to handle the possible places where hard line breaks may have been added. (2) We've lost diffability in the sense that if I correct a typo in the word, that correction can cascade through the word and cause multiple lines to show up as changed in the diff when semantically only one part of one word has changed.
Instead, I would prefer a soft semantic wrap: if a single semantic unit (be that a word, a clause, or whatever else) extends beyond, say, 80 characters, we keep it on the same line and let the editor/file viewer handle wrapping. This means that we maintain grepability over words and semantically-connected phrases, and we maintain diffability by avoiding the hard-wrap cascade. To me, this is a much more useful version of semantic wrapping, because it only wraps when there is a semantic clause, and not on any arbitrary semantic break.
My goal here isn't to convince you that this version is better than your version of semantic wrapping, only that wrapping based on semantics is an orthogonal concept to hard and soft wrapping, and that even if we choose to take a semantic wrapping approach, we still need to decide what to do with particularly long lines.
(Although I will add to this: I had a colleague who was a deep fan of semantic wrapping, and I just never really got it. I used it for a couple of years, but I've never run into issues with simply soft-wrapping everything. When inserting new clauses or changing text in the middle of a line, every diff tool that I've used has been able to accurately identify which portion of a given paragraph has changed and highlight it. Meanwhile, as a writer and reader, I need to put more effort into reading prose that is written in an odd, stylised format that is very different from the intended paragraph structure. I can see the argument that I've accepted semantic line breaks in code or configuration files, so I should be able to handle it in markdown, but I just find it harder to read and more irritating to write. But assuming someone does want to use semantic line breaks, I still believe that that's an orthogonal choice to deciding between hard and soft wrapping.)
> if a single semantic unit (be that a word, a clause, or whatever else) extends beyond, say, 80 characters, we keep it on the same line and let the editor/file viewer handle wrapping.
...the editor can't do that because it doesn't understand the semantics.
> that wrapping based on semantics is an orthogonal concept to hard and soft wrapping
Yes, that's why I've been saying "hard and/or soft [but in either case nonsemantic] wrapping".
> > > With semantic wrapping you put each sentence (or similar) on a new line [...] But if that sentence runs over e.g. 80 characters, [then...]
... You don't need to fall back on non-semantic wrapping, you can just just keep breaking it up into smaller and smaller semantically-meaningful pieces.
(You have to do that 'hard'-ly because the editor doesn't understand the semantics, but that's not "decid[ing] whether you're going to hard wrap or soft wrap", it's being forced to hard wrap as a implementation detail because that's what results in correct wrapping.)
It might not be worth the effort to do that, but you're never forced not to (given not-pathologically-short line length limits like 20 characters).
Hmm, I think we have different definitions of a semantic line wrap. To me, semantic line breaks means that line breaks are used to separate clauses and sentences, such that at least every sentence is on its own line, and every line break represents a semantic clause or sentence gap.
To you, I get the impression that semantic wraps are about ensuring that every wrap/line break happens at a semantically valid place, where semantically valid could be a semantically valid clause, but also a semantically valid intra-word line break.
In that sense, I can see how your strategy would produce the same effects as hard wrapping, albeit with different choices about where to put the wraps. But I think then, like I said, you end up running into the same difficulties that you do with conventional hard wrapping, at least in pathological cases.
> such that at least every sentence is on its own line
Yes, with the obvious possible exception of trivial/degenerate cases like "i++; j--;" in C or "This is a cat. That is a dog." in English.
> and every line break represents a semantic clause or sentence gap.
Specifically, it represents a maximally coarse semantic gap, drilling as shallowly down into subclauses as possible/practical.
> wrap/line break [can happen at ...] also a semantically valid intra-word line break.
Preferably only if that word would already be alone on its overly-long line. Eg:
# bad, breaks subordinate clause before superordinate
That sounds supercalifragilistic-
expialidocious.
# semantically valid, but ugly (a pathological case)
That sounds
supercalifragilisticexpialidocious.
# vertically larger, but probably fine
# (unless you're feeling incunabulum-y[0])
That sounds
supercalifragilistic-
expialidocious.
> you end up running into the same difficulties that you do with conventional hard wrapping, at least in pathological cases.
I've yet to see any evidence that really pathological cases exist. (As opposed to "I'm lazy and can't be arsed" cases, which I'm fairly explicitly not disputing.)
I have experience in both backend and frontend development, mainly in fintech but not limited to it.
I've primarily used JavaScript and am well-versed in popular frameworks and libraries like React, Fastify, and Lodash. Have also used other mainstream programming languages (Python, Java, C++, and C) for both recreational activities and university projects in the past.
PostgreSQL has been my go-to database, but I've also worked with Redis, MongoDB, LevelDB, and Prometheus for various projects.
I have experience with sysadmin and DevOps tools, including Linux/Unix, Bash scripting, Git, Docker, and Nix.
I’m a passionate developer who enjoys learning and building new products. Feel free to reach out if interested in collaborating!
Yeah, the experimentation being cheap is one of the reasons why it attracted me as well. The ability to rollback once you mess up things gives such a comfort :)
Liked the 'high potential energy' analogy but I think it misses a point. As far as I know, your Nix knowledge and home-manager configurations are transferrable to MacOS and other Linux distros as well.
> I'd rather beat my head against a wall for a day figuring out how to configure something than get locked into an OS-specific configuration that I can't move elsewhere.
Many people use Nix and home-manager on their MacOS or non-NixOS Linux setups. You can use Nix package manager without committing yourself to the constraints of NixOS.
> You are telling me I have to do things the "NixOS way" but also your documentation is bad / inferior? Absolutely no thanks.
Don't know about others but I don't tell you that for sure. I think poor documentation is among the most understandable reasons to NOT use Nix.
In the end, I am just trying out things to see whether they benefit me or not. Not here to sell you anything.
I recently helped my friend install his first Linux distro, Ubuntu. He told me he could not log in, and he kept getting back to the login page. I realized that he might be having problems related to his display manager installed by default. I made him go to virtual console and replace the default display manager so that he can start his desktop environment session without getting stuck in a display manager loop.
I did not like my own Ubuntu experience when I was using few years before as well. I don't think its stable enough for newcomers as well.
