dmitriid

> So I think "as far as the 70s" is fairly misleading

As far as the 70s refers to efforts to create whiter and more reflective paint.

> EU has just decided that this half billion of consumers will be downgraded to the third world standard of living (google "Fit for 55")

"Fit for 55 is a package by the European Union designed to reduce the European Union's greenhouse gas emissions by 55% by 2030."

I call bullshit on your statement.

You'd be surprised.

Efficiency is rarely about how many steps it takes to get there.

And even taking into account all the steps that you call inefficient, ICE cars are still 20-50% cheaper to buy. And with electricity prices what they are ICE cars are probably the same, or even cheaper, to run.

No. It was just a reflection if what these fines are, and why they come about.

Strange how you don't seem to realize that all these "ideas for fines" come years or decades after the "efficient and self-regulating free market" ends up what it will always end up: entrenched monopolies, moats, little competition and high barriers of entry.

> You'll end up without any sort of cohesive art style and you'll have random variations in quality level.

Oh look: exactly the result with AI tools.

Did you miss the point where the author went through multiple variations, had to construct intricate prompts and do quite a lot of manual work for the end result to be half-decent?

> Total cost of ownership is reduced significantly with BEVs

Is it? With the electricity prices what they are and sparse infrastructure I doubt BEVs have a lower cost of ownership. At least in Europe.

> oil infrastructure is obviously way less efficient

Not sure it's obvious. If anything, oil infra has been optimized to be as cost effective as possible. Remember Deepwater Horizon? They were extracting oil from 10 km under water still at competitive prices.

BEVs are unaffordable pretty much everywhere (if there are no government subsidies).

Every single BEV model seems to be 20-50% more expensive than its ICE counterpart. And the "cheap" ones are something like Renault Tweezy, useless to most people.

More than that, Polestar is a Volvo.

I've run into weird situations where either curl or wget wouldn't be installed by default, so I use... whatever :)

But usually curl.

Still no name or this mysterious better client.

And what happens when I need something more, or something else? I need to find a different "better client"?

> It's just one HTTP client.

curl supports 28 transfer protocols [1]

> There are better ones.

curl has 60 language bindings, runs on 89 operating systems across 24 CPU architectures [1]

So what is that mythical better client (that only does HTTP)?

[1] https://daniel.haxx.se/blog/2022/11/25/89-operating-systems

> I didn't get why fewer lines of code is better.

There have been a few studies showing that bugs-per-line-of-code is pretty consistent from language to language. So, if you can reduce the number of lines needed, you reduce the number of bugs.

There are also surely diminishing returns

Also known as Crossing the Chasm: https://bootcamp.uxdesign.cc/book-summary-crossing-the-chasm...

> All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms.

Of course it will.

If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost.

Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top.

Boom. You're operating close to the speed of light.

You had a trash can/bin/bucket at home and you'd empty it into a dumpster or garbage chute.

> Note how you don't have to strain your pinky to hit ctrl for any of these?

Note how insanely context-dependent all these are? How it's completely different commands for what is essentially the same operation?

Keys can be remapped (I have CapsLock mapped to Ctrl).

Those who relied on anything were decimated in the bubble of 2001.

Also, you're pretending that all of those sites were making a profit, or operated under the assumption of making a profit. There was a lot of money thrown at any and all internet companies by the end of 1990s. It's just that the market was much smaller.

> Ah, so we're arguing in bad faith.

Yes and no. My very first reply pointed out exactly what I found incredible in your story.

If we're sticking to anecdotal data, over 22 years as a programmer I've never seen those amazing feats of vim voodoo you're talking about.

> But then, I'd guess from your tone that this won't stop you from misreading another comment of mine and accusing me of lying

Really? Misreading? Go and read mu very first comment, will you?

> But only some of that was paid by ads.

Ah yes. They were paid by altruists who had the foresight to know that 30 years later they will be able to track everyone and collect their dues.

> If you're talking about language integration, I've got no quarrel with that

