I agree there's a difference between publishing code under an OSS license and actively maintaining a project while fielding the flood of low-quality AI issues and PRs. Someone in the latter category is obviously closer to that pain.

I still wouldn't go so far as to dismiss Carmack's view on that basis alone, though. It just means his experience is less representative of maintainers dealing with that specific problem every day.

I break down what you said as: "Sure, he's released code with an open-source license, but that's not real open source in the sense that matters."

I happen to disagree. OSS is OSS. AGPL is OSS. MIT is Open Source. Unlicense is OSS.

A. Delphi --- easy choice (or C++ Builder if I had to use C++) B. Also Delphi --- it supports macOS (arm64 + x64), Linux, and Windows

If I have to write a CLI app, I'm probably picking Go or Rust.

https://github.com/dwarvesf/hidden

  brew install --cask hiddenbar

But here's a cool thing - in coding interviews for non-SWE roles (I'm in security), when they say 'pick any language', I go straight for Perl. Why? Because it's very forgiving when prototyping a solution quickly, has great data-structures without a lot of setup (auto-vivification!), built in grep and map features, etc.

Well, not actually. With Anders' move to Microsoft, VB6 (aka, VB "classic") was discontinued. Microsoft supported Visual Basic syntax on the .NET runtime, but the vast majority of VB programmers considered this to be a different language because developing for the .NET Framework (remember this is ~2001) was a huge departure from VB Classic.

Many VB developers petitioned Microsoft to open-source VB6 or continue releasing improvements on it. Microsoft did not and chose to continue with their .NET + C# strategy.

The VCL component library in Delphi is still unmatched in native code – very comprehensive built-in (and commercial) components, and customizable. Plus, Delphi's database connectivity was unparalleled and can be setup in the designer where you could see data queried and returned live in your grid component!

Delphi also supported advanced language capabilities (when compared to VB), like inline assembly and pointers, which were essential for low-level optimization or system hacking. The robust error handling in Delphi was another plus compared to VB's older 'On Error' style.

Folks dealing with mental health issues might end their lives for a variety of factors. This is very sad to hear, but the headline (and article) that attempts to connect an employer to a person's death without any evidence is unfair.

Note: I do not work for Google.

My commentary is on the company culture and focus on sales over quality. I just don’t think this is a company that knows how to organically innovate or integrate purchased innovation…and I think that makes them vulnerable to being overtaken by a competitor that solves the same business problems in a different way than they do now.

They’ll be around for decades. Just like many other formerly innovative companies hang around for a long time.

They are not now, and never have been, and engineering focused company. The creation of the Salesforce platform itself is (or was) based entirely on Oracle tech...and it was SOLD extremely well because it solved business problems.

Salesforce has failed to innovate outside of releasing the CRM as a SaaS product back in 1999...which is why they have bought innovation, and then integrated it poorly...see Heroku, Slack, Mulesoft, Tableau, Quip, Demandware, ExactTarget, etc.

https://www.forbes.com/sites/patrickmoorhead/2019/06/18/sale...

I worked there for a short bit. Most frustrating experience of my career. It was the epitome of rest and vest well before COVID.

Extreme lack of urgency, little attention to quality, and a huge focus on sales and marketing.

Salesforce will print money for a few more years until someone makes a less awful CRM solution and just crushes their business...so long as Salesforce can't buy that company, integrate it badly, and disillusion all the employees that made it great.

  NumPy 
  pandas 
  Matplotlib 
  TensorFlow 
  PyTorch  

And with Edge being "basically chrome", and supporting Chrome plugins, the switching cost from Chrome -> Edge is quite small.

But for mobile, Android + iOS dominate...so that all goes to Google.

I think this could mean that Bing + ChatGPT has a really opportunity to beat Google in Search...it's gonna be hard, but I've never even considered them more than a distant 2nd option until now.

Yes, you are starting to see the problem. This is why I recommend statically compiled binaries as a solution to this scenario, and do not recommend any of the above.

Here's a real scenario I've had in my career, when deploying a script to 350k systems. I know I have Python 3.x, but I cannot count on the fact that every (or most) clients will have even a functioning Python interpreter. So what's the solution? Ship a docker container to everyone? There are multiple ways to solve it, but I complied a statically linked binary instead of writing a Python script...and had no issues.

> If you need dependencies, specify and install them.

Here be dragons, and this is the entire reason I avoid Python when I need my code to 100% work on another machine I can't fully control. I choose statically compiled languages in these instances. In a server deployment...sure it's fine because I can control that.

> Python 3 is completely backwards compatible in my experience

I do not agree. If you write a script that uses any of the following features and try to run on $version -1 (or more), your script will fail.

  * 3.6, F-strings were introduced  
  * 3.7, Dataclasses and introduced 
  * 3.8, Walrus operator (:=) 
  * 3.9, merge (|) and update (|=) operators added to the built-in dict class
  * 3.10, structural pattern matching
  * 3.11, exception Groups and except*¶ 

Maybe you'll say to just install a new version of Python. All that is overhead and requires more management. Ok, that's fair.

The problem is when you want to run that script on a bastion host, or a prod server, 350k machines, or a server you don't have ability to download and install external binaries? (all of these are real scenario's I've experienced).

My experience has taught me that if I can't control the machine the script runs on, I save headaches by using statically compiled languages. As always, YMMV.

I mean the Python ecosystem is such that now I have to "package" up this script to potentially tell the user with Python 3.6 that they need to download a new interpreter version (eg 3.9) to run my application (and any dependencies). This puts all the pain of running a script on every user that wants to run it.

I've said it before, but Python requires users to replicate the developers environment...and somehow this is fine?!? Statically compiled languages (eg Go, Nim, Rust, C/C++, Obj-Pascal, D, etc) ship binaries...that just run.

Obligatory xkcd: https://xkcd.com/1987/

Huh? This has a strong "No, it's the children who are wrong" vibe.

But to be more fair to your point, I think this is a dismissal of the OP concern's. A troubled ecosystem should be concerning to the Python community as a whole because it threatens future adoption if not addressed.

User's don't want a troubled ecosystem and will find languages that avoid these problems...and Go, Nim, and to smaller extent Zig, Rust, D are strong alternatives for the different workloads currently provided by Python tooling.

Python has a good moat with both ML and mind-share of developers...but at one time Perl had a similar moat...

ack

> I’m saying that avoiding Python because of it is illogical (to me) because the problems they’re describing aren’t unique to Python, and I don’t think there’s much that doesn’t suffer from it.

I don't completely agree, but I see your point. Any interpreted language (or non-statically linked binaries) could (and does) suffer from these problems. I'd like to see Python have a better packaging story...but for now we live with shipping the developers environment (via docker or virtualenv) for running complex Python applications and services.

I will say that *statically linked* compiled languages are able to avoid many of these problems because running these binaries typically only requires the OS (eg, Go, Nim, Rust, Zig, C/C++ when statically linked, Object-Pascal, etc)

> Perl is going 5->7 because 6 was such a disastrous break.

Agree. And they did the right thing by actually renaming it Raku and skipping the version release.

I'm old enough to have read this when it came out...and it changed my view on backwards compatability (from Joel Spolsky of Trello, FogBugz, and StackOverflow fame)

"Code doesn't rust": https://www.joelonsoftware.com/2000/04/06/things-you-should-...

If a company has production Python2 application / service (with hundreds of thousands of LOC), what business value does it bring to migrate it to Python3?

At that point, if you've got to make severe changes, folks might decide to use a language that doesn't impose breaking changes (and business cost) on them. YMMV.