
Python Is Eating the World - gilad
https://www.zdnet.com/article/python-is-eating-the-world-how-one-developers-side-project-became-the-hottest-programming-language-on-the-planet/
======
blaisio
Python has a lot of problems that really slow down development, but they are
all fixable.

The biggest issue, in my opinion, is in dependency management. Python has a
horrible dependency management system, from top-to-bottom.

Why do I need to make a "virtual environment" to have separate dependencies,
and then source it my shell?

Why do I need to manually add version numbers to a file?

Why isn't there any builtin way to automatically define a lock file
(currently, most Python projects just don't even specify indirect dependency
versions, many Python developers probably don't even realize this is an
issue!!!!!)?

Why can't I parallelize dependency installation?

Why isn't there a builtin way to create a redistributable executable with all
my dependencies?

Why do I need to have fresh copies of my dependencies, even if they are the
same versions, in each virtual environment?

There is so much chaos, I've seen very few projects that actually have
reproducible builds. Most people just cross their fingers and hope
dependencies don't change, and they just "deal with" the horrible kludge that
is a virtual environment.

We _need_ official support for a modern package management system, from the
Python org itself. Third party solutions don't cut it, because they just end
up being incompatible with each other.

Example: if the Python interpreter knew just a little bit about dependencies,
it could pull in the correct version from a global cache - no need to
reinstall the same module over and over again, just use the shared copy.
Imagine how many CPU cycles would be saved. No more need for special wrapper
tools like "tox".

~~~
astonex
>Most people just cross their fingers and hope dependencies don't change

Is there anything wrong with pip freeze > requirements.txt and then pip
install -r requirements.txt ? This would install the exact versions

~~~
sciyoshi
I've had a good experience with pip-tools ([https://github.com/jazzband/pip-
tools/](https://github.com/jazzband/pip-tools/)) which takes a requirements.in
with loosely-pinned dependencies and writes your requirements.txt with the
exact versions including transitive dependencies.

~~~
takeda
Same here, in my team we had immediate dependencies defined in setup.cfg when
PR was merged, a pip-compile was run and generated requirements.txt and store
it in central database (in our case it was consul because that was easiest to
get without involving ops).

pip-sync was then called to install it in given environment, any promotion
from devint -> qa -> staging -> prod, was just copying the requirements.txt
from environment earlier and calling pip-sync.

------
brainless
Remember NOT to jump into Python for your new product if don't know Python. If
you are developing for a young startup, have time crunch, then stick to what
you know.

IF you do not have a language, or know Python a bit, then pick Python. Here
are some of the reasons why I stick to Python (young startup/web APIs):

    
    
      - OOPs is not too strict (might give a headache to some folks)
      - Mixins, lambda, decorators, comprehensions - Pythonic ways make me feel productive easily
      - Create a data Model, drop into a shell, import and try things
      - Can do that on a live server
      - Do the same with Controllers, or anything else actually
      - really nothing fancy needed
      - Command line processing, SSH, OS integration, etc. has so many great libs
      - Python Dict someone looks like JSON (this is purely accidental but useful)
      - Debugger support even in free IDE like PyCharm Community Ed is great
      - Integration to a world of services is so easy, even ones you do not commonly see
      - Documentation - many libs have consistent structure and that helps a LOT
      - Really large community, perhaps only smaller than Java
      - The even larger group of people using Python in all sorts of domains from Biotech to OS scripts
    

What I would like improved in the language would be an even longer list. Every
language has a list like that, but when you are focused on being scrappy and
building a product, yet making sure that software quality does not take a big
hit, Python helps a lot.

~~~
yetanotherjosh
> Remember NOT to jump into Python for your new product if don't know Python.
> If you are developing for a young startup, have time crunch, then stick to
> what you know.

Are you saying this as a general maxim (don't try to learn a new tech under
pressure) or because of characteristics specific to Python, that make it worse
in such a situation than any other language/ecosystem?

------
KirinDave
Reading this got me thinking and I wonder if other people feel like me about
this, so I'm going to share it. This is not serious, but not entirely
unserious...

I try to be a good sport about it, but every time I write python I want to
quit software engineering. It makes me angry how little it values my time. It
does little for my soured disposition that folks then vehemently lecture me
about the hours saved by future barely-trained developers who will ostensibly
have to come and work with my code. Every moment working with python (and that
infernal pep-8 linter insisting 80 characters is a sensible standard in 2019)
increases my burnout by 100x.

I try to remind myself that we're trying to make the industry less exclusive
and more welcoming to new developers and "old" isn't necessarily "good" (in
fact, probably the opposite), but damn I just don't understand it.

It used to be that I could focus on other languages (Erlang, Nemerle, F#,
Haskell, Ocaml, even C++) and sort of balm myself. But now, I can't even
overcome the sinking feeling as I read the Julia statistics book that I'm
going to be dragged back to Python kicking and screaming in the morning, so
why even bother?

And frustratingly: it's one of the few languages with decent linear algebra
libraries. And that means it's one of the few languages with good ML and
statistics support. So it's very hard not to use it because when you want to
cobble together something like a Bayesian model things like PyMC or Edward
actually give you performance that's obnoxiously difficult to reproduce.

This is what the industry wants and evidently a lot of people are okay with
it, but to me it's misery and I can't work out why people seem to like it so
much.

~~~
blub
Over-sensitive individuals are hard to please and often unhappy. That's more
of a personality flaw than a flaw with the current state of software
engineering.

If there's one thing wrong with our profession is a lack of ethics and
accreditation - we're essentially letting random people build critical
infrastructure and utilities.

We don't have a tooling problem, in fact we have too many tools.

I see so many people (especially on HN) fixating on tools, dissecting
programming languages, editors and libraries into their most minute parts and
then inevitably finding faults in them, disavowing them and swearing that
other tools X, Y and Z are purer and worthier.

If you want to stop hating software and improve your burn out, stop caring
about irrelevant stuff.

~~~
vturner
Oversensitive? Is the contractor who chooses a Dewalt or Ridgid over a Ryobi
for daily work "caring about irrelevant stuff"? A drill is a drill right? Why
is it different for us in software?

