Do Python Developers Want Static Typing? (infoworld.com) 151
Results were announced this week for the fourth "official annual Python Developers Survey" of over 28,000 developers (in nearly 200 countries) conducted by the Python Software Foundation and JetBrains.
85% of the survey respondents use Python as their main programming language, InfoWorld reports: Python developers cite simplicity and ease of use as principal reasons for using the language, but they still want capabilities such as static typing and performance improvements, based on survey results released this week. Python's simple syntax, syntactic sugar, and ease of learning were the most-favored features, capturing 37% of respondents, who were asked which three features they liked the most...
Which three features would Python developers most like to see added to the language? Static typing and strict type hinting proved to be the most-desired features, with 21% of respondents, closely followed by performance improvements, with 20%. Better concurrency and parallelism came in third, with 15% saying they were their most-desired capabilities.
InfoWorld also describes some other interesting results:
85% of the survey respondents use Python as their main programming language, InfoWorld reports: Python developers cite simplicity and ease of use as principal reasons for using the language, but they still want capabilities such as static typing and performance improvements, based on survey results released this week. Python's simple syntax, syntactic sugar, and ease of learning were the most-favored features, capturing 37% of respondents, who were asked which three features they liked the most...
Which three features would Python developers most like to see added to the language? Static typing and strict type hinting proved to be the most-desired features, with 21% of respondents, closely followed by performance improvements, with 20%. Better concurrency and parallelism came in third, with 15% saying they were their most-desired capabilities.
InfoWorld also describes some other interesting results:
- "JavaScript was the most popular language used in conjunction with Python, with about 42% of respondents using both together. 75% of web developers said they were using both Python and JavaScript."
- "Just 8% of Python developers performing data-related tasks do not use any additional languages while only 3% of web developers use only Python."
- "Use of Python 3 has grown from 75% in 2017 to 94% in 2020."
Do they know why? (Score:3, Informative)
One in five Python programmers apparently don't understand that you can have different programming languages with different goals. Surprisingly low given how few of them even seem to know that other languages exist.
Re: (Score:2)
Re: (Score:2)
Indeed. People that do not understand a thing wanting to get rid of that thing. Gross human stupidity at work.
Re: (Score:3)
On the other hand, I have seen many Java programmers saying how stupid Python is for not having statically typed variables.
The funny thing is that many of those Java programmers *wish* they had the benefits dynamic typing, so they go and invent huge "bean" frameworks that use Java's grossly inefficient runtime introspection to approximate it. Then they often end up with huge bloated programs that can actually run slower than if they had just written them in Python.
Re: (Score:2)
Map<String, Object>
I have seen it done in java on a large scale and the results weren't pretty.
Re: (Score:2)
How would that have been better with dynamic typing?
Re: Do they know why? (Score:2)
Re:Do they know why? (Score:5, Interesting)
Same thing is true of C/C++ programmers, in my experience. What's worse is the proliferation of C syntax, which we know is substantially error-prone (even in production code written by experts - see the Bell Labs Technical Journal studies on errors in their 5ESS switch, one of the most comprehensive studies I know of for errors and error causes in a large software system.)
The one hard-and-fast rule I had when hiring programmers was "You must be fluent in 2 different programming languages." When I was in the Army and assigned a programmer who knew COBOL, I sent him to the local college to learn Pascal. Mono-lingual programmers are "Sapir-Whorf meets hammer and nail"
A lot of my friends from the Ada community who went into commercial world ended up being 'studly' C, Java or Python programmers, because they came from a different culture, one that emphasized 'structure and modularity' as first class constructs. Most of them had experience in other languages before they learned Ada.
Re:Do they know why? (Score:5, Informative)
"An Empirical Study of Software Faults Preventable at a Personal Level in a Very Large Software Development Environment" Weider D. Yu, Alvin Barshefsky, and Steel T. Huang, Bell Labs Technical Journal, Summer 1977.
"A Software Fault Prevention Approach in Coding and Root Cause Analysis" Weider D. Yu, Bell Labs Technical Journal April-June 1988.
Re: (Score:2)
And thanks for the references. Added to the reading pile.
Re:Do they know why? (Score:5, Funny)
I've decided that "coder" means someone who writes mostly structureless code, "programmer" means someone who writes at least minimally structured programs.
So far the taxonomy seems to work pretty well.
Re: Do they know why? (Score:2)
Re: (Score:2, Interesting)
"The one hard-and-fast rule I had when hiring programmers was..."
People use "hard-and-fast rules" as compensation for a lack of critical thinking.
The number of programming languages one is "fluent" in, whatever that means, is not an indicator of capability nor is it suggestive of any ability to learn proper tools for a job. Knowing what to do is critical, figuring out how to do it is merely tactics.
Re: (Score:3, Insightful)
Your mileage may vary, of course.
What I found was that monolingual programmers tended to think in terms of the 'one way to do it in the language they know.' Go read about Sapir-Whorf for a theoretical basis behind this. The guy I sent to Pascal class came back a much better programmer than when I first met him.
Re: (Score:2)
Unless you evaluated (literally) thousands of programmers, your conclusions are just a mix of anecdote and prejudice.
As to the Sapir-Whorf hypothesis, it's long discredited shit and programming languages are not like human languages anyway -- they're more like electrical/mechanical schematics or mathematical notation.
Re: (Score:2)
Algol 60 (Score:3)
Algol 60 is the grand-daddy of the begin-end, GOTO considered harmful, bondage and discipline, Structured Programming, scholars-in-CS-departments-are-smarter-than-you, people in Europe know the sensible thing to do better than you Murrcans computer language.
It had this one facility that no one particularly could understand of "call by name" that hasn't been used since only it is making a comeback as being called a "lambda expression" or some such thing.
It had a follow on called Algol 68 that was a vict
Re: (Score:3)
Actually, it is a pretty good indicator of a certain desirable mindset, one that says programming languages are tools not skillz.
When I hire programmers, I want people who like programming and who are good at it. A desire and capacity to learn new programming languages is a one indicator of those attributes.
Re: (Score:2)
The one hard-and-fast rule I had when hiring programmers was "You must be fluent in 2 different programming languages."
C and C++?
(they both require very different mental processes to use effectively)
Re: (Score:2)
Nope. In my scoring, those count as '1' for a couple of reasons. (1) shared syntax (2) similar type models for many things (scalars, strings-are-null-terminated-arrays, etc) (3) shared culture (I'm a strong believer that 'culture counts' - how you learn to code and who you learn from is important.) (4) a lot of C++ I saw was just 'plain old C with OOP sprinkled over it'.
I know that, particularly as C++ has evolved, the language can be used to approach problems in different ways. That being said, I'd s
Re:Do they know why? (Score:5, Informative)
It's even better with Python. Just install Cython and you can have static typing. You can write Python, C, a blend of the two, whatever you like, and it all gets compiled.
One thing that *could* be improved is to coordinate the existing (optional) type hinting system better with Cython. They play together a bit as is, but it could be better.
Re: (Score:3)
A lot of what makes a language practical and useful are the libraries and frameworks that come with it, as well as the experience programmers have with those facilities. Learning a language is not really that hard; learning all the *other* stuff you need to work professionally is a huge undertaking.
So creating a distinct, nearly-identical language that is different some fundamental way only solves the easy part of the problem. What you really need is the second language to be 100% interoperable with code w
Re:Do they know why? (Score:4, Informative)
Well, with Python/Cython you can use Python, C, and C++ libraries. I've personally also used bridges to R, MatLab/Octave and Objective-C. I expect others exist as well.
Re:Do they know why? (Score:4, Insightful)
I recently learned that they sometimes don't even know that it's named after Monty Python. Don't they teach kids anything important in school these days?
Re: (Score:2)
Honestly, I had no idea.
Re: Do they know why? (Score:5, Insightful)
This. Like adding pseudo-functional programming to Java. People want every language to have every feature. More and more cruft accumulates, until people get disgusted and move to the next language to screw up.
Re: Do they know why? (Score:4, Interesting)
(Almost) nobody wants a programming language to have every feature; as you say, that would make the language a hot mess.
(Almost) everybody wants their favorite programming language to incorporate their favorite feature; as adding it would be very helpful for their particular use-case.
Therefore, given a large enough user-base, eventually every feature gets lobbied for addition to the language, even though nobody wants a language with every feature.
Re: (Score:2)
Though I could be horribly wrong
Re: (Score:3)
One in five Python programmers apparently don't understand that you can have different programming languages with different goals. Surprisingly low given how few of them even seem to know that other languages exist.
Programming languages are tools, different tools may be better for different tasks. For example, you wouldn't use a screwdriver as a hammer (said as someone who's used a screwdriver handle as a hammer).
Yes! More features! (Score:3)
This is what happens when you let programmers design languages, rather than computer scientists. It's like the car that Homer Simpson designed.
Re: (Score:2)
Don't forget template metaprogramming.
Re: (Score:2)
So you want C++ then.
Meh (Score:2)
I don't have any problem with Python's weak typing, but I also don't care if it goes to strong typing. Wouldn't inconvenience me significantly, or provide any advantage to me.
What I really want is the ability to extend a standard class. I have already written a Python2 preprocessor [github.com] to get it done (most of what I work with is P2), but it sure would be better if the language allowed adding functionality directly to existing classes.
What this is for... when I write functionality to get something done with/to a
Extension Methods? (Score:2)
Re: (Score:2)
Dude, python2?
This python version is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisible!! THIS IS AN EX-PYTHON VERSION!!
Re: (Score:2)
This is what happens when you let programmers design languages, rather than computer scientists.
And if you let computer scientists do it you get Haskell. Yep it's beautiful and elegant. And yet...
Re: (Score:2)
Minor, but important, correction:
Python is a strongly typed language - all variables have a type associated with them and operations respect those types..
The debate here is between static and dynamic typing - the ability of a variable point to entities of different types or be constrained to only on (or a few) types.
You want a transpiler? That's how you get one. (Score:5, Interesting)
If coding in a type-free language is so great why does Typescript exist? And not only exist, but gaining popularity.
I never had much use for Javascript until I started using Typescript in WebStorm. What I found is that in a complex program it was invaluable for the IDE to know what types my references were. Without the IDE to do it for me I would have spent an aggregate of who-knows-how-many hours looking them up.
So Typescript gives my IDE the advantage it would have if I were programming in Java. I know that offends some people but I don't care. If for some reason I want a loosely typed variable I can still do it but in the frameworks I use that is a rarity to the extent I can't remember when I last needed it.
Python probably will and should go the same way. You don't want to have to depend on a transpiler like Typescript if you don't have to.
Re: (Score:2)
Then they would have to come up with python 4, which breaks compatibility with python 3, just as 3 broke compatibility with 2. When 3 broke compatibility with 2, that pissed off a lot of snakes. IDC either way though because I'm not a snake, I'm more of a rustacean.
Re:You want a transpiler? That's how you get one. (Score:5, Insightful)
Dynamic typing is great when you are using Python as a script language. In a large, complex code-base, it's a nightmare. I hate having to walk down through all the layers of Python calls to find out what type something is actually needed.
Python needs something akin to Perl strict mode. Let the programmer decide which mode to use the language in.
Re: (Score:2)
Trees are dead-ends (Score:3)
The way CRUD applications are developed needs an overhaul. Treat an app as bunch of event handlers rather than a giant program and the brevity of dynamic typing can shine again. Use a database to manage code instead of file hierarchies. Then it's easier to find, sort, search, group, etc. event handler code snippets.
The system may still "render" to files for running, but the IDE would mana
Re: (Score:3)
Several years back, I had a similar notion except centered on functions instead of event handlers. I was working on a HUGE code base (full compile took ~24 hours on the current high-end systems of the day) and it was painful trying to find what file functions were in.
Lots of advantages to the approach you suggest, but in the end, I didn't pursue it because you (as a programmer) had to be too exacting on the search terms to get a match. In practice, you've got to support much looser fuzzy matching to mimic w
Re:You want a transpiler? That's how you get one. (Score:4, Insightful)
If static/strict was so great, why do Python, Ruby, Perl, PHP, & Javascript exist? And these guys came AFTER the likes of C, Pascal, and Haskell. And are still around and popular (ok dismiss Ruby there).
I think your first reasoning is a lot more applicable toward type-free, than the other way you used it. To each his own, most languages are popular due to their differences finding their space within the universe of solutions. Let's not waste time hunting for that one true hammer and saying all others should adopt its set of features.
Re:You want a transpiler? That's how you get one. (Score:5, Insightful)
Because a significant proportion of developers, including the likes of Brendan Eich who designed Javascript actually have no idea what the fuck they're doing, that's why.
Dynamically typed languages are okay if you want to expose scripting functionality to less experienced users, and it's decent for small glue type scripts and infrastructure automation where the impact of any faults isn't felt immediately (i.e. if a non-essential batch process fails overnight once in a while and can be fixed the next day and doesn't matter). They're also great for experimentation and that's why Python is a fantastic tool for the science and machine learning communities.
The problem is too many people try and use them for large production systems, and that's where shit begins to hit the fan, the lack of static types results in whole additional classes of defects that compilers prevent where human fallibility results in an inevitable increase in defects - unit tests can't resolve this even though they're often proposed as a solution because human fallibility also means perfect unit test coverage isn't guaranteed either; the only real solution is static types which the compiler guarantees, this is the only way to remove those guaranteed types of defects in dynamically typed languages. Furthermore, dynamically typed languages by their nature also prevent entire classes of potential optimisations, and type checks have to happen at run time meaning they're always inherently slower. Finally, their nature also means it's not possible to achieve the same degree of tooling you get in IDEs which are essential for managing any significant codebase effectively.
So sure, it's not that there's anything inherently wrong with dynamically typed languages such that static/strict is ALWAYS the best option, the problem is that static/strict IS the best option in way too many places where people are foolishly using dynamically typed languages, and those software projects always inevitably suffer for it without fail - if you want some examples of this, look to Facebook, they started with classic interpreted PHP and realised it was unmanageable for a system the size of Facebook, so they wrote a transpiler to convert it into C and compile it, that kind of worked but wasn't great, so they created HHVM, a JIT compiler for PHP to try and solve some of those issues; effectively to make PHP work in a project of their size they basically just ended up turning PHP into Java/C# when they should've really just cut their losses early on and switched to Java/C# as soon as they realised PHP was the wrong tool for the job, which was very early on.
Re: (Score:2)
Your inability to use a dynamically-typed language correctly is not a problem with those languages.
Forth is an interesting language. It isn't dynamically typed, it's completely typeless! Still, proponents of Forth herald its ability to build large and complex systems easily and quickly. Of course, you need to have a Chuck Moore level of skill to realize those gains. It's not for everyone. Bottom-up design is hard, after all, and that's enough to keep people away. (Strange, as OOP also demands a botto
Re: (Score:2)
Well javascript came to exist on accident, so it's not a good example.
Re: (Score:2, Funny)
Oh and also, PHP isn't a real language, and Perl...lol [github.com]
Re: (Score:3)
You know that the script you linked to is a Shell script, not a Perl script, right? And I wouldn't be surprised if it was autogenerated in some way. Or maybe it was just built up over many years with workarounds for lots of different system behavior.
Re: (Score:3)
You need to separate history from convenience... Things had to start with machine code, then assembly, then compiled languages, then interpreted languages. That's just how things work when you're starting from bare metal without enough CPU to run the program and the interpreter...
The reality is that loosely typed interpreted scripting languages are great for prototyping and one-off projects. You can grow code in different directions without worrying about interfaces and structure. Then at some point, t
Re: You want a transpiler? That's how you get one. (Score:2)
With all due respect to your godly low /. ID, I disagree. The benefits of checking type at compile vs run are overstated. They make up a very small percentage of errors. I used to believe like you when I did C and later Java coding.
I changed my mind when I added Erlang, Perl, and Python . And I am OK with these languages being relegated to sub-100k LOC programs (I know, bad metric since these are concise). They are also bad for highly coupled monolithic designs vs modular ones.
Dynamic vs static isn't a "
Re: You want a transpiler? That's how you get one (Score:3)
When you're writing type definitions, you're programming the IDE. If you want to spend time to do that, fine.
Re: (Score:2)
Right.
Now tell us where in the above code the type definitions are, and how much time it took to write them.
If history (Score:5, Funny)
Python developers cite simplicity
If history of other languages is any guide, I am sure this issue will be fixed quickly
Re: (Score:3)
Having used Python since the 1990s (discovered it when looking for a good alternative to the surpringly useful implementation of RS232 in Qbasic. QBasic used to be very popular with engineers due to the ability to quickly throw together some RS232 code for testing hardware) I've really enjoyed the slow and careful pace with whicch the Python community built its ecosystem.
So I've feared the recent surge in popularity would
Re: (Score:2)
Python developers cite simplicity
If history of other languages is any guide, I am sure this issue will be fixed quickly
indeed. my strongest wish is that they stop adding features to the core language (and optimise the ones that exist). it's fine adding new libraries but constantly "improving" by adding new features means that stability and backwards-compatibility are adversely affected, to the detriment of everybody.
Keep it dynamic (Score:2, Redundant)
I'm starting to suspect that the history of every popular computer language is - starts dynamic, language adds more static features over time, people move to new, fully dynamic language...
Python just got away with it longer than most before the static police moved in to lock it down.
Re: (Score:3)
Pretty much. I wonder what the incentive for compulsory static typing everywhere is. There's a guy up above who wants it so his IDE can tell him what to do.
Keep it helpful. (Score:4, Insightful)
Tell him, or help him? There's a difference.
Re: (Score:3)
Yes, one that's impressed into every kid asking for "help" with their homework.
Re: (Score:3)
I wonder what the incentive for compulsory static typing everywhere is
Reduction in bugs. Once you get a program large enough that needs to be maintained by more than one person, this really comes into play. You don't want a simple typographical error to mess up your program. And yes, I've seen this all too often.
Re: (Score:3, Insightful)
Reduction in bugs.
Yeah I might have believed that at one time... now I'm more of a mind to paraphrase a quote:
"The more you tighten your grip Tarkin, the more star systems will slip through your fingers"
Static typing does not eliminate bugs. After a long time programming, I am really not sure statically typed systems have any fewer bugs at all.. it is helpful in some ways, but the lost flexibility brings with it other costs, more rigid code that is also more prone to failure, or at the very least can lead
Re: Keep it dynamic (Score:2)
You have obviously never converted JavaScript to TypeScript. Dynamically typed code always is full of bugs... always.
Still not sure (Score:3, Interesting)
You have obviously never converted JavaScript to TypeScript. Dynamically typed code always is full of bugs... always.
Most off those were probably not actually bugs (or at best irrelevant) in Javascript, and became bugs in the effort to port to a statically typed language.
Then when you were done, are you saying that TypeScript version was bug free?
I have ported stuff from dynamically typed languages to statically typed ones. Any porting effort from one language to another is always going to find issues with
Re: (Score:2)
I've ported several projects from JavaScript to C -- all with minimal changes. You work with idiots.
Re: (Score:3)
"Static typing does not eliminate bugs."
Science says you are wrong [researchgate.net]
"[Static typing] is helpful in some ways, but the lost flexibility brings with it other costs"
Then that's your fault. Don't write unflexible statically typed code.
Re: (Score:3)
For large, complex code-bases, it's more about changing when certain classes of bugs can be caught. Static typing lets you catch it immediately, before it's ever committed. With dynamic typing, you won't catch it until that particular line of code is executed. That's frequently well after you've moved on to other things or, even worse, when it's in the hands of your customers.
Yes, unit tests can help here, but they are a lot slower to run than a compiler. Also, how often have you seen unit tests with 100% c
Re: (Score:2)
Of course there are advantages to statically typed languages. I didn't say "everywhere" by accident.
I suppose if you choose a language because it's popular it becomes your hammer and you want to redesign it to be better for hitting screws.
Re: (Score:2)
It's not so much reduction in bugs as finding (certain classes of) bugs early, so that they're cheaper to correct.
Re: Keep it dynamic (Score:3)
The incentive is, that the bug due to discrepancies between the type the machine assumed and they type you assumed are gonna get you either way. If you were precise enough to think about the type at all, and didn't just keep the brain off and fuzzed the code until it seemed to work for your tests, like people often do for mere scripting languages and one-offs.
JavaScript's automatic casting is the prime example of this particular nightmare. (Is "2"+1="21"=21 or =1="1"? What about 2+"1"?)
The core problem is:
Clearer first sentence: (Score:2)
The incentive is, that the bugs, due to discrepancies between the type the machine assumed, and they type you assumed, are gonna get you either way.
Re: (Score:2)
This is precisely why I said "everywhere."
Re: Keep it dynamic (Score:2)
Re: Keep it dynamic (Score:2)
PCRE are great for what it actually was meant for: Parsing simole text, like some shell program's stdout/stderr or user input, e.g. in one-off scripts or on the CLI.
And no, the, are not hard. They are just write-only, basically. ;)
Re: (Score:2)
That's complete nonsense and you know it.
Technical Debt Abound? (Score:4, Insightful)
This seems ripe for creating yet another version incompatibility like 2.7/3.x that will result in yet more technical debt rather than recognize a design choice and living with it.
Please change the language (Score:3)
Please, change the language again, and abandon python3, so we get more and more obsolete code and impose further pain to Linux distributions, like you did with python2.
Do Python developers want static typing? (Score:2)
Easiness will go away with static typing. (Score:2)
Ease of use is mostly due to allowing people to be sloppy by not being specific and having the compiler figure it all out and use hacks like casting to unpredictably and unintuitively fill in the gaps (read: produce bugs while causing slowness too).
If you want to see how "fun" proper strict typing is, try Haskell.
All 5 seconds before you pull your hair out over the insane (but completely justified) type errors that you basically first have to decode like a complex sudoku with 80% of the fields invisible and
Re: (Score:2)
Obviously (Score:2)
75% of web developers said they were using both Python and JavaScript."
When it takes multiple scripts to display a static image, it's obvious they're using this. After all, why keep things simple when you can go whole hog and make the easiest task difficult to justify your job.
No (Score:2)
That would be the pinnacle of stupidity (Score:3)
Dynamic typing is one of the strengths of Python. It does need some skill to handle it well though. Seriously, those that want static typing in Python should move to a different language appropriate to their skill-level, like VBA or LOGO.
Optional (Score:2)
Yes, optional.
Sometimes I want it. Not always, but definitely sometimes.
In the beginning yes, later, no so much (Score:3)
Years ago, when I was learning Python, coming from a static typed language (Delphi) and tried Javascript (hated it *), at first I wanted static typing. Duck typing looked messy. But when I learned how to use it properly, and started to use that flexibility to my advantage, it clicked to me. Suddenly static typing was not that important anymore.
I think better performance and concurrency/parallelism (Golang-style) would do wonders, though.
PS: * because it was hateful at the time, but it improved a lot since then. But I still hate it a little.
Re: (Score:2)
Re: (Score:2)
Javascript is not static typed, but still have very good performance.
But I believe it was because Google had a big interest on it and developed a high-performing engine for it (V8).
Something similar could very well happen to Python.
Re: (Score:2)
Re: (Score:2)
Static typing is important when you have large teams, but not so important on small projects.
Dynamic/Implied Typing != Slow Processing (Score:4, Informative)
The Python language could be tremendously faster than it is, without changing the language specification. The V8 JavaScript engines proves the point, in terms of dynamic typing. However, classical object-orientation does add some inherent bloat and slowness.
I have written a number of interpreter languages and will attest that, unless implemented in a really dumb way, dynamic typing has little to no cost to execution performance against static typing. In the case of, say, Microsoft's CLR (underlying C# and VB.net), it is extremely slow because they use a general purpose object to represent the dynamic type. Classical object-orientation requires a lot of software overhead to support, as this is not close at all to how computers naturally work. Instantiation of a new object (such as a new object to hold a dynamic type value--but actually from any class) requires many new memory allocations and other setup work. The "new" operator is effectively a factory of its own. Memory allocations take a lot of processor time because they require simultaneous memory defragmentation (normally by the operating system).
In contrast, a non-object dynamic type requires minimal memory allocations. Each time an operation is performed to read or write to the variable requires, at best, one simply switch to specify its actual (at that time) type.
I suspect developers of Python interpreters just don't think this way. They likely trained to think in an object-oriented way and, consequently, don't really understand the machine underneath, as one who learned with assembly or C might. It's hard to change from one's originally trained manner of thinking about software structure from one designed from a human's idealized/abstracted perspective to one that is actual truth of the hardware on which it is to run. The new generation of programmers learn classical object orientation and know how to frame problems in that way.
One interesting fact on this theme is that the very fast and efficient V8 JavaScript engine is written in C++ yet implements a wholy different kind of object-orientation: proto-type object-orientation. Prototype Object-Orientation only allocates new memory where specifically requested. A new instance of an object will point to and share the various attributes and functions of that from which it inherits -- not copy them. This is vastly faster. Keep in mind that C++ provides conventional object-orientation but does not mandate it. You can pick and chose where and to what level of granularity you'd like to use it. Therefore, you can stay close to the machine. You can have the best of both worlds. This is why so many programs written originally in Java are gradually replaced piece by piece with C++ replacement parts for performances' sake. In the early days of Java, claims were made that identical software would be identically fast between Java and C++ when both are fully compiled (not just to byte code). But this was only true when both programs were identically structured. C++ provides far more flexibility and does not mandate any particular level of object-orientation. You don't have to write it identically to the Java program and in many cases probably shouldn't.
Personally, I really like JavaScript because it is fast to code and executes fast. I also use Python a lot and find it, like PHP, are quick to write programs in. I wrote a lot of PHP in the past but not recently. PHP is faster than Python because of two things, I think: (1) not based on objects to such a low level, and (2) uses a lot of memory in exchange for performance gains. JavaScript is still both faster for writing applications and faster at performance but doesn't inherently need to be. It's faster at writing software because it provides more flexibilities but also it's just so much easier to type things like:
JavaScript: record[i].subsection.name = "blah"
Python or PHP: record[i]["subsection"]["name"] = "blah"
Typing out code with complex objects is just much faster and more convenient than
Re: (Score:2)
The Python language could be tremendously faster than it is, without changing the language specification. The V8 JavaScript engines proves the point, in terms of dynamic typing. However, classical object-orientation does add some inherent bloat and slowness ...
Each time an operation is performed to read or write to the variable requires, at best, one simply switch to specify its actual (at that time) type.
Stick that "simple switch" inside a tight loop and see what happens to your performance compared to a statically typed language. Also consider that a switch is an "if" which rather messes up branch prediction logic.
Duct-Tape works! (Score:3)
Prototypes, patches, experiments, or even complex components all tied together BY DUCT TAPE. It works. It gets the job done in reasonable time.
Does it last? long enough. Does it look pretty? no. Is it elegant? maybe but unlikely. Is it fast? no, but it's fast to do and functions well enough. Do you need an engineering degree? hell no! Can engineers use it? hell yes!
Strap those well engineered components together in an every changing and ugly way and THAT is the purpose for scripting.
When you have
Imported Modules (Score:2)
From the TFS:
"Just 8% of Python developers performing data-related tasks do not use any additional languages while only 3% of web developers use only Python."
Translation: "Only 8% of Python developers remember that those imported modules are written in languages other than python."
Conference developers do, the rest don't (Score:3)
Don't listen to developers who go to conferences, they are not at all the average developer. Listen to the users who do this as their day jobs. I highly suspect that the only features they are really looking for are related to speed.
As you work through more and more advanced programmers you might find desires like threading friendly features long before static typing. To me static typing is found in other languages that really need it like C++. Not having it is a virtue for python. I would very much say that if you want static typing, use a different language.
The worst argument for static typing is that it is required for speed. This is total BS. Javascript is rocket fast without it. PHP is rocket fast without it. The people who want static typing are people who don't understand what makes python great and just want it to be something it is not.
Re: (Score:2)
The worst argument for static typing is that it is required for speed. This is total BS. Javascript is rocket fast without it. PHP is rocket fast without it. The people who want static typing are people who don't understand what makes python great and just want it to be something it is not.
My fastest code is assembly, without static types. Supports your point.
Python why ? (Score:2)
I always use dynamic typing. (Score:2)
It exists already! (Score:2)
Static typing already exists in Python. Type hints is a part of Python 3 [python.org]. You can then use a tool such as mypy [mypy-lang.org] to perform type checking at "compile" time (or whatever you want to call this type-checking step since Python doesn't need to be compiled).
I would've expected Slashdot of all places to have at least a few comments out of the hundreds posted so far mentioning this. Did nobody bother Googling "Python static typing"?
Re: (Score:3)
I'm hoping EPython becomes a reality. It sounds a lot like what you're asking for.
https://pypi.org/project/epyth... [pypi.org]
Python syntax with static typing and compiles to a python extension. I hope they allow for other targets as well. It would be nice to write numerical routines once in EPython and then just compile to target plain C++ (no python dependencies) or a Python module.
Many years ago I tried shedskin which was so far the closest to an ideal Python compiler I've seen. (I never liked cython since it is a
Re: (Score:2)
nim [nim-lang.org] is pretty good if that's what you're looking for.