4 ms·

For me personally, this is not the case. I work in multiple languages, some static, some not. And I have as many bugs in the one as the other. I add strings to

For me personally, this is not the case. I work in multiple languages, some static, some not. And I have as many bugs in the one as the other. I add strings to numbers less in static ones, but I tend to make more design mistakes, because I have to steer through the constraints of the type system. I view "must have static types/compile time checking" types as a bit reductionist. It's like saying "all food must be seasoned with salt." Salt's a good seasoner. For some meals, it's a must have. For others, it's a nice to have. And for others, it actually detracts. Compile time checking fits in the larger context of what programming in a given language is all about. Syntax, libraries, ecosystem, tools, execution semantics, runtime components. All of these compose for an end result. And typing plays a different role for each composition. I've been doing Elixir off-and-on for about 1.5 years now. The community is great. If I personally, had to lobby for "next big thing", it would be having a real IDE. I did Smalltalk for 20 years. I want an IDE where I work in modules/functions, not files and do/end syntax. I want a formatter that is not a PHD paper on generalized layout. I want refactoring tools. Inline macro expansion visibility. If I were independently wealthy, I would work on just such a thing in my spare time. ElixirLS and VSCode are OK, but so so limited really. What makes Elixir a standout candidate for a killer IDE experience is it's simplicity. Simple execution models make the language easier to model, navigate, and so IDEs don't need parse engines that are constantly needing updating (I'm looking at you Kotlin/Compose). Elixir as a language eats its own dogfood. It's sad to me that the Xerox Parc folks exploited this so beautifully with Smalltalk, but Elixir is stuck in the file editor mode still. :(

granshaw 4y ago
Isn’t that abit chicken and egg tho? Static typing is what really makes a language amenable to powerful IDE functionality…
- travisgriggs 4y ago
  That would make sense. More information, better IDE. But it has not been my experience. Nor some of my peers. Despite a meh text editor, the Smalltalk IDEs (Smalltalk/V, VisualWorks, and VisualAge) were amazing. The original "refactoring" work done by John Brant and Don Roberts was pioneered at UIUC in these environments. Their adaptation to the different IDEs just improved them. I remember sitting next to John and Don at OOPLSA and speculating that refactoring inside of Java (Eclipse was The New Editor at the time) should be superior in Eclipse vs Smalltalk because Java had more type information to work with. John and Don, both Smalltalk enthusiasts in those days, admitted they had anticipated that as well. And they did a bunch of work trying to port refactoring stuff to Eclipse. They were surprised to discover it wasn't so. But it's not typing vs not. It's simplicity vs not. When I asked if that meant that rising start Ruby would benefit from their refactoring work, they said that too was hard. Don explained that in a nut shell, it was the AST. Much of what tools/IDEs do is work with a model of the language. The Smalltalk AST had 15 polymorphic objects to represent its language model. Ruby was 90+ and climbing at the time. Java was insane. Their take was that while typing might add some information, the combinatorial explosion of modeling the language just made tooling for the language more difficult. It was an interesting insight. Elixir/Erlang has a language model that is even simpler than Smalltalk in some ways. The trickiest part is the macros.
dmix 4y ago
> And I have as many bugs in the one as the other. The case for types is very strong in Javascript though. I also use Ruby for backend and TypeScript for frontend and see no problem with that. Some languages are well suited for dynamic. Sometimes not just due to the language but the community + culture around it. Ruby codebases are also very heavily test driven which helps compensate and the inherent flexibility/developer experience of Ruby can't be matched. Elixir being the only close match.
- jspash 4y ago
  Seeing as you've adopted TS, have you had the chance to look into Sorbet? The Ruby type-checker?
calvinmorrison 4y ago
I hear you, but working primarily in php, the amount of lines of correspondence to type checking is wearing
dmpk2k 4y ago
I felt the same way about static types, until I had the misfortune to work on an absolute disaster of a codebase (happened to be in Javascript). The worst case for a dynamically-typed codebase is so very much worse in high-level languages. Admittedly, the immutable data structures in Erlang/Elixir help offset this.

granshaw 4y ago

Isn’t that abit chicken and egg tho? Static typing is what really makes a language amenable to powerful IDE functionality…

travisgriggs 4y ago
That would make sense. More information, better IDE. But it has not been my experience. Nor some of my peers. Despite a meh text editor, the Smalltalk IDEs (Smalltalk/V, VisualWorks, and VisualAge) were amazing. The original "refactoring" work done by John Brant and Don Roberts was pioneered at UIUC in these environments. Their adaptation to the different IDEs just improved them. I remember sitting next to John and Don at OOPLSA and speculating that refactoring inside of Java (Eclipse was The New Editor at the time) should be superior in Eclipse vs Smalltalk because Java had more type information to work with. John and Don, both Smalltalk enthusiasts in those days, admitted they had anticipated that as well. And they did a bunch of work trying to port refactoring stuff to Eclipse. They were surprised to discover it wasn't so. But it's not typing vs not. It's simplicity vs not. When I asked if that meant that rising start Ruby would benefit from their refactoring work, they said that too was hard. Don explained that in a nut shell, it was the AST. Much of what tools/IDEs do is work with a model of the language. The Smalltalk AST had 15 polymorphic objects to represent its language model. Ruby was 90+ and climbing at the time. Java was insane. Their take was that while typing might add some information, the combinatorial explosion of modeling the language just made tooling for the language more difficult. It was an interesting insight. Elixir/Erlang has a language model that is even simpler than Smalltalk in some ways. The trickiest part is the macros.

dmix 4y ago

> And I have as many bugs in the one as the other. The case for types is very strong in Javascript though. I also use Ruby for backend and TypeScript for frontend and see no problem with that. Some languages are well suited for dynamic. Sometimes not just due to the language but the community + culture around it. Ruby codebases are also very heavily test driven which helps compensate and the inherent flexibility/developer experience of Ruby can't be matched. Elixir being the only close match.

jspash 4y ago
Seeing as you've adopted TS, have you had the chance to look into Sorbet? The Ruby type-checker?

calvinmorrison 4y ago

I hear you, but working primarily in php, the amount of lines of correspondence to type checking is wearing

dmpk2k 4y ago

I felt the same way about static types, until I had the misfortune to work on an absolute disaster of a codebase (happened to be in Javascript). The worst case for a dynamically-typed codebase is so very much worse in high-level languages. Admittedly, the immutable data structures in Erlang/Elixir help offset this.