Intuitive function names like __new__() and __init__()? Or id() and pickle.dumps()?
The accessibility of Python is overrated. It's a language with warts and issues just like the others. Also the lack of static typing is a real hindrance (yes I know about mypy).
> Intuitive function names like __new__() and __init__()? Or id() and pickle.dumps()?
I use python for some basic scripting and I don't write anything huge. Most of these do roughly what I would expect.
> __new__ is a static method that’s responsible for creating and returning a new instance (object) of the class. It takes the class as its first argument followed by additional arguments.
> In Python, __init__ is an instance method that initializes a newly created instance (object). It takes the object as its first argument followed by additional arguments
> Python id() function returns the “identity” of the object. The identity of an object is an integer, which is guaranteed to be unique and constant for this object during its lifetime.
The pickel.dumps() is the only one that is a bit odd until to find out what the pickle module does.
> The accessibility of Python is overrated.
The accessibility isn't overrated. Python has something that is missing from a lot of languages that isn't often talked about. It is really good a RAD (Rapid Application Development). You can quickly put something together that works reasonably well, it also is enough of the proper language that you can build bigger things in it.
> It's a language with warts and issues just like the others.
>The difference between new and init is not knowable from reading their names. The same is true of pickle. By definition, that makes them unintuitive.
By that standard nothing is. At some point if you are using a programming language you are going to have to RTFM. None of things you cherry-picked would be used by a novice either.
Even the pickle.dumps() example is obvious when you read the description for the module and works exactly the same to json.dumps(), which works similarly to dumps() methods and terminology in other programming languages.
I feel like I am repeating myself.
> A lot of languages work for RAD including Clojure, C#, and JavaScript. This is nothing special about Python.
Nonsense. None of those I would say are RAD. JavaScript literally has no standard lib and requires node/npm these days and that can be a complete rigmarole in itself. C# these relies heavily on DI. I have no idea about Clojure so won't comment.
All the RAD stuff in C# and JS is heavily reliant on third party scripts and templates, that have all sorts of annoying quirks and bloat your codebase. That isn't the case with Python at all
R.E. scaffolding in C#, with upcoming .NET 10, it's really simple:
- Write code to myfile.cs
- `dotnet run myfile.cs`
That doesn't need scaffolding either. And the standard library is huge too; you could even add dependencies in that file.
And since we're talking about RAD, Python can't even compare to Clojure. Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.
> R.E. scaffolding in C#, with upcoming .NET 10, it's really simple: - Write code to myfile.cs - `dotnet run myfile.cs`
> That doesn't need scaffolding either. And the standard library is huge too; you could even add dependencies in that file.
I've just had a quick look at some of this and they've basically just moved stuff in to the cs file from the proj file. I remember them saying this was on the roadmap when I was doing a .NET 8 refresher.
// app.cs
#:package Humanizer@2.*
using Humanizer;
It also seems anything non-trivial will still require proj files. Which means that they are likely to still have project templates etc.
> And since we're talking about RAD, Python can't even compare to Clojure.
I am unlikely to ever use Clojure, I certainly won't be able to use it at work.
> Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.
All sounds very complicated and is the sort of thing I am trying to get away from. I find all of this stuff more of a hinderance than anything else.
Okay, and? I didn't make the claim that some other language was all that. I was dispelling the claim that Python is.
> Even the pickle.dumps() example is obvious
Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.
The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.
> Okay, and? I didn't make the claim that some other language was all that. I was dispelling the claim that Python is.
I believe that people should RTFM. Any arguments that is predicated on not reading the documentation for the language, and then pretending that it is somehow opaque, I am going to dismiss to be quite honest.
> Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.
You are still cherry-picking things to attempt to prove a point. I don't find this convincing.
> The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.
I didn't say that you can't do RAD with libraries. You didn't understand what I was saying at all.
I can get up and running with Python in mere minutes. It doesn't require a application templates/scaffolding apps to get started (like C# and JS/TS). You just need a text editor and a terminal. Doing that is still quicker and easier to get something working than all the gumpf you have to do with the other languages. I BTW was a JS/TS and .NET for about 15 years
I just wish there were more Python and Go jobs in the UK.
C# does not require scaffolding any more than Python does. It comes with a large standard library (aka .NET). Even the NodeJS standard library is quite large now too. How much setup you need really depends on what you are trying to do; if you are using Django, there will be an insignificant amount of that, and some of the most complicated setups I've seen have been with Pylons/Pyramid. If you're just making a CLI app, well I don't see how it's any less setup with Python than with Node. And anyway, RAD isn't about setup time, it's about iteration time.
I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...
> C# does not require scaffolding any more than Python does.
They've changed so much in the last few years I honestly don't know anymore. Which is part of the entire problem.
The last time I bothered writing anything with C# / .NET was .NET 8. They definitely had scaffolding tools for popular project types. Setting stuff up from a blank project wasn't straight forward.
> It comes with a large standard library (aka .NET). Even the NodeJS standard library is quite large now too.
I find dealing with C++ and CMake/Make (I hobby program Vulkan/OpenGL) easier than dealing with Node JS and NPM. People think I am being hyperbolic when I say this, I am not. Which show you how insane the JS ecosystem is.
I am honestly fed up of both C# and JS. There are far more headaches with both (especially if you are using TypeScript).
If you use TypeScript and don't want to use babel, until recently you have to basically use tsx or tsnode .
You then have to wrangle a magic set of options in the tsconfig.json to have some popular libraries work.
.NET after 5 has absolute DI madness in ASP.NET and none of it seems documented properly anywhere (or I can't find it) and it seems to change subtly every time they update .NET or ASP.NET.
I ended up resorting to pulling down the entire source code to see what the Startup was doing. C# now has total language and syntactic sugar overload.
I have almost none of these headaches with Python and Go.
> And anyway, RAD isn't about setup time, it's about iteration time.
It is both. I find Python quicker, easier and less headaches that either JS or .NET. I am well versed in C# and JS.
I know less Python than .NET and JS/TS, yet I find it easier.
> I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...
That is true. I am sure most Go jobs advertised in the UK are in London.
It doesn't solve all the problems at library boundaries, but pyright is fairly new and vastly vastly better than mypy.
With it Python feels about at the type safety level of Typescript - not as good as a language that had types the whole time, but much much better than nothing if enforced with strict rules in CI.
On the other hand, TS is terrible. The type system is ridiculously complex in order to support all the weird stuff you can do in JS, I frequently get insane error messages with 20+ lines of archaic type gibberish and when I figure out the solution it's usually very clear that the sparse information i managed to glean from reading the error message was nothing but a distraction.
I don't like JS but after having used TS intermittently for a number of years I'm starting to think JS is the better option. At least there I don't get tricked by typed objects being something other than what they claim to be, or waste time trying to declare the right types for some code that would work perfectly without TS.
TS is too much work for too little reward. I'd rather just make simple frontends with as little logic as possible and do the real programming in a real programming language on the backend.
We need to see a move toward the gold standard. People should generally be trading dollars for gold, even if it's virtual gold. Ever since we got off the gold standard, compensation has been lagging behind productivity, and that means that over time everyone's compensation has been slowly shrinking. It may well be true that fiat currency is necessary at some point in a country's history, but that moment isn't right now.
Another annoying thing Go proponents say is that it is simple. It is not. And even if it was, the code you write with a simple language is not automatically simple. Take the k8s control plane for example; some of the most convoluted and bulky code that exists, and it’s all in Go.
We were taught in grade school that the vowels were "A, E, I, O, U....and sometimes Y" without any real explanation. I count that as our first lesson about the convoluted complexities of the English language.
Y is used as a vowel when it's between two consonants, and a consonant when it's not. A word like "Synchronize" uses y as a vowel, but a word like "Yellow" uses it as a consonant. Honestly, it's more vowel-like then consonant-like in every case I can think of, so maybe that rule is kind of weak, and it should be counted as a vowel all of the time...
I'm not sure that's the (sole) rule for "Y as vowel". It acts as a vowel in "fly", "spy", and a few other words. And it seems pretty darn dipthong-like when clustered among vowels, eg "voyeur", "vying".
The word "eye" is an interesting one. It seems to be only vowels, based on pronunciation.
> a vowel when it's between two consonants, and a consonant when it's not.
Not a hard rule, honestly.
Some Indian languages exhibit a blurring of sorts with Ye- sounds. E.g., in Telugu, the word for 'How' is 'yela', which is often also pronounced as 'ela'. TBF, Telugu also blurs Ve-/We- sounds similarly.
The first rule of English is that the rules aren't really rules because they are broken all the time. Makes sense when you consider English is just an amalgamation of Scandinavian, Germanic, French, Latin, etc words and rules. Hard to have rules when you mix a half dozen completely different rulesets into one.
To push back on this article's thrust, those are actual issues that can occur with dependencies. It's just that they usually don't, and most dependencies are harmless, small, and transparent, so articles like this and people complaining about dependencies are almost always overstating their case.
And therefore, adopting a "zero dependencies" policy is absolutely an overreaction.
I'd argue harmless, small and transparent dependencies are the easiest to avoid. The extreme of it "is_even", but any library that could fit in 200 lines should probably be owned code.
Where the article hits is critical libraries that you heavily rely on and that your code is slowly formatted around. I'm thinking specific data parsers, fancy query brokers, time management libraries etc.
I don't think the author is actually arguing for zero dependencies here. While they do quote a "zero dependency policy" in one open source project as being "instructive", they also propose a "framework for evaluating dependencies" - which of course anyone advocating for zero dependencies would have no need for.
