4 ms·

Agreed, as an OO scripting language it's lovely, especially compared to Perl where the OO features never meshed quite right. Going back 10 years ago it had a nu

Agreed, as an OO scripting language it's lovely, especially compared to Perl where the OO features never meshed quite right. Going back 10 years ago it had a number of things that were novel compared to other languages: literals for common data structures, context managers ("with" statement), first class functions, comprehensions, generators. On the other hand duck typing is largely a joke. Letting functions take anything as an argument and then just assuming it's a duck with the methods you want is no way to write a robust system. Performance wise you're boxed into a corner. The slow runtime will have you writing native code in another language, complicating your project. The GIL will have you jumping through hoops to work around. As an offline data exploration and research tool limited to an individual or a small team, or for writing small utilities, I totally get it. For anything mission critical I'd much rather be in something like Java or C# where the typing situation is stronger, the performance is going to be much better, I have better access to threads if I need them, the reasons for dropping into native code are fewer, and the cross platform support works more seamlessly without additional layers like Docker.

kamaal 1y ago
>>Agreed, as an OO scripting language it's lovely, especially compared to Perl where the OO features never meshed quite right. Back then the whole OO crowd was with Java though. Python's Moat was beginner friendliness to write simple scripts, which at the time- Perl was more like a thermonuclear scripting language. Most people who never wanted to graduate to that advanced stage of writing mega million lines of Perl code over a week(which was literally the use of Perl then), realised they needed some thing simpler, easier to learn, and maintain for smaller scripts- Kind of moved to Python. But then of course simplicity only takes you that far, and its logically impossible to have a simple clean interface to problems that require several variables tweaked. Python had to evolve and is now having the same bloat and complications that plague any other language. Having said that, I would still use Java if I had to start a backend project.
- pjmlp 1y ago
  When Perl ruled the Earth, the OO crowd was with Smalltalk, Object Pascal, Delphi, Clipper 5, FoxPro, Actor, CA Objects, VB, C++. In fact, many books that the OOP haters attribute to Java, predate its existence.
- simplesocieties 1y ago
  Why not Go? I don’t understand starting new backend projects in a JVM language when go exits and its both faster and simpler. People love to proclaim Java’s ability to handle “big data” but I have programs parsing TB of data daily in Go without a sweat. And it was much faster to write and teach new engineers on than Java
ActorNightly 1y ago
> Letting functions take anything as an argument and then just assuming it's a duck with the methods you want is no way to write a robust system Everyone keeps harping on type safety, but it just doesn't play out in reality. Linux Kernel is incredibly robust, has never been a broken mess, and has basically no type enforcement, as you can cast pointers into other stuff. In general, all typing does is move error checking into the compiler/preprocessor instead of testing. And time spent on designing and writing type safe code is almost equivalent to time spent writing tests that serve as an end-to-end contract. There is a reason why NodeJS was the most used language before all the AI stuff came with Python. >Performance wise you're boxed into a corner. The slow runtime will have you writing native code in another language, complicating your project. Most of these performance arguments are similar to arguging that your commuter car needs to be a track spec Ferrari in terms of performance, by people that have very little experience with cars. Plenty of fast/performant stuff runs on Python. PyPy is a thing also. So is launching small compiled executables like a process, that takes literally one line of code in Python. >The GIL will have you jumping through hoops to work around. This is just laughable. Clearly you have extremely little experience with Python.
- sunrunner 1y ago
  > Linux Kernel is incredibly robust, has never been a broken mess, and has basically no type enforcement Yes, as a result of strong development practices, a high skill floor, and where work is done by a small number of people knowledgable in the domain. These things are not mutually exclusive with type checking. > In general, all typing does is move error checking into the compiler/preprocessor instead of testing Which is an enormously powerful thing. Having those things be required by tests requires that the test exists for all the cases, which turns your tests into things that not only have to test behaviour but are also simultaneously responsible for checking types. Compile-time type checking can essentially eliminate all need for type-based tests and is able to do it automatically for any code that exists, whereas this has to be opted in when using tests to check types. You also don't get the benefit of compile-time tests automatically checking use cases for the types you don't support (which is likely more than the ones you do), whereas leaving this to test-time is practically impossible and you can only test the valid path. I've never seen a codebase that checks the negative paths for the hundreds-upon-thousands of types that aren't supported. None of this is to say I'm against tests as end-to-end contracts, but moving type checking to compile time gives you a lot of extra kinds of assertions for free that you likely don't get from having tests to check types. > There is a reason why NodeJS was the most used language And the reason was? AFAIK Node came along as a runtime option for using a familiar language outside of the browser. Coupled with a single-threaded event-driven concurrency model out of the box it was an enormously practical/easy choice from the perspectives of both language familiarity for developers and fpr the workloads it was given.

