Python overtakes Java to become the second-most popular programming language
techrepublic.com
techrepublic.com
Sure, this is a problem of people, not language. But there is something to the argument that absent discipline and experience, these can be dangerous. One can detangle a dog's breakfast in Java Spring a lot more easily.
(ever seen "import gc" in a Python program? yes, that means what you think it means..)
I recently spent half a day implementing a hacky workaround for something using gc. Once I was happy that I got it working, I immediately laughed at how absurd it was and deleted it.
I still don't think I will ever be happier in C++ but I'm only 11 years into python, and 6 years into coding full time, so who knows :-).
One company I worked at had "we hire the best!" as its slogan, and they used it to justify so much bad practice. No code reviews (we just don't hire people who write bad code), no unit testing (same reason), python used for huge sprawling 10+ year old codebases that's on its third or fourth generation of maintainers, and no documentation anywhere. Everything is a spelunking expedition, and there's no type safety or anything to help you figure it out. There are more than a few thousand-plus line functions that make PyCharm chug every time your touch a character.
On the flip side, the Java and C++ codebases were similarly abused (no tests, no docs, four generations of maintainers/oral tradition, no code reviews ever) but are at least two orders of magnitude easier to traverse because the type system keeps everyone honest across decades in a way that dynamic languages just do not.
I'm writing some Java at the moment for an Android app, and it's just killing me after doing Scheme and Python, but I have to admit, if that start-up had used Java or C#, they might have been better off in the long run.
Hiring really good, disciplined people is super, super hard. My current thought is that if you don't have a super-star CTO who can attract and keep real A+ coders, don't use advanced languages. And if you do have that CTO, do it, but make sure you are architecting to make the rewrite in C# or whatever doable when you sell your company. If I were starting my own business now, I'd use Clojure or Scala or F#, and design things so that in 5 years new owners had a decent path to switch to C# or Java wherever they want.
that’s a logical fallacy. chances are that if they used Java or C# they might be dead by now (ie it sucks but usually it’s a good problem to have)
Android isn't Java though. It's some frankenstein contraption made from a mutated version of Java from a decade ago.
> I were starting my own business now, I'd use Clojure or Scala.
I personally wouldn't ever choose Scala for anything. It's tooling is horrible (Sbt is a special hell, and scalac is as slow as a C++ compiler).
I'm currently in a code base like you describe, scala core with a switch to Java. It's not fun. Were stuck with these legacy library and framework choices that don't fit into the Java ecosystem and it slows down development considerably.
Kotlin has wayyy better interoperability with Java
i wonder if Java is judiciously choosing the non crazily digressive parts of Scala, as they both evolve.
So far I’ve just seen a complex and wild stream API that mimics it in practice, without all the mental model behind it.
Oh, and what’s this nonsense with Java Option?! Really?
For better I'd say you should look at things like virtual threads vs async/await or kotlins when vs switch expressions.
The question is: if this support is enough or should the type system be enhanced so you can abstract over/compose a functor and/or a monad ?
The answer to this question is IMO still open.
Screw that... I should have been told sooner
Scalac is as fast as Javac if you don't overuse Scala-specific features which are known to compile slowly - implicits and macros. But it is unfair to use these features and than complain on compile speed or compare it to a language that doesn't offer similar feature set.
Also, in our Java/Scala project it turned out that Scala+Bloop was way faster (10x-100x) at incremental compilation than Java+Gradle. Bloop is based on SBT libraries so there are some things that SBT does right.
"Over the last 12 months, 75 per cent of the most active “buyers” of $100m+ technology companies have been PE firms. This is despite the fact that the combined cash balances of the “Big Five” tech companies is an eye-watering $330 billion. Today’s most active tech buyers are private equity firms like Silver Lake, Francisco Partners, and Vista Equity. Not Google, Facebook or Amazon."
https://ftalphaville.ft.com/2019/01/07/1546862666000/Guest-p...
One of the things that is not obvious to people coming from the VC world is that once the company has gone from VC to PE, it's likely going to get flipped several more times from PE to PE. At a guess, I'd say 3/4 of what I look at are one PE to another. Depending on the firm, they will sell every 3 to 7 years or so.
iain
You used it twice, but it's not on Google...
I don't feel confident when I program in Python, nor in Javascript exactly for the lack of proper typing. One could argue that if you know exactly what you are doing, types can even be ignored, which is kind of true - but they're there to help the developer and his team. I don't see any good reason to use Python over Golang, for example, if we only consider the language itself and the confidence that you get from using a statically typed language.
For any significant Python codebase, I make sure to put extra effort into precise and strict type annotations so I can rely on type safety. Sometimes after fixing all the statically detected type problems, my program works on the first try.
Python was strongly typed from the beginning, before it was statically typed. When you add a string to a number in Python, you get a type error. Python's static type system– which is formally part of the language and has multiple implementations– is an elegant and natural fit to the language. Unlike TypeScript, where the type system is artificial, and restricts what you can do with JavaScript.
Language features that made it into ruby– like blocks and unless– were rejected from Python because they would have made it possible to create advanced DSLs, which is something the language maintainers aim to avoid– enabling the creation of arcane application-specific special languages.
PEP-484 is the static type system's name: https://www.python.org/dev/peps/pep-0484/ (implementations include mypy and Pyre)
That said: I wish you the best of luck!
Source?
It does suffer from an excessive overloading of operators (“a” times 6 shouldn’t work). But that’s neither here nor there.
If Python wasn’t strongly typed, it wouldn’t be conceptually possible to move it towards explicit typing as the current push is.
Now, it’s not statically typed. You don’t get to assign values and interpretations to memory addresses. This is what “performant” people usually defend. But _that_ has nothing to do with typing assuming semantic roles in codebases.
Here are some references (there might be some overlap):
- https://labs.ig.com/static-typing-promise
- https://danluu.com/empirical-pl/
- https://medium.com/javascript-scene/the-shocking-secret-abou...
- https://www.researchgate.net/publication/259634489_An_empiri... (one of the original studies)
I hope it's clear I'm not implying that there are no advantages in using a statically typed language, only that it's often seen as a solution to a problem that doesn't originate there.
PS: what is up with the downvotes? What is this, Reddit?
People always ask me 'how do I become a programmer' the first thing I always tell them is 'you need to learn python it is fairly easy to pick up and learn' I aim them at the python org website and their excellent tutorials. Funny enough it weeds out the people who do not really want to be a programmer but thought it sounded cool, as they have to stop and learn something.
Interesting, one of the most successful companies I've seen in my tech due diligence work was doing the same thing in high end scientific computing. They had written their own DSL, and a whole containing application layer in C that could run on any target platform, with GUI adapters for windows, unix, osx, etc. They were doing very well. And they could get amazing scientists to work for them super-productively because the DSL was designed around the scientists needs.
The reason I'm asking is that that run-time flexibility can completely bite you in the ass if someone can submit code that does unacceptable, unanticipated things. For example, I had an engagement with a company to review their main application, that they host. The issue was that while the app was in Java, it accepted user templates in (IIRC) BeanShell. One quick System.exit() in a template as a proof of concept, and Tomcat came thundering down.
The concept still works of course if you restrict the language accepted to some minimal DSL.
Rails has a lot of magic that gets you running fast but it doesn't even have a service layer - and instead promotes the abomination that is mixins (concerns), fat models, fat controllers - stuff that gets you running with minimal effort but then crying over the code duplication all over the place and lack of logical separation.
ASP.NET is more verbose out the gate but you're basically guided in to stuff like repository pattern, service layer with POCO models, thin controllers and IoC. Static typing gives you guarantees when reading the code (I've seen RoR concerns that relied on random fields being present in target class, but had conditional logic with implicit assumptions about which class it would be included in - it was a hell to reason about). It's verbose but consistent and built to scale - I'll take a dirty ASP.NET project over a dirty RoR project any day.
I'm using it sometimes, what's the issue?
So my own heuristic has become:
shell script when < 100 lines of script
python code when < 1000 lines of code
else statically typed, compiled languageHowever, I have to acknowledge that modern IDEs (and even advanced code editors like VSCode) have pretty good support for dynamic scripting languages these days that make working with them in larger code bases not entirely painful.
These were the go-to "prototyping" languages people in science, R&D, etc. used (and still use!), and then you'd port those into more manageable languages for larger scale projects, or actual software products.
These days, Python does all that. Unless you need some extreme performance for your final product, a well-optimized Python program will work just fine.
But still, there's some of that matlab legacy left - instead of one comprehensive application, you have tons of smaller programs floating around, for one-off/single-issue uses.
I've found that using Python for large projects is both fine and productive as long as you utilize type annotations and modules. Ambiguity goes out the window when you do that.
Besides VS Code, these days lightweight editors like Kate, Sublime Text, Vim, etc can all take advantage of type checking LSP servers for Python.
It's quite good.
In the end I feel, if you really want that, use a language that treats types as a first class citizen. There are languages with most of Python's attractive features but actual optional typing (we use Groovy), or static with really good inferred types (eg: Kotlin) etc.
"Since y'all can't seem to use classes and interfaces correctly, let's physically separate the software so changing the service contracts becomes a bigger pain in the ass"?
I'm not even trying to be sarcastic. I'm genuinely curious. I feel like 90% of the benefits of microservices would be accomplished with discipline and good code review, but those things of course are more easily said than done.
(I understand your Facebooks and Netflixes benefit from having completely separate teams responsible for services with more autonomy, but I'm talking about small to midsize orgs that seem to have adopted microservices.)
1. More decoupling means you can use an entirely different langauge
2. Services can be deployed, restarted, etc. independently.
But that comes with disadvantages. The contract then becomes message passing and serialization/deserialization, which is fairly primitive. You can't pass functions/callbacks, and simple static checks become a whole validation problem. It also limits your ability to use interesting types across services.
The XML craze 20 years ago tried to tackle all of these problems (remember XML schemas?), but it became unweildly and didn't really succeed despite a huge enterprise push.
In certain languages, developers may find it difficult to maintain code quality and good design in a codebase of a certain size. So they find other ways of achieving good design by introducing service boundaries.
I agree with you, asking everyone to be discipline with their code in a dynamic language is a bit too much to ask (unfortunately).
Not job hunting, but always happy to chat with people doing cool stuff sort-of locally.
Fun fact, D language forum website is probably one of the fastest and the most responsive websites on the planet [2], and it's written in D but not based on vibe.d or Diamond [3].
[1] https://code.dlang.org/packages/diamond
Here I go about the batteries included vs micro thing. People pick Flask because it looks approachable but then DIY features in. The same thing happens with Sinatra+Rails. If the python ecosystem grows and other communities come in, maybe they will bring their culture and standards in.
Take poetry for python. It's basically, "hey ... cargo/yarn/mix/bundler all kind of figured out these ergonomics". Poetry's "why" section in the README really resonated with me. Cross pollination of ideas across tribes is _good_.
But then, I'm biased/blub-paradox of course. And it's definitely in line with the productivity/DSLs/rapid vs types/verbosity/slower modes discussion.
I also think rust's ? makes the "return err" pattern much nicer to deal with.
After 30 years of mediocre programming things I hate are unplanned/hidden side effects, train wrecks due to mutable state, and out of control dependencies. Error handling at this point seems like Weltschmerz.
I've seen the same occur with Spring based Java. To me this is similar to the old "no one has gotten fired for going IBM". The new phrase would be "no one has gotten fired for going with a static typed language."
When someone writes bad Java code, we tend to blame the developer. When someone writes bad Python code, we blame Python.
If you think it's the lack of types that make things more difficult to follow, you can always force build failure if type hints aren't provided (which Python has supported for a while now) in the same way you can fail your Java builds if test coverage isn't up to par.
Abuse of untyped ViewBags to pass data to views, using ViewBags to pass things to Helpers, badly configured AOP or XML-based dependency injection, people using Dictionaries/dynamic/JSON instead of objects for passing data between application layers...
As soon as you have escape hatches you get those things that make refactoring a nightmare in large projects and cause new employees to always fail to grasp the full-picture because of how fragile projects were.
In the frontend I feel the same about Vuex. It's a great library, way more ergonomic than Redux and the defaults are great, but the fact that actions and getters are untyped by default in Typescript is a major source of bugs in projects I work on, even in codebases with 100% coverage.
Some people may argue, "but documentation would make this an non-issue". Guarantees built-in to the platform itself are more reliable than human aspirations, or automatic memory management as a feature wouldn't have gotten popular.
Consequently, there was a big disincentive to monkeypatching.
In fact I never thought I'd say this - for the first two years of discovering sum types, I thought they were the silver bullet of computing, and certain experiences have sadly tempered me there :)
I still agree that types _can_ make the flow and transformation of data in the system clearer than if there were no types. Though without experience, we could very well end up with convoluted designs and that can be as difficult to untangle as a dynamic spaghetti.
So a hierarchy of choice for me would be like:
S The languages mentioned above
A Languages with Hindley–Milner type system and inference (SML, OCaml)
B Your typical blue collar languages (C, Pascal, Go, Java, C#)
C Scripting dynamic languages (JS, Perl, PHP, Lua)
The upside with the python code is that a complete rewrite of parts that has get extended beyond recognition tend to be easier than expected.
That sounds like a disadvantage tbh
The best codebases I have touched, in any language ecosystem, either didn't use a framework, or kept the framework firmly isolated from the other code. If you build your code "inside" a framework, it will eventually become an obstacle to change.
Furthermore, the best Java codebases I have seen avoided annotation-driven-development, reflection, classpath scanning, DI frameworks, AOP, etc. Anything that feels at all magical should be handled with great suspicion.
This. True in any language.
In the several years I spent doing .NET consulting, I believe that this is the crux of the problem, and not Python per se.
In .NET land (probably Enterprise Java too), this often manifests as an apparent goal to get every single pattern from PoEAA [1] into every file rather than extensive metaprogramming - but the root cause is the same - juniors not having appropriate guidance.
I don't think so. It is a problem of language.
Or more specifically, of dynamically typed languages (DTL) vs/ statically typed ones (STL).
We know for a fact now that DTL's simply don't scale to large code bases. And before dozens of people tell me there are a lot of large apps written in DTL, this doesn't mean it was a good idea in the first place nor that these large apps are easy to maintain and improve (they're not and they would be much easier to maintain and improve with type annotations).
We don't know that. This is not a fact.
Or they eventually come up with a hybrid micro services.
The real culprits, thinking about it since my post, were side effects and mutability. Python lets you create incredibly difficult to trace chains of side effects and mutations, and has basically no decent ways to prevent this. In Scheme, my code is still super small and I can dynamically create all kinds of object like things, but if I want private, I can make it god-damned private. In Python, anything can be changed by anything ("we're all consenting adults") and using side effects in weird ways is actually part of the idiom. I don't know how many times in Python literature I've seen some variant of "you don't need those baroque patterns because we can use 'import' as a singleton, running class initialization as the constructor". And so all the frameworks have crazy thread-local magic happening from bloody import statements!!! Do that too much and you have no idea what's happening where and why, and something as trivial as changing the order of imports can kill your app. Where I was, this had gotten so bad that the app couldn't even be turned on and tested in the normal way, and none of my predecessors had been willing to go through the pain of figuring out what the chain of imports were doing to bugger it up. (Because that didn't look like doing anything productive, I'm sure you all know the drill...)
If I were doing it again, personally, I'd use Clojure and Spec, and worry more about mutability and side-effects than anything else. Just my two cents Canadian.
Actually, I find Nim language [1] to be a great alternative to C++ as far as compiled, statically typed, high performance modern languages are concerned. Moreover, Nim's meta-programming capabilities (generics, templates, macros) are second to none for creating elegant DSLs. And its syntax makes Python developers feel at home. Preempting questions about garbage collection -- Nim allows to switch off GC and manually manage memory if a programmer so desires. Or you can manually manage memory in some critical parts of your program while letting the rest be garbage collected.
Elixir is all about immutable structs and pattern matching. I don't think "hyper dynamic" is a fair characterization at all.
Yeap. I ended up dragging my team to Golang due to this. Sure they didn't write unit tests and they still aren't writing unit tests. But at least now a compiler will take a look at the code before it's run. Lots of stupid errors at runtime disappeared.
For personal projects? Something like Python, Lua or Scheme is great. It can still be great in large teams, but they need to understand and care about what they are doing.
> but I would have been happier stepping into C++
Oh no you wouldn't. That's the nuclear foot gun.
I've been tasked(along with some great engineers, most more experienced than myself) to fix a mess left by two other teams. A project that was severely over budget and very late.
It was the worst abomination ever known to man. Crashes in random places. Race conditions. Global variables. Memory corruption galore. Lack of understanding of C++ in general (copy constructors, assignment operators, initializer lists) leading to many more bugs. Leaked like a sieve.
A lot of this wouldn't be possible in other languages (memory corruption in general). Some issues would happen no matter what (two modules opening the same file and writing on it simultaneously), unless something like Rust or Haskell was used to make this more difficult.
So far, that's the only project I've contradicted Joel Spolsky and it was completely thrown away and rewritten. Again in C++ because that was the requirement, but with proper modules this time, smart pointers and the like. It was completed in 3 months.
All of these are trivially detected with msan, tsan, lsan and ubsan.
This has serious implications for how you develop large systems. Don't try to get too sophisticated on a larger or longer-lasting project. You'll have people on it who won't' be able to play at that level, and if you try to make them, they'll make a mess.
The same thing happens over time. Sure, your team is only 20 people... today. But if the program lives for three decades, how many people will work on it? 100? Will they all be superstars? Even those maintenance people you hire 20 years from now? Probably not.
Yes, I see it all the time. People think that `gc.collect` collects all the garbage, but that's not true. It only checks for reference cycles.
Engineers are perpetually keeping mental tallies and notes in search of data on which tools, methods, and technologies will help them reach the promised land. I think really the majority of that is noise.
I agree on this part. The problem is many teams with 5 Ruby programmers is doing what 100 Java programmers' work. There would usually be many teams in Java projects, and nobody have full picture of the project. Then people would create jobs out of nowhere because they have to do something... Just see how many projects have dedicated teams writing piles of code for Kubernetes.
I would rather hire much fewer elites for higher price instead.
Personally I believe this is exactly why Python is dominant in ML now. We are harvesting after 20 years of academics happily writing libraries and tools for academic work in Python. :-)
So I have no idea how the article got their numbers, but I'm not at all surprised to see the sheer number of people programming in Python exploding.
Since there are many questions about the way the TIOBE index
is assembled, a special page is devoted to its
definition. Basically the calculation comes down to counting
hits for the search query
+"<language> programming"
In the next few sections it is explained what search engines
qualify, what programming languages qualify and how the
ratings are exactly calculated.
Search Engines
There are 25 search engines that are used to calculate the
TIOBE index. The selected search engines are the 25 highest
ranked websites of Alexa that meet the following conditions:
The entry page of the site contains a search facility
The result of querying the site contains an indication of the number of page hits
The results should be available in HTML with clear tags
Search engines in languages with special characters should be encoded properly
The search engine should at least return 1 hit for 1 query
The results of querying the site shouldn't contain too many outliers
Porn sites are excluded
Gave me a laugh. Engineers would initially qualify a porn search engine to search for this sort of experiment
Most of us really underestimate what "non" programmers can achieve with if/else, loops, equality tests, a repl and autocompletion.
It's like being an anaerobic bacteria complaining about the abundance of oxygen in during the Cambrian explosion.
"Back in my day no stinking, puny, oxygen breathing things were around, only sturdy creatures such as myself" :-)
Yeah, it was messy, but that's how we were able to have humans, hundreds of millions of years later.
I've found the reliability and tooling really unsatisfactory, at least compared to Haskell.
The libraries are there, though, and familiarity is in the departments (psychology (maybe more R?), physics, &c.)
Some people just stick to the basic stuff but there's plenty of other, more complicated programs that are developed by academics/students. Guess what they're going to use? The language they first used to make that pretty graph.
You had Matlab, R, Octave, Java, C++, Lisp, etc. all depending on what type of scientist or engineers you worked with (Statisticians used R/SPSS/etc., Physicists and Electrical Engineers used Matlab or C++, Computer Scientists used Lisp etc., and the list goes on)
At least today, most is written in Python - only the libraries are different.
Also, sharing code is a breeze today. Back then you'd have to download or manually transfer the codebase from other users, check dependencies, install software, check licensing, and what not.
Today you can fire up a Python notebook, and that's it - very nice for smaller stuff. Even larger applications is a easy as pie.
Trained as an EE and this is true. We used MATLAB/Simulink for signal processing and control systems. Octave, too (because our sensor technology teacher was more comfortable with that). x86 and Microship Assembly, C, and Pascal. Used LTSpice and NI Multisim for circuit design and simulation. Cadsoft EAGLE for printed circuit board (PCB) work. Played a bit with LabVIEW.
However, I started coding as a child with BASIC/x86 Assembly/C/Pascal/VB/Delphi. Doing mostly Python for the past several years. I suppose one could find reasons to "love" or "hate" anything, but I always found that nuance keeps sanity.
Julia is on the radar but even in Julians’ wildest dreams Python remains relevant through PyCall. Why rewrite it if you can reuse it? (Obv I refer to boring-to-write non-performance-sensitive code here)
Confession: Code quality is a problem. I care a lot about code quality. My team recently brought on a couple of people with real programming background, and I've asked them to help me bring myself up to date on good techniques, and it has helped. I was lucky that some of my former training, e.g., in Pascal, was not just about how to program, but actually how to write good code (for its time).
But here's my view. Don't just tell us that our code sucks. We already know it, but we're under the same pressures as anybody else, and programming is a force multiplier that we won't give up. We need instructions that we can understand at our level, that will help us do this stuff better, perhaps incrementally. Starting with a strict discipline is hard, but Python supports the ability to go back through working code and improve it.
- tests (unit, smoke, acceptance) (eg. https://mattsegal.dev/alternate-test-styles.html, https://understandlegacycode.com/approval-tests/)
- continuous integration (via GitHub actions eg: https://mattsegal.dev/pytest-on-github-actions.html)
- 10x performance improvements via cProfile (https://julien.danjou.info/guide-to-python-profiling-cprofil...)
- getting fast feedback on code changes by visualizing outputs with Streamlit (https://www.streamlit.io/)
- input parameter validation (eg. https://pydantic-docs.helpmanual.io/, https://mattsegal.dev/cerberus-config-validation.html)
- total automation of data processing job (eg. https://www.prefect.io/ - we don't use this but that's the kind of thing we have)
>I've asked them to help me bring myself up to date on good techniques
Here's an old draft of our onboarding document[1], and a few comments here on HN about this[2].
PS: in case anyone is wondering how I found the segment in question, I use a Chrome extension called "YouTube Captions Search"[3] went to the video, activated closed captions, clicked on the extension's icon, and searched for "geographic" because I remembered that the system the student had built was a geographic information system (GIS).
- [0]: https://youtu.be/iOp0mSDCh6c?t=1084
- [1]: https://jhadjar.gitlab.io/kbase/hiring/#resources-to-learn-o...
- [2]: https://news.ycombinator.com/item?id=15576496
- [3]: https://chrome.google.com/webstore/detail/youtube-captions-s...
Python is certainly #1 in ML, for example, but far from #1 in web.
I had a "which stack" argument with a client recently for a web server processing tons of data. He wanted to use Node (which I hate, but also use when performance doesn't matter because TypeScript is so good).
I showed him that the Node library ecosystem is actually pretty weak (many libraries, but most abandoned, single-contributor, and/or low-quality). Of course, browser libs for JS are amazing.
My point is just that mixing all these things together in popularity rankings is pretty meaningless.
To say nothing of trying to get patches into the core. Be prepared to wait months for any response at all, every time getting the feedback that there is some new minor problem (or even worse, a "this needs to be talked about" without any followup).
It's not a healthy ecosystem. For that you require high-quality core libs, a strong developer ecosystem (that doesn't mean a lot of devs, it means good ones) and a culture of third-party libraries being few but high-quality. Anything else is going to end up pissing you off, guaranteed.
I haven't tried Spring Boot, so I can't speak to that, but gather that a lot of people like it. Otherwise, though, it's kind of a mess of too @#$% many options and no clear winner aside from the legacy stuff that nobody actually enjoys working with on the flagship language, an alternative language that was initially promising for web development but ultimately collapsed under the weight of its own creeping featuritis, an alternative language that collapsed under the weight of efforts to turn it into Jonathan Livingston Programming Language, an alternative language that collapsed under the weight of a cult of personality, and an alternative language that looks poised to collapse under the weight of Oracle v. Google.
I too find it annoying that everything feels like early 00s as it prevents uptake; I think most can be fixed by creating a new, modern website for the project, adding examples how to interact with the system with modern tools and a 'try it out in your browser'. Many Apache projects, for instance, are great and very robust in the current time, however, when you go there to do research on what to use for a new project, the examples start with XML files and then Java classes. No matter what I think of node, examples these days must include a little few-liner with node, python, go, curl, java, clojure, ... . Most people like the idea of java -jar somethinggreat.jar, but opening IntelliJ, adding all kinds of arcane (when you are used to Go, Node, etc) artifacts and then writing actual Java code which you did not want to do in the first place, really hurts adoption imho. And made many projects not even appear on anyone's radar.
Like (anecdotally) picking mongo for a (trading) case geode was basically made for, but mongo was hip, not 'old apache' and not 'old java'.
The declining interest in Java is offset by Kotlin, Scala, and Clojure.
Did the Dart guys somehow gain massive momentum? Or is Electron or React eating this up?
I dismissed everything else pretty quickly for being too limited in what platforms I could target. Kotlin's out for being a poor choice for iOS. Dart/Flutter is out for not yet having fully baked desktop support.
Not only better library ecosystem, more performance and tooling.
The performance lacks somewhat and the debugging tools are not as mature as JVM's. But the libraries, frameworks, and overall development productivity are great.
* Pre-confugured prod/dev/test environments
* Preconfigured webpack for the environments above
* DB migrations
* telemetry/metrics with live dashboard
etc
P.S. encrypted signed cookies, changesets (validations for db models or arbitrary forms), clustering, websocket stuff, "liveview" serverside rendering ...
That said, I've seen that "liveview" thing demoed and that is definitely pretty slick. Off topic but it's very similar to a package I implemented in Django like 6 years ago or so (and happened to name it the exact same thing, too) --- sadly was for work in a proprietary setting, although I'm off-and-on working on remaking it now for a different project where I can open source it.
The original project I was discussing ended up going with Kotlin on the server, and everyone (including devs) are super happy with it.
I program in Node/JS currently and programmed in Java about 10 years ago. But my preferred language will always be Ruby. I will never understand why "the community" (ML, scripting etc) preferred Python to Ruby.
> Try vanilla Node/JS if you want a faster Rails.
Understanding now that you meant development velocity (or whichever term), I contest that static typing is in impediment in general, but rather that it's an impediment for people who aren't used to it. Especially for those who don't care if their code is correct or if it only appears to be correct superficially, although someone will inevitably (and authoritatively) drag out some decades-old study which finds no significant benefit to static typing when comparing Python/Lisp to C++89/Java or something.
That goes away with experience. Typescript can be particularly bad because it has in incredibly complicated type system (to accommodate all the wacky things you can do in JS), but after you get "used to it", the puzzled pauses become fewer and fewer. Eventually it's no inhibition whatsoever, and actually makes you faster because of IDE code completion, refactoring, and bugs caught by the IDE/compiler.
This is that "blub" thing people talk about.
Types are like living documentation - a contract between devs that describes and enforces specific behavior. Just because you know what properties an object contains now doesn't mean you'll remember it in a month, or that the dev who inherits your work will have an easy time figuring it out. I feel way faster when I code using types, because the type system tells me exactly what I'm working with at a given time. This ends up preventing lots of bugs and makes debugging errors that do happen way easier, in my experience.
So TL;DR types seem slower at first but the dividends are paid in full, and then some, when you have to maintain a project among many devs or teams of devs.
EDIT: not to mention that IDE autocomplete features often seem like a superpower when working with static types. I'd recommend Typescript for that reason alone, honestly.
Here are some stats that you could and should take with a grain of salt: https://w3techs.com/technologies/overview/programming_langua...
My anecdata also says neither Django nor Flask are very populate. I have yet to encounter either one already in use by a client. Rails is also rare. I think scrappy startup frameworks are a different population than what most devs (who work at big firms) use.
[Access to this page may require you to create an account.]
For years, IEEE has ranked the top 55 languages based on five use cases typical of IEEE members: overall, web, enterprise, mobile, and embedded, and ranked three ways: trending overall, in demand for jobs, and used by open source.
The 2020 results, ranked overall:
1 Python 100.0
2 Java 95.3
3 C 94.6
4 C++ 87.0
5 JavaScript 79.5
6 R 78.6
7 Arduino 73.2
8 Go 73.1
9 Swift 70.5
10 Matlab 68.4
11 Ruby 66.8
12 Dart 65.6
13 SQL 64.6
14 PHP 63.8
15 Assembly 63.7
16 Scala 63.5
17 HTML 61.4
18 Kotlin 57.8
19 Julia 56.0
20 Rust 55.6
21 Shell 52.0
22 Processing 49.2
23 C# 48.1
24 SAS 45.2
25 Fortran 43.0
26 Cuda 41.0
27 Visual Basic 40.3
28 Objective-C 38.9
29 Delphi 38.6
30 Perl 38.2
31 Verilog 37.6
32 VHDL 36.7
33 LabView 36.7
34 Elixir 35.8
35 F# 34.7
36 Prolog 34.6
37 Lua 34.4
38 Lisp 33.0
39 Ada 32.8
40 Apache Groovy 32.0
41 Scheme 31.4
42 Haskell 30.8
43 Cobol 30.4
44 Clojure 29.8
45 ABAP 29.5
46 D 27.7
47 Forth 23.7
48 Ocaml 23.7
49 TCL 22.1
50 LadderLogic 19.5
51 Erlang 18.3
52 Eiffel 16.5
53 CoffeeScript 15.9
54 J 14.3
55 Racket 0.0
Do keep in mind that one of the reasons people choose Python though, is exactly because it is used in a few different domains. E.g. I'd rather my server-side language be the same as my video-processing language be the same as my data-science language, it makes things easier.
Quote: "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. "
According to this index, "Logo", beats out Rust, Scala, Kotlin, and Cobol.
I cannot remind myself when I last time saw a course, book or even any source code covering Logo.
This must be some very poorly vetted, automatically collected data that tripped over something provoking the ranking.
[1] https://insights.stackoverflow.com/survey/2020#most-popular-...
SQL is justified though. I’ve met quite a few BAs or DBAs who can do magic in a sql developer suite but don’t have a programming bone in their body.
Besides that it's also influenced by how good the language is at explaining to the user what is going wrong. Clear error messages mean the user uses StackOverflow less, while arcane errors would mean they need to look for longer for the solution for their issue.
What this means is we have no idea if the sample of programmers is representative of the worldwide programmer population.
I'd argue that C# and other Microsoft languages are vastly under-represented in the SO survey, but we have no way of knowing if that's true.
StackOverflow is also a place for asking questions. C is a relatively simple language and one which has been around for longer than most developers have been alive. There may just not be much left to ask about it.
We sure are using more apps than ever. But I think we are also using more "smart" things than ever, and not just in the buzzword sense.
A ton of everyday object now have chips, from toothbrushes, thermometers, door bells, car keys, fire alarms, lights, even charging cables.
Considering drivers are coded for every variations of these appliances and chips, it look to me to be a tremendous amoubt of code written all over the world. Especially as writing code is cheaper than adapting hardware, even different uses of the same chip could get different drivers.
This only represents the sad state of Javascript documentation, I think.
Of course.
> ...their JavaScript Documentation is impeccable?
Well, no. MDN doesn't answer the questions everyone has: "Which browser does this work on?" "Is it okay to use this new feature?" "Why does this buggy thing do this to me?" "Is it really true that you can't do <simple thing> in CSS"?
Etc. Web standards really aren't. (And I'm not even touching the third-party library churn problem here.)
(The parent link has a quote from TIOBE CEO that illustrates they are not considering only professional software engineer use)
JavaScript is easily number one for reasons that will surprise nobody. On the WakaTime public leaderboards it dominates to such an extent that I think programmers spend more time writing JavaScript than all the other languages combined. I don't know if that generalizes to the broader population, but it gives one an idea how ubiquitous it is.
But I don't know what you do for a living but in general Hackernews tends to have webdev tunnel vision. Embedded, operating system development, browser development, OS, driver dev, games, telecoms, compilers, lots of IoT, systems development generally, all of this is in C/C++, and will be for the forseeable future.
That is a lot of lines of code, but mostly invisible to people whose role in the industry is "full stack development" type jobs.
Now, if you strictly interpret the "C" in this popularity nonsense as "C", then sure. Pure ANSI C has a fairly restrictive use environment. But "C/C++" is a much much larger ecosystem.
Also get a laugh out of the people here calling C "simple". Ho boy.
I'm well aware of the things C and C++ are used for. I'm currently mostly working in Rust at that moment to make use of libraries in C++. But I think web development easily swamps that kind of work in terms of number of developers.
does it though. IBM alone, a service company, has 380000 employees. And there are tons of service companies like that - at least in my country they are mostly doing Java and the like.
Get a thousand random developers and ask them to list all the languages they know well. What do you think will be the most common?
C seems quite realistic given what they measure.
So I guess it just doesn't count JS developers as skilled engineers?
It also didn't have the simplicity that Phoenix / Elixir still has, for example when you Google how to solve problems you have Python 2 versus 3, the old way to handle requests which is limited and the new way to handle requests which isn't as documented, yes you have type hints and named arguments but they're not everywhere yet and so on.
So I don't think I will circle back to use Python again unless there's some kind of reason I can't easily go around it. There are still some very good ideas in there (I like the braceless approach to code hierarchy and a standard on code formatting in general) and it's definitely not as dumb as JavaScript but it has accumulated too much cruft.
Python definitely doesn't have conceptual simplicity, because there are many competing concepts in the language, and lack of focus on uniformity. (Example - enums are implemented with a metaclass and dataclasses with a class decorator - arguably the latter is the wrong choice, because it is already evident it limits what kind of features can be added to dataclasses).
Another example just because it makes me irate - `typing.NamedTuple` has been added as an "alternative" to `collections.namedtuple`. Same name, new capitalization, slightly different features. Add to that, a collection type that's inside the module `typing` which is supposed to be for.. type annotations, not actual implementations.
> (Example - enums are implemented with a metaclass and dataclasses with a class decorator - arguably the latter is the wrong choice, because it is already evident it limits what kind of features can be added to dataclasses).
I'm curious about what features can't be added to dataclasses because it's not using a metaclass.
If anything, I think that not using a metaclasses is a good thing: it allows you to use @dataclass with classes that do require a metaclass. That metaclass would likely be incompatible with the metaclass that such a hypothetical @dataclass implementation would use.
The reason it's not an option by default is because it would be the one case where the decorator would have to return a new class, and I didn't want to do that on the first version. As it is, @dataclass just modifies an existing class. I might bite the bullet add a slots option, and we've had discussions on adding a language feature to automatically add slots to a class, based on annotations and maybe some other magic. If we did that, we wouldn't need to return a new class. But it's not a front-burner task for me.
Thanks for working on dataclasses :) - as I said, it's my #1 new feature in Python.
But still, I think not using a metaclass is the more flexible design. Maybe I'll add the "add_slots" behavior into the @dataclass decorator in 3.10, even though it would need to return a new class. At least it could be well documented, and I doubt it's a concern for most people.
> Thanks for working on dataclasses :) - as I said, it's my #1 new feature in Python.
I'm offended! I also wrote f-strings, but maybe that's not considered new anymore. In any event, you're welcome!
I have diligently converted to f-strings but it doesn't give me new expressibility like I feel dataclasses do, just convenience :)
What's it called? Google didn't turn up anything.
Pyre and PyCharm are third-party implementations of PEP-484.
EDIT - just want to add: I'm not au fait with the specifics of Rust but I presume from what I've heard about it that it also supports my position, as an advanced language, that the features you need are in the language so a heavy-weight IDE isn't so necessary.
Could you elaborate on this?
Though Python can look a bit more clunky than modern JS.
Requests is one of the modules that had more change on 2-3, but being basically the most popular language (for good reason), it’s pretty easy to find documentation for either version. I imagine a lot more than for Phoenix/elixir whatever that is.
I think you’re being difficult for the sake of being difficult. I am not a leet programmer and that is why I use python- it does everything for you very well and no more. If you want more “cruft” pip install cruft
It reminds me a lot of JavaDocs, although I never used them extensively. I'm also not very aware of how documentation looks in the Python world.
Another interesting thing is the code examples. You write them in the comments as "Doc tests", and they are run and tested like normal tests. This means that all the code snippets are up to date with the latest version of the project (as long as you do test!).
The best part, also imo of course, is that it all works out of the box.
See e.g. https://www.sphinx-doc.org/en/master/index.html and https://docs.python.org/3/library/doctest.html
Why? I was just trying to get something done that I've done in a variety of different languages already so there's a perfect comparison.
> I imagine a lot more than for Phoenix/elixir whatever that is.
I don't know how you manage to come to Hacker News often enough to find exactly my post to answer to but at the same time managed to have never heard about Phoenix/Elixir. What's the point of coming here if you're not interested in staying current in your field?
My Python setup is as follows:
* vscode
* pylance
* black formatter
* flake8
* python typing annotations used as much as possible
This seems to work very well with regards to autocomplete and preventing run-time errors.
One thing I do miss is proper refactoring support.
You should try PyCharm then. That, and their debugger is orders of magnitudes better than VSCode.
The debugging support in VS Code is fairly good, so it's just the refactoring I'm missing.
I'll give PyCharm another go when I get some spare time.
The first reads like english, the second doesn't.
Python is really a Perl replacement. It was meant for the scripting world, not software development - pretty much stuff that was too complex or cumbersome to do in bash.
It mainly seems to massively overvalue historical significance, the older the language the higher it is. E.g. the current ranking has Perl 5x more popular than Typescript, and Visual Basic 2x as popular than PHP.
It's definitely the case that Python is very popular though. It's everywhere. As others have pointed out, it's become very prevalent in scientific/academic circles. Outside of that, it's very useful for scripting. They teach it in universities as an introductory language. It's in use at every workplace I've been.
Since I started to follow it systematically (mid-2019), the trends I perceive are: Java or Scala -> Kotlin, JS -> Typescript, Angular -> Vue. Growth of (non-web) Python, React, Go and even PHP. Besides Kotlin, mobile tech demand seems stalled (Swift, React native, etc). Frontend demand is shrinking.
I also wonder, thinking back over my experiences and reading others here, if we are mis-ordering how these things come to be. Maybe it's not that python codebases are, for a given line count, worse than other languages. Maybe it's that python allows teams to continue using practices that aren't suited to their current scale longer than other languages. The reason that we all have seen hulking, monstrous, nearly unworkable python code bases is that most other languages would have already collapsed under the mismatch between approach and desired outcome.
I think we often approach software engineering as a puzzle - where you have a set of inputs (a too-large codebase, for instance) and a question of how to a better state. But programming projects are path-dependent creatures. Huge codebases must develop over time - they don't spring out of the heads of developers fully formed. If you were a typed language and your engineers had a lower LOC output per-day, then of course your code base will be smaller. Is that better? You iterate more slowly, but the scale of your code is also more manageable. In my experience, the challenge of large python code bases comes from the context that you need to understand from the surrounding environment: what are all these objects, what are their objects, etc. Typed languages force you to carry around more context, so any given function is easier to read, but you can still write un-navigatable code.
I remember trying to write a program to simply understand our dependency graph so we could decouple some of our services (we were just starting our SOA efforts at that time). This is something other languages give you for free.
Our build times were exceptionally slow, as a direct result of Python's dynamic nature. For example, test discovery took over 2 minutes on each test run. This also made it painful to have distributed test runs, as splitting up tests across multiple processes would require the test discovery step to be run in each process, incurring a 2 minute penalty per process.
We also had deployment issues, because of Python's dynamic nature. Some code paths were only exercised during a production deployment, and were not sufficiently tested before deployment. This is despite the fact that we had tens of thousands of tests and sunk many hundreds of person-hours into testing as much as was possible. Despite a very professional engineering culture, and a constantly expanding test suite covering these corner cases, we had deployments fail about once a week for this reason.
I adore Python and still use it extensively most days (mostly its data science/ML libraries). But I now think that large projects would really benefit from static typing and strict compiler checks, as well as just being able to actually compile a binary (which would have solved many of our testing woes). In contrast to some other smart people on this thread, I don't think that even disciplined developer teams should use Python for large projects, at least not in the long-run.
But the language problem remains. I think there are a lot more good language options today for backend services than there were in 2010, and if I were writing new backend code for a big website/service today, I might pick one of those.
Along the same lines, IoT depends heavily on C and even stepping out of that, pretty much every piece of silicon requires extensive C code to be written around it.
I still wonder about JS though. Billions of websites with JS and the JS gets rewritten every few years (or less during the framework wars period).
So, at least some of the gains are at the expense of Java.
For C and C++, you're probably not going to reach for Python as a replacement. It's not like in the 90s when these were considered general purpose. If you're using them these days, it's more likely due to needing to use them.
Java is still used for a lot of other things where a language like Python would be fine and likely more productive. Also, I have a feeling that the large growth in go from #20 to #13 likely also came at the expense of Java.
That, and the pie is growing. Python is taking a larger share of the larger pie.
The only one that is growing, although I rather not, is Go, as we now start to jump into the same container bandwagon as everyone else. And even there it isn't taking anything away from our Java/.NET setups, rather complements them.
As for Go, when they adopt generics, until then I rather spend my productivity in Java and .NET land, and only deal with it in the context of containers eco-system.
But for my personal experience Go's concurrency features, type system, and simplicity is pretty great for getting up and going quickly with performant code.
Um... nobody _loves_ Java. We use it, but we don't love it.
You can still run into something old and enterprisey, but Java is much less baroque than it used to be for getting things done.
Is there someone well-versed in a statically typed language who would still prefer python most of the time? Could you explain why?
For me it's just the opposite. When I program I think about the types first. When I read code I care more about types than variable names. This is in my opinion the way to go even in C.
Also most python programmers I know are engineers and for them it would be a waste of time to learn C++. I would like to know why an experienced developer might prefer python ...
The easiest example is web applications, especially internal ones, which are essentially shuffling JSON messages around from different SaaS and internal APIs. Adding (and testing!) a different ApiResultSerializer in between each of these points can become a huge headache when everything boils down to JSON string or number in your result anyway.
Though I do use C / C++ (recently some Rust) where business problems are not the priority, and I can focus on technical efficiency / correctness.
The reason for this is quite simple. A static type-system, by design is meant to invalidate programs which are incorrect and accept the programs which are correct. All static type-systems which exist invalidate a certain number of programs which are correct — that is to say, you can write a perfectly valid program, but the type-system can reject it. What we term to be a more expressive type-system, is one which rejects more programs. The line which one draws in the sand as expressive enough is completely arbitrary and the type-systems we have currently heavily rely on the user constructing their programs in a certain way, so the type-system can prove certain properties about it.
Here’s an example demonstrating what I mean. Consider a theoretical language which uses : as the type-ascription, has generics/kinds and all functions are total. A code-snippet taking the head of a list might look like this:
> let num: Option<Number> = head(numberList)
Note that the return type of the head will be Option<A>, if the function is total because the list can be empty. Now suppose I have the snippet — locally I can reason that the type of num should be Number — but I need to prove that to the type-system. In most current type-systems, proving this requires you restructure your code in a particular way.
> let numberList = prependList(4, previousList)
> let sortedList = sortList(numberList)
> let num = head(sortedList)
What I’m trying to drive at is that static type-systems are a spectrum and at some point you will run into a case which you’ll either need to use an escape-hatch or restructure your code in a non-trivial way to satisfy the compiler. The boundary of what you determine to be correct is also completely arbitrary — you can always encode more properties and restrict your code further; how far you go is ultimately determined by you.
I'm aware of the fact that every type system will reject some valid programs. C evades this problem by letting you "escape" the type system. Many people criticize this without being aware that the language would be useless without this feature.
I don't think that an expressive type system rejects more programs though. You don't have to escape the type system that often in C++ (compared to C).
Nonetheless I probably should look up some design patterns you can do in lisp, to get a feel for what I'm missing
By adding stricter typing and a bunch of middleware I can easily imagine a Python EE one day but let's hope that doesn't happen. Duck typing, a taste of functional paradigm, non-verbosity is what makes Python special IMO.
I wonder if Go, Rust might make it to top C one day.
This and the fact that C is number one suggest something very wrong. While C really has a place in my heart, you should have very good reasons to use it when "starting to build a new software system".
And three of those very good reasons are:
1) you're writing a library and you'd like to make it usable from a number of other languages as well, the most popular of which are at least partially implemented in C or C++ themselves to some degree, eg. Java, Python, Perl, Ruby, Haskell etc. Writing said library in C (in particular) makes the library much more accessible from those languages.
2) the platform you're writing for is partially if not largely written in C or C++, the most popular of which are Windows, MacOS, Linux etc. So the toolchain/runtimes used to build the systems are already supported, extremely mature and well tested.
3) the platform you're writing for is especially space constrained (eg. embedded Linux), also fits the criteria for (2) above, and where performance may also be a factor due to reduced CPU/bus speed, availability of RAM and storage. For every interpreter or JIT compiler you want to add to those kind of systems for a higher level language, you can normally fit a larger number of C or C++ programs to implement your device's required functionality.
There is far more years of effort required yet to overcome the inertia of the above than the average HN webdev would realise.
IME Java still has a very real stranglehold on business logic code, especially in bigger companies.
Golang and Rust are eating away at it, but more for infrastructure related projects rather than higher-level business logic.
This is an important distinction and often missed from programming language discussions.
Engineering languages like C++, Java, Rust focus on being able to create robust APIs, handle incredible complexity, deal with dependencies, etc. Hacker languages like Python, PHP, erlang, and Go focus on an approachable language, libraries that tackle problem domains, etc.
There is obviously a lot of overlap. But I think it's good to keep in mind that engineering and hacking don't always align.
Something else to consider is the Python shell at python.org/shell. Students often have Chromebooks. I'm about to mentor second year high school students who are interested in CS. Several of them have Chromebooks only. I can recommend Python and point them to the shell.
I would think Python got a good bump through Hour of Code and other programs to introduce people to coding.
Still, with C bring #1, one has top wonder about the quality of the index. Both Python and Java are much more common in the business.
Although such rankings are mostly good for entertainment, I'd whish there were a better, more solid index. Redmonk is better, but a bit too limited in its data source (Stackoverlfow and GitHub).
These ratings seem pretty meaningless. Visual Basic is #6, tell you pretty much all you need to know.