I've felt the same, but I blame error messages and language ergonomics rather than the practice itself. Basically, everything you said, but with optimism that future languages and language implementations make 'hyper typing' a good practice. Recent languages have shown that there's a lot of room for improvement on error messages in complex programs. Hopefully that extends to complex types before too long.
Fully agree. TS shouldn't throw internal types into the user's face. The errors UX is abyssymal.
The fact that the most popular editor - VSC - doesn't preserve line breaks makes reading TS errors even worse. I highly recommend the pretty TS errors extension, otherwise you're only hurting yourself working with TS.
I'm sad not to see any mention of numerical stability. One of the hardest parts of all these automatic optimization of numerical algorithms is getting ensuring numerical stability. Once we have a strong handle on getting the best of both of those, it will be a delight.
I went to a talk of his on CCC ages ago, and it was such a fascinating combination of geometry, causality, and asymptotics. I have absolutely no clue whether it's reasonable physically, but independent of that, it's just a really elegant fusion of topics in a fun to think about way. Worth a read for anyone who just appreciates elegant new ways of combining mathematical structures.
I've also seen this talk, at the behest of some spaced out friends of mine, an amazing experience and I still think about the universe through the lens of that talk!
Not just for training data, but for eval data. If you can spend a few grand on really good labels for benchmarking your attempts at making something feasible work, that’s also super handy.
MLIR is one of those things everyone seems to use, but nobody seems to want to write solid introductory docs for :(
I've been curious for a few years now to get into MLIR, but I don't know compilers or LLVM, and all the docs I've found seem to assume knowledge of one or the other.
(yes this is a plea for someone to write an 'intro to compilers' using MLIR)
I do scientific computing and a lisp was one of my first languages, so i feel like i ought to be the target audience, but it just never quite catches me.
It’s almost statically compilable which has almost gotten me to pick it up a few times, but apparently it still can’t compile a lot of the most important ecosystem packages yet.
The metaprogramming has almost gotten me to pick it up a few times, but apparently there aren’t mature static anti-footgun tools, even to the degree of mypy’s pseudo-static analysis, so I wouldn’t really want to use those in prod or even complex toy stuff.
It’s so damned interesting though. I hope it gets some of this eventually.
I've had a lot of fun with tracing decorators in python, but the limitation of data dependent control flow (e.g. an if statement, a for loop) always ends up being more painful that I'd hope. It's a shame since it's such a great pattern otherwise.
Can anyone think of a way to get a nice smooth gradation of tracing based transformations based on effort required or something. I'd love to say, 'okay, in this case i'm willing to put in a bit more effort' and somehow get data dependent if statements working, but not support data dependent loops. All I know of now is either tracing with zero data dependent control flow, or going all the way to writing a python compiler with whatever set of semantics you want to support and full failure on what you don't.
On a different note, some easy decorator DSL based pdb integration would be an incredible enabler for these kinds of things. My coworkers are always trying to write little 'engine' DSLs for one thing or another, and it sucks that whenever you implement your own execution engine, you completely lose all language tooling. As I understand it, in compiler tooling, you always have some burden of shepherding around maps of what part of the source a given thing corresponds to. Ditto for python decorator DSLs, except nobody bothers, meaning you get the equivalent of a 1960's developer experience in that DSL.
CSP (https://github.com/Point72/csp) has a healthy amount of AST parsing for their DSL. Looks like they have debug breakpoints working by augmenting the line numbers in the AST generation
reply