bloblaw · HackerTrans

há 5 mesesdiscuss

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.

bloblaw

há 5 mesesdiscuss

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.

bloblaw

há 2 anosdiscuss

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.

bloblaw

há 2 anosdiscuss

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

bloblaw

há 2 anosdiscuss

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

bloblaw

há 2 anosdiscuss

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.

bloblaw

há 3 anosdiscuss

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

bloblaw

há 3 anosdiscuss

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.

bloblaw

há 3 anosdiscuss

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.

bloblaw

há 3 anosdiscuss

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.

bloblaw

há 3 anosdiscuss

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.

bloblaw

há 3 anosdiscuss

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.

bloblaw

há 3 anosdiscuss

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)

bloblaw

há 3 anosdiscuss

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.

bloblaw

há 3 anosdiscuss

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.

bloblaw

há 4 anosdiscuss

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

bloblaw

há 4 anosdiscuss

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/

bloblaw

há 4 anosdiscuss

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

bloblaw

há 4 anosdiscuss

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

bloblaw

há 4 anosdiscuss

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

comments