~~~
taneq
Hey I _like_ my Ryobi drill. :(

~~~
vturner
I love my Ryobi tools too! Just, I've assumed given their price-point, they
aren't built for day in and day out needs of a contractor.

------
umvi
If only its package management were as easy as its syntax...

I wish pip worked the same way as npm: -g flag installs it globally, otherwise
it creates a local "python_modules" folder I can delete at any time. And
optionally I can save the dependency versioning info to some package.json...

Instead, pip is a nightmarish experience where it fails half the time and I
have no idea where anything is being installed to and I'm not sure if I'm
supposed to use sudo or not and I'm not sure if I'm supposed to use pip or
pip3, etc.

~~~
geofft
Here's a simple but less-than-completely-documented way to keep Python package
management under control:

1\. Don't install anything globally. Don't pip install --user, definitely
don't sudo pip install.

2\. For each project you want to work on, create a venv. Yes, there are tools
for this, but the base venv tool is totally fine. (venv should be included in
your Python, but a few distributors like Debian put it in a separate package -
install it from them if needed.) Use python3 -m venv ~/some/directory to
create a venv. From here on out

3\. As a first step, upgrade pip: ~/some/directory/bin/pip install -U pip.

4\. Install things with ~/some/directory/bin/pip install.

5\. Run Python with ~/some/directory/bin/python.

Slightly advanced move: make a requirements.txt file (you can use .../bin/pip
freeze as a starting point) and use .../pip install -r requirements.txt. That
way, if you get any sort of package resolution error, you can just delete your
venv and make a new one. (Downloads are cached, so this isn't super annoying
to do.)

A "project" can either be actual Python development, or just a place to
install some Python programs and run them out of the resulting bin/.

(Edit: Yes, I know about activate, see the replies below for why I don't
recommend it. With these rules, you get to say "Never ever type pip, only
.../bin/pip", which is a good safety measure.)

~~~
nexuist
Herein lies my problem. If I want to start a Node project I run `npm init` and
then `npm install --save` to my heart's content. If I somehow manage to mess
it up I just delete node_modules/ and install again.

If I want to start a Python project I have to set up venv and remember to put
relative paths in front of every command or else it'll run the system version.
Sounds simple, but it's still something to always remember.

~~~
rootusrootus
Just source the activate script and it'll prepend the correct path so that you
don't need to do anything else.

------
Ensorceled
Holy Crap! What a lot of irrational, hyperbolic hate for Python.

I think everybody should spend their first couple of years working in Fortran
IV on IBM TSO/ISPF. No dependency management because you had to write
everything yourself. Or maybe [edit: early 90's] C or C++ development where
dependency management meant getting packages off a Usenet archive, uudecoding
and compiling them yourself after tweaking the configure script.

I'm not saying Python is perfect, but if it's causing your burnout/destroying
your love of programming/ruining software development you seriously need some
perspective.

~~~
CydeWeys
Here's some rational "hate" for Python then.

I just returned to Python for the first time in a little while to collaborate
on a side project and ran into a few tricky-to-debug errors that caused a fair
bit of lost time. Know what the errors were?

In one case, I was iterating over the contents of what was supposed to be a
list, but in some rare circumstances could instead be a string. Instead of
throwing a type error, Python happily went along with it, and iterated over
each character in the string individually. This threw a wrench into the works
because the list being iterated over was patterns, and when you apply a single
character as a pattern you of course match much more than you're expecting.

And another one, I typoed a variable name as groups_keys instead of group_keys
(or vice-versa, I don't remember). Instead of just throwing an error, Python
happily went along with it, used an uninitialized value, and then all the
logic broke.

There's entire classes of errors you can cause yourself in Python that aren't
possible in stronger, statically-typed languages. For a large project, I'd
pick the old and boring Java over Python every time.

~~~
_coveredInBees
Your 2nd error isn't possible in Python, so I'm not sure what you did there.
Regarding the first, sure, it is a bug that was annoying to catch. But, having
an `Iterable` interface in Python is also really neat and useful if used
responsibly. If you're programming regularly in Python, you are accustomed to
the tradeoffs that come with a dynamic programming language and no static
types, and you can still avoid issues like the one above.

Right off the top of my head, using type hints with a decent IDE or an assert
statement would likely have caught the issue.

I'm not saying that Python doesn't have issues (all languages do), but I don't
see the error noted above as any sort of deal breaker. On the other hand, if
you're only ever going to use Python like a strongly typed language without
taking any advantage of its dynamic characteristics, then I can see why it
would seem as a total downgrade compared to languages like Java.

~~~
CydeWeys
I didn't explain the second one well. Here's some exact code.

    
    
      group_keys = ...
      if not isinstance(group_keys, list):
        groups_keys = [ group_keys ]
    

So rather than listifying the non-list variable, it was creating a new
variable. The cause of this bug is that Python doesn't distinguish between
declaring new variables and overwriting existing ones.

~~~
jldugger
Well, this should have been caught as an unused assignment in static analysis.
A whole ton of languages allow this situation, so I'm not gonna ding Python
too hard for that one.

However, here's a related but different python gotcha:

    
    
        if foo(a):
            v = list(bar(a))
        for i in v:
            print i
    

In this example, v is only defined inside the if. Due to python's limited
scopes, v is also valid outside the if, but only has an assignment when foo(a)
is True. When foo(a) is false, the for loop throws an NameError. And yes, a
coworker wrote code that accidentally implemented this antipattern, albeit
much more spread out in the code base.

This is clearly a bug in the code, yet no static analysis tools I've tried
have successfully discovered it. There's a bug in pylint that's been marked
WONTFIX because it requires a wildly different implementation. At a language
level, it feels weird that if blocks aren't a scope level for new variables.
If you want to reference v outside the if loop, declare / assign it outside
the loop first.

~~~
joshuamorton
Indeed, as another user mentions, mypy will detect this issue, as will pytype,
even without any annotations.

~~~
jldugger
Interesting, I had not looked at these because I'm not interested in
volunteering to add type notations to our code base.

------
randomsearch
According to people who work with a lot of programmes teaching coding, the
reason python is so appealing to new coders is the syntax. Particularly the
lack of braces, the indents, the nice keywords, that make reading code much
easier to a newcomer.

Having taught both python and JavaScript, I can tell you that the former is
far far less confusing to newcomers than the latter. Imagine explaining the
problem with equality comparison or prototypes in JS to someone who just
learnt what an IF statement is.

The reason I agree that python will dominate programming for decades to come
is the batteries included and pythonic approach that enables people to do cool
things with just a few lines of code. As a result of the above, the ecosystem
has reached critical mass. For most tasks there’s a library that does that,
and it’s good, and it’s easy to use, and the developer of the library usually
doesn’t expect you to understand their opinionated philosophy to use it.

I _love_ the python convention of putting a minimal example on the homepage of
a library.

You’re not going to get your average developer to appreciate the beauty of
Lisp or the value of static typing. They want their ML to work, or their
graphics to display, that’s all. Ends not means, almost entirely, for most
people who aren’t full-time programmers.

Let’s not hate on a language that opens up programming to the world, unless we
want to be gatekeepers. If you want to maintain an air of superiority, just
learn Lisp or Haskell or C++ and write code that’s “deeper” into the tech
labyrinth. Programming will probably specialise into “end user programming”
and “Service and system programmers”. Embrace the democratisation of coding.

~~~
reallydontask
> Particularly the lack of braces

Since most of my professional experience is with C like syntax languages, I
don't get how the lack of braces is an advantages, quite the opposite in my
limited experience with Python.

Braces define scope unequivocally, they are easy to visually parse and don't
care whether you are using tabs or spaces or even if you, loud gasp, mix them.
Furthermore, you can copy and paste, say for loop from a method to another
method and it will work. In Python you might have to faff about with spaces
(I'm sure there must be IDEs that solve this problem but it was no fun on vim
or even notepad++)

~~~
retube
Absolutely agree. maybe its just cos I am coming from languages with braces
(java) but yeah I find the lack of braces + whitespace having meaning (tabs
versus spaces for example) _incredibly_ frustrating

I also don't like the fact it is dynamically typed. It makes reading soure
code so much harder. E.g What is the type of this thing that is being passed
as a function arg?

~~~
reallydontask
> I also don't like the fact it is dynamically typed. It makes reading soure
> code so much harder. E.g What is the type of this thing that is being passed
> as a function arg?

I didn't want to get into that as it always seems to open a massive can of
worms but agree 100% with you.

I need all the help I can get when developing, to throw away all the type
checking that the compiler does before _runtime_ seems like developing with a
hand tied behind one's back, but each to their own, far be it from me to try
to convince somebody that they should switch languages: if Python works for
you, then great, keep using it.

------
xxxpupugo
The part that Python really bothers me, as someone who had write Python for
almost 10 years, and right now doing it professionally, though personally I
don't consider myself a Python developer rather than a Python senior user, is
actually obvious to nail down, and frustratingly, difficult to handle.

SLOW. The sin of all. I don't want to make other arguments with people who
just come to repeat 'Oh you can make it fast, you are doing it the wrong way'.
Sorry, I have heard that 100 times, now is sounds like bug-as-feature excuse
to me.

Sorry, but Python is just slow. All the stuff people might bring up is just
trying everything to bypass Python itself. Multiprocessing is hell to work
with, buggy and unpredictable. Cython is OK but it is not Python.

Python's slowness is like cancer, and terminally so. Down deep, it is because
its overtly flexible/loose type system, the never-going-away GIL, and
prematurely exposing of C-API makes it almost impossible to optimize without
breaking the existing compatibility.

And most importantly, I don't think it is solvable, truth is the patches are
so integrated, people already forget what problem they tried to fix in the
first place and just live with it.

But it will haunt Python in long term though, people will be struggling with
Python in performant production until they start reimagining a world that
without Python. Maybe a better Python in that sense.

~~~
metroholografix
Same here. I've used Python daily or almost daily for the last ~10 years
(thankfully I've used other languages too).

I've architected reliable systems on top of it but it was obvious to me almost
from the get-go that Python is a terrible language. I credit my previous years
of programming in Lisp that trained my mind to see through the Python mirage.

One issue is that veneer of Python user friendliness that lures people,
usually those who are new to programming or don't have extensive experience
with _multiple_ languages, in.

The major issue for me is that Python lacks internal consistency and is based
on a inverted-design (meaning, no design really) that accumulated over the
years and stinks. This makes it really easy for people to use Python and write
unmaintenable code but also very hard for them to find out how to write good
code. The hallmark of a terrible language is making good code hard to write.

As far as specifics, I think the module system is a joke, the packaging even
worse, the REPL is not really a REPL (in the Lisp sense), ctypes is bad and
has 100 different ways you can hang yourself with, there are tons of gotchas
in the language and standard library that if you haven't memorized [usually by
running into them], they will bite you hard, the GIL ties my hands,
iterator/generator obsession makes for really bad code messes if people take
it seriously and start poorly designing their APIs around it, absence of
proper lexical scope, statements are not expressions and led to gross hacks
like PEP 572... I could keep going for days.

Python is really the PHP of the 2010 generation.

~~~
odonnellryan
I honestly think you've just worked on bad projects. Python isn't the perfect
language but the quality of the available libraries makes it awesome. The
individual quality of projects in any language will always vary.

~~~
metroholografix
My criticism is mostly aimed at the language (and its standard library)
itself. The major projects I worked on, I architected from the beginning. It
is when designing and architecting reliable systems that Python's terrible
nature hits you in the face, especially if you're used to better languages.

Take the nonsensical but alluring Python motto "There should be one -- and
preferably only one -- obvious way to do it." Assuming this was even true,
which it isn't as a series of Python debacles - by its designers no less -
over the years has proven, I don't want a language that shoehorns my thinking
into "one"-ness. One-ness doesn't solve hard problems. I want modeling
flexibility, the ability to examine a problem from multiple perspectives and
explore the solution space in-parallel from multiple angles of attack. C and
C++, bad as they are, let you do this. Perl lets you do that. Common Lisp is
the best language I know on that front, it is _designed_ to let you do this.

I'm not going to say that Python is outright hostile to that mode of working,
but it's not designed to bend / be stretched or mold with your mind in the
same way that great languages are. Sooner (if you're solving fuzzy problems)
or later , you'll run into its limitations and then you can't help but think
that you're wasting your time.

~~~
odonnellryan
Don't get me wrong, it is obviously your right to dislike a language.

I've designed plenty of reliable systems in Python without much issues
whatsoever with making them reliable.

I have had some problems with code organization over the years (Python
certainly lets you "do your own thing" which can lead to issues with
organization over time) however I haven't had reliability, stability, or speed
issues for 95% of the problems I've worked on.

Only times I've ever personally needed a faster language - when submitting
problems in Python to online courses (algo). Then I used C#. Whatever, not a
big deal :)

Python says the goal is to have "one right way" to do things, but certainly
there are many, many ways to do any of those things.

> I want modeling flexibility, the ability to examine a problem from multiple
> perspectives and explore the solution space in-parallel from multiple angles
> of attack.

Can you give an example of where Python doesn't allow you to do this? I've
never had this issue. Actually the opposite: mocking solutions are extremely
easy with Python IMO and the tooling available (even the uber-free stuff) is
awesome and easy to debug with (much easier than using Visual Studio for
example - not saying VS is a bad app, it is great).

~~~
metroholografix
How about all of the following:

Python GIL takes away lots of viable solutions.

Lack of metaprogramming / code generation at runtime.

Lack of performance forcing me to severely compromise or implement things in
C.

Type system is probably among the worst in the dynamic language space (compare
to Common Lisp and Erlang).

Python is not an interactive programming language and can not be used to
implement rapid feedback loops as is possible in Common Lisp, Smalltalk and
Erlang.

The object system is very basic and error-prone compared to CLOS.

The error handling system is very limited.

I've found that all of these points translate into loss of flexibility and
severely constrain the solution space. Having worked extensively in all of the
alternative languages that I mentioned, there is not a single day that goes by
where I'm programming in Python that I don't curse the language for being so
limited / badly designed.

~~~
odonnellryan
> Python GIL takes away lots of viable solutions.

Agreed the GIL is annoying, but I've had no issues with creating large
distributed job engines with Python. Actually the tooling made it very easy.
If you're trying to do this without using existing frameworks I guess it may
be difficult.

> Lack of metaprogramming / code generation at runtime.

IMO Python is the definition of metaprogramming. Actually, usually you use
something that is literally called a "metaclass" to do so. Also everything is
an object that you can override as you like, so not sure what you mean here.
Maybe you were not aware of these features and functionality?

> Python is not an interactive programming language

That just isn't true...

Are you using libraries at all or are you avoiding them?

I've met a lot of developers who do not like to use libraries, but that is a
major strength of the Python ecosystem.

~~~
metroholografix
I get the feeling that you are easily dismissing my points without having
personally experienced the languages and ways of working I'm referring to. If
that's true, then we can only agree to disagree as the only way for you to
really see my point of view would be through familiarizing yourself with the
paradigms and tools I mentioned.

I'll give you one example, for the last point, Python not being an interactive
language. If you work in an actual interactive language (Smalltalk, Common
Lisp, Erlang) you will realize what the term can mean when properly pursued
and made the focus of a language, and see exactly how Python fails to live up
to that.

~~~
odonnellryan
Unfortunately I can only speak with regard to Python, but I don't mean to
dismiss your views.

The language isn't perfect, but I'm sure the languages you love have flaws as
well.

Regarding interactive language, can you give an example? I've tried to search
and while I can find a lot of examples of what I mean in the context of Python
I can't see anything that gives me good info regarding Common Lisp, Erlang, or
Smalltalk.

Also, can you answer my question whether you were leveraging libraries when
you used Python or trying to create all your own solutions to issues?

------
ssivark
Python's success is richly deserved. The fact that it has been a long time
coming (Python is almost 30 years old!) is an indication of the amount of
sheer effort involved, and should give heart for all those working on building
up the next generation of languages.

Since this forum is likely to have some folks looking towards the future, I
found interesting a couple of talks by Python veteran Armin Ronacher [1, 2].
Watching that presentation makes me wonder whether I should think of this in
the context of "Worse is better". That said, Python's runtime introspection is
such a killer feature that it's difficult to explain how empowering it feels
for someone who is relatively new to programming.

[1]: How Python was Shaped by leaky Internals --
[https://www.youtube.com/watch?v=qCGofLIzX6g](https://www.youtube.com/watch?v=qCGofLIzX6g)

[2]: A Python for Future Generations --
[https://www.youtube.com/watch?v=IeSu_odkI5I](https://www.youtube.com/watch?v=IeSu_odkI5I)

------
DonHopkins
It's so refreshing to not see anyone here whining about Python forcing them to
indent their code properly. The kind of people who think that's a PROBLEM
instead of a FEATURE really should not be ever writing any new code, and
instead should be punished by forcing them to maintain other people's code
written with that same lazy misguided attitude, until they recognize how self
indulgent, inconsiderate, and disrespectful that is not just to other people
who have to read their code, but also to themselves.

The same kind of people criticize Lisp for having too many parenthesis, then
go on to write unintelligible shell scripts, Perl and C++ code chock full of
skewbald menageries of sigils and punctuation bound together with a towering
inferno of precedence rules, terribly worse than Lisp's "too many
parenthesis".

~~~
kazinator
The best, brightest and most informed/experienced people who do not think it
is a good idea for significant whitepace to be the determiner of syntactic
nesting do not hold that position because they would like to inflict badly
formatted code on their maintainers. You've invented a stupendously silly
strawman.

~~~
DonHopkins
That's a stupendously anonymous appeal to authority you've made there, and
it's unclear what argument you're actually saying without some explicit
parenthesis around all those deeply nested phrases, or some kind of
grammatical diagram.

Can you please restate how we disagree in a few simple sentences? Are there
any names or links or citations or concrete examples you could add to support
your argument and help us respect your authority?

Speaking of best, brightest and most informed/experienced people:

Have you ever used Dave Winer's outliner based scripting language, "Frontier"?
Since the syntax of the scripting language is actually a structured outline,
it's impossible to indent your code improperly. It's not that white space is
significant, it's that no white space or brackets or begin/end keywords are
even necessary, because your code is simply an outline.

[https://news.ycombinator.com/item?id=20425970](https://news.ycombinator.com/item?id=20425970)

After the success of MORE (an outliner and slide renderer for the Mac), he
went on to develop a scripting language whose syntax itself (for both code and
data) was an outline.

Kind of like Lisp with open/close triangles instead of parens!

It had one of the most comprehensive implementation of Apple Events client and
server support of any Mac application, and was really useful for automating
other Mac apps, earlier and in many ways better than AppleScript.

[https://en.wikipedia.org/wiki/UserLand_Software#Frontier](https://en.wikipedia.org/wiki/UserLand_Software#Frontier)

[http://frontier.userland.com/](http://frontier.userland.com/)

Then XML came along, and he integrated support for XML into the outliner and
programming language, and used Frontier to build "Aretha", "Manila", and
"Radio Userland".

[http://manila.userland.com/](http://manila.userland.com/)

[http://radio.userland.com/](http://radio.userland.com/)

He used Frontier to build a pioneering fully programmable content management
system, blogging and podcasting platform, with a dynamic HTTP server, a static
HTML generator, structured XML editing, RSS publication and syndication, XML-
RPC client and server, OPML import and export, and much more.

He basically invented and pioneered outliners, RSS, OPML, XML-RPC, blogging
and podcasting along the way.

Frontier certainly had its problems, but it was enormously successful. I think
it's a good idea to learn from Dave Winer's experiences successfully designing
and using practical powerful scripting languages.

Dave Winer's second outliner screencast:

[https://www.youtube.com/watch?v=mgUjis_fUkk](https://www.youtube.com/watch?v=mgUjis_fUkk)

Dave Winer's the many lives of Frontier screencast:

[https://www.youtube.com/watch?v=MlN-L88KScw](https://www.youtube.com/watch?v=MlN-L88KScw)

Dave Winer on The Open Web, Blogging, Podcasting and More:

[https://www.youtube.com/watch?v=cLX415mHfX0](https://www.youtube.com/watch?v=cLX415mHfX0)

>UserLand's first product release of April 1989 was UserLand IPC, a developer
tool for interprocess communication that was intended to evolve into a cross-
platform RPC tool. In January 1992 UserLand released version 1.0 of Frontier,
a scripting environment for the Macintosh which included an object database
and a scripting language named UserTalk. At the time of its original release,
Frontier was the only system-level scripting environment for the Macintosh,
but Apple was working on its own scripting language, AppleScript, and started
bundling it with the MacOS 7 system software. As a consequence, most Macintosh
scripting work came to be done in the less powerful, but free, scripting
language provided by Apple.

>UserLand responded to Applescript by re-positioning Frontier as a Web
development environment, distributing the software free of charge with the
"Aretha" release of May 1995. In late 1996, Frontier 4.1 had become "an
integrated development environment that lends itself to the creation and
maintenance of Web sites and management of Web pages sans much busywork," and
by the time Frontier 4.2 was released in January 1997, the software was firmly
established in the realms of website management and CGI scripting, allowing
users to "taste the power of large-scale database publishing with free
software."

[https://en.wikipedia.org/wiki/RSS](https://en.wikipedia.org/wiki/RSS)

[https://en.wikipedia.org/wiki/OPML](https://en.wikipedia.org/wiki/OPML)

[https://en.wikipedia.org/wiki/XML-RPC](https://en.wikipedia.org/wiki/XML-RPC)

~~~
ubu7737
I just don't think Winer should be used as an authority for anything like
this. What he pioneered was "just make it work for the user" solutions from a
usability perspective, and not from an engineering perspective.

Winer part in the XML-RPC and SOAP outcomes was a source of misery for
developers in the early part of this century. MORE was neat because it had a
place on the Macintosh System 6 platform, when there was literally nothing
else of its kind. What did MORE evolve into later? Nothing.

Winer has long been an advocate of "the semantic Web", which is a user-focused
idea of what's essentially an engineering problem. The semantic Web was/is a
dead-end and in its time it led to a great many stupid uses of HTTP.

Winer can be celebrated as an advocate for users but not as a great engineer.

------
mantap
In general JavaScript is eating the world.

Python still dominates in numerical computing and JavaScript hasn't been able
to make a single dent. Because nobody wants to write

    
    
        a.mul(k).add(b)
    

rather than

    
    
        k * a + b
    

or

    
    
        a.set([i,j], b)
    

rather than

    
    
        a[i,j] = b
    

JavaScript's lack of operator overloading is keeping Python alive.

Python also has integers that feel part of the language, rather than being
segregated from normal numbers in case anybody uses integers by accident.

~~~
blub
You're enormously overstating the influence of JS on things outside of the JS
ecosystem.

~~~
mantap
Consider that 10 years ago Ruby and Python used to be spoken about as a pair,
with Ruby being the more popular one. Now Ruby is rarely heard about,
JavaScript has eaten it whole and only the bones remain.

------
Agentlien
What stood out to me, reading the comments, is how among the first few
comments I read there were 4 comments from people with decades of experience
writing python professionally. Each stating their dislike for the language and
citing entirely different parts of the language as its biggest problem.

Personally, I'm primarily a C++ programmer with about a decade of professional
experience in C++. I also used to do daily work in C# for a few years. For me,
python is a language which I use for making simple command line tools, for
processing input and clobbering together different tools. I use it to build
interfaces which streamline certain workflows. Essentially, I use it as a more
powerful replacement for bash or batch. For that purpose, I find that the
language works wonders and is quick and easy to work with.

~~~
mantap
The problem is that when they did the big Python 3 transition they didn't fix
the _real_ pain points (with the exception of string types), many of the
things they fixed were not a problem, or worse they removed things that were
actually useful. Such as the infamous print statement.

So now they can never fix the real problems, because everybody is so
traumatised by the Python 3 transition.

I'll also say that the rate of development of Python is incredibly slow,
slower than even JavaScript's TC39 if that's possible. I waited my whole
Python career to get format string interpolation.

------
RcouF1uZ4gsC
Python is not eating the world so much as becoming the new Excel. It has a
pretty easy learning curve for people who are not programmers. It has pretty
good built in tooling. A domain expert, who is not a programmer, can put
together pretty impressive models and visualizations relatively quickly.

However, like with Excel, there are serious issues regarding reproducibility,
performance, and long term maintenance.

~~~
medecau
One who writes a program is a programmer irrespective of being a domain expert
or not.

If you write code in Excel you are an Excel programmer.

------
lucb1e
For what it's worth, I have none of the issues the currently top voted
comments describe. Dependency hell (apt does that for me), closer to burnout
any time I work with it, would rather work with C++ (a language with a
completely different purpose)? If the author of the article had written this,
people would fall over themselves to say how wrong they are. Nearly everyone
who tried Python loves it. From this thread you'd think we're talking about
Visual Basic for Applications.

There is a reason Python is one of the most popular languages. PHP was popular
because it's quick and dirty, but Python is popular because people love
working with it. The arguments in this thread are beyond me. (They're also
unsubstantiated, but if I ask for substantiation I'm sure someone can
rationalize some reasons to dislike any language, so that's pointless.)

------
mixmastamyk
One thing very interesting about Python is how gradual the ride up has been.
Perl dominated then sputtered. Java shot up and hit the ceiling. C# is mostly
limited to Windows, JavaScript mostly to the web. Ruby stole the spotlight for
a few years and then faltered mysteriously. Others found their niche. But
Python just keeps chugging along slowly gaining ground almost everywhere like
a tortoise to multiple hyped-up hares.

------
sunaurus
Am I correct when I assume that most of the people hating on Python here are
using it for medium or big projects?

I feel like the dev community figured this out ages ago: Statically typed
languages are easier to read, harder to write, dynamically typed languages are
easier to write, harder to read (and also harder to refactor).

For small projects (scripts, prototypes, etc), you don't care about
readability, you just want it to be as easy to write as possible. Python
really shines here.

For bigger projects, using Python is painful, but that's also the case with
pretty much any other dynamic language..

~~~
mixmastamyk
Looks like a lot of folks are using the wrong tool for the job. Reminds me of
that onion article about chastising a dog for being a dog. Found it:

[https://www.theonion.com/dog-chastised-for-acting-like-
dog-1...](https://www.theonion.com/dog-chastised-for-acting-like-
dog-1819566352)

------
pbreit
Considering Python can power the largest web sites (Netflix, Instagram), I
don’t understand why there’s so much use of much more complicated
platform/languages (eg java, .net)?

Note: I am an amateur which is likely the reason for my ignorance.

~~~
chrisseaton
> I don’t understand why there’s so much use of much more complicated
> platform/languages (eg java, .net)?

What language is Python implemented in? Is it Python, or something else? This
tells you that even the implementors of Python don't think Python is suited
for everything.

~~~
joshuamorton
No it doesn't. As someone else mentioned, RPython exists, and in general,
bootstrapping is nice, but there are a variety of compelling reasons to not
rewrite CPython in python, that have nothing to do with it being "suited" or
not.

History, reliability, simplicity, lack-of-value, etc. At this point there's
not much to gain by rewriting cpython in python (pleasing some guy on the
internet), and quite a lot to lose (simple c-interop) for what would be years
of work by a lot of people.

~~~
chrisseaton
It wouldn't have been years of work if they started right after Python was
first implemented instead of a big-bang now. For 25 years each time they've
implemented a new feature they've chosen C over Python to do it, for reasons
of it being better suited, some of which you've listed yourself! Like simple
C-interop!

I don't think it's a criticism of Python! I've worked on meta-circular
implementations of languages and I don't do it for the sake of it. Not every
language is suited for every task.

~~~
joshuamorton
Right, but all of those are historical, not innate, which makes your comment
wildly misleading.

If the Python ecosystem weren't c-based, it wouldn't matter. But it is. But
that has nothing to do with python the language in a vacuum, and everything to
do with choices some guy made 25 years ago.

------
emersonrsantos
Definitely EVE Online's MMO secret weapon is Python:
[https://www.eveonline.com/article/stackless-
python-2.7](https://www.eveonline.com/article/stackless-python-2.7) \- as well
as its numerous ecosystem utilities like Pyfa, Evernus, used by tens of
thousands per day.

~~~
krapht
I would not use Eve-Online as an example of performance.

Once it gets to a few thousand concurrent users they have to drastically slow
down the server tick rate. It's like playing a turn-based strategy game at
that point.

*Disclaimer: I quit Eve awhile ago.

------
dehrmann
There ware a time when I wondered if I should learn Ruby or Python. These
days, unless I'm going to be a Rails dev, hands-down Python.

~~~
jes5199
I was a Ruby programmer for a long time, but I think the world has moved on.
Nowadays, I want a language with some type checking, and Ruby is extremely
hostile to any kind of static analysis. Rails was pretty exciting as a
replacement for how we built websites in the perl/php era, but now that React
has taken over, Rails feels weirdly bloated. I would probably choose
Typescript for basically everything now.

~~~
spraak
I feel that way too regarding choosing Typescript. It's a real joy to use TS
and I'd be depressed having to ship plain JS to production again.

------
blumomo
Reading all the comments here I have the impression that there are 2 groups of
programmers:

There's one group that uses Python regularly and which is getting their stuff
done right now.

And there is the other group which has time to complain about Python.

------
simula67
In my opinion, the biggest problem facing Python is still concurrency. The
mitigation efforts still look to me like Perl's 'bolted on' implementation of
object orientation. Python should have gotten rid of the GIL during the 2 to 3
transition. It may have also been an opportune moment to introduce optional
typing and maybe even optional manual memory management, making it useful to
develop almost all kinds of software. Write a WASM backend and it could have
even been used for front end development.

~~~
sien
Now there is Julia that has concurrency.

Julia, because it's much newer also seems to have dependency management built
in as well.

Surely a lot of people who write numerical software are going to either look
at or switch to Julia for these reasons.

------
winter_blue
This makes feel a bit sad/somber, because a lot of people are missing out on
the exhilarating power of using advanced powerful type systems. I wish the ML
community had picked up a few notes from Python, and built an Ocaml-like
language with beginner-friendly Pythonic syntax (Reason comes close). I wrote
about this here in the past
([https://news.ycombinator.com/item?id=15549101);](https://news.ycombinator.com/item?id=15549101\);)
quoting myself below:

 _I 'm a big fan of strong static type systems. I believe type-safety
increases code quality significantly. I used to think several years ago, that
the main benefit of strong static typing was code safety / eliminating a whole
class of bugs. But I've changed my opinion. I now think the biggest benefit is
that it makes the code a lot easier for other people to read and understand.

I mean I have multiple personal projects where I've used Python (which is a
dynamically typed language), but these are small one-off projects. But I think
when working in a team, especially a large team, having types becomes a huge
thing. Having types for objects is especially useful. Having types forces you
to think more clearly about the structure of your data.

It's really sad when I see `foo(bar)`, and I have no idea what the type of
`bar` is, and if it's an object, I have no idea what fields `bar` has. I have
to simply guess the structure of the various implicit types by looking at the
code (sigh). It makes the code difficult to read, and rather unpleasant to
work on. Not to mention, all the multitude of bugs that come from duck/dynamic
typing.

I don't think good statically typed languages are hard to use at all. Type
inference has spread everywhere that the old argument of having to repeat your
types doesn't hold anymore. TypeScript, Flow (JavaScrpt), Haskell, languages
from the ML family are really good at type inference. Even the `auto` type
inference in C++17 was better than I'd expected._

If dynamic typing continues to grow in popularity, I don't want to even begin
to fathom the number of large projects that are going to built, which will
suffer from a avalanche of TypeError-class bugs that could have easily been
avoided with static typing. One encouraging sign I've seen in the Python world
is that _optional_ static typing is reluctantly being adopted in many circles.
There was mypy for a while, and now, there's a new type checker called Pyre
(written in Ocaml). I find hope in these little things.

------
moosethemucha
I've been told that my choice of python was poor numerous times. 'Do
java/.net' etc. is something I've heard all throughout my career. I use python
because it doesn't work against me - It's not the best language but I think
its definitely the most versatile. I love python and it will be around for
another decade I guarantee it.

------
systems
Python and JavaScript

Ease of use trumping advanced features every time

~~~
mopsi
Ease of use and advanced features are not polar opposites.

I do a lot of geospatial work and Python bindings for GDAL [1] are godsend. In
10 lines of code, I can read shapes stored in different projections and file
formats; load, reproject and merge them into an in-memory SQLite database; do
all sorts of complex geospatial operations on them using spatial extensions,
and save results to a file.

I'd spend half a day writing C++ code that Python abstracts away into very few
commands. It's a joy to work with, and I struggle to see any downsides.

[1] [https://en.wikipedia.org/wiki/GDAL](https://en.wikipedia.org/wiki/GDAL)

------
cryptica
The number of views of questions on Stack Overflow is a bad metric to measure
language popularity. This metric combines popularity and
complexity/unintuitiveness. If a language is half as popular but twice as
complex (or unintuitive) as another language, then it will get the same number
of questions and same number of views.

If the language is becoming more fragmented; more different kinds of
frameworks and tools then it will translate to more questions on stack
overflow. Fragmentation of the language is not necessarily a good (or bad)
thing but it has nothing to do with the popularity of the language.

But definitely the JavaScript ecosystem is pretty homogeneous at the moment
(ReactJS or VueJS on the front end and Node.js on the backend).

------
kamyarg
If you hate python, just write whatever your hearts desires. There is no use
in saying "oh python does not let me know when a variable I expect to be list
is string", well yes, it is a dynamically typed language, please learn the
difference between dynamically and statically typed languages before hating on
any language. As a bonus, you can check if a value is list or string and throw
your own error, python is versatile, although it probably would be an
antipattern and you should go back to writing C. If you love the good old days
of Fortran, then I am sure many Financial Institutions and Aerospace industry
or old school mathematicians would love to have you.

------
ragerino
I would argue that Pythons biggest issue is performance, which translates in
large applications directly into costs. You will need more machines to scale
and you will need more power per operation compared to other programming
languages.

see here: [https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/fastest/python.html)

I think Python makes sense for prototyping and stuff like Jupyter Notebooks.
But once mature and going into production I recommend porting stuff to
something faster like Java or even Javascript nowadays.

~~~
zuuow
Let's count the minutes until someone comes saying "but you can just write C
and bind it to Python", completely missing the point.

------
Dowwie
While I use more than just Python in my work, it remains my go-to toolset for
a range of tasks. For instance, Python offers the best interactive programming
experience of any language today. You can step through code flow and inspect
values with great ease. This is particularly valuable during prototyping, as
you are getting a handle on interactions between your application and third
party dependencies. Further, as designs take shape, you can quickly assemble a
proof of concept and learn how to address a problem or design. Python can be
used with little or any inheritance. Adopt a compositional style. You can
assign types. You don't need to use all of its bells and whistles if you don't
want to. This allows you to use Python in a way that streamlines it for
porting to a strongly typed, high performance language such as Rust, should
the need or desire to do so ever arise.

The Python community is truly global, hosting local events in hundreds of
countries. So many talented, helpful people have been dedicated to the
language and community over a very long period of time. Look at its ecosystem
on GitHub to get an idea of how that manifests. Questions about how to solve a
problem are often a single search away from being answered on Stack Overflow,
Google groups and countless channels on Freenode IRC. Python conferences are a
great place to learn and connect.

------
cztomsik
I like a lot of things in python, but unfortunately, everytime I happen to use
anything which uses python, there's a good chance it won't work on my
environment. And so I'm very surprised how python can be so successful if it
doesn't actually work. I literally fix my env for some tool A, only to make it
incompatible with tool B. And I can't believe I'm alone.

------
C1sc0cat
The comment "Meanwhile, the Unix shell had different problems -- it offered a
suite of utilities for common tasks, but ran so slowly it couldn't handle
complex logic."

This doesn't make sense and also why the F is the " Dutch national research
centre for math and computer science. " using c and nor Fortran

------
newbie578
Interesting article, I would love to read one regarding Java and Kotlin, or if
even someone here would share some knowledge with me, I would be grateful.

Is Java dying, what is its future? Where is Kotlin heading, currently it is
the hottest language for Android development, can it also compete with Python
in some branches?

~~~
rainygold
Java moved to a six month release cycle and it has breathed new life into the
ecosystem as a whole. Its one of the most robust and important languages out
there.

Java will likely never truly die because of legacy applications. It's also
still firmly set in the market and that is not looking likely to change in the
future. Its also the king of microservices with Spring Boot.

Kotlin could well take over the mobile space. Many of the touted benefits of
Kotlin are slowly being added to Java itself.

Java itself may decline as a language, but I'm near certain that the JVM will
be with humanity forever. Someone will be programming in a JVM language
somewhere. Whether it's some future language or Java 532.

------
jasoneckert
I recently gave a Python book to a co-worker that wanted to experiment with
deep learning. _Co-worker: Wow - this book is like 900 pages long!_ _Me: Don
't worry, it's mostly whitespace._ And that is one of my favorite features of
Python - easy to trace and code!

------
sakesun
"I was very disappointed in how the people who disagreed technically went to
social media and started ranting that the decision process was broken, or that
I was making a grave mistake. I felt attacked behind my back,"

May I ask who did he mentioned about ?

~~~
DonHopkins
I don't know the answer to that question, but this post from February 10, 2006
captures some of Guido's frustration with the way certain contributors would
insist on changing Python in ways in which they might be able to win an
argument about syntactic disambiguousity and technical implementability, but
at the expense of that ineffable sense of essential Pythonicity.

[https://www.artima.com/weblogs/viewpost.jsp?thread=147358](https://www.artima.com/weblogs/viewpost.jsp?thread=147358)

All Things Pythonic

Language Design Is Not Just Solving Puzzles

by Guido van van Rossum, February 10, 2006.

Summary

An incident on python-dev today made me appreciate (again) that there's more
to language design than puzzle-solving. A ramble on the nature of Pythonicity,
culminating in a comparison of language design to user interface design.

Some people seem to think that language design is just like solving a puzzle.
Given a set of requirements they systematically search the solution space for
a match, and when they find one, they claim to have the perfect language
feature, as if they've solved a Sudoku puzzle. For example, today someone
claimed to have solved the problem of the multi-statement lambda.

But such solutions often lack "Pythonicity" \-- that elusive trait of a good
Python feature. It's impossible to express Pythonicity as a hard constraint.
Even the Zen of Python doesn't translate into a simple test of Pythonicity.

In the example above, it's easy to find the Achilles heel of the proposed
solution: the double colon, while indeed syntactically unambiguous (one of the
"puzzle constraints"), is completely arbitrary and doesn't resemble anything
else in Python. A double colon occurs in one other place, but there it's part
of the slice syntax, where a[::] is simply a degenerate case of the extended
slice notation a[start:stop:step] with start, stop and step all omitted. But
that's not analogous at all to the proposal's lambda <args>::<suite>. There's
also no analogy to the use of :: in other languages -- in C++ (and Perl) it's
a scoping operator.

And still that's not why I rejected this proposal. If the double colon is
unpythonic, perhaps a solution could be found that uses a single colon and is
still backwards compatible (the other big constraint looming big for Pythonic
Puzzle solvers). I actually have one in mind: if there's text after the colon,
it's a backwards-compatible expression lambda; if there's a newline, it's a
multi-line lambda; the rest of the proposal can remain unchanged. Presto, QED,
voila, etcetera.

But I'm rejecting that too, because in the end (and this is where I admit to
unintentionally misleading the submitter) I find any solution unacceptable
that embeds an indentation-based block in the middle of an expression. Since I
find alternative syntax for statement grouping (e.g. braces or begin/end
keywords) equally unacceptable, this pretty much makes a multi-line lambda an
unsolvable puzzle.

And I like it that way! In a sense, the reason I went to considerable length
describing the problems of embedding an indented block in an expression
(thereby accidentally laying the bait) was that I wanted to convey the sense
that the problem was unsolvable. I should have known my geek audience better
and expected someone to solve it. :-)

The unspoken, right brain constraint here is that the complexity introduced by
a solution to a design problem must be somehow proportional to the problem's
importance. In my mind, the inability of lambda to contain a print statement
or a while-loop etc. is only a minor flaw; after all instead of a lambda you
can just use a named function nested in the current scope.

But the complexity of any proposed solution for this puzzle is immense, to me:
it requires the parser (or more precisely, the lexer) to be able to switch
back and forth between indent-sensitive and indent-insensitive modes, keeping
a stack of previous modes and indentation level. Technically that can all be
solved (there's already a stack of indentation levels that could be
generalized). But none of that takes away my gut feeling that it is all an
elaborate Rube Goldberg contraption.

Mathematicians don't mind these -- a proof is a proof is a proof, no matter
whether it contains 2 or 2000 steps, or requires an infinite-dimensional space
to prove something about integers. Sometimes, the software equivalent is
acceptable as well, based on the theory that the end justifies the means. Some
of Google's amazing accomplishments have this nature inside, even though we do
our very best to make it appear simple.

And there's the rub: there's no way to make a Rube Goldberg language feature
appear simple. Features of a programming language, whether syntactic or
semantic, are all part of the language's user interface. And a user interface
can handle only so much complexity or it becomes unusable. This is also the
reason why Python will never have continuations, and even why I'm uninterested
in optimizing tail recursion. But that's for another installment.

------
zer0faith
You can't deny Python is versatile language with a moderate learning curve and
packages that will do almost anything.

These things have made me more productive programmer and allowed me to get
stuff done in a reasonable amount of time.

------
zettaquark
I love Python but.... I would not go to the lengths that this article
proposes. The dev world recreates itself every year with dozens of new high
level languages and task specific support libraries. Every developer has their
favorite language (Everyone is comfortable with their personal preference)
That being said, I enjoy Python and it provides a quick, easy script to
accomplish task in my space but I would not go as far as the article in saying
that it is the end all be all for everyone. Use what you like, and understand
that all languages have strength and weaknesses for task.

------
chrisfinazzo
Is there a reason people don't choose Perl much anymore? It's a fine scripting
language and supports the UNIX C API almost full stock.

^ Another Siracusaism, who's still - by his own admission - a Perlhead.

~~~
mixmastamyk
It doesn't scale to multiple developers, even more poorly than Python.

------
ashishb
I find Python to be a great alternative to writing bash scripts. I did that
with this semi-popular Android tool ([https://github.com/ashishb/adb-
enhanced](https://github.com/ashishb/adb-enhanced)). Python is close enough to
be a language but straight-forward enough to be a shell script.

For the Python haters here. No, Python is not as good as GoLang or Kotlin for
maintenance but IMHO, it is better Javascript/Typescript/C++ for writing non-
performance critical code.

------
deltron3030
What I find baffling is that almost every program I'm interested in as a
creative power user has a Python API for scripting, from type and graphic
design to 3D modeling, rendering and music making.

I'm a bit into web design/frontend as well, and was thinking about either
learning JS and Node more deeply, or add some other "backend language" like
PHP or Ruby, and learn their frameworks like Laravel or Rails.

Should I pick Python, Django or Flask instead to cross the gap to my creative
hobbies?

~~~
_bxg1
The data synergy of Node + Web is hard to beat, and JS is very elegant for
writing asynchronous code. Also, I've found the web (canvas, svg, webgl with
Three.js) to be an amazingly hackable creative platform. Just my two cents.

------
rafaelvasco
A joy to write and read. But a pain to debug and maintain. Coded a big project
in Python once. When the project was still small everything was perfect. When
the project grew it became unsustainable. Of course I was an already
experienced C# dev, just getting started with Python but the problem is there.
A whole lot of errors spilling to runtime is a big pain. But that's a problem
with every dynamic language at variable levels.

~~~
mixmastamyk
Tools, tests, and logging are the cure to those troubles. I've not experienced
substantial problems with projects large or small.

If a project is known to be huge up front and/or some developers will be
inexperienced choosing a language with additional guardrails would be prudent.

------
safgasCVS
I cant comment on general software engineering but in the data science domain
coming to Python from SAS / SPSS feels like being given free superpowers

------
hajderr
I've not written that many heavy applications in Python (Java mostly). I do
like the dynamic nature of it. I find myself leaning more towars dynamic these
days, appreciating Javascript today as well. I like the v.env side of Python.
Many languages have this plumbing to get a project started and Python is the
most comfortable of them all. Python is smart. Python is easy to teach also.

------
vincent-toups
If you ask me the world only needs two programming languages, Scheme and OCaml
and it would be better if OCaml had s-expressions as syntax.

~~~
AnimalMuppet
There are more things in the computer programming universe than are dreamed of
in your philosophy.

(With apologies to William Shakespeare...)

~~~
vincent-toups
That is why we have syntax-case.

~~~
AnimalMuppet
Non sequitur? (That is, your comment does not seem to follow whatsoever from
mine.)

~~~
vincent-toups
Suppose there are more things in the programming universe than are strictly
represented in (say, R5RS) Scheme. Because Scheme has things like
continuations and syntax-transformations, we can put them into the language.

------
sgt101
It's easy to get going on it, it's productive for writing scripts and
experiments. It's dreadful for programming in the large, but only in
comparison to languages designed to take account of the lessons learned about
large code bases and team working. Most programmers have never encountered
these and have very little idea of what they are missing.

------
altmind
Can totally agree that python is eating the world, while in the same time
being too opinionated on certain things and lacking in certain points. I would
rather see lua more adoption - its the language designed right - minimal and
logical, easy to comprehend quickly for anyone who got any exposure to other
C-like languages. Easy integrations as a bonus.

------
lame88
Python’s killer feature - and perhaps reason for its popularity- seems to be
it’s nice-looking syntax, which is only the most superficial of qualities.
Below that surface, the semantics and its standard libraries are all very
irregular, and always leave a bad taste in my mouth. I now avoid touching it
if i can.

------
fratlas
[https://outline.com/4zf4Dd](https://outline.com/4zf4Dd)

------
Jerry888
I have used all code from c+, java, php, javascript, ruby and more and found
python is the easiest and simplest to use (you do not have to setup 5 classes
to declare 1 variable) the only thing i hate about python is there is no built
in parser to handle formatting.

Which is a simple but big design flaw for me.

------
Maledictus
Anybody else sad that this is not Ruby?

------
mobilefriendly
This is wrong in terms of the web space. With the modernization of PHP and the
emergence of Laravel, and continued evolution of Drupal and Wordpress, I don't
think PHP has ever been this dominant in the web stack. Django is an also-ran.

------
fredthomsen
Funny that I seen a few articles titled somewhat like this in reference to
javascipt.

~~~
nineteen999
Javascript might be eating the world of web development, but there are a whole
lot of other scenarios outside of web programming that Python is more likely
to be used in, IMHO.

------
agumonkey
Saying this again, is this a cover effect ? I'm strongly thinking that python
reign just peaked, and that either python will change drastically into a more
solid static core or people will go Julia..

------
enginaar
Never had the chance to use python but what I hear most about Python is that
it's easy to develop/saves developer time. Is it still true when maintaining a
project vs developing from scratch?

------
Tehchops
Wow. uBlock registers at least 50 unique blocks, and my laptop still churns
trying to load all the extraneous ad content ZDNet tries to jam down the pipe.
ZDN stopped being journalism long ago

------
spenrose
Best thing I have ever read on Python's history. Really fine work.

------
pc2g4d
It's such a great language, and so incredibly slow :-/

~~~
hnarn
Probably a kind of premature optimization on my part, but this is why I chose
Golang over Python as my primary language. Maybe one day Python will have its
own compiler without having to drop into writing C, who knows? For know I
think the features of Go are just more attractive than those of Python.

~~~
asperous
Python has a compiler without dropping into C (cython).. but it's mostly used
these days for glue code between c and Python, or for small bits of code that
need extra optimization.

There is also Rpython and pypy

~~~
yesenadam
I do most of my programming in Cython these days, mainly maths/graphics-
related, but all kinds of stuff. It's great for that! I do the intensive
calculation parts with typed C variables, structs, arrays, at C speeds, while
doing the once-only stuff like loading and saving images in pure Python. I
guess it's weird floating between C and Python from line to line in a program,
but I like it a lot. (Not having to type semicolons and curly braces anywhere
is no small benefit also.)

------
karl11
I am just happy to see that debates on whether some programming language is
awesome or the worst are still popular on HN.

------
breatheoften
It’s really terrible that python should be growing. It’s a bad language and a
bad ecosystem ...

The knowledge exists that we shouldn’t be encouraging systems to be built with
the patterns/tools commonly advocated in the python world — at what point do
we acknowledge that the forces promoting this kind of ecosystem are
essentially propaganda-like mind viruses ... so much future suffering that
will not be prevented ...

------
melling
Are there any good cloud solutions for developing in Python?

I’ve been using Pythonista on the iPad but it doesn’t support numpy.

~~~
audiometry
I use pythonanywhere. Seems to work well enough and isn’t expensive. Main
problem I have with it is I cannot use Altair-viz in a Jupyter notebook
because their notebook server is out of date.

------
mark_l_watson
Well, I could be put in the ‘Python hater’ category: I do love Python for
short programs using TensorFlow, the SpaCy NLP library, PyTorch, etc. I really
hate using Python for large applications. Everyone gets to choose their own
favorite languages, and for me that would be Common Lisp, Haskell, Java, or
Scala for working on large projects. Each to their own though.

------
victoray
It's not flexible as PHP does, but I guess it's faster than PHP.

~~~
stunt
When it comes to raw performance, PHP7 is much faster than Python.

PHP is more flexible when it comes to building web applications. But in some
areas Python just have better libraries (computer vision, matrices, high-level
mathematical functions). I remember reading that PHP is going to add FFI and I
believe FFI will have a big impact in PHP world.

------
seisvelas
I really hoped Julia would become a major player in scientific computing and
data science, but it looks like ever less probable. I like Python, but for
science I like Julia more.

------
amelius
Is it fair to say that Python is the new BASIC?

------
DonHopkins
>"In the past, it had always been clear that if there were a decision to be
made about a change in the language or an improved feature, a whole bunch of
core developers would discuss the pros and cons of the thing. Either a clear
consensus would appear or, if it was not so clear, I would mull it over in my
head and decide one way or another. With PEP572, even though it was clearly
controversial, I chose 'Yes, I want to do this', and people didn't agree to
disagree.

This is a characteristically practical, effective Dutch attitude, known as the
"Polder Model". The United States currently suffers from the opposite problem
of extreme partisanship and gridlock.

[https://en.wikipedia.org/wiki/Polder_model](https://en.wikipedia.org/wiki/Polder_model)

The polder model (Dutch: poldermodel) is consensus decision-making, based on
the acclaimed Dutch version of consensus-based economic and social policy
making in the 1980s and 1990s.

The polder model has been described as "a pragmatic recognition of
pluriformity" and "cooperation despite differences". It is thought that the
Dutch politician Ina Brouwer was the first to use the term poldermodel, in her
1990 article "Het socialisme als poldermodel?" (Socialism as polder model?),
although it is uncertain whether she coined the term or simply seems to have
been the first to write it down.

[...] Other uses

The term polder model and especially the verb polderen (to polder) has been
used pejoratively by some politicians to describe the slow decision-making
process where all parties have to be heard. The model flourished under the
"Purple" governments of Dutch prime minister Wim Kok, a coalition including
the traditional rivals the Labour Party (a social-democratic party, whose
colour is red) and the People's Party for Freedom and Democracy (right-wing
liberals, whose colour is blue). In the declining economic climate of the
early 21st century the model came under fierce attack particularly from right-
wing politicians and Pim Fortuyn in his book entitled De puinhopen van acht
jaar Paars ("The wreckage of eight years Purple").

Historical background

[...] A third explanation refers to a unique aspect of the Netherlands, that
it consists in large part of polders, land reclaimed from the sea, which
requires constant pumping and maintenance of the dykes. So ever since the
Middle Ages, when the process of land reclamation began, different societies
living in the same polder have been forced to cooperate because without
unanimous agreement on shared responsibility for maintenance of the dykes and
pumping stations, the polders would have flooded and everyone would have
suffered. Crucially, even when different cities in the same polder were at
war, they still had to cooperate in this respect. This is thought to have
taught the Dutch to set aside differences for a greater purpose.

------
coleifer
What stood out to me: online bullying (dressed-up sometimes as
concern/outrage) is what led to Guido stepping down.

Python is great, but it will never be perfect. But the outrage stuff, the
entitlement stuff, essentially anything that happens on Twitter... Python
seems like a victim of it's own success. Once it got popular, it couldn't
scale the checks that might have stopped this runaway train of shit-tweets and
bickering on the mailing list.

Personally I don't like a lot of the things that have happened in 3 (asyncio,
type whispering, fstrings). I can't help but wonder if, again, this is due to
becoming too popular too fast. I say that because aesthetically these features
seem to go against the Zen of python.

May you never have users, but if you do, may they not have Twitter accounts!

~~~
wil421
What’s wrong with fstrings? I use JavaScript at my day job and leaning python
for Raspberry PI projects. Fstrings looks like it’s better than .format or +
concatenating + a bunch is strings. Especially large strings.

------
mlwhiz
I have been a Python guy for 10 years now switching from another profession -
I was a mechanical engineer. I tried to learn other languages like Java ,C and
was partially successful too. But I don't remember creating anything useful in
those languages.

Everything was so verbose that I got drowned in the syntax rather than the
logic behind the program. For me, Python signifies ease of development and
fast iterations and as such is suited for any young developer.

------
GnarfGnarf
Dynamic typing does not scale.

------
peter303
Python is a prototyping language, but not a serious software engineering
languagebfor large and fast projects.

------
paulcarroty
Switch to JS was like obtaining new home, don't want to write Python code
anymore. Also "Eating the World" isn't correct anymore, 'cause Python
popularity decreasing last ~5 years according to Github stats.

------
captainbland
I wonder what the consequences of this are given Python's apparently very poor
energy consumption profile: [https://thenewstack.io/which-programming-
languages-use-the-l...](https://thenewstack.io/which-programming-languages-
use-the-least-electricity/)

It appears to consume over 17x more power than JavaScript, 40x more power than
Java or 75x more than C/Rust. The only language which performed worse than it
in terms of pure power consumption was Perl.

While I'm sure these results aren't exactly indicative of day-to-day usage as
they're based off of benchmarks which are not exactly representative of day to
day use cases it nevertheless raises the question of whether Python is an
appropriate choice of language where the application itself is likely to see a
high level of total use. I suspect the answer is "more work needs to be done"
on the subject to truly assess the impact and a big part of the answer is
"depends on how you're using it". It'd be good to see some standardised tests
of web frameworks. For instance, load testing a standardised server side
version of the TodoMVC project to determine what happens for each framework
there, along with what happens when you stick a cache in front of them and so
on.

It'd also be interesting to attempt to estimate how much power consumption and
hence CO2 generation each given programming language is responsible for given
their marketshare and typical usage profiles - although I suspect in practice
this would be quite difficult given the diverse usage profiles of modern
programming languages. And obviously the fact that machine learning libraries,
for instance, will naturally be quite energy intensive - it's probably the
case that Python actually does quite well there because most of its popular
libraries for that are just wrapping C or similar rather than being pure
Python code.

Given the success of V8 and PHP7 in terms of boosting the performance and
presumably energy efficiency profile of their respective languages it'd be
nice to see the mainline CPython interpreter undertaking a similar kind of
transformation. Obviously we have things like PyPy but it seems to me the
Python community needs to be united around a solution to this which forks
simply are not going to be able to drive.

~~~
mixmastamyk
Find the hot parts of your app with a profiler, then augment them with Cython
to boost efficiency 10-100x.

------
flyinglizard
I feel like the world has gone insane when it comes to Python. Or have I gone
insane?

Python is an incredible waste of time. No types, IDEs that suck (a side effect
of not having types), very partial validation with linting tools that are an
afterthought to the language, indentation is a mess (good luck moving files
between different editors and environments or through clipboards), slow,
agonizing deployment (pyenv? Come on).

I’ve been doing C# these past two years and it is laughably effective in
comparison, almost like cheating. Standard libraries covering almost anything,
tooling that couldn’t get any better, runs everywhere, lighting fast builds.

Most importantly, in C#, due to the incredible tooling and language design, if
it’s built successfully then there’s a very high chance it’ll do what I want
it to right out of the bat. In C/C++, much less so. In Python it’s almost
guaranteed not to do anything but crash unless I’ve ran everything through in
depth coverage testing and I’d still take the C# build checking every time.

My Python is pretty good, and I’ve known it for more than 15 years now. I’m
not taking this position out of ignorance.

For the love of god, go learn a proper language. It can be C#, which I think
is as perfect platform/language as anything, or Rust or Go or even Java.

I see young devs on their vim or Sublime editors developing Python and I want
to shout to them, that’s not how it’s done. You’re missing out on decades of
industry evolution and know how in things like the Visual Stdio and .NET or
even Java and JetBrains/Eclipse. You’re using stones to start fires where you
could just use an oven.

I still use Python, but it’s always for very short and specific programs. It’s
just a bad tool for more than that. If you are unable to resist the temptation
of using Python for that short program, just make sure it never ever has a
chance to grow.

Regrettably the ML world lives on Python, fine; let them have it.

~~~
6gvONxR4sf7o
Pycharm is pretty excellent in terms of IDEs. It's quite literally IntelliJ
for python.

~~~
flyinglizard
Python’s lack of typing means the IDE heavily uses heuristics. It’s nowhere
near as good as Intellisense on C#. Take refactoring a variable name as an
example.

~~~
gcthomas
The "heuristics" are down to Python being _dynamically_ typed, not it's lack
of typing, so the type can't be known until run-time. Python is actually
_strongly_ typed.

~~~
flyinglizard
Sorry, I meant lack of static typing, not the lack of any typing.

------
higherkinded
And that's a sad thing to hear. Before my death by thousand downvotes, I'd
like to tell you why do I feel that way.

Back in the day when I was way more inexperienced than I'm now, I was a die-
hard Python fanboy. To me, it seemed like a best option available due to it
being way more concise and readable than JS/PHP, not to mention that it was
way more powerful and dense. I didn't really bother with type safety at the
time and I wasn't exposed to any real criticism of it at the time, as it
happens often when you're just too new, and I was more than fine with it.

Time mercilessly marched forward since then. I worked with different
codebases, changing tech stacks and languages a bit, learning new stuff and so
on. With some experience, lots of self-education and a vast amount of
different workflows to compare with, I've realized one important thing. While
Python may be better than some languages that are considered trash by industry
consensus, it's also a trashcan language to ones with sound and flexible type
systems, not to mention that, across dynamically typed contenders, it's
nowhere near as powerful as literally any solid Lisp.

That said, I feel bad for the industry that "dives into Python" more and more
over the last years. While it may seem like a pretty easy and cool-ish
language to write in, you will inevitably have large problems at scale, it
just doesn't have what it takes to be easily scalable, and most importantly,
it's just tedious to refactor when it's big, even though the language itself
is mind-numbingly easy and even your grandma can jump right in.

In a conclusion I'd like to say that you'll be better off without using Python
as your project's main driver. Yes, it's simple to write it and the developers
supply is abundant. It's easy to start. It'll just be a major pain to scale it
and support it later on.

Edit: Made a pun.

~~~
joshuamorton
> sound and flexible type systems

Python has a more powerful type system than any mainstream language except for
C++ (templates). No other mainstream language has support for explicit marking
of variance of arguments, nor does any other language support literal
(dependent) types, except for typescript.

~~~
higherkinded
And how's it helping you verify the correctness of your codebase at compile
time (it still compiles the source to byte-code before evaluation)? Last time
I checked, it didn't care too much about type annotations, and it didn't type-
check anything before execution without additional shoehorning.

>No other mainstream whatever

C#, Rust. Notice that I don't even mention my man Haskell or Scala while the
latter one is really big.

>literal (dependent) types

Uh, even Java has dependent types, anyway. Read the docs.

>templates

Yes, that's parametric polymorphism. No, it's garbage in C++ to the point
where you can't guarantee the soundness of a template. It's done in Java,
Kotlin, C#, TypeScript, for the most mainstream ones, not to mention that (and
how exactly) it's done in Haskell and Scala.

Edit: How do you feel about type-level programming, anyway? ;)

~~~
joshuamorton
> And how's it helping you verify the correctness of your codebase at compile
> time (it still compiles the source to byte-code before evaluation)? Last
> time I checked, it didn't care too much about type annotations, and it
> didn't type-check anything before execution without additional shoehorning.

All of the python I write is checked at compile time. Much like java and javac
are different tools, python and pytype/mypy are different tools. This is
nothing new.

>C#, Rust. Notice that I don't even mention my man Haskell or Scala while the
latter one is really big.

Neither supports dependent types.

> Uh, even Java has dependent types, anyway. Read the docs.

No, Java has generic types, not dependent types[0]. Dependent types are types
that depend on the _value_ , not the _type_ of an argument. As a concrete
example:

    
    
        @overload
        def open(
            path: _PathType, 
            mode: Literal["r", "w", "a", "x", "r+", "w+", "a+", "x+"],
        ) -> IO[Text]: ...
        @overload
        def open(
            path: _PathType,
            mode: Literal["rb", "wb", "ab", "xb", "r+b", "w+b", "a+b", "x+b"],
        ) -> IO[bytes]: ...
    
    

Java, rust, and C# don't support this. C++ does for certain types (integers).
Python and typescript support this for certain types (integers, strings, enum
_values_ ).

Other common examples are type-safe matrix multiplication that at compile time
can ensure that the matrix sizes all match correctly. Eigen in C++ does this.
Haskell and Scala can do this with some massaging, although its not natural.
Java, Rust, C# just plainly cannot.

[0]:
[https://en.wikipedia.org/wiki/Dependent_type](https://en.wikipedia.org/wiki/Dependent_type)

[1]:
[https://www.python.org/dev/peps/pep-0586/](https://www.python.org/dev/peps/pep-0586/)

~~~
higherkinded
>Much like java and javac are different tools, python and pytype/mypy are
different tools

I get where you're heading. The `java` one is for JVM bytecode interpretation
and the `javac` is for actual Java. Ok. Cool. I suppose that you do understand
it well that leaving the choice on typechecking to external tools is something
rather atrocious, do you?

>All of the python _I write_

The factory that produces the hammers for us carpenters provides just
hammerheads alone and leaves us to choose and get the grips, so oftentimes
fellow woodworkers use them without any grip whatsoever, some make flails and
flail the nails, and I just go buy the soft grip from a third-party vendor.
What's the problem here?

>[throws a Wikipedia link with the term definition at me, goes on showing me
what must be done by a sum type]

You sure do consider me stupid, right? Anyway, what dependent types _usually_
do is they limit a category (think set) to some sub-category. Your example
indeed describes dependent types but the problem with it is that it isn't a
good place for dependent types. It can be expressed by sum types and I don't
see any reason not to do so. By the way, do you have the sum types in Python
nowadays?

>has generic types, not dependent types

(1) Look. Have you heard it anywhere that once you get powerful-enough
generics, you can at least emulate dependent typing to some extent if not
outright get it? Consider this: Java can express Peano numbers at the type
level, along with Rust, C# and whatever there is with even remotely working
generics. Do you know what that means to us here? Yes. We can express anything
number-related at the type level, thus getting one little step closer to
dependent typing. The most modest example of what you can do with that is a
list with length limited on a type level, which qualifies pretty ok for
dependent typing.

>not the _type_

Dependent typing is still about types, and if you work with these on a type
level, you will deal with types. The type isn't inferred here but the value is
limited by the type in question, so please don't say this, otherwise it will
not constitute a sane type system. Imagine the types that just constatate the
fact once it happened instead of setting an invariant (ah yes).

>with some massaging

Zero massaging[0] but ok. I hope that, knowing about [0], you've already
guessed that there's an implementation of matrix multiplication with actual
dependent types[1].

Actually, if you want, I could implement type-level floats for you but I'm not
sure if they have any good use case and I'm pretty sure that some operations
will compile for a little while: type families operating on numbers are
usually defined in terms of recursion. Not sure if we're going to flex type
systems at each other at this point, there's a clear winner even if we're not
bringing the said to the table: static typing in Python isn't provided out of
the box, and while your little example makes me check it out and appeals to
me, it's still a third-party tool and that's not how it must be. I will not
mention anything about types describing here. If that's not enforced by type
system, it's pretty bad but there's no point in discussing that already,
enough's been said.

>plainly cannot

Refer to (1).

[0]: [http://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-
Ty...](http://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-
TypeLits.html)

[1]: [https://hackage.haskell.org/package/linear-
code-0.1.0/docs/M...](https://hackage.haskell.org/package/linear-
code-0.1.0/docs/Math-Algebra-Matrix.html)

Edit 1: one more link.

Edit 2: a suggestion and some out-of-place conclusion.

~~~
joshuamorton
> It can be expressed by sum types and I don't see any reason not to do so. By
> the way, do you have the sum types in Python nowadays?

I'd suggest you attempt to do so. If you mean that, with the benefit of
hindsight, you could go back and replace the string with an enum or set of
flags, sure, but no, the signature of the function in question is, and due to
historical baggage, must stay

    
    
        def open(path: _PathType, mode: str) -> Union[IO[Text], IO[bytes]]: ...    
    

It's just that the set of values `mode` can take on is restricted to a list of
~30 valid strings, which importantly can affect the output type and swap it
from Text to bytes. Python already has sum types, and they, uhh, can't solve
this problem, as you should know.

> Dependent typing is still about types

Well kind of, in the sense that Literal[4] or Nat::2 is a type, yes. In the
sense that Literal[4] is a subclass of int, yes. But it's very different, and
much more powerful, because most type systems force you to deal with types as
sets of values, and you can't introspect into the sets at all. Dependent types
let you introspect and care about particular values, and so you don't have to
deal with the types as opaque things. You can care about values, and you
aren't restricted to working with only types. But yes the values are still
types.

> Have you heard it anywhere that once you get powerful-enough generics, you
> can at least emulate dependent typing to some extent if not outright get it?

Yes, but implementing peano numerals in java or rust's type system isn't the
same as having literal-dependent types, in which you can dispatch based on the
actual values present in the language. PEANO_FOUR isn't the same as `4`, and
short of a massive amount of codegeneration, you're not gonna have
PEANO_FIFTEEN in java generics. Or I mean, if you want to do that, be my
guest, but I'll just use `4`.

Or to put it another way: yes, Java's type system is technically turing
complete. That doesn't mean that it is pleasant to write programs that execute
only during java compilation. Support for literal dependent types makes that
more pleasant (and in some cases possible, I'm not actually clear on how you'd
write a java function that compiles if passed `4`, and fails to compile
otherwise, bridging the gap between PEANO_FOUR and `4` isn't, I don't believe,
possible in java. You can no longer use java's own integer class in your code,
you have to use your new peano integer class). Native support for dependent
types inverts that.

> I suppose that you do understand it well that leaving the choice on
> typechecking to external tools is something rather atrocious, do you?

This depends. There's a gradient: I run probably 20-30 static analysis tools
on my code, from linters to typecheckers to autoformatters. Things that check
for malformed TODO comments and all kinds of other fun things. They all
prevent various classes of errors. I think not investing in typechecking for
large programs is bad, but I also think there's a huge value in gradual
typing. Being able to explore interactively in a repl is something that would
be painful in java or C++, but is quite pleasant in python. Being able to then
convert that code to be production ready by adding types and type-checking,
without rewriting in a totally new language, is also quite pleasant. Leaving a
user without the choice is also atrocious for many styles of development. That
python is able to work for more than one is imo, a feature more than a bug.

~~~
higherkinded
>cross the bridge

No one really wants that in any use cases of type-level numbers. Type-level
numbers are generally used to do just opposite: silently (well, loudly, if you
ask the compiler to check it) govern the structure in question, limiting, say,
its arity or whatever. But if you want to "cross the bridge", I think it's
still possible but tricky in case of Java. Don't get me wrong, I don't
advocate for Java nor intend to write it, I just use it as a dummy trashcan
language to illustrate concepts and their latency in a sense that you don't
really need to use fancy X in order to do Y or express Z.

>20-30 static analysis tools

Too bad. I'm usually pretty happy with just plain compiler and a 80-char bar.

>huge value in gradual typing

Doubt that. It's actually a good safety net to stop a project from turning
into a big ball of mud but it won't help unless used correctly and with the
right intent.

>being able to explore interactively

Hindley-Milner type systems can infer your stuff so well that you usually
don't have to worry about supplying type signatures at all. For instance, in
Haskell you don't have to "add types" compared to what you do in REPL, you
have them all the time and oftentimes you don't have to annotate anything,
it's still static and usually done just to give an idea to other people what's
doing what.

Oh, not about our little conflict but about Python: does it have some form of
traits/typeclasses/whatever? I mean, yes, it has them in form of mixins but
can it, in modern days, put a constraint on some type variable, saying that it
must have some properties that are described in different traits?

~~~
joshuamorton
Protocols, which are essentially traits are a WIP. I think there's an
experimental impl supported by mypy, but it's not in common use just yet.

------
TekMol
Two things I don't like about Python:

1: No seperator sign like ";", so you cannot express everything you want in
one line. Oneliners are often so useful that I don't want to live without
them.

2: By default, it caches the bytecode on disk. This is slow and spills those
files into the filesystem. I prefer PHP in this regard, which caches the
bytecode in memory.

~~~
petters
Python has semicolons.

~~~
TekMol
But they do work the same as a newline. So you cannot do everything you want
in one line.

------
neya
I am currently writing Python based software for a client on serverless
architecture. Honestly, I really feel like myself and a lot of people I know
use Python only because it has some useful libraries like Pandas compared to
other languages. In addition, the effect of 2.xx and 3.xx fiasco can still be
felt during development.

These days, I really wish I could write my stuff in Elixir, but too bad its
data science eco-system isn't as strong as python's. In the very least, even
Ruby as a fallback is much much better to write code with since its philosophy
is drastically different from Python's - "Optimize for programmer happiness
(Ruby) vs Fuck the programmer and optimze for computers (Python)".[1]

[1] [https://rubyonrails.org/doctrine/](https://rubyonrails.org/doctrine/)

~~~
Daishiman
This a complete misrepresentation of the Python philosophy and a cheap troll.

~~~
neya
What makes you think it's a cheap troll? Please read the doctrine on how
drastically different Python's philosophy is. The interpretation - It's my
opinion. Take it or leave it.

~~~
Daishiman
Zen of Python. There are good reasons why a lot of the language is the way it
is and it optimizes for developer happiness exactly by not letting you do
everything under the sun.

Some languages take this to an extreme with its type systems or coding
guidelines. For a lot of people Python is a very happy medium for a large
subset of a lot of software written out there.

------
lwansbrough
Recently was trying to convert Python to C#... there are few things that are
as absolutely incomprehensible as a Python programmer being clever with numpy.
I gave up on the conversion. Perhaps this is a point for Python’s flexibility,
but I’d say it’s just a waste.

Here’s the code. Try to convert this to any C style language.

    
    
                mins = X.min(axis=0)
                maxs = X.max(axis=0)
                idxs = np.random.choice(range(self.dim), self.dim-self.exlevel-1, replace=False)  # Pick the indices for which the normal vector elements should be set to zero acccording to the extension level.
                self.n = np.random.normal(0,1,self.dim)                             # A random normal vector picked form a uniform n-sphere. Note that in order to pick uniformly from n-sphere, we need to pick a random normal for each component of this vector.
                self.n[idxs] = 0
                self.p = np.random.uniform(mins,maxs)                               # Picking a random intercept point for the hyperplane splitting data.
                w = (X-self.p).dot(self.n) < 0                                      # Criteria that determines if a data point should go to the left or right child node.
                return Node(X, self.n, self.p, e,\
                left=self.make_tree(X[w],e+1,l),\
                right=self.make_tree(X[~w],e+1,l),\
                node_type = 'inNode' )

~~~
TheDong
Your challenge isn't possible because the code snippet isn't complete. It
doesn't include the definition of 'make_tree', 'Node', or the broader context.

That being said, I have no doubt that C++ with Boost would look quite similar
to that. The boost libraries have very powerful numeric constructs and can
easily handle matrices, uniform random distributions, dot products, and trees.

~~~
lwansbrough
Well, yeah. My point is the syntax itself is very (too) clever. This syntax is
probably possible in C# but you’d be a monster to write it (lots of operator
overloads.)

The whole implementation is from an implementation of an extended isolation
forest. It’s easy enough to find on GitHub if you’re interested.

