Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open-sourcing MonkeyType – Let your Python code type-hint itself

engineering.instagram.com

Post reply on HN
Print view View original

181–190 of 237 posts

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#181

Post by walrus1066 »

blub wrote: post #170
gxs wrote: post #29

Earlier quoted context omitted.

This is exactly it. People are running a business, not writing an a treatise on code maintenance and hygiene.

Ok, then the business men among us should learn their lesson, that agility matters. The software developers among us should also learn their lesson: don't build large-scale software in dynamic programming languages unless you can afford to spend time later adding a static type system on top.

I'd think the business men at Instagram have been very happy with the agility of development, that got them to a $2.8 billion revenue p/a company. More than enough to cover the engineering effort to help improve the maintainability of the code.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#182

Post by ValleyOfTheMtns »

FYI, it requires Python 3.6+. It mentions it in the article towards the end, but if you're like me and prefer to jump straight into trying something out you may not have seen it. I wasted a bit of time trying to figure out what the ContextManager is in the Python typing module and why it couldn't find it.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#183

Post by weavie »

Yxven wrote: post #115
maltalex wrote: post #13

Reading this as someone who writes mostly in statically typed languages, the whole exercise seems odd. Having so much dynamically typed code to maintain that you need to run production code using a separate tool just to figure out the types sounds just wrong. Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are look…

Personally, I would love to ditch python for a language with strong types and type inference, but what is the replacement for django? Where do I find a well-designed, well-documented, battle-tested framework that I can easily hire developers for? Currently, I think the nearest competitor is node with typescript, and I'd rather stick with python. Please tell me if I'm wrong.

I dream of a time when OCaml becomes the obvious answer to this question.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#184

Post by nothrabannosir »

techdragon wrote: post #172
blub wrote: post #168

Earlier quoted context omitted.

Most people would expect software to crash, hang, be slow or somehow leak their personal information. That's normal behaviour for the products of the software industry. For a long time there have been efforts to ensure at least a degree of quality and robustness through processes, practices and verification tools. One such tool is a type system which allows encoding requirements and expectations that will be automati…

The reality borne out by the evidence [0][1] is that Python is at the very least perfectly suitable for the development of web stacks powering companies worth in excess of hundreds of million dollars. Putting aside concrete technical issues regarding the python runtime’s performance envelope (eg: startup time, FFI inter-op call time, etc) and memory footprint, there is no reason not to use Python. Again, concrete tec…

You can substitute Python for assembly, point at the Apollo mission and your argument still holds.

Rarely is a programming language chosen because it actually is the best tool for the job. Often, it’s whatever the people at the ground floor were most comfortable getting a prototype out the door with. Prototype working well? Fix this bug, add yonder feature. Before you know it you’ve built Facebook in PHP. “PHP is at the very least suitable for the development etc etc”, yes, that’s why Facebook invested all that effort in Hiphop VM.

There’s an irony in saying “there’s no reason not to use X” in reply to an article that is about a company spending a ton of effort working around a problem in X.

My point is: as a community, it’s our duty to learn from these mistakes. Let’s admit there is a problem, investigate, adapt, overcome. We can improve whatever will be the next Python so the next Instagram doesn’t have to go through this. But that won’t work if we keep saying “this is a nice problem to have, there’s nothing wrong.” It isn’t. There is. Look at the article.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#185

Post by outsideoflife »

blub wrote: post #171
kbd wrote: post #169

Earlier quoted context omitted.

> This tool is the proof that Python has significant problems at scale... This does not prove your point. Annotating a large dynamically-typed codebase with type information is a large amount of work, regardless of the language. This tool makes that easier.

I'm bemused by your reply and curious to know why you think Dropbox and Instagram are working on static type analysers for their large Python code bases. Instagram at least gave us a hint: "we’re keen to make our code easier for new developers to read and understand, as well as more amenable to static analysis that shrinks the domain of possible bugs". It seems to me it's so difficult to manage such a code base, that…

Isn't dropbox doing it partially to aid a future migration to Python 3?

> In which case it seems prudent to avoid the said amount of work by picking another programming language for one's large-scale code base

When I first saw Instagram I thought it was nonsense, I was wrong. When the founders started Instagram, I wonder if they had the amazing foresight to see what it would become. I would suggest getting to market was more valuable to them than worrying about what maintenance they would have to do once they had a billion dollars

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#186

