361–370 of 581 posts
https://blog.codingconfessions.com/i/174257095/lowering-to-c...
Earlier quoted context omitted.
It's a boon if the goal is to write code then go home. It's a loaded footgun if the goal is to compose a stack and run it in production within SLO. Python type hints manage to largely preserve the flexibility while seriously increasing confidence in the correctness, and lack of crashing corner cases, of each component. There's really no good case against them at this point outside of one-off scripts. (And even there,…
> It's a boon if the goal is to write code then go home. It's a loaded footgun if the goal is to compose a stack and run it in production within SLO. Never has been an issue in practice...
Earlier quoted context omitted.
I meant if you have two classes that need to refer to each other. But good pointer anyway, I hadn't noticed it, thanks!
I ran into some code recently where this pattern caused me so much headache - class A has an attribute which is an instance of class B, and class B has a "parent" attribute (which points to the instance of class A that class B is an attribute of): class Foo: def __init__(self, bar): self.bar = bar class Bar: def __init__(self, foo): self.foo = foo Obviously both called into each other to do $THINGS... Pure madness. S…
Earlier quoted context omitted.
Can't you define your own hint for "type that has __getitem__ taking int"?
The way I understand parent is that such a type would be too broad. The bigger problem is that the type system expressed through hints in Python is not the type system Python is actually using. It's not even an approximation. You can express in the hint type system things that are nonsense in Python and write Python that is nonsense in the type system implied by hints. The type system introduced through typing packag…
I'm founding a company that is building an AOT compiler for Python (Python -> C++ -> object code) and it works by propagating type information through a Python function. That type propagation process is seeded by type hints on the function that gets compiled: https://blog.codingconfessions.com/i/174257095/lowering-to-c...
Earlier quoted context omitted.
It's a boon if the goal is to write code then go home. It's a loaded footgun if the goal is to compose a stack and run it in production within SLO. Python type hints manage to largely preserve the flexibility while seriously increasing confidence in the correctness, and lack of crashing corner cases, of each component. There's really no good case against them at this point outside of one-off scripts. (And even there,…
> It's a boon if the goal is to write code then go home. It's a loaded footgun if the goal is to compose a stack and run it in production within SLO. Never has been an issue in practice...
I work at big tech and the number of bad deploys and reverts I've seen go out due to getting types wrong is in the hundreds. Increased type safety would catch 99% of the reverts I've seen.
Ruby particularly is already strongly typed so there isn't too many suprises with automatic conversions or anything like that. RBS also just makes metaprogramming more annoying - and Ruby's ability to do metaprogramming easily is one of its biggest strengths in my opinion.
If I wanted a statically typed language I would just use a statically typed language.
I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…
Ruby has had static typing via RBS for a while now, and I don't know if it's because I'm primarily a Rails developer and DHH doesn't like static typing so using these with Rails feels third-class or maybe just that I'm really just all the way in "the ruby way" but it feels antithetical to a dynamically typed language to start shoehorning in static types. Even as a type definition in a separate file it just feels wron…
Honestly the only people I see who really push back against it are the people who haven't bothered learning it. Once people use it for a bit, in my experience at least, they don't want to go back.
I'm founding a company that is building an AOT compiler for Python (Python -> C++ -> object code) and it works by propagating type information through a Python function. That type propagation process is seeded by type hints on the function that gets compiled: https://blog.codingconfessions.com/i/174257095/lowering-to-c...
Have you talked to anyone about where this flat out will not work? Obviously it will work in simple cases but someone with good language understanding will probably be able to point out cases where it just won't. I didn't read your blog so apologies if this is covered. How does this compiler fit into your company business plan?
It's kind of funny: our compiler currently doesn't support classes, but we support many kinds of AI models (vision, text generation, TTS). This is mainly because math, tensor, and AI libraries are almost always written with a functional paradigm.
Business plan is simple: we charge per endpoint that downloads and executes the compiled binary. In the AI world, this removes a large multiplier in cost structure (paying per token). Beyond that, we help co's find, eval, deploy, and optimize models (more enterprise-y).