Why not use cython? It has types
Open-sourcing MonkeyType – Let your Python code type-hint itself
161–170 of 237 posts
Re: Open-sourcing MonkeyType – Let your Python code type-hint itself
#162Earlier quoted context omitted.
The point is that there is no property of python that allowed them to build a successful company that any statically typed language don't have. It is a completely unnecessary detour. The cost of doing it right from the start is negligible.
You're assuming that the original developers would have been just as productive in a statically typed language as they were Python. Big assumption. Both because they might have known Python already and also because Python is quite a bit more newbie-friendly, concise and expressive than the mainstream statically typed languages.
Obviously what the programmers knew to start with is of importance. But that's no property of the language (well, sure, being easy to pick up increases the risk).
But no, ignoring that it is not a big assumption really. The benefits of static typing comes pretty quickly, especially if there are more than one programmer.
Re: Open-sourcing MonkeyType – Let your Python code type-hint itself
#163Earlier quoted context omitted.
There's nothing here that tunes down the dynamism. Hints aren't statically checked or enforced. It's still possible to pass in an empty list to an int-hinted var and, e.g. have `if not var` evaluate to True (rather than raise an Exception). Type hints allow external tools to check some things, but at this point you're basically imposing static types so why not use a language with the tooling and optimizations to take…
>Type hints allow external tools to check some things, but at this point you're basically imposing static types so why not use a language with the tooling and optimizations to take advantage of that? Python's type system is, imo, currently better than Java's, and the syntax is cleaner than java's or C++s. You get all the benefits of static typing without having to put `auto` and `List ` everywhere. And at the same ti…
You don't put auto everywhere. You write out the type in 99% of cases and save auto for 100+ character templated types.
There is no reason to to save the literally 0.2s (you can still spend that time reasoning about your code) it takes to write the type. It is better for yourself writing it and for readability to be explicit.
Re: Open-sourcing MonkeyType – Let your Python code type-hint itself
#164Earlier quoted context omitted.
>Type hints allow external tools to check some things, but at this point you're basically imposing static types so why not use a language with the tooling and optimizations to take advantage of that? Python's type system is, imo, currently better than Java's, and the syntax is cleaner than java's or C++s. You get all the benefits of static typing without having to put `auto` and `List ` everywhere. And at the same ti…
You don't put auto everywhere. You write out the type in 99% of cases and save auto for 100+ character templated types. There is no reason to to save the literally 0.2s (you can still spend that time reasoning about your code) it takes to write the type. It is better for yourself writing it and for readability to be explicit.
By everywhere, I mean where it's otherwise obvious:
auto s = "Hello world";
for (auto c: s) {
cout Re: Open-sourcing MonkeyType – Let your Python code type-hint itself
#165Earlier quoted context omitted.
>(i.e. matrices of compatible dimensions) What language do you use where you can get these kinds of guarantees? As far as I know very few languages provide those kinds of dependent types statically.
C++ makes this possible via templates. Generally the size is moved to a template argument, which allows the compiler to check this at compile time (of course, this restricts you to statically sized matrices).
Good to know. I was apparently unaware how powerful templates were.
Re: Open-sourcing MonkeyType – Let your Python code type-hint itself
#166Earlier quoted context omitted.
>Is this done by purpose, or did they end up with a million lines of Python code and are looking for ways to make the maintenance easier? Definitely the latter. I've seen this discussion a few times before, and it's always the same. Your initial developers are not looking down the road to the million lines of code milestone, they're just trying to make a product that might actually make some money here and now. I'm s…
Navigating a large code base that is dynamically typed like Python is far more tedious than something like C++ or C#. First you can't read what the types passed into and out of functions are. You have to find their usages to work it out. Second, you can't reliable do things like "find usages" or "go to definition" because of the dynamic typing.
> Second, you can't reliable do things like "find usages" or "go to definition" because of the dynamic typing.
In my experience PyCharm can do both correctly for the vast majority of cases.
Re: Open-sourcing MonkeyType – Let your Python code type-hint itself
#167Reading 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.
PHP 7
Re: Open-sourcing MonkeyType – Let your Python code type-hint itself
#168Fantastic 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 automatically verified with the help of a checker. This is exactly what Instagram is attempting in an effort to increase quality and ease maintenance.
It seems many are wondering why they haven't done this from the beginning. A typical (and probably correct) answer is development speed and flexibility: early stage companies need to be nimble and compromise on quality if they want to survive. Fair enough, I understand that. We can applaud Instagram's success on the markets, but that doesn't have to mean that they're a role model of technical excellence for building a million line Python code base.
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). Definitely not JavaScript (see FirefoxOS).
The founders of a start-up can continue to do whatever they want in the name of success. Instagram at their beginnings was basically a different company from today's Instagram, no one would have used them as a technical role-model. Now they're at best a role model for large Python code bases, but many here seem to be drawing the wrong conclusion, namely that it's a good idea to do large-scale Python in the first place.
Re: Open-sourcing MonkeyType – Let your Python code type-hint itself
#169Fantastic 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…
> 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.
Re: Open-sourcing MonkeyType – Let your Python code type-hint itself
#170Earlier quoted context omitted.
I agree with you but I think it's pretty straightforward how this sort of thing happens: 1. Startup builds thing fast in dynamic language because they need to optimize for development speed and iteration, not maintainability or scalability. 2. Startup grows and continues to hire for expertise in the tech stack they are mostly already using. 3. Repeat for some years and some hundreds of engineers and you arrive at thi…
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.