Is Python the Future of Programming? | Hacker News Reader

Is Python the Future of Programming?

m.slashdot.org

51 pointssubmeta73 comments

How are people writing large programs in Python? Isn’t the lack of compiler type checking making it difficult? And what about lack of access modifiers? People aren’t bothered by this?

For programs less than 500 lines, I have no issues with Python, but it feels to me like Python just isn’t suited for large-scale programming in the way C#, Java, Go, or Rust are.

Access modifiers are something that I only ever find to get in the way. I've recently moved to Java from Python for work. The underscore convention in python works fine for hiding stuff from the general public namespace, but its still there if you want to explore how some code or module works. Java really annoys me because I can't access implementation details when I'm trying something out in an interactive shell or debugger, even if I'd never access a private/protected variable in production code

The point of access modifiers is to get in the way. They're ways of allowing developers of one part of the source to control what the path of least resistance is for the users of that code.

If you expose everything, someone will write code that depends against it and make it harder for you to improve or change it in the future. Tossing in roadblocks helps guide users to the better long-term path.

It doesn't really matter for small teams, but it's essential for large ones without aggressive (and difficult) enforcement of contract between team members.

`foo._a` accessible outside `Foo` but it makes code look gross and means you're doing something wrong.

`foo.__a` accessible only inside `Foo`

I think it works.

> `foo.__a` accessible only inside `Foo`

It's not all that inaccessible. Try:

    class C:
      def __init__(self):
        self.__private = 'Is it private?'
    
    c = C()
    c._C__private

Double underscore names aren't so much about access control (because access control isn't strongly enforced) as about limiting name collisions (by including the class name in the underlying field name).

Specifically, it's about avoiding collision of "private" names via inheritance.

If you are working with a large team, you need a statically typed language. Access modifiers are the least of your problems, the lack of refactoring support is a much bigger problem.

I agree, but I was focusing on a single aspect and explaining why its value might not be apparent to the parent commenter. Really, the same argument can be adapted to other contentious features of popular static languages.

> If you expose everything, someone will write code that depends against it and make it harder for you to improve or change it in the future. Tossing in roadblocks helps guide users to the better long-term path.

> It doesn't really matter for small teams

Doesn't even have to be your team. We encountered this by way of a major library, celery.

I forget all the details, but celery was importing something else (name started with a "k", I think), and that was importing an underscore-prefixed function from uuid. Somewhere between python versions 2.7.8 and 2.7.13, the implementation of uuid changed and that import failed.

Personally, internal mutation is something you should avoid in general. Pretty hard to avoid in OO languages though.

Easy. They write code. Code "works". Cool, ship it. Oh what's that? It has lots of bugs? How much money is it going to make us if we fix them? Eh, maybe we'll get to it. /s

The real productivity win here is that you can hire a bunch of junior engineers out of university for "cheap" that "know" python. After all, why would you train a new hire in a different language for a few weeks or months when that would take a huge amount of time in startup-verse? /s?

It's important to note that the largest push for things like type checking and access control in dynamically-typed, shared-mutable-everything languages are coming from the companies that built themselves quickly on these languages and now need to deal with scaling.

I think programmers often misinterpret what’s hard about building large projects.

It’s not correctness it’s communication. A type checker will save you from small errors but well written and easily understandable code will save you from a lot more.

Not saying readability is harder in c# java go or rust just that the type system doesn’t help with it that much.

As a Python developer, I love type annotations on function signatures because they're great, up-to-date documentation. I don't care so much about them being checked, I care that they make the function much easier to read and reason about.

If they weren’t checked, how would you know they are up to date?

I don't care how they're updated, I just care that they are. If that's by checking, it's fine by me.

Some of the biggest web services are written with Python. There are tradeoffs, just like everything else. I happen to work for a company with a gigantic python codebase. It would be a hell of a lot easier to refactor our systems if we were in a statically typed system, but we work around this by having shitloads of tests. Tradeoffs.

I don't think python is good for large systems, but for companies, it's hard to get to that point without something that you can prototype quickly with.

Agreed. I love both (you can check my post history) but literally the most basic thing trips me up beyond a certain size/scope of programs: typos. Having a little structure that an IDE can leverage makes mountains of difference.

I'm sure a more competent typist wouldn't have these issues but it trips me up constantly just in dev. Tests protect this from hitting prod.

The extra refactor support just isn't there compared to java.

> Isn’t the lack of compiler type checking making it difficult?

There is type hinting.

> And what about lack of access modifiers?

