Live data from Hacker News

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

engineering.instagram.com

211–220 of 237 posts

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

#211
post #170
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 agree - there's just always a condescending tone in the way people question the technical practices in hindsight of companies that are successful.

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

#212
post #168

Fantastic contribution back to the community; I look forward to trying it out. I must say this is the first time I've been disappointed with the quality of discussion on HN. For a community that promotes using the right tool for the job at the time , I would have thought people would be more open to the choices the early engineers made. I'm sure that Instagram are using a variety of tech across their stack.

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…

Use the right tool for the job.

"Scale" can be seen under different angles. You can run thousands of boxes with relatively simple code if it's designed to scale horizontally. Twitter used to run on Ruby this way, until they accumulated money and expertise enough to rewrite the whole thing and save on operations and further development costs.

Your code can be millions LOCs and run on a few boxes; it's a very different sort of "scale".

In one company where I worked they had a crazy mix of codebases, from modern Scala down to ancient PHP code. But since it was architected reasonably, it was possible to replace the PHP code piecemeal, without stopping the system. Do the devs that started it 15 years ago with PHP deserve blame for choosing a poor language, or praise for coming up with a serviceable architecture?

You can see the original post as a step in the right direction: in a complex codebase, static typing has a large number of advantages. Barring a wholesale rewrite, how would you gradually transform your code to using it? Yes, by documenting the current state in a formal way, introducing a typecheck build step, then maybe splitting out certain components and rewriting them in other languages, etc. Look at TypeScript.

Unfortunately, there's no way around using quick-and-dirty prototypes at the very early stages, if nothing else, for lack of technical expertise among founders and their first employees. They have business ideas first and foremost. So a tool like that would help exactly the step you want done, switching to a nicer and more manageable stack as growth allows / demands it.

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

#213
post #176

Earlier quoted context omitted.

Ah yes, this old chestnut: "(language I don't like) is only suitable for teeny-tiny puny baby child's toy programs, and once you're not writing those anymore you must use a big strong grown-up language like all the other Real Programmers™ do!" The empirical evidence of reality is against you: there are successful large (in terms both of codebase and contributors/development team) projects in these awful terrible chil…

It doesn't correlate with success, but the choice of language does correlate with development speed, number of faults, maintainability, etc. The interesting thing to note is that a language that's perfectly acceptable at the above at small or medium scale might turn into a hindrance at large-scale. An otherwise fast to develop in language like Python won't be so fast if every change has to be painstakingly reviewed a…

won't be so fast if every change has to be painstakingly reviewed and tested due to the complexity of interactions in the code base

You can write spaghetti code in any language, it turns out. Blaming the language for that is not really an indicator of understanding the problem.

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

#214

Earlier quoted context omitted.

Good to know. I was apparently unaware how powerful templates were.

https://stackoverflow.com/a/22645853

I think I knew that templates were Turing complete, but so are java generics, it's just that to get dependent types in generics you have to reinvent the integers within the generic system. Not so for templates, which I didn't realize. That's pretty nifty!

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

#215
post #173

Earlier quoted context omitted.

By everywhere, I mean where it's otherwise obvious: auto s = "Hello world"; for (auto c: s) { cout Those autos don't need to exist, they're completely inferable, otherwise you wouldn't use auto. It's not like you can use auto in function declarations, nor should you, I agree.

I always write std::string etc. in those cases. It is consistent and quicker to read and there is not tangible benefit to using auto.

Right, but my point is that there's really no tangible benefit to writing the type at all. In a language with good type inference (Haskell, ml, modern python), the string literal is known to be a string, and you don't need to do any extra work.

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

#216
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…

> This tool is the proof that Python has significant problems at scale, which is something the Python community has denied for a long time. They're still doing it in this thread, but the lesson looks pretty clear to me: if you plan on building large scale, don't use Python. Or PHP while we're at it (see Facebook). Yeah, absolutely, don't do this! These are two examples of successful companies that did it and look at…

There are two things that are critically incorrect about your argument:

1) That market success implies having quality software. Average seems to be enough in my experience.

2) That start-ups are a good example to follow if one wants to achieve good quality. In fact they should be ignored, because they will absolutely murder quality in order to stay alive. Sometimes the product doesn't even work and is held together with duct tape in order to get past that important demo... It's quite pointless to discuss quality and start-ups.

The lesson I mentioned should be heeded by mature companies that are able to do some project planning, complexity estimation, etc.

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

#217

Earlier quoted context omitted.

Empirically, there are a lot more million line python codebases than F# or haskell codebases, in fact I can name multiple million line python codebases, and 0 F# or haskell codebases. Given that, logic would indicate some sort of failure on the part of haskell and F#, or they would see wider adoption among the large codebases where they are so useful. Do you disagree?

Given how much smaller is the F# community and how much more you can crank in less lines of codes in F# I can believe it. Between C# and F# there is about an order of magnitude of difference in the LOCs for big projects and C# and Python are comparable from this metric.

It appears you missed my point. I can't think of a 100kloc f# or Haskell codebase, so even if they were 10x as terse as python, which they aren't, python comes out ahead. If they're so much better, why don't people use them?

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

#218

Earlier quoted context omitted.

There's still a good deal of people who think of static typing as 'limiting', and dynamic typic as 'human'. Matsumoto said as much during (iirc) last years Ruby conf. I think the reverse is true. Static typing is liberating for humans because it tames complexity. Because I'm not a machine I cannot possibly keep track of fuzzy programs that arise from dynamic typing.

> Static typing is liberating for humans because it tames complexity. It doesn't, though. Not with the currently existing type systems and implementations. - Without type inference you end up righting multi-tier type declarations everywhere. - With overly powerful type systems you need something close to a PhD in math to create proper types and then figure them out half a year later when you've already forgotten most…

you'll have to expand on this a little for me. I just recently looked at an older Haskell codebase I was working on two years ago, and simply because of a very few straight forward types, nothing special, I could really wrap my head around the code-base a lot easier. Not just because the code tells me in plain text what types occur where, but also because enforcing a strong type system encouraged compositionality and well-formed behaviour in the first place.

If I look at some of the python code I've written, I'll be perfectly honest I often cannot tell you what to make of it any more.

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

#219
post #111

Earlier quoted context omitted.

There is something else, in the darkest reaches. It has many incantations, but the non-believers have a singular name. Lisp.

With it's comforting, reassuring warmth, Perl shines on as a luminous sun, lighting the way for youngling languages to learn from. Hushed whispers foretell the sunset, but none truly believe them...

Back to Perl folks.. The freedom, the happiness !!

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

#220

Earlier quoted context omitted.

You could implement the following with a decent bit of work (declaring k and reversed to be variables of special, hand-written/macro-generated types with overloaded operator, and operator=). sorted( (k.weight, k.name).for_(k).in(somelist), reverse=true)); You would never be able to get that past code review, however.

Sure, but at that point you've just reimplemented python in macros ;) The other thing to note is that sorted([(k.weight, k.name) for k in somelist], reverse=True) is essentially already typechecked: def biggest_ks(ks: K): return sorted([(k.weight, k.name) for k in ks], reverse=True) The above code now has all the same type guarantees as your c++, actually maybe more since the macros you use are going to be...uhhh, my…

The macro would only be used to generate k for convenience. It could be all implemented in straight, macro-less C++98 in O(minutes).

My point was just that you can implement almost whatever you want (even without macros, they'll just expand the design space).

Post reply on HN