Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Diminishing returns of static typing

blog.merovius.de

Post reply on HN
Print view View original

331–340 of 632 posts

Re: Diminishing returns of static typing

#331

Post by amelius »

stephengillie wrote: post #4

One of my favorite parts of Powershell is optional typing. Variables are a generic "Object" type by default, which can hold anything from a string to array to "Amazon.AWS.Model.EC2.Tag" or other custom types. Or, type can be specified when setting the variable: [String]$myString = "Hello World!" This would generate a type error: [Int]$myString = "Hello World!" Often, typed and untyped variables will sit together: [In…

So when you call a function which takes a String as argument, do you need to cast the value manually?

If no, then what is the use of the typesystem?

If yes, isn't that cumbersome, since I suppose most library functions have typed arguments?

Re: Diminishing returns of static typing

#332

Post by dvlsg »

flavio81 wrote: post #49
Eire_Banshee wrote: post #41

Earlier quoted context omitted.

This. Not just, "who the hell uses this", but "where the hell is this defined" as well.

>Not just, "who the hell uses this", but "where the hell is this defined" as well. On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition. So this isn't exclusive to statically typed languages.

You can even do this with Javascript, too. And without doc types. At least in vscode, anyways.

Well, usually. It gets a little confused when you start using dependency injection containers, or dynamic requires, or anything like that.

Re: Diminishing returns of static typing

#333

Post by crdoconnor »

macspoofing wrote: post #307
crdoconnor wrote: post #291

Earlier quoted context omitted.

>I struggle to think of any benefits of dynamic typing on a reasonably sized code-base Being able to define and initialize types at runtime offers more flexibility and it's quicker to develop in. I'm frankly surprised nobody brings it up more often but the prototypical example of "static typing done right" - Haskell - is talked about nearly constantly but when I look for actual software I might use that's written usi…

>Being able to define and initialize types at runtime offers more flexibility and it's quicker to develop in. Quicker if you're writing shell scripts or a small single-purpose applications. Not quicker if you're adding to a codebase of any significant size.

Decent programmers compose code bases of "significant size" from many small, loosely coupled single purpose applications.

Yes, IME it's still quicker.

OTOH, if you're using "codebase of significant size" as code for "big ball of mud", static typing certainly helps, but integration tests are the real lifesaver.

Re: Diminishing returns of static typing

#334

Post by fulafel »

nnq wrote: post #283
fulafel wrote: post #205

Earlier quoted context omitted.

What makes you put Python and JS in the same basket here? Python is widely raised as a language that has a good dynamic typing system with strong types and good type error handling - arguably better than Lisps (nil punning). JS is infamous for the opposite. Macros are quite orthogonal to this.

> Macros are quite orthogonal to this. You ain't gonna to find any sane way to combine macros with a powerful type system in a way the doesn't make a 140+ IQ a requirement for any programmer touching the code using these features in a real world project... Problem with programming language design is that the ideal/Nirvana solutions lie at the edge, or beyond, the limits of human intellect. If you want something that…

Rust has macros that seem well liked, and everyday stdlib constructs are implemented using them. Though I can easily believe that the average Rust macro is authored by a smart person.

Re: Diminishing returns of static typing

#335

Post by Lutia »

andrewla wrote: post #244
flavio81 wrote: post #148

What amuses me in all "static typing versus..." discussions, is that it usually it is the comparison between two camps: Camp A: Languages with mediocre static typing facilities, for example: -- C (weakly typed) -- C++ (weakly typed in parts, plus over-complicated type features) -- TypeScript (the runtime is weakly typed, because it's Javascript all the way down) Camp B: Languages with mediocre dynamic typing faciliti…

It's Camp D that I'm least familiar with here; outside of academic projects in lisp/scheme I've never used them for anything serious. What exactly does it mean to have "good dynamic typing facilities"?

> What exactly does it mean to have "good dynamic typing facilities"?

To quote Peter Norvig on the difference between Python and Lisp, but you could apply it to most other mainstream dynamic languages vs Lisp :

> Python is more dynamic, does less error-checking. In Python you won't get any warnings for undefined functions or fields, or wrong number of arguments passed to a function, or most anything else at load time; you have to wait until run time. The commercial Lisp implementations will flag many of these as warnings; simpler implementations like clisp do not. The one place where Python is demonstrably more dangerous is when you do self.feild = 0 when you meant to type self.field = 0; the former will dynamically create a new field. The equivalent in Lisp, (setf (feild self) 0) will give you an error. On the other hand, accessing an undefined field will give you an error in both languages.

Common Lisp has a (somewhat) sound, standardized language definition, and competing compiler/JIT implementations that are much faster than anything that could ever possibly come from the Python camp because the latter is actually too dynamic and ill-defined ("Python is what CPython does") and making Python run fast while ensuring 100% compatibility with its existing ecosystem, without putting further restraints into the language, is akin to a mirage.

Re: Diminishing returns of static typing

#336

Post by gnaritas »

igouy wrote: post #311
gnaritas wrote: post #306

Earlier quoted context omitted.

Which is why Smalltalk's refactoring browser has a manual intervention step to allow you to see what it proposes to do, and remove any steps you don't agree with, as well as the ability to scope your refactorings to a package or class to limit the scope to more relevant data. Either way, it's sufficient to get 99% of the benefits of automated refactorings without the 100% guarantee static typing provides; good enough…

> Automated refactoring was invented in Smalltalk, claiming it's a benefit only static typing provides is to not know history. History: In Bill Opdyke's thesis work, the tooling was written for C++ and written in CLOS. http://www.laputan.org/pub/papers/opdyke-thesis.pdf

Ralph Johnson, a prominent Smalltalk'er, was advisor on that paper and was the creator of the first Smalltalk refactoring browser and that paper is littered with references to how things are done in Smalltalk. I was unaware a C++ was involved, but I still think Smalltalk had the first commercial refactoring browser. A research paper is not a product, however, thanks for the ref.

Re: Diminishing returns of static typing

#337

Post by smallnamespace »

gopalv wrote: post #201
Eridrus wrote: post #35

Earlier quoted context omitted.

I think dynamic typing proponents get hung up on the auto-complete aspect. The real benefit is when you find someone writing a property with a common-ish name to a data structure and you want to know "who the hell uses this", you can answer that question pretty easy in statically typed languages. In dynamically typed languages you kind of just grep and hope the name is not too common.

> In dynamically typed languages you kind of just grep and hope the name is not too common. For four days, I spent debugging a python production script because in one place I had typo'd ".recived=true" on an object and just couldn't understand why my state machine wouldn't work. And very quickly, the whole team became fans of __slots__ in Python. I still write 90% of my useful code in python, but that one week of deb…

This seems like something a linter can catch though. ESLint certainly seems to give me warnings for use of undefined properties.

Re: Diminishing returns of static typing

#338

Post by tabtab »

I've generally felt that each shines in different areas. Static typing is best for lower-level infrastructure and shared API's, while dynamic is better for gluing these all together toward the "top" of the stack, closer to the UI and biz logic. The problem is that languages tend to be all one or the other so that we have to make choice. What's needed is a language (or language interface convention) that can straddle both. A given class or library can be "locked down" type-wise to various degrees as needed.

Re: Diminishing returns of static typing

#339

Post by icebraining »

macspoofing wrote: post #304
icebraining wrote: post #269

Earlier quoted context omitted.

What crap? Types? Types, especially those that could easily be inferred and that provide no value to the programmer. Writing types down can be useful - Python programmers do it too. Having to tell the compiler every little thing is crap. Like what? Type erasure. Having to treat primitives and arrays differently from other types. No first class functions or classes. I won't go on, the arguments are easy to find.

I won't deny that Java had some quirky design decision that the language is paying for (though some of those have been mitigated). But I can't find your criticisms very persuasive in a world where languages like JavaScript and PHP are popular. Even C and C++ have their own idiosyncrasies to contend with. I am surprised though that you were completely ignorant of the benefits of static typing outside of Java. I would…

II can't find your criticisms very persuasive in a world where languages like JavaScript and PHP are popular.

Persuading you on the general demerits of Java wasn't really my intention; my point was that if you want get more people on the static typing train, Java is a bad ambassador and might work against you.

I am surprised though that you were completely ignorant of the benefits of static typing outside of Java. I would think that simply out of curiosity you would do a language survey just to get an idea of what else is out there.

Well, back then (early 2000s) I was a self-taught teenager with a poorer grasp of English (I'm not a native speaker), so while my curiosity did lead me to discover a few languages (JavaScript, PHP, Python, Lua and C), anything remotely approaching "academic" - Haskell, OCaml, Oberon, etc - was out of bounds for me.

Since C was the only other statically-typed language I knew, and I also knew it was much older and designed for much slower machines, I assume static typing was mostly for efficiency, like manual memory management.

Re: Diminishing returns of static typing

#340

Post by maxxxxx »

seasoup wrote: post #84

I really enjoyed how the analysis shows that different developers can have different equally valid opinions on this topic. It's where you place your values and preferences of programming, modified by what you are programming. The failure state of a cat photo sharing web app likely isn't as dramatic or important as that of a financial system or driverless car code. Great article.

My theory is that there are different psychologies of developers. I always liked how C++ (now C#) checked a lot of stuff at compile time and I rely heavily on the compiler. On the other hand I know very good devs who hate this and prefer dynamic languages. Their whole style is geared towards dynamic languages where mine is geared towards as strict as possible typing.

I think the key is not to confuse both approaches and leverage the strengths of each to the max.

Post reply on HN