There is @property decorators

> How are people writing large programs in Python? Isn’t the lack of compiler type checking making it difficult?

Python 2 and 3 both have AOT static type checkers available (this is essentially “pre-compile-time”). Presumably those for whom not having this would be a problem use it.

> And what about lack of access modifiers?

It's an issue, but use of the conventional underscore prefix makes mitigation via code review fairly simple.

That is why we have python type hints: https://docs.python.org/3/library/typing.html

Not as good as a real static type system with compiler, but still helpful for documenting the code and tools for static code analysis.

With unittests, proper planning and stern discipline. Access-control and typecheckers exist, but they are optional.

I have never got serious about python until very recently(I mean about one week), the more I dive into it the more I am convinced yes python is the future in the sense it does the below:

    replacing BASIC(i.e. good for beginners)
    replacing Java in colleges for intro to programming
    replacing matlab(ipython jupyter)
    replacing R for ML and big data
    great for web scraping
    replacing Perl and probably shell scripts for CLI scripting.
    strong backend framework candidates such as flask and django comparing to php/javascript frameworks too.
    micropython runs on resource constrained systems so it can replace Lua there.
    C friendly so you can optimize performance bottleneck when there are any.

The only missing area I can see, is that it is not designed for html/css/js frontend, so you have to use javascript there.

yes, Python could be the future of programming.

I think the one area that Python won't fit in is low level languages such as C/C++. I can easily see Rust taking over that space.

Java is never going to go away, but let's hope Scala becomes more popular. Neither is C#.

I'm not really sure where Go fits into the picture.

> I think the one area that Python won't fit in is low level languages such as C/C++

What Python is really good at, though, is gluing together/scripting C/C++ code. I've had a lot of success in my career starting a project in Python, and then dropping down to C or C++ for the high performance bits. As an example, I worked on a software-defined radio project with some errr... special requirements. All of the modulators etc were all written in C, and the bitstream generation/manipulation was done in Python. There was also a bunch of numerical processing bits (solving diff eqs with RK4) written in C++, parameterized by Python. The net result was that we could use a Python REPL to experiment and script the system, while handily using all of our CPU cores to their maximum capacity.

Python is stupidly simple and that's the reason I use it for 99% of my work (netsec/forensics).

I introduced my ex to it for her dissertation in astro-physics. It took her under a week to mainly self-learn and start writing scripts with numpy and matplotlib, and it was her first language. The code wasn't good by professional standards, but it did the job. I cannot think of any programming/scripting language which can be learned by someone with no previous programming experience in under a week at a level where it can be used in a masters dissertation.

NO, Python is not simple at all, especially nowadays with all the asyncio stuff and tons of new features in 3.4+. One can't even follow what's happening with the language.

I don't understand where this nonsense is coming from. Probably ignorance? You might not know too much about it to understand how huge and complex Python is.

asyncio is a feature, not a requirement. Most people will never need to use it or the threading library will meet their use case.

Every language will get more complex as you dig into it, but most people don't need to go beyond the surface.

The most basic things are hard to grasp also. I had a really hard time understanding what is the difference between unicode, str, bytes and how to encode what when I started with it 5 years ago: https://stackoverflow.com/questions/14839028/how-are-these-s...

Nowadays, teachers have to start with generators and yield even for beginners, because most of the things are generators in Python3, which is not a trivial concept to understand when you have no programming background.

It depends.

I can have an intern up and programming basic Python in about 3 days from nothing. I have run this experiment multiple times with teenagers.

The nice part about Python is that I can gradually introduce them to new features as they hit the problems the features are meant to solve.

And, I WILL argue that Python's syntax is easier to keep in your brain. Somewhere on HN there was an article showing the grammars of various programming languages as connected graphs, Python was quite obviously simpler than just about everything else.

Possibly http://blog.nicksieger.com/articles/2006/10/27/visualization.... A comment links to http://flickr.com/photos/nicksieger/281055485/

I agree Python isn't simple at all, but I think it does have a kind of surface simplicity that its culture reinforces. 'one obvious way', etc.

Or to put it another way its a language you can do a lot with without caring too much about details.

Or to put it another way still you can go a long way with Python, Stack Overflow, and a bit of copy and paste.

No need to use asyncio as a beginner. Not all problems require concurrency to solve. The vast majority of the automation scripts I write have no need for it.

Not saying that python great for this, but this exact use case is literally what matlab was created for. I'd take python over matlab any day, but people have been writing crappy matlab scripts for their dissertations for a long time now.

