Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing one sentence per line

sive.rs

Post reply on HN
Print view View original

281–290 of 307 posts

Re: Writing one sentence per line

#281

Post by spartanatreyu »

hinkley wrote: post #239
luhn wrote: post #209

One big advantage not mentioned in the article particularly relevant to this audience: git diffs (or your VCS of choice). One sentence per line means diffs will operate per-sentence, rather than per-paragraph. This way the diff can capture the restructuring of the paragraph (adding/removing/replacing a sentence), which gives much more insight than swapping out the paragraph wholesale. It also means minor changes (e.g…

I think we need to start changing this. In an era of language servers, perhaps our diff tools should be semantic instead of line based. I get so tired of seeing diffs where I add a function and the diff shows that I added it inside the previous function instead of between them, because it starts the diff one line too early.

The problem with diffing goes further than most people think.

It's not a problem itself, it's a symptom of a deeper problem: we represent all of our code as plain text.

We have built almost everything around plain text, for a long time now. The few things that aren't built around plain text tend to require either proprietary software or open software that seldom lasts more than a decade.

Yes, plain text has impressive strengths (see: https://news.ycombinator.com/item?id=30521545) but it may be holding some areas back.

There has always been talk of smarter diffing tools (new diff algorithms, syntax aware diffing, semantic diffing) but it tends to get hamstrung around supporting plain text.

Usually the approaches go with one of two ways. Either:

1. a diffing algorithm has a smarter diffing algorithm than what we already have, until it gets into a corner case and ends up worse than what we already have.

2. an LSP-like service goes through the effort of building a full AST to perform diffs with, only to convert everything back to plain text in the end. This makes diffing take longer. The fact that ASTs can't represent some changes and we don't realize until after the work is done doesn't help this.

I'd wager that over the next few decades, new languages are going to migrate away from plain text representation and move entirely to AST representations. ASTs can be perfectly diffed, and only writing code as an AST means that it'll be impossible to write some kinds of code that is almost correct.

There's a few academic research languages around this, but I think one of the more interesting explorations with this kind of AST only development styles has to be by Dion Systems: https://dion.systems/blog_0001_hms2020.html

They basically acknowledge that we as developers are not going to move to a new AST-based tool if it's not going to work with our other tools, so they want to experiment across the development workflow to see how well ASTs can work across the development space.

Their 2020 talk about this was fascinating: https://vimeo.com/485177664

Re: Writing one sentence per line

#282

Post by ketzu »

fragmede wrote: post #190
ketzu wrote: post #7

Earlier quoted context omitted.

> diffs make way more sense when there is only one sentence per line I did the same thing for some time for papers at university for the same reason. It used to annoy me, because I hate to change for my tools, I rather have my tools support my workflow: There should be a nicer diff for that.

There is! If you're using Git, you can do git diff --word-diff to enable word mode, which is computationally more expensive, but computing power is cheap these days. There's also an "ignore whitespace" mode ( -w ), though that doesn't play well with Python.

Thank you, that's a nice feature. I hope I won't forget it until I need it again.

Re: Writing one sentence per line

#283

Post by MrDunham »

SamBam wrote: post #131
MrDunham wrote: post #75

Earlier quoted context omitted.

Here’s my biggest critique of Enso: It’s not very easy to send myself a reminder when I’m back at my computer to use it. Content: i’m currently on my mobile phone and I absolutely adore the idea of Enso (funny enough I’m currently holding & feeding my infant named Enzo). I would like to write with it and try it when I don’t have an infant on my lap but that requires me remembering it and looking it up when back on my…

You want a sign-up on the site that just sends you an email and tells you to use it? You could also just send yourself an email, you know. Or, if you're fancy, use a to-do list that you can access both on your mobile and your computer. (To be fair, I recall the brain-fog that comes with having an infant.)

It's a user experience thing. Too often product designers (myself especially) think that a user should remember/do an action/etc. However, I believe most failures are design failures VS user errors and that a better designed system could/should strive to fix them.

So, yes, I could use a Todo list or some other solution to remind myself. But that inherently assumes this rises to the level of neurally important... which trying out a new tool rarely is.

That's why I offered a marketing/growth idea to better help passers-by remember to try it out in a super clean UX way that integrates with their workflow.

Re: Writing one sentence per line

#284

Post by MrDunham »

rpastuszak wrote: post #117
MrDunham wrote: post #75

Earlier quoted context omitted.

Here’s my biggest critique of Enso: It’s not very easy to send myself a reminder when I’m back at my computer to use it. Content: i’m currently on my mobile phone and I absolutely adore the idea of Enso (funny enough I’m currently holding & feeding my infant named Enzo). I would like to write with it and try it when I don’t have an infant on my lap but that requires me remembering it and looking it up when back on my…

> remind me via email to give Enso a try I like this. Thanks! Email notifications nowadays are a bit of a pain to set up, since they need to contain the physical address of the sender in the footer, so this is a piece of work I _always_ keep postponing. I was even considering dropping that form completely. Maybe I could generate a calendar event with a reminder instead? This way I won't have to store any data about t…

Go get convertkit. It's bloody awesome, cheap, and they even have an address of their own that you can use if you don’t wqnt to share your physical address.

The sequenced auto responders that they have boost my open and click rates as much as 300% and allow for some truly powerful/complex programmatic features that anyone who's on HN would love.

Re: Writing one sentence per line

#286

Post by iainctduncan »

3qz wrote: post #147

This is awful. It’s the LinkedIn writing style and I can’t look at it without being reminded of all the shitposting that “thought readers” do. Thoughts?

Did you even read to the second paragraph of the article??? He says specifically in the source... not the render.

Re: Writing one sentence per line

#287

Post by iainctduncan »

Am I the only one thinking this thread should be immortalized as the ultimate example of how poorly HN readers read things before shit-posting about articles? Sigh.

A) He says in the SOURCE not the published, in literally the third paragraph. B) Count the damned sentences in the first handful of paragraphs. 2,3,3,1,4. He's clearly not saying you should do the stupid one paragraph per sentence nonsense in the published article.