kamaal 1y ago

>>Agreed, as an OO scripting language it's lovely, especially compared to Perl where the OO features never meshed quite right. Back then the whole OO crowd was with Java though. Python's Moat was beginner friendliness to write simple scripts, which at the time- Perl was more like a thermonuclear scripting language. Most people who never wanted to graduate to that advanced stage of writing mega million lines of Perl code over a week(which was literally the use of Perl then), realised they needed some thing simpler, easier to learn, and maintain for smaller scripts- Kind of moved to Python. But then of course simplicity only takes you that far, and its logically impossible to have a simple clean interface to problems that require several variables tweaked. Python had to evolve and is now having the same bloat and complications that plague any other language. Having said that, I would still use Java if I had to start a backend project.

pjmlp 1y ago
When Perl ruled the Earth, the OO crowd was with Smalltalk, Object Pascal, Delphi, Clipper 5, FoxPro, Actor, CA Objects, VB, C++. In fact, many books that the OOP haters attribute to Java, predate its existence.
simplesocieties 1y ago
Why not Go? I don’t understand starting new backend projects in a JVM language when go exits and its both faster and simpler. People love to proclaim Java’s ability to handle “big data” but I have programs parsing TB of data daily in Go without a sweat. And it was much faster to write and teach new engineers on than Java

ActorNightly 1y ago

> Letting functions take anything as an argument and then just assuming it's a duck with the methods you want is no way to write a robust system Everyone keeps harping on type safety, but it just doesn't play out in reality. Linux Kernel is incredibly robust, has never been a broken mess, and has basically no type enforcement, as you can cast pointers into other stuff. In general, all typing does is move error checking into the compiler/preprocessor instead of testing. And time spent on designing and writing type safe code is almost equivalent to time spent writing tests that serve as an end-to-end contract. There is a reason why NodeJS was the most used language before all the AI stuff came with Python. >Performance wise you're boxed into a corner. The slow runtime will have you writing native code in another language, complicating your project. Most of these performance arguments are similar to arguging that your commuter car needs to be a track spec Ferrari in terms of performance, by people that have very little experience with cars. Plenty of fast/performant stuff runs on Python. PyPy is a thing also. So is launching small compiled executables like a process, that takes literally one line of code in Python. >The GIL will have you jumping through hoops to work around. This is just laughable. Clearly you have extremely little experience with Python.

sunrunner 1y ago
> Linux Kernel is incredibly robust, has never been a broken mess, and has basically no type enforcement Yes, as a result of strong development practices, a high skill floor, and where work is done by a small number of people knowledgable in the domain. These things are not mutually exclusive with type checking. > In general, all typing does is move error checking into the compiler/preprocessor instead of testing Which is an enormously powerful thing. Having those things be required by tests requires that the test exists for all the cases, which turns your tests into things that not only have to test behaviour but are also simultaneously responsible for checking types. Compile-time type checking can essentially eliminate all need for type-based tests and is able to do it automatically for any code that exists, whereas this has to be opted in when using tests to check types. You also don't get the benefit of compile-time tests automatically checking use cases for the types you don't support (which is likely more than the ones you do), whereas leaving this to test-time is practically impossible and you can only test the valid path. I've never seen a codebase that checks the negative paths for the hundreds-upon-thousands of types that aren't supported. None of this is to say I'm against tests as end-to-end contracts, but moving type checking to compile time gives you a lot of extra kinds of assertions for free that you likely don't get from having tests to check types. > There is a reason why NodeJS was the most used language And the reason was? AFAIK Node came along as a runtime option for using a familiar language outside of the browser. Coupled with a single-threaded event-driven concurrency model out of the box it was an enormously practical/easy choice from the perspectives of both language familiarity for developers and fpr the workloads it was given.