The problem is that for the vast majority of use, LLM output is not revised or edited, and very many times I'm convinced the output wasn't even fully read.
I assume FrustratedMonky's comment was satirical, given that it appears to have been written like an LLM and starts with a "but, but, but" which is how you might represent someone you disagree with presenting their argument.
Joke is, it was GPT 4o. I didn't phrase it to be like an LLM, I asked GPT to defend itself, and used it's text un-edited. Except adding the 'but but but"
There is a lot out there that people are no longer able to determine if it is an LLM. They are getting better. That they are no longer obvious is the scary part.
Ah, I've never really been able to discern. There is obvious LLM text, but it's harder to tell the difference in short samples, and with some prompting to get it to write in a particular style, it's been easy to make LLM output non-obvious for a while now.
I agree with you, and I'll put it slightly stronger. Ruby is a better language than Python in every way except the very most important two:
- Imports in Ruby seriously suck compared to Python. Everything requires into a global scope and an ecosystem like bundler which encourages centralizing all imports for your entire codebase into one file.
- Python has docstrings encouraging in code documentation.
Add common ecosystem things like the Ruby community encouraging generated methods, magical "do what I mean" parameters, and REPL poke-driven development, and this leads to the effect that Python codebases are almost always well documented and easy to understand. You can tell where every symbol comes from, and you can usually find a documentation entry for every single method. It's not uncommon for a Ruby library, even a popular one, to be documented solely through a scattering of sparsely-explained examples with literally no real API documentation. Inheriting a long-lived Ruby project can be a serious ordeal just to discover where all the code that's running is running, why it's running, where things are preloaded into a builtin class, and with Rails and Railties, a Gem can auto insert behavior and Middleware just by existing, without ever being explicitly mentioned in any code or configs other than the Gemfile. It's an absolute headache.
My dream language would be Ruby with Python-style imports and docstrings.
I think your comment needs to mention that Python has syntax for type annotations and two mature type checkers (mypy and pyright) with more under development. Python is thus very much part of the modern statically typed languages scene (moreso than Go) whereas Ruby isn't at all. Many people wouldn't touch Python today if it weren't for this.
I’ve never quite understood how this works. Surely a type system is absolutely fundamental to a language - how can you have multiple incompatible ones?
Do you need to choose a particular type checker for each project? Are you limited to only using third-party libraries that use the same type checker?
I think Python was successful because it started off without a type system and you can still choose not to use it. Duck typing is the big feature really.
It might float your boat to think about types but why would everyone have to want the same thing?
Look at JavaScript and typescript - Python’s typing is maybe halfway to that gold standard but there were other typed languages based on js. Python is special in that it provides type hinting syntax which is not used by the interpreter, so writing types doesn’t require the Byzantine build systems of js.
Hard agree on the global Ruby import issues. I remember inspecting large custom Rails or Capistrano codebases in pry and having thousands of names imported. That and monkey patching had me wishing for Python with imports only having module scope and being a lot more explicit.
It's a shame Python has a strong anti-FP stance with crippled lambdas. And an OO system that looks like it has been bolted in, compared to Ruby which is essentially a Smalltalk with Perl-like syntax and some Lisp influence.
These two issues would have been quite easy to fix and would have led to a completely different development experience. Python had a good implementation with a nice C FFI (CPython) right from the beginning, whereas Ruby MRI had lots of efficiency issues with long-running computations. IMHO this is one of the reasons why Python won. Building a numerics stack on top of MRI did not look very promising.
> an OO system that looks like it has been bolted in, compared to Ruby
I think the two languages just have different design philosophies. In Python, functions are fundamental and classes are built on top of them. In Ruby, objects are fundamental and functions (i.e. Procs etc) are themselves objects.
You could just as well claim that in Ruby, functions look like they have been bolted in. For example, you can’t call a Proc itself but need to call one of its methods.
I agree. Python was designed in 1989 and it looks like the OOP we were doing in C (without the ++) back at the time. Objects were a struct with data and function pointers and we were passing them around as pointers. Python has self, explicit in function definition and implicit in function calls, and that self is really like the pointer to the struct. By the way, OO languages from the 90s (e.g. Java and Ruby) were designed to always hide that self, both in method definition and method call. They use it when there is a need to tell the difference between instance attributes and local variables with the same name.
Maybe the explicit self was there to make C programmers feel at home. Functions as fundamental building blocks of the language also make C programmers feel at home. Developers got more familiar with OOP by mid 90s so the new languages could jump from functions-first to objects-first.
I think Python's OO is a bit suboptimal even if the goal was to have method-centric OOP like in C with classes. For example, mechanisms to hide information, a fundamental part of the OO paradigm, are hacky. You need to use name mangling.
Same applies to FP, a few things are weird and crippled. IMHO, the net result is that Python code tends to look longer and much more algorithmic than in Ruby, Smalltalk or various Lisps, where the language favors lots of little functions that call each other.
Things are changing a bit, though. For example, pattern matching (PEP 622) brings some conciseness. Fixing those other issues would be great.
I think they would have to here, to support native modules. Jython (and I believe IronPython, but don't quote me) does not support native CPython modules. CPython modules explicitly control the GIL, so if they are supported (as they are here), you can't really leave the GIL out without exposing potential thread safety issues.
Eh, it's still a numbers game. Changing your chances of contracting terminal cancer in the next 5 years from 1% to 0.5% is still significant.
In this case, the specific percentages are all the significance. When a lot of the factors are controllable and a lot of them are uncontrollable, the most reasonable question is "How much do the controllable factors actually change the odds?"
> Changing your chances of contracting terminal cancer in the next 5 years from 1% to 0.5% is still significant.
Short of quitting smoking, there's almost no way to do that, because you don't know what the factors are or how they're weighed & influenced by individual genetic, immune, and metabolic factors.
> "How much do the controllable factors actually change the odds?"
Not only does nobody know, nobody has the foggiest notion. I've never seen a relevant population-wide observational study that wasn't so full of methodological flaws that you could spend hours picking apart its defects.
Of course we know that there's a set of factors associated with the development of cancer -- like, e.g., long-term exposure to polonium in drinking water -- but there's also a large set of factors that nobody is aware of or which can never be controlled for. To use only the first set -- the set of what we know and can control for -- to accurately estimate the odds of contracting cancer within the next five years is impossible.
We can and do, all the time. And all puzzles are a "waste of resources", really.
I'm not into crypto and I do think Bitcoin is stupid and wasteful, but I don't find it "sick" or all what upsetting that this kind of puzzle exists, though I think some smart contract-based Ethereum puzzles could be much more interesting, demanding solutions to more interesting problems that don't directly relate to the blockchain itself. Imagine a smart contract with a pot anybody can pay into that pays out to whoever could crack a particular previously unsolvable problem. Basically a public bounty. The only downside is that it has to be a problem that can be validated algorithmically.
The point is that many (maybe most) of us didn't even realize that "soup" was part of the company's name. I always assumed something like "Campbell's Chicken Noodle Soup" was by the company "Campbell" or "Campbell's". Nobody calls it "Campbell's Soup Company Chicken Noodle Soup".
> Killing copyright because you dont like Microsoft would equally kill things like Free Software (because it would invalidate the freedoms enforced by the GPL.)
Without copyright, the GPL wouldn't need to exist because the freedoms it protects would be impossible to suppress.
I'm not sure I see how that's true. The GPL puts a legal onus on modifiers to publish their modifications to the source with distributions of the software. Without copyright, any other party might be legally entitled to use and redistribute said modifications, but the modifier wouldn't be compelled to publish them.
That's not really the problem the GPL is intended to fight against. The source code can usually somehow be recovered via decompiling. But that's illegal in the presence of copyright, and even reverse engineering is a legal minefield further encumbered by patents.
> source code can usually somehow be recovered via decompiling
Absent IP, ceteris paribus, you'd run as much code as possible on your servers and obfuscate what you deliver to a client. There would be an entire industry in producing technical DRM.
That's what the AGPL is designed to cover, and I think it's a major reason why a lot of software nowadays runs in the cloud. This is already a common way to circumvent the GPL.
Obfuscation only gets you so far. But faithfully recovering the original source code is not really the point. Even heavily obfuscated code is useful and can be worked with since in the end the program is still doing what it's supposed to do.
Ok, so why is are GPL licenses so popular compared to BSD and MIT licenses? Why did the GNU foundation even bother writing a license at all?
Those other licenses do not require republishing, so it seems that authors of OSS value the additional republication requirements provided by the GPL license. Even in under the current copyright regime, one can (perhaps other-than-legally) decompile binary to recover source-like code, and then launder and reinject the learned improvements back into the open source project.
And the GPL license does not universally grant patent rights back to the source project.
The primary difference between GPL and OSS (BSD, MIT et al) is one of philosophy.
The FSF believes that closed-source software should not exist at all. Their license is explicitly designed to make it completely incompatible with closed source software. Updates to the license (GPLv3, AGPL etc) are specifically designed to close loopholes which closed-source companies were exploiting.
OSS by contrast sees Open Source as a public good, but lives in a world that tolerates closed-source entities. It's possible to use an MIT licensed gzip library in a closed-source program, with GPL you cannot.
OSS says "Open Source us better, but closed Source is better than nothing." The FSF says "it should be Free, or you should not use it at all."
Both OSS and Free licenses mandate that users should be able to build binaries from Source. If I make a change to the gzip library then my users are entitled to those changes. (There's no "giving back", only giving forward.)
It absolutely is a problem intended to be addressed by the GPL. That's why it is specified in the GPL that the source code means the code in its preferred form for making changes.
The idea is that without copyright there is no benefit in keeping the source code secret. It justs makes it a little bit harder for the customer to recover it. The GPL is ultimately intended to be customer-friendly, therefore sharing source code together with the build system is preferred.
It's still a form of proprietary lock-in similar to not offering data export, but it's not an unsurmountable hurdle anymore.
> The idea is that without copyright there is no benefit in keeping the source code secret.
Why not? You can decompile a cookie to try to see what method was used to make it, but Nabisco or whoever still treats that method and the ingredient ratios as trade secrets. In fact, the whole idea of trade secrets are things that are kept secret because IP protections don't cover them.
That's not really comparable; by reverse-engineering a cookie one would have to fight against entropy. The issue with software is that it's magnitudes easier to figure out any trade secrets inside of it. Reverse-engineering LLMs is much more akin to the cookie example.
> Computer people adopted a term in use for more than half a century and brought it into the digital world. The wording in the Harvard log book—“first actual case of a bug being found”—suggests the computer programmers and engineers there were already quite familiar with the time-honored usage and were remarking on the novelty of finding an actual insect bugging up the computer. “Debug,” by the way, was also used in an 1945 issue of the Journal of the Royal Aeronautical Society, which Shapiro takes to suggest it was “probably preceded by several years of oral use in engineering slang.”