This is a great idea for those of us who like writing prose in vim. Will adopt!

Re: Writing one sentence per line

#288

Post by ivansavz »

luhn wrote: post #209

One big advantage not mentioned in the article particularly relevant to this audience: git diffs (or your VCS of choice). One sentence per line means diffs will operate per-sentence, rather than per-paragraph. This way the diff can capture the restructuring of the paragraph (adding/removing/replacing a sentence), which gives much more insight than swapping out the paragraph wholesale. It also means minor changes (e.g…

RE diff: you should try `git diff --color-words` it's very good for diffing text (output is similar to output of latexdiff: red = word removed, blue = word added)

Re: Writing one sentence per line

#289

Post by michaelmior »

_tom_ wrote: post #280
michaelmior wrote: post #43

Earlier quoted context omitted.

This would require accurately detecting the end of the sentence which is not an easy thing to do correctly consistently.

No, but NLP toolkits like opennlp already do this quite well.

Fair point, but I still prefer the solution of just putting in a new line myself. Then I don't have to worry about maintaining such a script, setting up the git hook, etc.

Re: Writing one sentence per line

#290

Post by HKH2 »

fknorangesite wrote: post #255
HKH2 wrote: post #222

Earlier quoted context omitted.

What difference does it make? They are multiples of five. Are they okay to him? I doubt that is so. He dislikes chunks of five. He was not prescribing semicolons. That would still bother him.

I think you might be missing the forest for the trees, here. It's not about five-word sentences; it's about the repetition making the paragraph as a whole monotonous and robotic - something you demonstrated very well in this very comment.

The OP primed you to read it robotically. I'll admit my sentences seem somewhat contrived though.

I was delighted when I first read the short, punchy, and somewhat dislocated clauses of The Stranger by Camus. Actually, a more pertinent example is the first page or so of Molloy by Samuel Beckett. Maybe the reader is supposed to be bored; I find it refreshing.

Post reply on HN