521–530 of 856 posts
My "load bearing" language path was Fortran -> (Forth) -> C -> C++(YUCK!) -> Python/Numeric/Numpy/scipy/et al.
I'm now dabbling with Julia.
In addition to Numpy (and it's predecessors) making array computation dead easy to express (slices!) for me personally it boiled down to Guido having taste that matched my own.
I'm sure that YMMV...
Earlier quoted context omitted.
I think Python was popular as a general-purpose language first. After all, there was a reason people put so much effort into writing Numpy in the first place. I think a lot of people were attracted to the language design, as captured in the Zen of Python ( https://peps.python.org/pep-0020/ ), such as: Explicit is better than implicit. Readability counts. Errors should never pass silently (unless explicitly silenced)…
There are just too many ways to do things in Ruby. How many forms for an if-else or for loopin can you name in Ruby? Just as the simplest example. Monkeypatching is also awful for readability. Explicit imports are way more readable than things appearing into current namespace implicit kind of stuff like it happens with Ruby
Earlier quoted context omitted.
Not just perl, but C/C++/Java as well. Ruby was a competitor to Java JSP development back in the day. And I remember when a lot of Java people jumped ship to Ruby. I moved from C++ to python over a decade ago and never looked back. Back then, the python jobs were scarce -- but based upon how I picked up the language, many of the typical C++ issues just disappeared -- and I knew it was going to become popular. One com…
C++ and Python are not competitors. Sure both are Turing complete so you can implement anything in either. However if you should is a different question. Python is very difficult to maintain when you program goes over 100k lines of code, while the static type system of c++ is good for millions. C++ compiles to fast binary code, while Python is typically 60x slower for logic (though often Python calls a fast algorithm…
We have all the cool kids like Kotlin, Rust, etc.
However, when it is about finishing a project, beating C++ or Java ecosystems is almost impossible.
Besides that, C++ has improved a lot over time. It still has its warts and knives but you can code very reasonable C++ with a few guidelines and there are also linters, and -Wall -Wextra -Weverything -Werror. That takes you quite far in real life provided you have a reasonable amount of training.
I would choose C++ over Rust any day. The only hope I have for C++ successors are Cppfront and Carbon and they are highly experimental. As successors those two fit the bill.
There is a third one, my favorite. It is this one: https://www.hylo-lang.org/ but I am not sure how compatible it will/would be.
I come from an analytic philosophy background. I studied mathematical logic and set theory in grad school as part of my logic requirements. I never learned to program for a long time, and it was always a source of embarrassment. A friend finally suggested that I learn Python because it was "English-like" as you say, so I bought Learn Python the Hard Way . When I opened the book, unlike java or js, I could just read t…
Earlier quoted context omitted.
Before Python got popular, Perl was the most similar popular language. Once I encountered Python, I felt, this is Perl, but done right.
That was my experience. I like Perl. I'm comfortable with Perl. And after about a day of Python, I never wrote another line of new Perl code. There were so many "it can't possibly be that easy, but it is!" moments. Let's write a function to add five to a number: def add_five(num): return num + 5 OK. So, can I pass that function as an argument to another function? def call(func, value): return func(value) call(add_fiv…
def call(fn, val) = fn.(val)
call(->(n){ n + 5 }, 10)Earlier quoted context omitted.
> There should be one-- and preferably only one --obvious way to do it. This is so hilariously wrong in python though
I like Python, but most of the Zen has always been a meme, and not a guideline of design principles of either the language, or software written with it. Besides the one you mention, I also find the "Explicit is better than implicit" line to be against everything Python stands for. The language is chock full of implicit behavior, and strongly encourages writing implicit code. From the dynamically typed nature of the l…
"Explicit is better than implicit" is more around things like Django not just automatically importing every directory it sees (instead requiring you to list the apps used). It's also a decent rationale for changes made from Py2 to Py3 regarding bytes-to-string conversions needing to happen explicitly.
It's also about how usually you end up explicitly listing imports (wildcard imports exist but are pretty sparing), or lacking implicit type conversions between data types.
This stuff is of course dependent on what library you are using, the projects you are working on, etc. And there's a certain level of mastery expected. But I think the general ideas exist despite the language allowing for much more in theory.
Python ended up 'specializing' in data contexts, thanks to Numpy / Pandas, and as a result, ended up becoming the first exposure to programming than anyone doing data stuff had. That was millions of people. In that space, it had no competitors. Ruby ended up 'specializing' in web dev, because of Rails. But when Node and React came out, Ruby on Rails had to compete with Nodejs + React / MERN as a way of building a web…
Numpy is certainly amazing, but there are tons of competitors in the data/scientific space, which pure "A-type" data scientists tend to prefer: R, SSPS, Matlab... The difference is that Python doesn't entirely suck as a general-purpose language. Sure, you might have better options, but it's still reasonable to write almost anything in Python. Other scripting languages like Ruby, JS and Lua are probably a little bit b…
Earlier quoted context omitted.
> There should be one-- and preferably only one --obvious way to do it. This is so hilariously wrong in python though
That was the one mantra from the zen of python that I always laugh at too. Because my #1 complaint with python is that there are so many ways to do the same thing. It sounds nice in theory if you are a new developer because you can create your own voice in python and character. For example, lets say I gave a simple coding puzzle (think leetcode) to 10 python engineers. I would get at least 8 different responses. A fe…
I get what you're saying, but I don't think that's as true as you mean. I think that most experienced Python developers tend to gravitate towards the same style of solutions for things like coding puzzles (including the classic "read in data, map it through a comprehension, write out data" pattern).
There are multiple ways of expressing the same thing, but very often in a specific context one of the ways tends to be overwhelmingly a better fit than the other.
Earlier quoted context omitted.
That sounds trivial? I mean, you can do that in C, what’s surprising about it? I have never found Python as nice to use as you seem to have, but Ruby always fit like a glove. I’ve written Python since 1999 and I still would rather use almost anything else. It’s so labored to do anything complex. You can build worlds in Ruby in the time it takes you to align indentation properly for a single class in Python.
> That sounds trivial? I mean, you can do that in C, what’s surprising about it? Here's the C version of it: #include int addFive(int num) { return num + 5; } int call(int(*func)(int), int value) { return func(value); } int main() { printf("%d\n", call(addFive, 10)); return 0; } It's still manageable, but not nearly so simple. Even Perl doesn't let you escape having to consider pointers and references: sub addFive {…
The space was not that crowded back then: Go/Rust did not exist, C# was Windows only, Perl was a mess, PHP was web only, Java was hated, Lua a niche and C++ too low level. And JavaScript was that slow thing in the desktop browsers. It was python or ruby and python like said was on every system and ruby the exotic thing.