I am. Because we are talking about these mythical Java programmers who couldn't do something that Vim would have done in seconds

> I won't beleive your assertion, however, that this invalidates the benefits of learning Vim bindings

And the reason to learn them is because there's a fairy tale of some programmers not doing the job that we're led to believe could be solved in seconds in vim.

> If you're talking about normal minute-to-minute text handling and creation of text files

Are we? Let me remind you: "I have quite some anecdotes about e.g. creating integration tests where my colleagues wouldn't test something properly just because doing so would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro."

Oh look. We're literally talking about programming.

> we're at the point where I have trouble believing you.

Let's start with your fairy-tales before we come to believing or disbelieving what I wrote.

> But I've had enough of these conversations that I can assure you that this low a bar is needed for some people to skip important jobs. If your doubt applies to the usefulness of knowing the system

No. My doubt extends to "omg vim is so amazing that these tedious tasks take seconds unlike in these primitive text editors".

Because my experience at work has been consistently the exact opposite: vim users routinely take longer time for most tasks precisely because it's a rather primitive text editor, and not a code assist tool.

> would involve 10 minutes of drudge work in their simplistic editors, instead opting for "deploy & pray" when the task was totally doable in a couple of seconds with a Vim macro.

I really very much doubt this. Sounds like an application of rose-tinted glasses and wishful thinking to some one-off task that then is extrapolated to all tasks.

> It's clearly more conducive to solving problems to be able to move around our environment more quickly.

Then vim ain't it.

My "vim-empowered" colleagues spend significantly more time trying to find symbols, related configs and tests, function definitions and interface implementations than I do. Because their hodge-podge collection of vim plugins and extensions rarely amounts to anything more than a full-text search across the whole project.

But sure, you can count the number of lines where you need to go and then the number of characters/words you need to move in the line and code it in 3 characters. By the time you've done that I've clicked there with the mouse, found the definitions and done project-wide refactoring.

> Everything is much more fun when it's paid by someone else, that's why the old web was so nice.

What are you talking about? The old web was filled with ads. They just weren't tracking you every nanosecond of your life.

Google's AdWords was launched in 2000. DoubleClick that Google acquired in 2008 was launched in 1995. Ad exchanges are from 1998. And so on https://en.wikipedia.org/wiki/Timeline_of_online_advertising

All of the browser vendors are supportive, all had initial prototypes etc.

Speculation: The spec is still a Working Draft aka: comments welcome from anyone, may drastically change. Chrome already intends to ship soon. It's quite possible that Chrome is rushing ahead as usual even though the spec hasn't been fully finalized.

His speech is not worth the paper it was written on.

Calling out one obvious lie: "It is not our plan to occupy the Ukrainian territory. We do not intend to impose anything on anyone by force."

In September Russia "held" a "referendum" in occupied territories and immediately adjusted the Constitution to include the occupied territories.

So how is it different from Tailwind?

Every design system I've come across contains any combination of:

- rigid inflexible components that need complex overrides even for the simplest cases

- multiple classes with seemingly innocuous names like "col col-8" that get increasingly obtuse and one-off like "uxg-menu-header uxg-avatar-hero-block uxg-avatar" [1] or "fas fa-fw fa-bell pf-c-alert pf-m-info pf-c-alert__title" [2]

- multiple often contradicting css variables (esp. colors)

- ... i'm missing something else, but it's late here and my brain doesn't work ...

[1] Design system by some new age finance company: https://design.fusionfabric.cloud/components/app-bar?tab=dev

[2] Opensource design system by RedHat https://www.patternfly.org/v4/components/alert/html

> However, if you're using HTML without a JS framework, Tailwind can be superior to BEM and global styles, but still not as much as CSS modules, CSS-in-TS, and the like, due to maintainability concerns.

How are you going to maintain consistent values across components such as spacing colors etc? Those tend to grow to the size of Tailwind

> we now (almost) have the technology to build personal assistants that actually work

That parenthetical "almost" is doing an awful lot of heavy lifting.