Scripting languages have that property. Some are even more gradually learnable, like Perl, where you don't need to be exposed to anything from the language beyond what you want to do and it will run your code.

I'd sooner Python be the future than JavaScript.

I think it's more likely to continue to be the future of glue languages.

Many problems can be solved in Python directly and when they can't you can often call out to something to do the heavy lifting.

For that I've found it absolutely excels.

I’m having trouble thinking of a dynamic language in Python’s class (Ruby, JS, even PHP) that fails your use case here.

The implicit part you're missing is that Python is just nice to work with in a way that JS and PHP aren't (I don't have Ruby experience).

If there's a bunch of languages that meet the baseline functionality, why not choose the most ergonomic of the bunch?

Pretty much and Python has massive library availability and consistently good libraries (PHP and JS have lots of libraries but the quality is...meh and to an extent they silo much more than in Python - though both languages have at least improved their (PHP with composer and PSR/FIGS and JS with npm/ES6 imports)

I've been wanting to learn Rust for a long time, but Python is just so good at so many things that I find it hard to get started with Rust. The other day, I wanted to make a small server that would email you if your cron jobs didn't run[1] (using a checkin system), and I started to do it in Rust, but I found prototyping with it at my starter level so hard, that I thought "alright I can either do this in Python in three hours, or spend a week with Rust and probably quit half-way".

This is whether the project is for the web, desktop, microcontrollers, CLI, whatever. Python might not be perfect for any of these things, but it's great for all of them. I need to try to write a kernel or something.

[1]: This is the finished product, by the way: https://gitlab.com/stavros/caduceus

I've never been a heavy Python user myself, but I 'm working in Elxiir w/ a couple other people who are/were heavy Python users. They seem to much prefer Elixir/Erlang's concurrency model over Python's. Scanning the article, I don't see any mention of concurrency, and concurrency seems to be an increasingly valuable tool in a micro service world.

Does anyone here have a preference for using Python to tackle concurrency-related issues? If yes, I'd love to hear your thoughts on the matter.

Very good question! Python have a couple of tools to handle concurrency and parallelism, but it's a mess.

For I/O bound programs, you can use threading (in stdlib). For CPU bound, you can use multiprocessing (also in stdlib). But these have huge overhead, (e.g starting a Python thread costs 32kb memory minimum.) and there are multiple solutions in the stdlib like ThreadPoolExecutor and ProcessPoolExecutor in concurrent.futures beside the threading and multiprocessing modules...

If you want to write async code, there is tornado with callbacks, tornado with the new async stuff, asyncio (tulip for Python2), the new async/await from 3.5 which is very immature. The async part of the ecosystem is like a totally separate whole new world, you can't really mix and match or pick parts from the other, however, there are brave folks like Andrew Godwin how tries to make Django async with not moderate success.

For web frameworks, there are a ton of servers which might fit you, but they are mostly very complex to set up or reason about like greenlets, pre-forked web servers and stuff.

I have 5 years experience with Python, using it every day and once I tried to write a custom SSH server and it took 1-2 weeks to grasp Tornado fully, then I tried the same with Go and WITH LEARNING THE LANGUAGE itself, it took me about 2 weekends and my server was up and running!

TL;DR: You can write concurrent code with Python but it's a mess and you will probably have a hard time.

I'm not sure. I see so much money being poured into making scripting languages faster [0], and with the "End of Moores Law" in sight I feel like the industry is going to be leaning towards static languages [1].

Perhaps developments in gradual typing will allow for the benefits of quick and experimental development (scripting) that can later be calcified into a sturdy fully-typed program with higher performance (through optimized AOT compilation).

[0] https://instagram-engineering.com/dismissing-python-garbage-...

[1] https://youtu.be/Azt8Nc-mtKM?t=9m59s

AOT compilation doesn't really solve the problem. You also need to get closer to the metal with the language, data types, algorithms, only then you can get significant performance increase. But this only postpones the problem, hardware is still capped by the end of Moore's law and will push you into concurrency and distributed systems sooner or later. And which language does it better will be an important factor.

Wait, wasn't Java the future of programming?

For the 90s, yes. That future happened and now we're looking at a new one. For as much as I dislike the language and most of the software built on the JVM, I do think it helped advance the world of application-level software development to a better place.

Without it, people would likely have built the same memory-hungry, slow, and bloated software, but in C++ with all its added risks, lessened portability, and none of its advantages (except maybe better start-up times). There are more problems that need fixing, but Java at least solved some of them.

Edit: Java, and other languages and systems like it, really. Java had the advantage that it was familiar to C++ programmers.

Python does have two growth vectors going for it right now:

1) Deep learning / data science works really well in Python

2) Lambda functions are really great in Python... maybe people will choose to write servers out of Lambda functions instead of writing high performance servers in Go - who knows?

