Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Python Programming

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:
  • "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."

This discussion has been archived. No new comments can be posted.

Do Python Developers Want Static Typing?

Comments Filter:
  • Do they know why? (Score:3, Informative)

    by nagora ( 177841 ) on Saturday February 27, 2021 @12:39PM (#61105948)

    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.

    • On the other hand, I have seen many Java programmers saying how stupid Python is for not having statically typed variables. I agree with you, but many people on the other side cannot see the purpose for being free of static typing.
      • by gweihir ( 88907 )

        Indeed. People that do not understand a thing wanting to get rid of that thing. Gross human stupidity at work.

      • 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.

      • I do not feel I have ever gotten a good reason to be free of static typing. Every reason just seems to call out for using a templates function, which still gives us compile time static typing to catch errors. What is the benefit and what am I missing?
    • Re:Do they know why? (Score:5, Interesting)

      by david.emery ( 127135 ) on Saturday February 27, 2021 @12:53PM (#61105994)

      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)

        by david.emery ( 127135 ) on Saturday February 27, 2021 @12:56PM (#61106006)

        "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.

      • by ceoyoyo ( 59147 ) on Saturday February 27, 2021 @01:03PM (#61106028)

        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.

      • Shit it doesnt get any more C than ATT/Bell Labs programming on a SystemV 5ESS. Its practically the birthplace of everything I know these days. I was never a windoze person, and when windows abandoned netbui for tcp/ip, they too began to be assimilated by the borg. Mac switched to a BSD based OS around 1999, Novell later started running their tools ontop of Suse ehen Netware 5 and its java native OS fell flat on its face. Windows tried to make WindowsCE relevant but every attempt of dominating the tiny devi
      • Re: (Score:2, Interesting)

        by dfghjk ( 711126 )

        "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)

          by david.emery ( 127135 )

          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.

          • 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.

        • by jeremyp ( 130771 )

          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.

      • 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)

        • 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)

      by ceoyoyo ( 59147 ) on Saturday February 27, 2021 @01:00PM (#61106018)

      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.

      • by hey! ( 33014 )

        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

    • by Anachronous Coward ( 6177134 ) on Saturday February 27, 2021 @01:48PM (#61106146)

      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?

    • by bradley13 ( 1118935 ) on Saturday February 27, 2021 @02:00PM (#61106174) Homepage

      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.

      • by Jeremi ( 14640 ) on Saturday February 27, 2021 @07:42PM (#61106988) Homepage

        (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.

        • Yup, but having perl's "use strict" would really make me happy. Python loses very little by having the option exist.
          Though I could be horribly wrong
    • 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).

  • by ZeroPly ( 881915 ) on Saturday February 27, 2021 @12:45PM (#61105968)
    We need both strong and weak typing, and also some monads, virtual functions, and direct pointers to memory. Did we add ternary operators and spaceship operators? I lose track...

    This is what happens when you let programmers design languages, rather than computer scientists. It's like the car that Homer Simpson designed.
    • Don't forget template metaprogramming.

    • So you want C++ then.

    • by fyngyrz ( 762201 )

      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

      • Those work well in C#
      • 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!!

    • 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...

    • 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.

  • by AlanObject ( 3603453 ) on Saturday February 27, 2021 @12:50PM (#61105984)

    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.

    • 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.

    • by tippen ( 704534 ) on Saturday February 27, 2021 @02:04PM (#61106190)

      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.

      • by rnturn ( 11092 )
        Hey! I thought I had mod points. What a time to not have any available.
      • Dynamic typing is great when you are using Python as a script language. In a large, complex code-base, it's a nightmare.

        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

        • by tippen ( 704534 )

          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

    • by orlanz ( 882574 ) on Saturday February 27, 2021 @03:06PM (#61106328)

      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.

      • by Anonymous Coward on Saturday February 27, 2021 @03:23PM (#61106352)

        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.

        • by narcc ( 412956 )

          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

      • 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]

          • by theCoder ( 23772 )

            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.

      • by reg ( 5428 )

        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

        • 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 "

    • When you're writing type definitions, you're programming the IDE. If you want to spend time to do that, fine.

      • Right.

        a = 5;
        msg = "You are dumb.";

        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)

    by jmccue ( 834797 ) on Saturday February 27, 2021 @12:51PM (#61105990) Homepage

    Python developers cite simplicity

    If history of other languages is any guide, I am sure this issue will be fixed quickly

    • If history of other languages is any guide, I am sure this issue will be fixed quickly

      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

    • by lkcl ( 517947 )

      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)

    by SuperKendall ( 25149 )

    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.

    • by ceoyoyo ( 59147 )

      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)

        by Ostracus ( 1354233 ) on Saturday February 27, 2021 @01:22PM (#61106082) Journal

        Tell him, or help him? There's a difference.

      • 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)

          by SuperKendall ( 25149 )

          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

          • You have obviously never converted JavaScript to TypeScript. Dynamically typed code always is full of bugs... always.

            • Still not sure (Score:3, Interesting)

              by SuperKendall ( 25149 )

              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

            • by narcc ( 412956 )

              I've ported several projects from JavaScript to C -- all with minimal changes. You work with idiots.

          • "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.

          • by tippen ( 704534 )

            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

        • by ceoyoyo ( 59147 )

          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.

        • by pjt33 ( 739471 )

          It's not so much reduction in bugs as finding (certain classes of) bugs early, so that they're cheaper to correct.

      • 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:

        • 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.

        • by ceoyoyo ( 59147 )

          It depends on if the code you write actually matters.
          E.g. go ahead, write a game in Python.
          But you better fuckin write that life support machine in Haskell!

          This is precisely why I said "everywhere."

    • Python has been my goto systems programming language to do tasks for a couple decades now. Bash/Bourne shell programming had a few limits parsing data and stringing that data into arrays and dictionaries. PCREs give me migraines bordering aneurisms so Perl has always been a nogo for me. The best part if pythons is that chances are someone already wrote a module/library for it and you can just call a function that saved you a few hundred lines of logic. Its fantastic for task oriented jobs at the system lev
      • 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. ;)

    • by narcc ( 412956 )

      That's complete nonsense and you know it.

  • by dangermen ( 248354 ) on Saturday February 27, 2021 @01:00PM (#61106016) Homepage

    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.

  • by ptaff ( 165113 ) on Saturday February 27, 2021 @01:04PM (#61106032) Homepage

    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.

  • Static typing might make me want to be a Python developer.
  • 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

  • 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, if you are looking for static types in Python, you aren't using the language properly.
  • by gweihir ( 88907 ) on Saturday February 27, 2021 @02:54PM (#61106304)

    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.

  • Yes, optional.

    Sometimes I want it. Not always, but definitely sometimes.

  • by fabioalcor ( 1663783 ) on Saturday February 27, 2021 @03:44PM (#61106440)

    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.

  • by Slicker ( 102588 ) on Saturday February 27, 2021 @05:28PM (#61106758)

    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

    • Comment removed based on user account deletion
    • 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

  • 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."

  • by EmperorOfCanada ( 1332175 ) on Saturday February 27, 2021 @08:31PM (#61107102)
    I read a story long ago about microsoft developing their C++ IDE (Pre visual studio). They kept shoving in features the top developers in the US wanted, but nobody would buy their garbage product. Borland continued to rule until a new guy took over the Microsoft effort and focused on features joe average developer wanted like wizards to make setting up a basic windows program. Microsoft then proceeded to dominate.

    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.
    • 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 has to be one of the biggest pigs breakfast around, everything is tacked on, even objects. Those double underscore magic variables and methods are pure joy and designer beuaity.
  • I am very fast at typing code on the keyboard. Programmers typing in a static way cannot write code.
  • 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"?

Never test for an error condition you don't know how to handle. -- Steinbach

Working...