5 ms·

I think the reasonable take-away is that if you ever intend your language to be used for large programs, just take the hit and start off with static types. Your

by chubot 6y ago

I think the reasonable take-away is that if you ever intend your language to be used for large programs, just take the hit and start off with static types. Your future self will thank you. I think this is missing something: the creators of those languages wanted languages that were fun/productive for writing small programs. That is, extremely flexible languages (and yes maybe they were unaware back in the 90's how this would limit their optimization potential) And all big programs were once small programs. Facebook is probably one of the easiest to see, since it was "just" a bunch of PHP scripts (although people tend to underestimate/dismiss it for that reason). Just like nobody ever says: "Well I estimate that in 10 years Facebook will consist of 10M lines of PHP with 5,000 programers working on it -- I should probably write it in another language". Nobody ever says: "Well I think my language is going to be used by millions of people and will have billions of lines of code". Well, there probably were people who thought that, but those were exactly the people who didn't make languages as useful as Python and JS :) ---- That said I think the phrase "irrational exuberance languages" referring to Python/JS is kinda funny, and in a way accurate ... https://blog.sigplan.org/2020/10/12/from-heavy-metal-to-irrational-exuberance/ https://blog.sigplan.org/2020/10/12/from-heavy-metal-to-irra... Although again I would say the unexpected part was not that they thought single core scaling would continue forever and make their languages fast, it's that those "slow" languages turned out to be the "best" ones for writing some of the most important systems of the last couple decades (not just commercial ones, but also Wikipedia, BitTorrent, etc.) ---- I'd make another analogy, to ISAs. If you talk to anyone who knows about CPU design, they'll say that x86 is shitty with a big pile of hacks. "It would be better" if someone designed it from the beginning with current applications in mind. But if anyone actually did that back in 1980, they wouldn't have been successful. And from my perspective, I mostly don't care, because the C compiler makes it all work for me (although I know the people who make it work care very much). So I guess the point is that technology adoption proceeds by evolution, and trying to plan 10 or 20 years ahead of time never works. ---- Also, there is a pretty hard tradeoff between static types and metaprogramming. Recent languages have come closer to reconciling these features (Zig, Nim, D), but dynamic languages chose reflection/metaprogramming, and that's a primary reason why they became successful. Ruby on Rails is a great example of that. It uses Ruby metaprogramming/reflection to a hilt, and lots of people who have no idea what that is love it, and they built tons of things with it (which now makes it an interesting optimization target)

munificent 6y ago
Yeah, there's a longer essay you or I could write about path dependence here. The language that enables you to get to the point where your codebase is that big in the first place may not be the language best suited to that codebase once it has. That's the main argument in favor of optional type systems like TypeScript. Start small in a dynamically typed language and then add the types later when you need them. But my personal experience is that I've never found types to cause much friction when programming in the small. What I have found painful is not having GC and not having type inference. If I was doing a startup and needed to be able to prototype and change quickly, then C++ or Java would be pretty painful. But C# or any modern typed, managed language with a decent modern IDE? I would be surprised if you were any less productive than someone using Python or Ruby.
- chubot 6y ago
  Yeah, "path dependence" pretty much sums up the comment. I should probably write something about that, because a huge factor in the design of https://oilshell.org https://oilshell.org. But I still get questions about it (like "Why can't we just get rid of shell and start over from scratch?") A few points I would like to add on: - I don't view the existence of TypeScript, MyPy, and Sorbet as evidence in favor of static typing. It's evidence in favor of gradual typing! - The Oil project gave me a lot of experience with the relation between metaprogramming/reflection, dynamic types vs. static types, performance, and code length. In particular the code moved from dynamic to static typing, and got a lot faster. But dynamic typing wasn't a mistake. Short recap: Oil's code is 5-7x shorter than bash [1], and a lot of that is due to starting out as dynamically typed, with a lot of metaprogramming. (I still believe "size is code's worst enemy" -- big code is understood more poorly, which makes it harder to modify, regardless of static types.) It is also something like 30x-50x slower than bash in Python! So, unusably slow. However the surprise is that I statically typed this code, and semi-automatically translated it to C++, and the result is now faster than bash. [2] ----- So the high level, short code has enough semantic information to be fast (after you add explicit types). The static typing process mainly evolved expanding metaprogramming to textual code generation! I estimate that this was at least 9 months of rewriting. That's what your arguments are missing IMO. If you're writing Java in Python, then sure Python is going to seem like it offers no advantages, and it might as well be statically typed. But that's not how people write programs in dynamic languages (and honestly I thought you would appreciate that more, having written so much about dynamic languages!) The porting process taught me exactly how much dynamism I was using, and it was a lot! It was pulling a lot of weight. I should show all the code generators and generated code in an essay... it's a very concrete demonstration. So there is the fallacy of "type inference" solves the problem -- it's not that we're too lazy to write down types; it's that we're using techniques that static type systems can't handle. Good thread about that: https://twitter.com/sliminality/status/1317331149354463232 https://twitter.com/sliminality/status/1317331149354463232 I'm not saying the Oil experience generalizes, since it's an unusual project, but it's definitely not as simple with "go with static types so you don't get trapped". That said, the conundrum you're talking about is very real. ----- But despite writing all that, I'm actually leaning in your direction, and I started a statically typed language :) https://old.reddit.com/r/ProgrammingLanguages/comments/jb5i5m/help_i_keep_stealing_features_from_elixir_because/g8urxou/ https://old.reddit.com/r/ProgrammingLanguages/comments/jb5i5... I would start with an interpreter so it can have metaprogramming (e.g. like a constexpr interpreter, or what Zig does). I would like to add a gradual type system, but I don't really know how to write one, so the first cut will be a traditional static type system. (In this world, getting the 30-50x speedup relies on the program being 100% statically typed, yet gradual typing is still important IMO. It's very simple, no infinite treadmill of JIT work as you see in the "professional" projects.) ----- This is probably something for an essay, but I would say dynamic types are demonstrably better than static types for at least 3 domains: UI, data science, and security/reverse engineering (and I have a bunch of experience to back this up). Basically anything that involves "learning about the world", or "schema discovery". [1] http://www.oilshell.org/blog/2019/06/17.html#why-is-it-written-in-python http://www.oilshell.org/blog/2019/06/17.html#why-is-it-writt... [2] https://www.oilshell.org/blog/2020/01/parser-benchmarks.html https://www.oilshell.org/blog/2020/01/parser-benchmarks.html Good thread about how successful Ruby and Python have been in YC companies: https://news.ycombinator.com/item?id=24279611 https://news.ycombinator.com/item?id=24279611

