The Python Paradox (2004)
paulgraham.com
paulgraham.com
Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS.
Crystal is a neat typed, compiled Ruby-alike but it's buggy.
Rust hits more of these but it's ugly. Uglier than Python and approaches C++-level eyebleed. Rust generics aren't as flexible as they could be because type constraints don't have union and specialization is painful. Tag structs are laborious. Go hits more of these except it's not as flexible and not quite as safe as Rust. Rust makes enormous binaries and compiles slow and the cargo index download is glacial, I'm surprised they don't have an "sccache" for it. Go is easy to learn but then the capability of it plateaus. Go compiles and tests insanely fast.
Rust should rebase its type system to have union types, i.e., foo: i32 | f32. Also, more granular and specialized type constraints (negation, union) on generic trait parameters.
Elixir (on erlang) can be productive. It's gorgeous, it's fast, it's powerful, and fairly expressive.
Haskell and Idris are beautiful and powerful, but inaccessible to most software engineers.
Pony is beautiful, productive, extremely safe, and fast.
Zig, Nim, Kotlin and friends are all moving in the right general directions. Swift is alright too.
Have you ever hit F12 on any C++ std function or data structure? Every time I do it genuinely feels like I'm back at day 1 freshman year of an undergrad CS degree.
https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a0109...
Honestly I don't think it's that bad if you can look past all the underscores. I looked around for something worse but maybe I'm just accustomed to the eyebleed that C++ has to offer. To me, Rust is uglier, but that's because it's been around a quarter of the time that I've been using C++ and I don't know what all the symbols do without looking up a cheatsheet.
The problem with C++ template metaprogramming style is symbol length, the notation ordering (insane levels of nesting), and diagnostics generated from those that easily turn into absurdity.
Another issue is static languages lack universal diagnostics, introspection, and symbolic evaluation capabilities of dynamic languages with REPLs and remote debuggers.
Dynamic languages are often missing "compile" (deployment)- or at-boot-runtime type checking, data race condition borrow/mutability/concurrency analysis, and monkeypatch protections.
I don't see any fundamental reason why that should be the case. It seems to me that while it's true that most engineers would have a hard time navigating these languages today, it's mostly due to socio-historical accident. It's not because the languages are particularly difficult or arcane, it's mainly because people don't already know it, and people don't like to learn to do things differently: their experience stands in the way.
The main decision I am thinking about is lazy evaluation. Lazy evaluation forces authors to write pure code, which drove Haskell’s community to build libraries that expressed effects in the type system, which made things like STM possible. If I wanted to design a Haskell-like for industry use, I would give it non-lazy evaluation (I’m not gonna say “strict” because I think the compiler should be free to omit the evaluation of any expression, but it sure would be convenient if we had more predictable performance characteristics).
I’m also not saying that you can’t use Haskell in industry. Obviously, people do that.
That said, the type system _does_ stand in the way of learning it - though it's very powerful once you get your head around it - and lazy evaluation means you do spend more time than you'd generally like hunting down space leaks if you're writing the sort of code that's capable of getting space leaks.
It may be subjective, but even for the syntax I felt a much stronger cognitive load working with Haskell.
I beg to differ. I studied compsci BSC at an eastern european university. The professors decided to test that theory and decided to introduce programing to everyone in our program through Haskell. Every year about 500 new students were thaught Haskell. I don’t know a single one of us who stuck with it. Probably there are a few odd ones, but if it were only a question of familiarity you would expect that more people from there would keep programing in it.
A lot of us here have read "Learn You A Haskell for a Great Good". We've used it.
It's not a socio-historical incident, and it's not just beginners who struggle with the language either.
Your point is perfectly valid. I'm just saying the thread has just become a sequence of assertions and not particularly enlightening.
I'm somewhat of a fan of Haskell (though its standard library is awful) and very much a fan of Idris (at the very least it's a better-Haskell, at best, dependent types!), but hard disagree.
These languages are difficult and arcane, compared to eg Python. A beginner to programming can get started with Python immediately, it reads like pseudocode.
Get started with Haskell or Idris, you quickly hit higher kinded types, monad transformers, free monads, final tagless. It's a different universe.
How is any new developer hitting any of these "quickly"? I'm working on a mature production codebase with plenty of advanced Haskell, and we barely have any tagless final code - much less free monads. Even HKDs and monad transformers are relatively recent additions to our toolbox that we reach for when appropriate - most of the code uses plain old datatypes and one or two concrete monad types.
My experience of learning Haskell is that many production codebases use advanced features because they are big boons to productivity, but few learning resources make reference to them. In fact, Haskell's biggest problem is probably the gap in knowledge between simple, low-productivity code written by newer developers, and the kind of code that actually goes into production with all the optional advanced features. A budding developer can easily write a whole application that never goes beyond `IO` without issue.
And yet everyone in my intro to CS class in uni managed to pick up Java within a week or two. Haskell is a bit more involved than Python, but not more involved than most languages.
Rust has ADTs, so I'm not sure what you're saying here. Can you expand on how you think unions would make code nicer than disjoint unions? They definitely make generics much harder to think about for me.
I mean typescript has those because the underlying runtime is Javascript, which tracks the types of stuff and handles some kind of polymorphism, so you can get away with undiscriminated unions because the runtime is doing the job of discriminating them
It was introduced 18 years after JavaScript but feels like a perfectly natural evolution of JavaScript. TypeScript _should_ feel like a wonky bolt on but it’s wonderful. A testament to the folks who built it
Sometimes during the late 2.x series TypeScript really came into stride with ability to express more "dynamic" types, using a functional style and having arrays-behaving-like-tuples,etc and the 3.x and 4.x series has really made it polished.
TL;DR; It's quite great now, but don't dismiss sceptical people because early versions of it kinda DID suck.
I think Ruby is much better than Python for building large applications.
Ruby is essentially Smalltalk with a neat Algol-like syntax and some Perl-isms. Its OO system is a joy to work with.
Python got so popular in data-oriented applications because it's a really simple procedural language.
More importantly, it had the right libraries (NumPy, SciPy and Matplotlib) when Torch (implemented in Lua) was no longer viable (due to LuaJIT limitations).
You’re right, they’re dicts unless slots are used. I read the parent comment and saying you can define types easily. But you can with dataclasses
Sorry what? This is absolutely not true.
Global variables are stored in a dict (`vars()`). Unless you use slots, an object is essentially a dict
Doesn't really disturb me because they're not used like a dict in practice though
Also I remember the dependency management system was a pain in the ass to deal with, especially with modules with native libraries.
Python had some issues with 2, but when 3 came around and fixed all that, it became the language of choice specifically because of its consistency.
Given that almost every cloud native project is written in Go I'd say this is entirely not true.
Plenty of them are still Java and .NET based, as the ecosystems counter reacted to Go's adoption hype, and Rust is the new kid on the block specially for cloud native Webassembly projects and eBPF.
Like Helm creators nowadays doing mostly Rust, https://deislabs.io/posts/
...x86_64? ;)
> Rust makes enormous binaries > and compiles slowOne thing that can definitely improved on is how cargo manages dependencies, I am tired of each of my project's /target directory using >2GB of disk space, there at least should be some kind of opt-in global cache.
I am also worried about dependencies going in the same direction as the JS ecosystem, many of my projects only have 3-5 top level dependencies, but I end up downloading hundreds. A few are only compile-time, but this makes auditing very difficult and does make compile times a lot longer.
[0]: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab... [1]: https://github.com/johnthagen/min-sized-rust
But it DOES make binaries. Such a breath of fresh air after years of Java/Scala.
Like docker, for instance. If I had to write "java -jar docker.jar -cp ..." and fuck around for a week trying to figure out where the env vars, JVM flags, and arguments to the actual program go, I would not use docker. Let alone piping input through grep, less and tail.
Cargo has been working to resolve this, it's been testing a new feature that lazily fetches fine-grained index info over HTTP rather than the legacy approach, which is to clone the entire index stored as a git repo (which worked fine when crates.io was young and small, but hasn't scaled well). You can enable it on nightly Rust via the sparse-registry config flag, and it was recently accepted for the 1.68 release in March (which means you can try it out on the beta channel right now). In the future, it will become the default behavior.
https://doc.rust-lang.org/nightly/cargo/reference/registries...
It's quite verbose, as well, or was the last time I looked at it.
I don't demand a Perl level of terseness (that's going too far the other way), but neither is reinventing the verbosity of COBOL a good idea.
For example, imagine the following in an imaginary version of Rust with union types:
#[derive(PartialEq)]
struct Option<T> {
value: T | (),
}
impl<T> Option<T> {
fn some(value: T) -> Self {
Self { value }
}
fn none() -> Self {
Self { value: () }
}
fn is_none(&self) -> bool {
match self.value {
_: () => true,
_: T => false,
}
}
}
I only recently discovered that python's reference typechecker, mypy, has a small side project for typed python to emit C [1], written entirely in python. Nowadays with python's rich specializer ecosystem (LLVM, CUDA, and just generally vectorized math), the value of writing a small program in anything else diminishes quickly.
Imagine reading the C++wg release notes in the same mood that you would the python release notes.
I have followed development of C++ and... yeah, committees and subcommittees.
[1] https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth...
with packaging there are things the committee is good at (making sure that a change to packaging does not break packaging for certain configurations and use cases) and individual initiatives outside of the committee often had drawbacks improving packaging in some area and making it worse in others. But the “committee” then was able to take inspirations into the committee which means there is the best of both worlds.
IMHO the python PEP process is a good example of python going the middle way.
You might want to reach for something else if you need better performance than that.
Which mood are we talking about here? Mild dread? They keep adding new features to the language. The Python programming language is around 30. The release notes at this point should be "wow, we found a bug this year! Didn't expect to see one of those!".
The secret of Python is it is actually a large community all learning to program together. They all discovered static typing together, they're all learning about functional techniques together (removing reduce() from core Python was a really interesting move), yada yada. It is a happy, productive and cohesive community. Probably a study in how to build a community around a programming language.
But one of the reasons I like Clojure is they don't have release notes any more, the release notes are basically "hey we're working on some libraries". They built something extremely powerful and it is done, because there isn't any more power needed in the core. If you invest in learning a tool, the tool shouldn't sprout a new handle and expect to be held differently.
While I'm not too keen on hardcore feature divergences, most of the new features have been really nice things to have, and which are never imposed. (E.g. the walrus operator, type hints, dataclasses, etc). I don't see the need to be so outright hostile to changes, unless they were clearly breaking features.
I'm not sure about that part. Even if one personally ignores something new, someone else within the same project or a dependency will employ the new shiny, and invent one or a couple more ways of doing the same thing in a different way.
That means if it's in the language, you'll have to account for it. Not saying Python is, but given enough new features a language may become a kitchen sink of ideas over time.
--
(At the risk of contradicting myself a bit here, I actually agree with the features you mentioned here are all nice to have, and I like using them. IDK if nice to have is a high enough barrier to clear though.)
Or complete. Eternal change is not a value in itself.
Even Python is likely to die; in time. Most things do. Something will have to change first, at the moment it is doing great.
Only in so far as the user actually _can_ make those changes, if deemed necessary or elegant using macro facilities. Once something has proven itself good enough to be part of the language standard, there is nothing limiting language maintainers/creators to take it into the standard and ship with next release. So it is strictly more flexible in that way and users do not have to wait on commitees.
And the Clojure example imho is a bit of a red herring, because while it allows a lot of flexibility (reader macros in Clojure are very powerful), they don't encourage ecosystem divergence, since Clojure can use JVM/Java for "Batteries" and most standard libraries. Cljs is more similar in that way, because it carries much of javascript's divergence with it.
I have been using Python in and out for system administration since version 1.6.
From this, people started making lots of libraries that accelerated code and provided bindings to other software.
At a certain point the ecosystem reached a critical mass, and the rest is history.
They hardly seem like iconoclasts in that respect, it feels like there is a lot of group mentality there which is strange to me. People in a place with strange groups dynamics might not be aligned with the public outside the group (who are oblivious to the group think since they are just "normies"), and so the group is sure, against the grain in some respect, but that aspect of being separate from the general population is due to adherence to groupthink, not really due to individual eccentricity or originality.
Another aspect, rust is being hyped by some big names in Tech, so at this point, rust feels alot more like Java in its early days, so not really niche but just new and before mainstream penetration.
[0] Yes, some anti-systemd people literally say Lennart Poeterring is hitler or some nonsense, they are idiots. I just think the software he pushes is not the best.
And so there has been this long investment in frameworks, libraries etc that no one would ever otherwise write. Especially areas like governance, security, compliance, reliability etc.
I think Rust is just going to end up just being a better C++ not a true mainstream language.
* Microsoft Azure's CTO says C and C++ are deprecated
* Most-loved language in StackOverflow dev survey for 7 years running
* Now in the Linux kernel
Sounds like success to me.
[0] https://foundation.rust-lang.org/
[1] I checked, it looks like intel is funding julia development to some extent. The rest is government research orgs like NSF and DARPA. Okay, that's "large org" support on some scale, although it's clearly because julia is meant for science, not industry.
I've heard people use 'reactionary' to mean "doesn't want things to change", or "wants things to go back to the way they were", which would actually be a pretty reasonable opinion for a pro-systemd person to have about people opposed to systemd.
(I'm not saying that systemd is or isn't good/bad, but it was definitely a change, so describing people who wanted to keep initd as reactionary does seem to jibe with the definition of reactionary folks as being people who favor going back to the earlier status quo)
It's like saying Nickelback's "Woke Up This Morning" is Classic Rock because you never heard of the Rolling Stones "Start Me Up".
I hate that everything is politically-coded nowadays, but, honestly, as much distaste as I feel even writing this, I think they're not entirely wrong / there is something significant underlying that sentiment. Especially post-2014, nearly everything on the internet, including open source technology, is highly entangled with the culture wars. For better or worse, Rust really is left-coded and anti-systemd sentiment really is right-coded. A lot of this stems from the 4chan /g/ (Technology) board's staunch opposition to systemd and Rust + the broad cultural influence 4chan retains to this day. I've been a 4chan regular for over a decade and have seen all sides of this.
I know what I'm saying sounds, and is, utterly ridiculous, but this really actually is a "thing", for some reason. Of course most people who like/dislike systemd or Rust aren't politically motivated or even aware of these associations, but there's a surprisingly large chunk of both who are, even if they aren't really consciously thinking of it in this way. It's very easy and understandable to laugh at someone accusing systemd critics of being neo-Nazis - it's the ultimate Godwin smear/cope - but for a variety of reasons the inverse pretty much does hold: alt-right technologists indeed are near-universally actively opposed to systemd, and generally actively hostile towards Rust. The Rust opposition is in large part due to their belief that Rust and Mozilla are associated with trans people and that if you use Rust you are "pro-trans agenda", "cucked", "pro-Jewish", "pro-globohomo". The systemd opposition is less concrete and seems to be more a matter of happenstance + typical conservatism/"if it ain't broke, don't fix it".
What puzzles me is that OpenBSD people seem to be quite actively opposed to Rust too. They are the project that disables hyperthreading for security reasons, runs ld to relink the kernel after every boot to shuffle memory addresses, patches all sorts of software to support capability self-limiting with pledge, and so on. And the idea of using a fast memory-safe language is somehow nonsensical to them. It is hard for me to take this opposition as motivated by security.
I am expecting new vulnerabilities to pop up from developer’s misunderstanding of what Rust actually guarantees, especially in the same memory space as the kernel.
On top of that, Rust implies a huge new bundle of complexity, a second compiler to have bugs in, and a new software supply chain to attack. The language is extremely complex compared to C. These are not easily dismissible problems.
While Rust is definitely a step up from C++ in embedded, I am not convinced bolting it onto existing kernels will fix more potential CVEs than it will cause.
The project could start moving critical software to Rust. They could even write their own crates for this purpose, or fork others’ crates to rule out supply chain attacks.
None of this would be unprecedented for the OpenBSD project. They have forked Apache, OpenSSL, they maintain their own SSH client and server. What would be new is that now all of this would not be happening in C but in another language.
Edit: I don’t even think that the above has to be done in Rust. It could be done in any other modern language. But you also mention the complexity of Rust. In what way do you see it as an infosec problem?
To me it appears that the complexity of Rust is good. The limitations that the language puts on your code give you pain before compilation, not afterwards. It makes you do work that avoids certain kinds of memory and logic bugs.
Also, "conservatism" meaning "if it ain't broke, don't fix it" is NOT equivalent to political conservatism at all. Conservatives all the time advocate for changes that contradict tradition all the time. Just look at the zoning debates in the US, none of the "keeping X neighborhood sfh" people who argue for it because of "preservation" want to minimize parking to the point they can't fit their f-150s anymore, which dwarf the trucks of the 50s. It has a veneer of "respecting tradition" but they don't really care about tradition in the strict sense. It's like most political ideologies, it centers on a set of values and ideas with justifications that come later.
The left really is the same honestly. While "progressivism" has a nice summary as being "for political change" in some respects, they too respect tradition and history when it fits their aims. It's more correct to say that the sides really have a set of values and ideas that are central, without some overarching central tenet or explanation.
>Also, "conservatism" meaning "if it ain't broke, don't fix it" is NOT equivalent to political conservatism at all. Conservatives all the time advocate for changes that contradict tradition all the time.
True. Frankly, I don't know the exact reason why anti-systemd sentiment seems tied up with conservative/reactionary political tendencies (or, more correctly, why the latter seems tied up with the former).
That's what I was getting at with my comment about how claiming we should go back to the steaming pile of shit System V init system with all its directories full of symlinks they think is "Classic Unix" is like claiming Nickelback's "Woke Up This Morning" is Classic Rock because you never heard of the Rolling Stones "Start Me Up".
https://news.ycombinator.com/item?id=34546815
There's definitely an underlying anti-BSD, anti-Berkeley, anti-hippie, anti-Mozilla, anti-woke, anti-gay, anti-trans, pro-Brendan-Eich, pro-GamerGate, alt-right sentiment that runs through all those irrationally ignorant anti-systemd weenies received belief system they parroted from 4Chan.
One group thinks change is ultimately a good thing and will make changes for the sake of changes.
Another one thinks change is ultimately a bad thing, and will always oppose it.
Too much change is chaos, too little is stagnation. The truth is somewhere in the middle.
I don't think you are actually referring to the entire Rust community here. Did one person say this on Twitter, and maybe a handful retweet? Besides, what does Rust have to do with systemd?
(Not a Rust user, and don't really have an opinion on systemd.)
Or, maybe not that new. "These people to that" without even saying what people you are talking about has been used on politics since forever.
But $LARGE_CORP, or at least one of the $LARGE_CORPs in your space, is just as likely to be using Python themselves anymore, or some other relatively nice language. Even the bad ol' languages from 2004 have cleaned themselves up a lot since then. There are some potential much more isolated advantages to be harnessed here and there in certain cases by using the correct language in place the wrong one has become entrenched, but I just don't think this particular delta is anywhere near as available, in general, as it used to be.
Now, if you deviate from PHP, Python, Node, Rails, etc., to one of the new “esoteric” languages, you have to learn a new language, plus reinvent the wheel in a lot of areas that you’d otherwise be getting for free.
So you have brilliant developers working in esoteric languages trying to complete 25-50% more code.
Even if you can swim upstream fast enough to compete with highly competent devs working in a more popular language, then you get into hiring / onboarding challenges, documenting and debugging custom features (features that would otherwise be a “solved problem” in other languages), acquisition due diligence, etc., that persistently weighs against you.
I think this is the key concern. The #1 priority is how quickly Engineering can respond to business demands. Maybe the #1 priority instead ought to be culture, and that can be a great approach for Mittelstand-style/small-forever/bootstrapped businesses. But for venture-backed growth-at-all-costs businesses? Porting functionality to an esoteric language does not drive business value. Complain that you have difficulty hiring because you can't find engineers who know the esoteric language, and you're likely to get pressure from your investors to make boring technology choices instead.
> C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.
> In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with.
Oh Linus...
Love this sentence. Python is a success precisely because it enabled a lot more people to be sculptors. Ofcourse this means you see a lot ugly, unfinished pieces. And indeed bronze or iron sculptures may require a slightly different workflow and skillset.
Not clear for how long Python will retain this advantage. People parlay lists of technical reasons but most likely the new hot language will be one that makes it even easier and fun to push around blobs of code.
The distinction Python has (wrt to the rest of this list) is that it is a language created by someone who really cares about systems programming, descended from a language (ABC) created by people who really cared about programming theory.
(that said, my vote for the mechanism of python's current popularity is: time and chance)
It does seem that Python has settled into a niche as one of the mainstream data science languages.
It's even more surprising to me given that Pandas is such a poorly designed library. (Apparently the guy who developed it was learning Python while he was writing Pandas.) I saw candidates make mistakes due to quirks in Pandas often. And quirks can be extra deadly with data science code: https://news.ycombinator.com/item?id=33797339 So overall it's a weird situation. I think a big factor is that a lot of data scientists are newbie programmers who are just piling in to what's popular & established.
This makes a lot of sense. I remember trying to learn Pandas before v0.24 and finding the syntax changing a lot between versions which just confused me even more. I later learnt some R and was blown away by how easy tidyverse, and even base R data.frames were to use.
Thats why I always personally enjoyed duck typing.
Static or dynamic? You will ask a non-duck to quack. Do you want to find out before or after you start your application?
To do types well, I'd recommend constraining as much as possible. E.g. if a library gives you a union of 5 possible return types, just type it as one of them that you know you'll get and don't let that "complexity" propagate further into your code base. Likewise if you're wrapping a lib function that can take 3 levels worth of complex union or umpteen varargs, don't let that bleed through in your function signature "just in case".
And most crucial advice. Don't use Google's type checker pytypes. Or any other type checker for that matter other than Pycharms built-in one and mypy. Don't faff about with vscode either. Pycharm will make your python type hinting journey a pleasant experience (barring some generics and OOP corner case scenarios.)
Eh, I’m not getting different editors for different languages (coding, documentation, and otherwise) used in the same project, and IntelliJ doesn’t have nice tooling for everything I need that VSCode does. Not sure how good Pycharm’s typechecking is, but pyright is, IME, usually better than mypy, and VSCode lets me belt-and-suspenders both of those if I choose (I did for a while, between being pure mypy and being pure pyright).
Just a lot of people from other programming languages coming in and trying to make the language more familiar to them.
It makes refactor much easier, I can easily understand what parameter a function wants, without having to read the docstring or worse, the body of the function.
typecheckers do find a lot of errors that would otherwise be runtime errors.
It's bad, really really bad.
Refactoring can be done just as well via a good IDE and unit testing.
Using typechecking creates far more errors then it finds. They are a necessary evil in compiled languages. It's been measured that it creates more errors. That is not open for debate.
I don't think you should be surprised. Untyped Python code is a lot shorter and more concise than typed Python code.
The easiest way by far to reduce the bug count is to reduce the lines of code.
It only seems to say that typed code takes longer to write and is longer. It doesn't seem to say that typed code has more bugs, nor does it compare typed Python with untyped Python.
This is a claim I see repeated over and over without much evidence to support it. In my experience type checkers find a lot of errors that would still be found at later stages and a lot of tiny errors that don't matter and can be dealt with via much cheaper tools.
Shorter feedback cycle is nice, and occasionally it does catch a real bug, but the benefits of static typing are vastly overblown.
There probably are teams where typecheckers do catch a lot of important runtime errors. Those are the teams with a horrible engineering culture. In those environments typecheckers are a bandaid, not a cure. If anything, they are hiding the real problem: you shouldn't give a perfume to someone who doesn't shower.
Well there are like 3 or 4 checkers existing.
Then there's pydantic which needs a mypy plugin because it uses the types in a very non-standard way. But I use typedload (which I wrote) so that's not an issue for me.
Other than pydantic I've just encountered libraries without type definitions, or done properly.
Perhaps the fact that I tend to avoid adding dependencies helps me there.
Yes, don't try to shove all your code into OOP, and you will be fine.
Anyone following this approach is an idiot, it's like prescribing a very niche diet to everybody.
If you want it to be useful instead of doing it everywhere, you should limit it as much as possible. Find a few isolated places where you want types and limit analyzer to this area only (btw, it is entirely possible that there are no places like this in your code - that's a good thing). You can always extend the area that's covered by static analyzer, but you can never shrink it (at least I've never seen it happen).
If you don't do this, typing becomes viral and you will soon be doing typing for the sake of typing and fighting your tools instead of extracting value from them.
Although I do think between Python and Java, just pick your poison, they're not night and day. Unless you're writing 1990s Java consisting of factories of factories which is more to do with library style and over-conventionalism (back then when people were writing APIs after reading GOF). Even in 2004 I don't think there's much credibility in knowing both languages although I wasn't around.
What I find stupid that a lot of recruiters and jobs look for certain languages/technologies and require X years of experience in them. Sometimes requirements predating the existence of certain frameworks. Makes sense if you for some reason need a Kubenetes guy but mostly not.
But I still see this happen more than 20 years later when brilliant ex-Java folks are doing Python.
Java has this weird cultural inertia which reminds me of "Five Monkey Experiment".
I wish more of those weren't flagged to death when people post them here.
Here's a deeper explanation from a random Google search result.: https://www.businesswritingblog.com/business_writing/2022/05...
I am a programmer and a published book author (8 books so far and over 35000 sold copies). I wrote a pile of shit, too, but it helped me become a better coder and a better author.
Then again, maybe he's asking for it, given that he calls his blog posts "essays". Lol.
EDIT: I just realized this was 2004. And now I agree with him.
By selecting ocaml developers, you filter developers who
- aren't afraid of trying stuff even if it has a reputation of being hard (or leart it at school) - are biased towards a mathematical way of thinking
- C++ 1985
- Perl 1987
- Visual Basic 1991
- Python 1991
- JavaScript 1995
- Ruby 1995
- Java 1995
- PHP 1995
- C# 2000
Back in 2004, despite how small Python was - it was still in the top 10, just past Delphi. - Java dominated, followed by PHP.
I don't know how popular Python was, but I remember it was a "toy" language, and when Reddit rewrote their whole website in it a few years later (2005? 2007?) it was seen as a bold risky move.
During the late 90's there was a DDJ issue dedicated to Python.
The first Python version I used at work was 1.6.
Almost 20 years ago. Was Python even a teen?
Python does not attract smart young iconoclasts anymore. It's the scripting language everyone writes because everyone writes Python.
What languages do attract smart young iconoclasts? Nim? Elm? Whatever you're doing that is not yet old enough to drink by the time you comment?
If anyone cares, here's some comments from one of those authors: https://github.com/StefanSalewski/NimProgrammingBook/issues/... . And from the other: https://twitter.com/d0m96/status/1592827547582332929?t=IqKBz... .
These quarrels with Araq differ obviously, but both are pretty discouraging as far as Nim's prospects are concerned.
https://github.com/nim-lang/Nim/issues/9026
Nothing as strong as the above but it definitely rubbed me the wrong way. So much advertising about Nim being efficient/fast and the default way to read a file is incredibly slow and inefficient .... and they don't care.
Almost 10 years ago, I translated this article to Telugu.
Interesting how it started to attract people with the same mindset that likes Java: great care for trivial correctness guarantees s.a. those ensured through type hints or producing programs through ticking boxes in existing templates. And disregard to large-scale design issues, something that was initially thought to be helped by more concise syntax and greater freedom to explore / less fear of novelty.
However, the thought that dedication to a (marginal) language will help you hire better programmers isn't new, and has some supporting evidence. I remember similar argument coming from Linus Torvalds, when he didn't want C++ programmers working on Git, for example.
I also happen to think that a lot of new(-ish) languages today are trying to ride the hype wave, and by doing so are trying to become instantly more popular rather than appealing to the tastes of a small but dedicated community. Eg. Rust is trying to be a "better C++", but in a way C++ programmers would most likely not be repulsed by it. Both superficial decision (s.a. "familiar" curly bracket syntax) and more fundamental ones are there to ensure that large audience of C++ programmers would have an easy migration path.
I think that, today, if you wanted to match the effect the author saw created by hiring Python programmers in 2004, you'd have to go after hiring people dedicated to undeservedly forgotten languages s.a. Ada, Scheme or Erlang. Rust is posed to become just a slightly different flavor of C++ with the large volume of low-skill programmers pumping out low-quality software from big corporate shops. For now, it may attract enthusiastic people, but that's not going to last.
I am completely repulsed by Dart, but people seem to actually not be bothered by the hideous syntax. Must be wearing Flutter colored glasses...
My question is: when will Python be seen as "risk or exposure 'free'" in the near future?
Edit: small typo
What's up with the Turkish and Japanese translation links not working?
Are they just dead cos they rotted? I've been working on my own multilingual site upgrade lol so my mind is on this
@PG to future proof consider using archive.org's wayback machine for essential links like translations, shld hopefully be straightforward to roll into your blog software
No idea about the Japanese translation, but the Turkish one was hosted on a Turkish Slashdot clone (fazlamesai.net) back then [1]. There is still a web site at that domain but I believe it is owned by someone else these days.
Key takeaway: Host translations yourself, do not let others host it for you.
[1] https://web.archive.org/web/20040910012806/https://fazlamesa...
It calls Python "esoteric"! :-D
I agree with the sentiment even if the example given hasn't aged well.
We hired from Open Source communities (mailing lists, conferences, our own website), and applicants always had at least basic language skills and more importantly a desire to work with it. Once you start hiring people from outside, who are not interested in you or your tech and just interested in a job, you lose the benefits being discussed in the article. One of the reasons we expanded to include Go was to increase the size of the recruitment pool.
An opposite observation, the engineers that want to differentiate themselves by using "less popular" tools often have some of the biggest egos and are most blind to the issues in their designs.
The one place I worked where we built the application in Python was rife with: - People with a big chip on their shoulder about Java and .NET being inferior
- Constant talk about how bad Java/.NET were and how their use of Python was so much better
- The design of the product hit every weak point of Python that Java and .NET are much stronger at
- We had bugs & data leaks that Python's issues made possible in ways that were almost impossible in Java/.NET
- Performance issues and jumping through hoops due to Python's issues around multi-threading
- Tons of tech debt and difficult to decipher code
Still there was a good result in the end, and the rapid iteration of Python was helpful in getting things done fast. The question is how bad was it to deal with the issues after the exit when the new owners had to keep scaling it.
Another place we had a bitter LISPy guy. Always trying to write everything in the most esoteric language he could, always leaving behind maintenance issues, never stopping talking about how bad the tool chains were (Java/C++) that actually brought in the revenue his job depended on.
I do not have this impression in 2023. No website written in Python is as polished as GitHub (has Ruby influenced the elegance?).
The scientific ecosystem is chaotic, new and half-finished tools are released daily, packaging is a mess. Of course some of the scientists are smart in their domain, but not always in programming.
Core development is pedestrian and run by unproductive, dominant bureaucrats who want to remain in power. From a CS point of view, Python is of zero interest and has few exciting areas.
Python has maximalist specifications with many bugs in the resulting case explosions. Python has too much churn and a horrible package manager.
I don't see smart people who are attracted to Python (like maybe in 2004). They sometimes use it, grudgingly.
Can you name them? I’m not personally aware of any. Python is here to stay for a long long time. It’s become the de facto language for AI/ML and there’re good reasons for that. And programming the AI way or with a significant component involving AI is very likely the future of programming. Until a much better general purpose tool comes around (ie a language that doesn’t get in the way and comes with batteries included - especially for non cs types who have to accomplish programming like tasks) I don’t see it going away anytime in the near horizon
At least in my area, these days there are many programmers who know Python because that's the only language they have been taught. And there are many job opportunities specifically looking for Python.
1. Hiring is harder: "When it comes to hiring people, it’s true that programmers versed with functional programming would be, on average, better than those who aren’t. However, the hiring pool itself would shrink massively. Learning a language is an investment, and not many people are using their spare time to learn a new one. As I have seen it happen, demanding functional experience soon becomes an unreasonable expectation."
2. Less resources: What's the point of choosing an esoteric langauge and having to build nearly everything from scratch. You're basically throwing away years of experience that a vibrant community provides.
3. Hackers use languages they know: I am nearing 30, and having seen rise and fall of many tech trends, I want to play my cards right. Why should I waste my energy on learning a new language, especially when it can fade into obscurity and the output is going to be the same anyway? MeteorJS[2] was supposed to revolutionize front-end programming, who is talking about it now?
Facebook was written in PHP. Mark used one language he knew and a $300B company was built on top of it. While a company I worked at that prided itself on being written in Clojure, slowly felt behind the competition and barely managed to get acquired (at a deep discount to what they raised funding at). Trust me, your time is better spent shipping, and learning internals of how things work.
[1]: https://shubhamjain.co/2018/12/01/why-paul-graham-wrong/
A recent, not-boring technology that requires less resources than the old, boring one must be an exception.
This example doesn't further your point at all seeing as they had to over time literally invent an entirely new language to make their PHP codebase scale. And on top of that FB went on to use a whole bunch of uncommon languages (Haskell, Erlang, D, probably a bunch of others I don't know about)
I - er.. okay.
I have also seen teams using languages traditionally considered "easy-to-understand" use various forms of meta-programming to customize the code and make it even more easy to understand... eventually reaching the point where nobody except the experts of this specific sublanguage could understand it.
I have seen teams using languages considered hard-to-understand being obsessed with documentation and communication – and others who don't care at all.
I've come to the conclusion that it's a teams thing, much more than a language thing.
I used that reasoning to keep writing perl when python suddenly seemed everywhere and over-hyped.
To be honest, I probably should have just taken the time to learn python sooner. I haven't abandoned perl, and I doubt I ever will, but it would have saved me some time/trouble to have picked up python earlier since it wasn't the fad I assumed it was.
Today, I assume Rust is just a fad so I'm tempted to avoid the same mistake and pick that up too. Haven't bothered yet though.
where at that time - java had slow velocity - because it was tied up in marketing speak - and enterprise jargon.
however reading in between the lines - languages or ecosystems that are not shaped up by hype / marketing to do tend to encourage faster velocity and an uncanny advantage.
in this day and age though - maybe due to resume driven development - influx of vc funding. keep in mind - when YC started it was just a seeder fund - which encouraged companies to reach ramen profitability as soon as possible, not survive on the next round of funding.
what you now experience in the present - is rubber gum / viscous velocity amongst startups due to marketing i.e things like k8s, cloud tools etc which reach the complexity of J2EE tools of back then; when only the appointed prophets could show you the right true path.
now every company big and small - talks about doing things at scale. yet if you take a step back - no one has a definition of what scale is.
at $job - the talk of scale is prevalent - yet we're reaching for tools to solve human problems. that wouldn't need tech at all.
good luck finding a place that shuns complexity, isn't afraid of letting servers fail - to make sure they're robust and reliable enough. where the presentation layer - isn't going through a yearly ritual of sacrificing hours dealing with dependencies.
was lisp considered esoteric back then?
is lisp programmer smart[er]?
I've used Python on program with >30000 LOC without any problems.
And concurrency issues and memory overhead problem are from not knowing the right way to do it. Although I will concede that naive approach to both of those is sub-optimal.
Paradoxically, this can actually lead to a better understanding of how to write performant code. When I first learned some of the be implementation details of python, I couldn't believe it was performant enough to work for anything ... after optimizing enough of it, I understand better what actually matters
There is a lot less stuff that needs remembering.
Testing the code's behavior implies testing the code's typing. And if you are not testing the code's behavior then the code isn't really tested at all.
If so - then you're writing a whole lot of manual checking that a strongly typed language would perform for you, at compile time. If not - well then you're doing less testing than a strongly typed language would.
I agree that these issues are rare, and there is evidence that strongly typed languages have a similar number of bugs to dynamic ones. But suggesting that because you have unit tests, you don't need strong types, is a bit naive to me.
Testing via typing is very weak testing. Almost worthless. Type checking doesn't find many bugs in general.
Strongly typed languages have 2.5 times the number of bugs as dynamically typed languages per software feature.
Why would you intentationally add bugs to your code?
It doesn't make any sense to me.
Thinking using static typing in a scripting language is a good idea is pretty naive. It's like creating a version of Haskell with mutability.
This is actually very insightful, but I'm afraid you won't be able to convince most people.
The only valid metric of code correctness is empirical: how many times code ran successfully in production. Everything else (unit tests, static typing) is theoretical and often close to useless.
I remember seeing a talk where someone analyzed all Github repos to find which languages produced most reliable software. He found C++ to be the most reliable. But not because C++ itself is great as a language. The main reason was that lots of the dependencies that other languages are using were written in C++. C++ software happened to be the most battle tested.
I'm aware of one case where a program traded 10 million dollars, made 5 million profit. There was a serious jaw dropping error in it. Did it matter? (and if so, to whom?)
What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough?
Yeah, that was my assumption. Still, typing in Python feels very clunky compared to TypeScript. And even though it is much better after 3.8 and 3.9 updates, the adoption of typing in various useful libraries was relatively low as far as I remember.
> What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough?
Maybe it is just me, but the scoping rules feel weird: blocks like "with"-statement or for-loops don't create scopes. There is no distinction between declaration and assignment. Sometimes you have to use those weird "nonlocal" and "global".
The typing has been great in my experience. Most of my deps have types and if they don't I can autogenerate them. The powerful typing of TypeScript is mostly not needed if you're not interacting with JS code.
I used comments in the code to say what the types were, e.g.:
def processNotesForm(d):
""" process the notes form
@param d::{str:str} = the form data
"""
def processNotesForm(d: Dict[str,str]):Please actually think about what you are saying instead of just parroting off stuff you read on blogs.
Python has concurrency. Its called multiprocessing. Of course, there is startup overhead, but it achieves the same functionality. Furthermore, processes that are most commonly threaded (like fanning out network requests) are well suited to async, which has less overhead than threads.
Also, memory considerations are relevant only for embedded systems, for which you would never use Python. Memory is dirt cheap these days.
No one is saying you can't make a web site using Python. Just that it is inherently a slower language that is far poorer at concurrency than many other languages.
However, Python is slow compared to most compiled languages for simple large loops over any data structure.
A good example is how ORM libraries will fetch a million rows from the database as a list of tuples in roughly the time the db emits them at (say, a second with C-based code), yet it will take them 100x or 1000x as long to turn those rows of tuples into Python objects with pure Python code.
Google emails prior to acquisition happen to confirm that.
If you want to learn rust/go/nim/haskell/whatever do that, and that is probably going to be worthwhile. Do it to learn more about programming, gain fresh perspective, pick up new skills, broaden your mind, any number of reasons. But don't do it to "be hardcore".