“Inception” is frequently misunderstood to mean entering other people’s dreams or having multiple layers of dreams.

In the movie, they of course have the technology to do these things, but it’s usually used for “extraction”: stealing information and ideas from one’s subconscious by infiltrating their dreams.

“Inception”, as used in the movie, is just the opposite of “extraction”: to plant an idea in someone’s subconscious by infiltrating their dreams.

So while I think it’s a stretch, it’s not as bad as suggesting that people can commingle in dreams.

If I know that an entity goes to great lengths to conceal secrets, why would I ever believe I know of their most secret secret?

Interestingly, “highlights” is not there.

“More quinoa”

A commuter typically takes a free public bus ride to work. The bus broke down this morning. The commuter had to go out of their way to take a different bus to get to work. Wouldn’t it have been better if they stayed and fixed the first bus?

I get the proverb but you have to admit that it's kind of a big deal that a tree-shaker bundler optimizer has a pretty big glaring known broken issue with it where it doesn't bundle.

The bus gets fixed eventually. This doesn't (unless somebody fixes it).

I don't think the bus will get fixed unless somebody fixes it either.

It’s exhausting because: _____

If you find yourself struggling to articulate it, seriously and honestly consider whether you’re simply choosing to be stressed about it.

I’m speaking from experience here.

I’m sure they could, I imagine they’re appealing to those who prefer JSX’s syntax.

Yeah that's right, I was trying to simulate JSX syntax. I'm not against ERB syntax tho, maybe the lib could eventually support both?

yeah doing a call_html_erb method would be fantastic

This is definitely solely an HN Replies thing.

This is the first time I've seen it in my HN Replies, but I have seen "* * *" before on https://news.ycombinator.com/. I even saw another comment asking about this type of comment.

Do you have any HN-related extensions installed?

Edit: I truly did not believe you, but it appears to maybe be the “delay” feature [0]. Users with a delay set might show the asterisks until the delay passes.

My apologies.

0: https://news.ycombinator.com/item?id=231024

I’ll criticize it.

I recognize this is a preview and I desperately hope this implementation isn’t kept around and treated as a quirk.

This implementation is extremely unintuitive given their explanation of the expected behavior of CSS Nesting and the & symbol.

To quote:

    The & signals to the browser “this is where I want the selector from outside this nest to go”.

Their explanation and the actual implementation result in a majorly different CSS selector.

The implemented functionality, however useful, makes no sense as a default if one can explicitly use :is to achieve this behavior like below.

    .foo .bar {
        .baz :is(&) {
        }
    }

The default should behave like they claim it does; simply replace & with the “outside” selector.

With this hidden :is behavior, migrating to native CSS nesting from SASS will be extremely difficult.

There’s plenty of things that are done in code that we don’t adopt in prose and vice versa. You could just as easily make the case for adopting underscores in place of spaces in prose to increase readability, but we haven’t done that.

In code, you have to balance readability in many contexts.

Snake case and kebab case look more readable in isolation, but do they look better when used as part of a larger expression, for example part of a chain of member access and method calls and argument passing? I don’t think the answer is obvious, and it probably depends on other formatting affordances (e.g. breaking the expression up on multiple lines).

I’m on mobile and I don’t trust HN’s formatting to do any justice with examples, but it might be worth trying it out in your code editor.

It'sSimplyNotVeryNaturalToReadTextWhereCapitalLettersTakeThePlaceOfSpaces,AndThereIsThe"NASAIs"ProblemToo.

In_most_fonts,_the_underscore_character_is_visually_like_a_space,_and_you_can_distinguish_"NASA_is"_and_Mike_vs_mike.

I’m specifically saying that prose/text and code are different contexts that don’t necessarily benefit from the same styles of writing.

What I was saying is that just because spaces in prose naturally improves visibility does not _necessarily_ mean that underscores and dashes improve overall readability across many contexts _in real code_, because code and prose are different. It could be the case, but it’s not the obvious innate property people are suggesting it is.

If it such an obvious innate improvement in readability, then why don’t we replace spaces with underscores in prose and handwriting? It would remove any ambiguity between intentional separation and awkward unintentional spacing or kerning. But we don’t and haven’t done that for some reason, so there must be something else at play.

Your examples (and many examples in this thread) of long sentences in these formats are not what code actually look like.

Real code has meaningful symbols and syntax that occur between identifiers that carry semantic meaning. Maybe the lack of symbols in identifiers in camel and pascal case make it easier to identify these other symbols and syntactic elements, so you end up with better overall readability. Maybe adding to that the flexibility of using camel and pascal and upper snake case for different "types" of identifiers improves mental mapping of code concepts that you'd lose if you always used snake case.

Again, I'm only making the argument that readability in code and readability in prose are two totally different things, and the effects of different casing and different identifier naming schemes are likely more subtle than what is better clearly separating words in the identifier.

Is it not natural or are you just unpracticed at it?