Video games, like cinema, footballs, the olympic games or music, are a huge market, and have strong influence on culture.

In fact, given they now employ people from all the other entertainment industries, and make recurring payments, product placements, and build communities, I'd say they are pretty huge.

This is almost a point in favor of having Microsoft ruin the market.

If we consider that media/marketing driven entertainment is a negative externality, having bad games would cause people to do entertainment that is more akin to their personal interests.

More outdoor time, more reading time, less playing the latest IP from a studio that spent millions on commercials to make an addicting game.

> If we consider that media/marketing driven entertainment is a negative externality

I guess that's the difference here. Most people do not consider this a negative, it gives them more options. You're fooling yourself if you think people would prefer to ditch AAA games and just have obscure indie titles.

Oracle enters the chat.

And don't forget their new IDE in the cloud move with VSCode.

I guarantee once they got enough devs locked in their cloud to write softwares, the spanking will start.

And once again, the victims will act all surprised.

Everyone cheers VSCode, but I'm happy with Spyder now that it has VIM.

Maybe its time to fork VSCode seriously if people want to use it forever.

Already done: https://github.com/VSCodium/vscodium

I prefer VSCodium builds over proprietary Microsoft ones any day of the week, but:

   > This is not a fork. This is a repository of scripts to automatically build Microsoft's vscode repository into freely-licensed binaries with a community-driven default configuration

This is the correct way to go about it imho. A real hard fork would inevitably fall behind upstream and the project will eventually be abandoned.

Theia[1] is a bit closer to a hard fork. They even try very hard to avoid saying outright they're just a rebranded VS Code, using euphemism such as "Theia embraces many of the design decisions [of VS Code] and even directly supports VS Code extensions."

1. https://theia-ide.org/

There's nothing wrong with that. VSCode will certainly have a lot more development that a fork would ever see. So the best thing to do here is simply build VSCode with all proprietary stuff removed.

The plugins are the real value, and those are built behind the M$ fortress.

Clangd and rust-analyzer plugins aren't made by MS. Python has a couple separate ones, one of which the official Microsoft plugin uses. I think the only language needing a MS plugin is TypeScript, which is a MS language anyway.

For anyone else who hadn’t heard of Spyder: https://www.spyder-ide.org/

Yes, but the quote use the word "truth", not "hypotheses".

The real kicker is that they are already assuming they are right, which is definitely over the top :)

Well at least it keeps them motivated, and it keeps readers engaged.

> the quote use the word "truth", not "hypotheses"

All truth starts as a hypothesis, but not all hypotheses turn into truth.

They're using the quote to say, "Hey, maybe they're ridiculing us, but look at Einstein!"

That's... what I'm saying?

It was that "Yes, but" there /s

This is what motivates them, give them exposure and likely financing. It's good for moral, and for marketing.

If they eventually draw extraordinary conclusions from this, there will be hundreds of scientists to double check it, just out of curiosity, precisely because they had this stance.

All in all, it will be a win-win.

GPRD doesn't target just cookies, but tracking in general, which must be known and consented.

So basically what OP says is that most sites are just not following the European laws.

Thank you! I find people repeating the "GDPR is stupid because there are other ways to track than using cookies" thing all the time and it's so frustrating. Misinformed comments like that usually end up at the very top of discussions like this.

It's hard to convince someone when their livelihood depends on not understanding.

While I appreciate VSCode, I think Discord, Slack and Obsidian are not selling the platform at all. They feel sluggish and have poor ergonomics. Now the second one may or may not be attributed to Electron depending of if you buy the cultural thinggy, but the first one clearly is. Mumble is super reactive in comparison to them, and most note softwares dance around Obsidian.

Having a latency on local clicks and transitions is not my idea of fun.

VSCode is an outlier here. And it's getting slower and slower with age, while sublime text is getting faster.

It's probably a generational thing.

The 20 last years, the web, the animations and the badly coded apps lead people to be used to slow software.

However, when you have used software for decades on much less powerful hardware, the sluggishness of all of it is kinda jarring.

This is true for me, as well. Whenever I start a 50 MHz computer and something is instantaneous instead of displaying a "Please wait…", or I start a modern computer with the Haiku operating system instead of Windows or Linux, I'm reminded just how responsive things can be.

On Android, I stumbled upon a file explorer, called Little File Explorer, that feels like this. It's 170 KiB, and generally opens directories without a feeling of transition. Instead of feeling like it's laboriously building a view, it feels almost like the view's already built. Alas, it doesn't yet remember scroll position when paging back.

Modern things can make stuff that would be slow, fast; but they also usually make stuff that can be fast, slow. I believe this normalisation of slowness is a "Normalisation of Deviance".

Open sublime text side by side, and it will be obvious.

Well sublime is amazing, and trying to build an Obsidian equivalent in Sublime would be astronomical work.

For what it is, Obsidian is very impressive.

The author should rather be honest and say "I like TCL just because", instead of coming up with contrived examples to state alternatives are bad.

E.G, in the Counter snippet, why make some complicated code when Python is designed to make it simple?

    import sys, collections

    for p in sys.argv[1:]:
        try:
            with open(p) as f:
                for k, v in collections.Counter(f).items():
                    if v > 1:
                        print(v, "\t", k, end="")
        except Exception as e:
            print("dup error: ", e)

I don't buy the argument of simplicity here. Also, if you are going to just do "get", you don't need requests, the stdlib is fine.

And I don't get the speed argument either, given his script uses most_common(), that basically sorts the entire dict, which none of the other codes do. Yes Python is likely slower, but let's not push it.