Those are big areas, but still a small percentage of all programming work falls into those two categories.

> Lambda functions are really great in Python

Hah, if you had told anyone that five years ago they would have been very confused. "What are you talking about? Lambdas in Python are horribly neutered..."

Back to what you actually meant, I think that lambda functions will get simpler to use in every language, and I think JS will extend a lead there even though I prefer Python as a language.

I should get my "microservices built out of spreadsheets" project (https://6gu.nz) onto AWS Lambda to get in on the zeitgeist though, put a horse in the race. And then somehow get deep learning (and the blockchain...) in there to really cash in on the bandwagon trends.

I must be stuck in the past. What's great about lambda functions in Python?

I think the parent isn't talking about lambda functions, but about python code deployed on the AWS Lambda

They support many languages, and you have to pay more for slower ones

hey yeah I meant AWS lambda functions! I think they are better suited for serverless than JS because JS is so asynchronous, hard to debug, and really designed for an event loop that lasts forever. I tried doing AWS lambda with JS but I found it much less intuitive than Python for AWS lambda, in the same way NodeJS is more intuitive for writing servers with lots of async logic than Python.

Sorry, but you don't have no clue what you're talking about.

Python is an imperative language by nature, and lamdba is very uncomfortable to use for anything than a simple expression. You can use functional elements up to a certain degree, but it will be a pain if you try to force it to be a functional language; you simply can't go very far with it.

I think he means AWS lambda functions, which are super easy in python

I'm surprised to see this bit:

« I certainly didn't set out to create a language that was intended for mass consumption » [Guido van Rossum] explains.

As early as 1999 he was one of the authors of the "Computer Programming for Everybody" DARPA funding proposal, which was supposed to be based on Python.

See https://www.python.org/doc/essays/everybody/ .

1999 would be a decade after van Rossum started working on Python.

Python in particular, maybe not.

But the nature of the language, its simplicity, its indenting style, its readability, obviously yes. Those were big improvements on the C language it was inspired from.

I don't think python will survive its lack of performance, although I really wish it would.

Python is one of the simplest language you can learn. It is really nicely designed and executed. If simplicity is the goal, Python has that in spades.

Lua is far simpler, and still easy to learn. Yet it's powerful enough to be used in "real" projects (e.g. Photoshop Lightroom).

I feel Lua has a lot of anti-patterns which makes transitioning to/from other languages difficult. Tables are unintuitive versus other data structures, structure syntax varies from other C-languages, and oddly it uses one-based indexing.

Lua is nice in that it's easy to embed into existing projects, and has an established userbase in game modding communities (Garry's Mod, Minecraft computer mods).

"Lua is far simpler" - citation needed 8)

At some stage I will have to get to grips with Lua (Mediawki) but I believe your comment is completely arse about face. No, I wont give any more justification than my assertion.

Unqualified simplicity is useless metric. Brainfuck is about as simple as a language can be, and people can learn it in an afternoon.

That's why I qualified it by mentioning a huge commercial product which uses it extensively.

Lua comes in quite high on the "Most Dreaded" list of programming languages and has 1-based indices in a world of 0-basing.

Not exactly something I would recommend ...

I would love to see that list. Have a link?

Here's one: https://www.reddit.com/r/lua/comments/60ynhr/lua_featuring_a...

It's NOT simple at all, see my comment above: https://news.ycombinator.com/item?id=17584388

It's simple in practice to learn incrementally and usefully, even though it's not simple in total. In fact, I think the two kinds of simplicity are often opposed.

Brainfuck is simple, but not simple to learn to do useful things in with.

If web browsers would start to interpret python directly, then maybe. Otherwise I fear it will be Javascript.

Simple, just create webassembly-bytecode from python, and it will run in all modern browsers. Or at least thats the goal.

This doesn't seem to be so simple: https://stackoverflow.com/questions/44761748/compiling-pytho...

But some people had success nevertheless: http://droettboom.com/blog/2018/04/04/python-in-the-browser/

Nope. Maybe it’s the future of getting into programming, or scripting, but not programming as a whole.

At least not if I have anything to say about it! Lol

No.

This. Swift is the language of the future.

Reply on news.ycombinator.com