Post by outsideoflife »

blub wrote: post #174
techdragon wrote: post #172

Earlier quoted context omitted.

The reality borne out by the evidence [0][1] is that Python is at the very least perfectly suitable for the development of web stacks powering companies worth in excess of hundreds of million dollars. Putting aside concrete technical issues regarding the python runtime’s performance envelope (eg: startup time, FFI inter-op call time, etc) and memory footprint, there is no reason not to use Python. Again, concrete tec…

I'm not claiming that one can't be successful by using Python (or pretty much any programming language). Market success or user count are unfortunately not tightly correlated with technical excellence, as many of us have bitterly found out. Development speed, maintainability, error count are also important development issues. Unfortunately we don't have much data to judge, but the little that we have such as this art…

> Market success or user count are unfortunately not tightly correlated with technical excellence, as many of us have bitterly found out

It depends on how you define technical excellence. I would suggest a low memory usage might get you a thumbs up from HN, but isn't real technical excellence the ability to solve users problems?

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#187

Post by lmm »

didibus wrote: post #18

Its interesting, this is a similar learning Clojure came around with, that the types weren't really useful unless everything is typed. Though Typed Racket's solution was to promote types to runtime validation at those borders between things with types and things without. I do find it intriguing though, that adding back types manually is so hard and slow. Is it slower when done retroactively? Or is it just as slow whe…

It's a lot slower to do retroactively. You basically have to tell the computer why you believe something is correct - e.g. if you're moving to having a distinct type for non-empty lists because some functions are only valid for non-empty lists, you have to explain why you believe a list you're passing to such a function is non-empty. That's a lot easier to do at the same time you're doing it (even in Python you'd probably still ask yourself whether you knew the list was non-empty as you were writing it) than to come back months or years later and remember why.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#188

Post by mratzloff »

didibus wrote: post #18

Its interesting, this is a similar learning Clojure came around with, that the types weren't really useful unless everything is typed. Though Typed Racket's solution was to promote types to runtime validation at those borders between things with types and things without. I do find it intriguing though, that adding back types manually is so hard and slow. Is it slower when done retroactively? Or is it just as slow whe…

It's slower when done retroactively. A developer writing typed code has the problem domain and software design unmarshaled into his brain while writing his small section. Type testing occurs concurrently with feature testing. Types added retroactively need to be applied to a large codebase and undergo separate testing.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#189

Post by lmm »

deathanatos wrote: post #142
aub3bhat wrote: post #107

Earlier quoted context omitted.

Please show me C++ equivalent of sorted([(k.weight, k.name) for k in somelist], reverse=True)

Note: my C++ is extremely rusty. Right now, I think that's approximately, vector > output; transform( somelist.begin(), somelist.end(), back_inserter(output), [](const auto &f) { return make_tuple(f.weight, f.name); } ); sort(output.rbegin(), output.rend()); Ranges, I believe, would reduce this a lot , possibly even to a single line. If I am reading the docs on it correctly, something like, vector (somelist | view::t…

> 1. I feel like most of the desire for a static language is to know what type something is. Is C++ exactly as brief as Python? No, as I think you've demonstrated. But I think you're a lot more likely to know the type of something.

Sure, but you don't have to choose between them, there are plenty of languages where you can have both Pythonic terseness and full type safety. E.g. Scala:

    (for {k
Many other strongly typed (ML-like) functional languages are similar.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#190

Post by lmm »

Cieplak wrote: post #41

Given that people have asked why not use a statically typed language, seems appropriate to mention that it's possible to write pythonic-looking C++: http://preshing.com/20141202/cpp-has-become-more-pythonic/ I have been using C++ a lot lately but really wish there were more tools for reflection at compile time, e.g., ability to iterate over all the members of a class. Other than that, I'm really loving C++17's auto t…

Why C++ though? In e.g. Scala you have much more pythonlike code than even modern C++, full type safety, much better performance than Python, strong IDE support, and the ability to do the things you would want compile-time reflection for (e.g. typeclass derivation and similar use cases for "iterate over all the members of a class") in a completely type-safe way without needing dangerously flexible macros or code generation. Other ML-family languages will be similar.
Post reply on HN