by chubot 6y ago

munificent 6y ago

Yeah, there's a longer essay you or I could write about path dependence here. The language that enables you to get to the point where your codebase is that big in the first place may not be the language best suited to that codebase once it has. That's the main argument in favor of optional type systems like TypeScript. Start small in a dynamically typed language and then add the types later when you need them. But my personal experience is that I've never found types to cause much friction when programming in the small. What I have found painful is not having GC and not having type inference. If I was doing a startup and needed to be able to prototype and change quickly, then C++ or Java would be pretty painful. But C# or any modern typed, managed language with a decent modern IDE? I would be surprised if you were any less productive than someone using Python or Ruby.

chubot 6y ago
Yeah, "path dependence" pretty much sums up the comment. I should probably write something about that, because a huge factor in the design of https://oilshell.org https://oilshell.org. But I still get questions about it (like "Why can't we just get rid of shell and start over from scratch?") A few points I would like to add on: - I don't view the existence of TypeScript, MyPy, and Sorbet as evidence in favor of static typing. It's evidence in favor of gradual typing! - The Oil project gave me a lot of experience with the relation between metaprogramming/reflection, dynamic types vs. static types, performance, and code length. In particular the code moved from dynamic to static typing, and got a lot faster. But dynamic typing wasn't a mistake. Short recap: Oil's code is 5-7x shorter than bash [1], and a lot of that is due to starting out as dynamically typed, with a lot of metaprogramming. (I still believe "size is code's worst enemy" -- big code is understood more poorly, which makes it harder to modify, regardless of static types.) It is also something like 30x-50x slower than bash in Python! So, unusably slow. However the surprise is that I statically typed this code, and semi-automatically translated it to C++, and the result is now faster than bash. [2] ----- So the high level, short code has enough semantic information to be fast (after you add explicit types). The static typing process mainly evolved expanding metaprogramming to textual code generation! I estimate that this was at least 9 months of rewriting. That's what your arguments are missing IMO. If you're writing Java in Python, then sure Python is going to seem like it offers no advantages, and it might as well be statically typed. But that's not how people write programs in dynamic languages (and honestly I thought you would appreciate that more, having written so much about dynamic languages!) The porting process taught me exactly how much dynamism I was using, and it was a lot! It was pulling a lot of weight. I should show all the code generators and generated code in an essay... it's a very concrete demonstration. So there is the fallacy of "type inference" solves the problem -- it's not that we're too lazy to write down types; it's that we're using techniques that static type systems can't handle. Good thread about that: https://twitter.com/sliminality/status/1317331149354463232 https://twitter.com/sliminality/status/1317331149354463232 I'm not saying the Oil experience generalizes, since it's an unusual project, but it's definitely not as simple with "go with static types so you don't get trapped". That said, the conundrum you're talking about is very real. ----- But despite writing all that, I'm actually leaning in your direction, and I started a statically typed language :) https://old.reddit.com/r/ProgrammingLanguages/comments/jb5i5m/help_i_keep_stealing_features_from_elixir_because/g8urxou/ https://old.reddit.com/r/ProgrammingLanguages/comments/jb5i5... I would start with an interpreter so it can have metaprogramming (e.g. like a constexpr interpreter, or what Zig does). I would like to add a gradual type system, but I don't really know how to write one, so the first cut will be a traditional static type system. (In this world, getting the 30-50x speedup relies on the program being 100% statically typed, yet gradual typing is still important IMO. It's very simple, no infinite treadmill of JIT work as you see in the "professional" projects.) ----- This is probably something for an essay, but I would say dynamic types are demonstrably better than static types for at least 3 domains: UI, data science, and security/reverse engineering (and I have a bunch of experience to back this up). Basically anything that involves "learning about the world", or "schema discovery". [1] http://www.oilshell.org/blog/2019/06/17.html#why-is-it-written-in-python http://www.oilshell.org/blog/2019/06/17.html#why-is-it-writt... [2] https://www.oilshell.org/blog/2020/01/parser-benchmarks.html https://www.oilshell.org/blog/2020/01/parser-benchmarks.html Good thread about how successful Ruby and Python have been in YC companies: https://news.ycombinator.com/item?id=24279611 https://news.ycombinator.com/item?id=24279611