bloblaw

That framing makes more sense to me.

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.

This sounds to me like the "No True Scotsman" argument. https://en.wikipedia.org/wiki/No_true_Scotsman

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.

I presume we are talking about GUI programs:

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.

That article is from 2011. I can imagine that in 13 years this may no longer be true.

The open-source Hidden Bar is my current solution to this problem, but I think I prefer this native fix.

https://github.com/dwarvesf/hidden

  brew install --cask hiddenbar

Perl's still got a special place in my heart, but honestly, I don't use it much these days. I mainly bring it out when I'm processing a lot of text or writing scripts to be used by Perl-savvy teammates.

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.

> After Heilsberg moved to MS, a lot of improvements were made in VB that utlimately made Delphi less attractive

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.

Having worked with both Delphi and Visual Basic, I've found that Delphi had the edge, especially for professional apps. Its use of Object Pascal meant you got compiled, efficient code right out of the box, and it didn't need an extra runtime like VB.

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.

Without an understanding of their motive, I think tying "google" to a person's mental health crisis is clickbait.

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.

THIS!! A high-quality cross-platform GUI toolkit that can be built using Delphi's RAD designer would be a huge hit in the market, IMHO. There is literally nothing that does this now.

This is true, I did not use the platform as a user. I know it solves business problems and theyve built a big moat.

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.

Salesforce is a sales and marketing company that was founded (and is led) by a brilliant sales and marketing person in Marc Benioff.

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.

The number of them isn't as relevant as their usage. Lots of data science related modules are effectively wrappers around C code. Here's a few:

  NumPy 
  pandas 
  Matplotlib 
  TensorFlow 
  PyTorch  

These modules are critical to many of the workloads using Python (ML / AI / Data Science)

Similar statements have been made about most dominant technology when it was in its infancy. You are not wrong, but it can quickly go from novelty to necessity once folks start to rely on it.

All good points. Windows still very much dominates desktops / laptops sold (especially large corp environments)...so the default installed Edge browser + Bing is a significant share of users.

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.

> Good luck running a jar built with JDK19 on JRE8, or an executable linked against glibc2.36 on Ubuntu 18, or a Python file written for Python 3.10 on a system that comes with Python 3.6.

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*¶ 

All use of these will fail to function in a previous release.

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.

But what if you just write a Python3 script and want to run it? Not a full blown application, but just a script.

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/

> Take some ownership of your problems, even if the ecosystem provides them -- they are chosen, and can be managed.

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...

> I’m not trying to dispute whether it’s a problem. I agree it’s a problem.

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 have no time for whinging snowflakes complaining 12 years (2020-2008) was not enough time to migrate their code to Python 3. Hell, even the original 7 years (2015-2008) should have been long enough for 99.999999% of the community.

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.

Yes, but *which* Python3? Are you getting one with f-strings support? Because if you aren't, now you've got to install that.

How about one with dataclasses support? Again, you get to install a new interpreter everywhere.

Python packaging continues to be a sore spot for the language.

> Tons of other languages have version requirements as part of their end user experience.

That does not dispute the original claim though. It's still a problem for Python even when other languages have the same problem.

> or Perl language versions being breaking

Perl 5.0 code written in 1999 will still happily run in 2023. In part due to the fact that breaking changes are *opt-in* within a Perl script.

Reference: https://www.perl.com/article/announcing-perl-7/

"""Perl 7.0 is going to be v5.32 but with different, saner, more modern defaults. [..] Perl 5 still has Perl 5’s extreme backward compatibility behavior, but Perl 7 gets modern practice with minimal historical baggage. """

Honestly, Perl is an example of extreme backwards compatibility that has the user experience at the forefront of their design decisions.

"rant"? Is that what a criticism of a technology that you like is called?

I feel your response is best summarized as: "I like Python. I've never had this problem and don't think it's a legitimate problem. Only $megacorp users have this issue, and their concerns aren't important."

If you dismiss the problem (as you've done) then you don't have to intellectually address it. The Python 2 -> 3 transition was hard for those that huge productive workloads in Python2, and this pain will have a long tail.

Eevee also dismissed with this argument as well in the same article: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

> Do not tell me that Facebook and Wikipedia are built in PHP. I’m aware! They could also be written in Brainfuck, but as long as there are smart enough people wrangling the things, they can overcome problems with the platform. For all we know, development time could be halved or doubled if these products were written in some other language; this data point alone means nothing.

FTA: > Otherwise, the only thing that matters is that the tool works. Every tool comes with its own upsides and downsides, but most of them are increasingly the same. They mostly differ in workflow. But I can promise you: they all draw rectangles equally as well. If you can accomplish your work with the tool, then it serves its purpose.

Eevee dismissed with that argument succinctly when they wrote in their "PHP: a fractal of bad design" article:

> Do not tell me that “good developers can write good code in any language”, or bad developers blah blah. That doesn’t mean anything. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best.

That last sentence drives the point home.

BSD grep vs GNU grep has burned me enough times that when I do anything moderately complex in a bash script, I quickly move to Perl. And since Perl is installed most everywhere (or can be bundled up easily with PAR::Packer), it's an easy decision for me.

> If you don’t (need to) care about Unicode, maybe

Perl has had strong unicode support since Perl v5.12 (~2010).

references: 1. http://xahlee.info/perl/perl_unicode.html 2. https://stackoverflow.com/a/6163129/12458

> If you think pythons package management is not disastrous enough, maybe.

Huh? I've used PAR::Packer with great success since 2005.

> If you do not (need to) consider Windows, maybe.

Microsoft used to ship Perl scripts to work with COM and WMI with their NT4 and Windows 2000 resource kits. Perl works *extremely* well with Windows.

I mean, there are lots of reasons to choose Python over Perl, but IMHO, these are not those reasons.

I use Perl as a better-bash. If I was writing a modern website, a large application, or any ML related work...I'd choose Python. But for complex system administration, I'm picking Perl. YMMV

Here's Google's stance on why they ban AGPL software: https://opensource.google/documentation/reference/using/agpl...

> The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license.

> This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed.

> Because Google's core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube), the consequences of an engineer accidentally depending on AGPL for one of these services are so great that we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner.

FWIW, every company I've ever worked at bans AGPL products / code.

You can easily remove the RTTI info from your binary: https://stackoverflow.com/a/3975363/12458

When I statically compile a C++ or Go binary, I end up with something I can copy and execute on any platform for which it was compiled for.

Single file. Copy and run.

Virtualenvs require every single target to reproduce your dev environment:

(1) have internet access and able to reach pypi (or artifactory, or whatever you use).

(2) the ability to install the required version of Python if it isn't already installed. That's another 30mb download.

Ever want to run a complex Python script on a bastion host or a host behind a bastion? Well now #1 and #2 above won't work (or haven't in my direct experience working for some of the big cloud companies). So you have to use something like PyInstaller and hope it works. It might. It might not. A statically compiled C++ binary or Go binary probably will.

This thread is full of pain points in python package management. The first step is admitting there is a problem. I don't think you've experienced the pain caused by Python package managers that others outline in this thread.