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

91–100 of 237 posts

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

#91

Post by depressedpanda »

vasilipupkin wrote: post #35
newfoundglory wrote: post #30

Earlier quoted context omitted.

80% of startups are going to die before their codebase reaches this size. They should probably not be making tech stack choices based on "what if we succeed beyond all likelihood".

two things come to mind: maybe those startups would die at a slower rate if their code was comprehensible to begin with ? but leaving that aside, for companies where survival is not an issue then, doesn't this indicate that using a dynamically typed language is not great?

Well, in the case of Instagram, this just shows that Python was a great choice.

They went with a dynamically typed language, were successful, the language they chose added an optional type hinting system, and they wrote a tool that would automatically type hint their code in order to reap many of the benefits of a static type system.

I think that the amount of man hours that went into writing the tool is negligible, so it's a net win for Instagram.

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

#92

Post by tjoff »

depressedpanda wrote: post #88
angelsl wrote: post #73

Earlier quoted context omitted.

You've totally missed the analogy. See pfranz's comment.

No, I the analogy just wasn't very apt. Python allowed them to build a successful company. Now, when their stack is mature and maintenance is more important than rapid prototyping, Python allows them to add type hinting. Because they are engineers, they built a tool (in Python) that allows them to do it in an automated manner. And all of this is great! They are evolving their code to fit their needs; it's nothing lik…

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.

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

#93

Post by jw- »

Barrin92 wrote: post #22
vasilipupkin wrote: post #14

Earlier quoted context omitted.

I literally just had this exact thought independently of you. I mean if you need to do something like this, doesn't that mean you should be writing code in a statically typed language?

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.

I also get the impression that some people view using dynamically typed languages as a badge of honor, taking more expertise to harness the greater 'expressive' power, all whilst juggling the types in your head. Bad programmers can't use them properly, but if you're one of the good ones then you're not held back by rigid types.

I'm one of the dumb ones and just let the computer do the checking for me.

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

#94

Post by meowface »

fiatjaf wrote: post #37
realbarack wrote: post #24

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

Isn't it faster to write everything in Go, for example, that has a compiler guiding you all the way and you rarely get runtime errors? I feel my developer time very much "optimized" when writing backends in Go than when I wrote then in Python (I also tried Node, which was a disaster).

It's probably faster to verify that your Go code is working as intended, but many would argue that dynamically typed/interpreted languages are faster to write code in than statically typed/compiled languages. Others would argue that the pure "writing code" part isn't the majority of what takes up a developer's time. There's no one right answer.

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

#95

Post by david-cako »

chc wrote: post #90
david-cako wrote: post #83

Earlier quoted context omitted.

The downside to using a certain tech stack is technical debt, not a health risk. Technical debt seems like a wise acquisition in moderation, especially for a startup that wants pictures and buttons on screens ASAP, and even more especially when everyone is realizing that it can rather easily be undone when/where it matters with type checker addons and FFI.

That doesn't have anything to do with the question of whether "raw number of successful projects using it" is a good metric for how good something is. Lots of successful companies have made mistakes, and there are even mistakes that many companies in a field made simultaneously (e.g. the XML mania of the early 2000s is not fondly looked back on). I'm not commenting on the specific issue of whether Python creates good…

Ah, I gotcha, that’s a good point. I still do believe that these decisions for dynamic languages that can later be contorted aren’t just a symptom, but I don’t have any way to prove it.

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

#97

Post by forgotpassagan »

nawgszy wrote: post #33
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…

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

I can picture these poor souls vividly. Millions of lines of python, flowing like the mightiest of rivers. Nobody really knowing whence it cometh and goeth.

A hero arises, offering a sacred herb to calm the torrent and light the golden path. The hero is elevated, yet they continue to pray

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

#98

Post by oblio »

tjoff wrote: post #92
depressedpanda wrote: post #88

Earlier quoted context omitted.

No, I the analogy just wasn't very apt. Python allowed them to build a successful company. Now, when their stack is mature and maintenance is more important than rapid prototyping, Python allows them to add type hinting. Because they are engineers, they built a tool (in Python) that allows them to do it in an automated manner. And all of this is great! They are evolving their code to fit their needs; it's nothing lik…

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.

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

#99

Post by ageofwant »

tjoff wrote: post #92
depressedpanda wrote: post #88

Earlier quoted context omitted.

No, I the analogy just wasn't very apt. Python allowed them to build a successful company. Now, when their stack is mature and maintenance is more important than rapid prototyping, Python allows them to add type hinting. Because they are engineers, they built a tool (in Python) that allows them to do it in an automated manner. And all of this is great! They are evolving their code to fit their needs; it's nothing lik…

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.

I think the general consensus is that that is not true. Python's dynamic nature is a clear advantage it has over statically typed languages. Add the fact that you can elect to tune down the dynamism when it makes sense to with very little impact on your existing stack makes Python the technological superior choice for the majority of applications.

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

#100

Post by rspeer »

mbid wrote: post #80
shados wrote: post #58

Earlier quoted context omitted.

We're getting into a world where languages finally have type systems that dont suck for fast development. This wasn't the case until very recently. And many of the current options only became realistically viable in the last few years (or months!). We still have to work with the world as it exists. Not as it should be or will be. And even with the crop of modern languages, its often still faster to start with less op…

What are you talking about? Haskell is 30 years old.

You must have missed the part about "the world as it exists" and "fast development" and pretty much the entire point of the post you're replying to.

Haskell remains impractical for many use cases, it is not used much outside of academia, it's not documented to be used outside of academia, and it didn't even have a working package manager until a few years ago.

Post reply on HN