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

Why is Prettier rock solid?

mrmr.io

Post reply on HN
Print view View original

51–60 of 163 posts

Re: Why is Prettier rock solid?

#51

Post by bluSCALE4 »

treve wrote: post #43
bluSCALE4 wrote: post #23

The debate for me is now eslint —-fix or prettier. I don’t get why people need more “control”. If it breaks code, then sure, I understand the reservation but in 99% of cases, it just, “I don’t like how it breaks up my code”. Why care? At least, if you’re all using it, the diffs will be predictable and PRs can focus on what matters. //rant

I can't remember the last time PR comments addressed minor formatting issues at all, in any language. If something is hard to grok it usually has to do with logic, not if there's a space between `if` and `(`.

You're right, I more meant that if you don't format, your code sometimes becomes difficult to read and you become disincentivized to fix anything because git blame will point at you. I run into this all the time when people tell me, don't format the code because we won't know who did what. I get this even from senior devs as if using git blame and history is rocket science. If everyone stops bickering and just formats, all this noise goes away.

Re: Why is Prettier rock solid?

#52

Post by andrewstuart2 »

ramenmeal wrote: post #44

> note that gofmt doesn't indent, which is the hard part interesting because for me it's hard to read changelogs of js/ts based repos that are using prettier compared to go repos, I wonder if the indentation is a reason for that. I'm honestly not sure what the author means by that either, gofmt seems to fix indentation for me.

Yeah, gofmt does and always has fixed indentation (by tabs, thus avoiding another pointless conversation on teams using it).

Re: Why is Prettier rock solid?

#53

Post by chubot »

munificent wrote: post #24
sa46 wrote: post #16

Earlier quoted context omitted.

I suspect the author meant that gofmt doesn’t break lines, which dramatically simplifies the complexity. See https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr... for a fun, related read.

Yeah, line splitting is the hard part. I wrote that article and I'm actually in the middle of rewriting dartfmt right now to have an entirely new internal representation.

Oh I'm curious why you're rewriting it? Maybe speed, quality, handling new language features, or all of the above? I may dive into this problem

What do you think of the functional "pretty printing languages" like Wadler's (cited in the blog post)?

It is kinda interesting that the author of prettier credits the algorithm, but other people say that it's more about labor and testing of specific style rules.

Having never written a pretty printer, it does seem like there is a lot of labor in encoding the "rules people like", and flags for different styles. And then there's the actual algorithm to find the line breaks.

Or maybe they are not really separate things. I think the more academic work is trying to separate the 2 things, but they can be fairly intertwined? (e.g. for performance reasons)

Re: Why is Prettier rock solid?

#54

Post by withinboredom »

xrisk wrote: post #50
deepfriedrice wrote: post #29

Earlier quoted context omitted.

1.1k open issues. OOF

Is that because they don’t use a bot to auto-close issues like a lot of other projects?

That annoys the crap out of me. Closing stale issues doesn’t make the issues go away, it just means that edge cases aren’t addressed. If I have an issue and find myself in a stale-closed issue, I’m not even going to bother reporting it. I’m either going to look for a different library altogether, one that actually tries to solve edge cases; or I’m going to create my own library as a big middle-finger to the project. At work, I’ll just open a new issue, which will probably just be ignored.

Re: Why is Prettier rock solid?

#55

Post by chubot »

noam_k wrote: post #38
itishappy wrote: post #11

Earlier quoted context omitted.

I think prettier's initial author answered the question quite concisely in the article's first link. Title and excerpt copied below: > Dig into past research. > If you're excited about an idea, it's super tempting to sit down an immediately get going. But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely ch…

I can't agree more, and I can't disagree more. There's a great deal to be learned by experimenting yourself. My workflow is: * Learn the concept * Implement it * Research prior art * Throw away my first implementation and rewrite it properly (Edit: formatting)

