4 ms·
The article's title is somewhat coy about the author's central thesis which he states at the bottom[1]: Basically, he prefers a language that is dynamic instea
by jasode 11y ago
The article's title is somewhat coy about the author's central thesis which he states at the bottom[1]: Basically, he prefers a language that is dynamic instead of static.
Instead of giving a reader an immediate heads up about the dynamic-vs-static argument, he gave it the subtitle of "Another kind of performance" ... which he means to be "programmer performance." The majority of the article is about this topic.
The (cpu) "performance" is therefore a subtopic of the dynamic-vs-static choice. He argues that "performance" was one of the drivers of static type checking but that factor does not matter anymore. (E.g. his example of objc_msgSend taking nanoseconds on both desktop & mobile.) I think the Android interest in AOT (static) instead of JIT is a counterexample to that. Performance still matters on battery powered, low GHz cpu devices like smartphones.
[1]author says: "Yes, I realize that would have meant pushing some errors from compile time to run time, in exactly the same way Objective-C does right now. But I don’t care — I’d take that trade-off every single day of the week."
- Sean1708 11y agoYeah, as soon as I hit "Another kind of performance" it became pretty obvious to me (IMO at least) that this was a thinly veiled opinion piece on static vs dynamic. And at the end of this day this is an argument with no clear winner, some people are more productive in Ruby and some are more productive in Swift. IMO most modern statically typed languages aren't statically typed because they're faster, they're statically typed because their designers preferred that kind of environment.
- mbrock 11y agoFor me, when working in dynamic languages (that lack static checking of types, null, etc) I'm a bit too nervous to "really fly." When the computer helps me find errors, misspellings, and bugs—given that I understand the type system well enough to not get very confused—that's when I "fly."
- mpweiher 11y agoWhat sort of dynamic language? And what sort of environment? I know people working in very dynamic/interactive environments who feel exactly the same way when they can no longer "touch the objects".
- mbrock 11y agoWell, I'll also say that I really fly in Common Lisp, and I think that language has a nice balance: the compilers do check types and nullability, to some extent at least... and the interactivity, "touching the objects"-ness, and general pleasure of coding weighs up for the lack of a really rigorous Haskell-like type system. And I'm not really a strong advocate of any particular language. I'm still holding out for a really excellent environment with some kind of best of all worlds approach. Maybe in 30 years...
- mpweiher 11y agoSame here (2nd para). IMHO, it all sucks pretty badly, though there are tiny patches of light here and there. What I get somewhat tired of is advocates who have seen one of these tiny patches and then proclaims having seen THE LIGHT and declaring all the rest obvious darkness (and you're obviously not one of them). I want to be able to adapt my language to my domain without having to write a DSL or solve boring multi-language integration problems, I want to reuse components without being overwhelmed by and stuck in glue code, I want to be able to define any type of architectural connector that's appropriate for my problem and have it be on par with any built-in stuff. I want static checking of any properties I care to check, and I want to that to not get in my way by obscuring the problem I am trying to solve. And I want it all live and with amazing performance that is under my control :)