Live data from Hacker News

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

engineering.instagram.com

221–230 of 237 posts

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

#221

Earlier quoted context omitted.

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).

I don't see how you could implement the (k.attr).for_(k) part. That's essentially an assignment, a macro could maybe convert it to a lambda, but I don't see how it would be done macro-free.

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

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

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

Easy:

    std::vector

people = { P{"jane", 47}, P{"mary", 71}, P{"john", 65} }; ranges::sort(people, [](auto& x, auto& y){ return x.weight > y.weight; });

Compile this gist with `c++ -std=c++1z -I range-v3/include`:

https://gist.github.com/cieplak/dcd587c67d989768900e4110e776...

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

#223

Earlier quoted context omitted.

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

Types being code depend on people writing them (as is the rest of the code :) ). I guess you’re lucky/smart that your code base is just simple types.

Quite often people construct complex type hierarchies just because they can (or don’t know better). And it’s a pain to wade through and coerce to what you want it to do.

I’m very much on the fence between static and dynamic typing, having used (and probably abused) both. I prefer a “pragmatically” typed language, but I haven’t come up with a proper definition for it yet :)

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

#224

Earlier quoted context omitted.

>>> but navigating a million lines of Python seems just daunting to me (although maybe I'm just not experienced enough with Python). It's not that bad. The first thing you learn when you're in a million lines codebase is that you will only work within your project of maybe a hundred files. Once in a while, there is a guy who is asking for help on his project or there is an old weird bug to fix and you dive in other s…

Sounds like the projects you worked on had excellent encapsulation.

I wouldn't say excellent encapsulation. It's just normal to use sub directories to split things. The project was over ten millions lines of python.

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

#225
post #102

> At Instagram we have hundreds of engineers working on well over a million lines of Python 3. Man, that's crazy. At the time they were acquired by Facebook, they had 13 employees.

This was the part that stood out to me also. They must have a ton of new stuff in the pipeline, or their "display photos, insert some ads in between" loop is way more complex than it seems.

Or that's total number of engineers and way fewer actually twiddle the Python...

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

#226

Earlier quoted context omitted.

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?

I can think of 100kloc Scala codebases, e.g. Kafka.

People do use ML family languages, and they are better. There are plenty of non-technical reasons they aren't as widespread as dynamic languages or shitty static languages.

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

#227
post #226

Earlier quoted context omitted.

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?

I can think of 100kloc Scala codebases, e.g. Kafka. People do use ML family languages, and they are better. There are plenty of non-technical reasons they aren't as widespread as dynamic languages or shitty static languages.

Right, but Scala is different from Haskell or f#. It doesn't use the same kind of type inference (hm) as classical ml derivatives.

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

#228

Earlier quoted context omitted.

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…

> vector Really? O.o How could this possibly work?

Oh, that was probably a typo (it was late); replace that with a concrete type.

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

#229

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…

Didn't Facebook do this for PHP (Hack) and Microsoft with JavaScript (TypeScript)? From a technical aspect, I do find these projects cool. I wonder if its more efficient for large companies to initially develop using dynamic languages then transition them with these optionally typed languages.

Dynamic languages definitely help with the rapid development of a small application or prototype, but when you have a large team trying to maintain the application, static typing allows for better compile time error catching. Weird hybrid approaches makes me wary.

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

#230

Earlier quoted context omitted.

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

Easy: std::vector people = { P{"jane", 47}, P{"mary", 71}, P{"john", 65} }; ranges::sort(people, [](auto& x, auto& y){ return x.weight > y.weight; }); Compile this gist with `c++ -std=c++1z -I range-v3/include`: https://gist.github.com/cieplak/dcd587c67d989768900e4110e776...

What if two weights are equal, the python code will also sort by name as well ;)
Post reply on HN