Yeah I kinda think people are always "learning from their last mistake" (and that's definitely true for me)

- Sometimes you hack, and you end up with a mess. And then the lesson you learn is to study the prior art first.

- Sometimes you spin your wheels reading stuff that isn't actually applicable to the problem you have. Then the lesson learned is to "do the simplest thing that could work", "solve 80% of the problem with 20% of the effort", etc.

So to me, programming is really a cycle of learning, and you can't really generalize the order of doing things ... It's iterative stumbling and learning, in both orders :)

Re: Why is Prettier rock solid?

#56

Post by bowsamic »

mgraczyk wrote: post #47

Interestingly, prettier just made a breaking change in a patch release and refused to undo it for a week or so, until a particularly silly pedantic argument won them over. https://github.com/prettier/prettier/issues/15942 My only bad experience with prettier, besides the incredible slowness (orders of magnitude slower than ruff)

> until a particularly silly pedantic argument won them over.

Which comment are you referring to? The release notes sound practical

Re: Why is Prettier rock solid?

#57

Post by yard2010 »

noam_k wrote: post #38
itishappy wrote: post #11

Earlier quoted context omitted.

I think prettier's initial author answered the question quite concisely in the article's first link. Title and excerpt copied below: > Dig into past research. > If you're excited about an idea, it's super tempting to sit down an immediately get going. But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely ch…

I can't agree more, and I can't disagree more. There's a great deal to be learned by experimenting yourself. My workflow is: * Learn the concept * Implement it * Research prior art * Throw away my first implementation and rewrite it properly (Edit: formatting)

This is the way. Unfortunately this is not going to work, not in a startup environment. You probably do everything except the throwing away and re-implementing part..

Re: Why is Prettier rock solid?

#58

Post by rplnt »

richev wrote: post #21

Skimming past the capital "P", I read this as "why is prettier rock, solid" . . . and was left perplexed, as most rocks are solid.

Yeah, and some people intentionally do cause these types of confusions by using title case.

Re: Why is Prettier rock solid?

#59

Post by nindalf »

haburka wrote: post #9

This isn’t actually true. Prettier does break code in strange circumstances and it can be very difficult to fix. The maintainers have a ton of stress on them and it’s hard to improve it sometimes. It’s very well tested and easy to add cases too - just add an input and an output so that may be why it seems so solid, just whenever there is an issue people fix it. I think the main thing is that Meta maintains it which p…

Yeah I think having motivated and paid maintainers helps a lot. If maintaining the repo is the responsibility of a team that’s working 9 to 5, it’s much more likely that it’s going to succeed. Such a project avoids most of the pitfalls that are faced by individual open source developers coding in their spare time - lack of funding, appreciation, time, help etc. If one person in the team wants to move on, the company will find another person to take their place.

That’s possibly why React and Go and Prettier continue to flourish. While the maintainers have had a lot of hard technical problems to solve, they didn’t need to worry about making rent or burning their weekends triaging issues instead of spending time with family. Many of the original authors are no longer working on the projects, but they’ve been replaced by other Google and Meta employees. This had a bigger impact than basing Go on a paper written by a Haskeller.

All this to say - if you’re depending on open source you need to fund it directly. Dont expect that FAANG will forever, or there will be a magic wand like a research paper that makes it automatically easier to maintain.

Re: Why is Prettier rock solid?

#60

Post by 8n4vidtmkvmk »

noam_k wrote: post #38
itishappy wrote: post #11

Earlier quoted context omitted.

I think prettier's initial author answered the question quite concisely in the article's first link. Title and excerpt copied below: > Dig into past research. > If you're excited about an idea, it's super tempting to sit down an immediately get going. But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely ch…

I can't agree more, and I can't disagree more. There's a great deal to be learned by experimenting yourself. My workflow is: * Learn the concept * Implement it * Research prior art * Throw away my first implementation and rewrite it properly (Edit: formatting)

+1 I think there's something to be gained by just trying it your way first. Maybeyou'll come up with something new and insightful by not tainting your brain first, and if not, you will at least gain a deeper understanding of the problem space.
Post reply on HN