Also the Go code is more complicated, but you can cross compile it and ship it as is. And it's fast.

I get it, TCL is cute, but making up arguments is not selling it.

Yeah—as a TCL fan, I agree. Comparing implementations of common coding tasks with other languages doesn’t highlight TCL’s strengths or, really, its purpose.

Personally, TCL fits a niche like QBASIC did. QBASIC was the shortest path from brain -> code drawing on a monitor. Literally 1 line to draw a shape, no initialization and not even an entry point function.

TCL similarly lets you just get on with what you’re doing when you need glue code, GUI’s, and DSL’s. It is easily (even trivially) able to do things that are just a pain in other languages, especially all at once:

- interop with native code (no limits on who calls who or in what order)

- define GUI’s that behave well without it being a huge pain to make anything non-trivial (lookin at you, UE5)

- create novel control flow that feels built-in

- implement an interactive GUI debugger with breakpoints & variable watch in ~200 LOC (saw this once, it’s amazing what you get “for free”)

- save or load a running program’s entire state, including code defined at runtime

- detour any function, allowing you to optimize or patch on the fly

- run from tiny, standalone executables so your users don’t have to install a ton of crap just to run your widget

There’s more but you get the idea. It’s been around for decades for a reason :)

That's actually a much better sale pitch than the article.

TXR Lisp:

  (each ((file *args*))
    (catch
      (dohash (k v [group-reduce (hash) identity (op succ @1)
                                 (file-get-lines file)
                                 0])
        (put-line `@v\t@k`))
      (error (e)
        (put-line e *stderr*))))

The author, while having a passing familiarity with it obviously, is clearly not a Python expert, so take all the Python stuff with a major grain of salt. Like they claim not to know how to get granular exceptions out of the requests modules:

>The requests here is a third-party package that required installation and a virtual environment to use. I don't know how to catch more granular exceptions in this example.

so I guess they even didn't RTFM:

https://requests.readthedocs.io/en/latest/api/#exceptions

The "take command-line input and print it out" in Python is even more succinctly written:

  import sys
  print(*sys.argv[1:])

So, like context managers in Python, except you only have `__exit__` and not `__enter__`.

What's missing from the article is the semantics when there is an error. In Python, `__exit__` is always called (with the exception as param), but depending of if you return True or False, you reraise or not the exception.

Anyway, it's a useful addition.

While you can craft an API with this behavior in JS by accepting two callbacks, it's nice to have a standardized way to do it. Plus making it an official feature will encourage the pattern, which nurture the culture for better API.

Same conclusions.

And children, dogs, birds, metal plaques...

So many things out of your control, so just assume the worst, all the time if you want to survive.

Motorbikes are just dangerous, that's it.

Another thing I'd add: say no to ridding under the rain.

Don't buy a better suit, better tires, adapt your schedule and run slowly.

Just don't use it.

There is nothing in the world you can do that will make it much safer. It's a death trap. Bite the bullet, and use something else.

But who am I kidding, young me would have read that comment, say "mehhh", and just ride the storm anyway :)

I was riding a rented bike through the Coromandel outside Auckland one day on holidays many years ago, with my girlfriend on the back. Loads of nice wide curves and mountain climbs. I’m not a particularly aggressive driver but the road was clear and I was certainly fanging it from time to time.

Towards the end of the trip, the roads were mostly downhill. It’s easy to go too fast for the corners, so I back off a bit, but am still having fun.

We passed a sign saying “caution, winding road”. Great!

Then a minute or so later, we passed a sign saying “warning: falling rocks”. Ok.

Another minute and we passed a sign saying “slippery when wet”. Well it’s not raining so I’m good.

Then less than a minute later it started raining, seemingly out of nowhere.

I sat up straight in my seat, dialled the throttle back and decided the rest of the ride would be entirely defensive.

$DIETY had given me enough warnings for one day.

My Grandfather lost a leg to a motorcycle accident in 1944/1945. He was riding the while line past a military convoy in the UK as a dispatch rider when unfortunately he met someone doing the same in the opposite direction.

He had a succession of prosthetic legs, the technology was always improving but one thing he said never changed: The clinics were always full of lads in their late teens. Year after year.

> Motorbikes are just dangerous, that's it.

I would extend that to anything with two wheels at a speed of 30km/h+.

A while ago I restored my bicycle after years of it gathering dust in the cellar and now that I'm older and more aware of risks I see how much I have to think ahead to not run over anyone.

At certain, low from a car driver's standpoint, speeds a bicycle will just go straight unless of course you decide to slide.

Indeed, but strangely 2 wheels is the sweet spot for fun as well.

Such a hard choice.

The friction coefficients in rain aren’t bad if you’re riding at posted speeds, outside of solid metal and painted lines. It’s riding right after it starts raining that you want to avoid - all of the oils which drip from vehicles get displaced by the initial deluge, and that is slippery stuff.

First, that's a lot of if, second, that's not nearly all the if, and finally, there are a lot of if about things that are not you.

> “…say no to ridding under the rain.”

I use my moto for Moto camping upstate New York. I plan my trips to avoid storms, but they happen never the less. And I love my super banana suit. It keeps me comfortable while I’m trying to hold my $#!t together out on the highway.

I grew up in CA and every year people go nuts with the first rains. Lots of accidents. Same happens here—especially the spring and early summer rains. People lose their minds and forget how to drive.

Slow down. Increase following distance. And if you’re on a moto, watch for manhole covers, leaves, road markings which can be slick.

And not running your tires to slick helps, too.

Wind can also be a nightmare. When riding on a highway in Spain, south of Barcelona I was sure I was going to die cause the wind just blew me all over the place.