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

321–330 of 632 posts

Re: Diminishing returns of static typing

#321

Post by golergka »

gwbas1c wrote: post #113
cm2187 wrote: post #3

The benefit of static typing isn't just reliability. Tooling is another major argument. Won't appeal to certain hardcore programmers who think that even notepad has too many features. But it is great for refactoring, finding all references to a function or a property or navigating through the code at design time. Basically all the features visual studio excels at for .net languages. And I disagree with the barrier to…

Isn't static typing a requirement when writing an algorithm and data structures for "every bit and clock cycle counts" situations? How can a 0-compute overhead for dynamic typing exist in a dynamic typed environment? I always thought dynamic typing is a feature for situations where the code needs an extreme amount of flexibility to adapt to a wide variety of data; even at the expense of performance.

Dynamic languages can actually be quicker in some cases because of virtual machine optimizations based on how your code actually runs with live data.

Re: Diminishing returns of static typing

#322

Post by tome »

amirouche wrote: post #79
christopheml wrote: post #29

Earlier quoted context omitted.

My main progamming language at the time is Java, and the amount of assistance my IDE provides is astonishing (to the surprise of no one, it's IntelliJ). The confidence strong automatic refactors provide is of great help when managing large codebases.

I agree that static typing helps reading comprehension and that IDEs like pycharm help getting into big code bases, that said, at the end of the day, when you know the code both the IDE and static typing are getting in the way. Actually, I never saw anybody as quick as people using simple editors like emacs and vim. GUI is getting in the way of the programmers intent. Static typing is a hindrance in front of refactor…

> Static typing is a hindrance in front of refactoring.

Are you kidding? Python programming's my day job but Haskell is an order of magnitude easier to refactor.

Re: Diminishing returns of static typing

#323

Post by flavio81 »

Tade0 wrote: post #302
flavio81 wrote: post #256

Earlier quoted context omitted.

>friendly learning curve To be honest, i love Common Lisp, it might be the most powerful programming language out there, but it's not easy to learn at all. In part because, being a truly multi-paradigm language, you should better make sure you are well versed in most programming paradigms first, otherwise you won't leverage the full power of Lisp. Not to mention the paradigm of meta-programming and DSLs, something th…

>Not to mention the paradigm of meta-programming and DSLs, something that is usually new to programmers foreign to Lisp. Is it really? What about templates(as in C++ templates), macros, CSS and HTML? These are two examples of metaprogramming and two DSLs respectively. > However, languages like Clojure and Smalltalk can be rather easy to learn, and they are fairly powerful. It's not like I don't believe you, but if th…

>Is it really? What about templates(as in C++ templates), macros, CSS and HTML?

"Lisp macros" go far, far beyond "C macros" ("preprocessor macros", and indeed go far beyond what you can do with C++ templates. You should take a look, but basically, explained in a few words:

In Lisp, code is data. Code is a first-class citizen. The functions and constructs that are there to manipulate data, also manipulate source code with the same easiness. So your code can manipulate code very, very easily. Writing code that creates code "on the fly" -be it at compile time or at runtime- is not only possible, it is also very easy to do, and it is 95% similar to writing regular code.

Thus, Lisp is sometimes described as "the programmable programming language."

>It's not like I don't believe you, but if this is true, then where's the popularity?

"Programming is pop-culture" -- Alan Kay.

The reasons a programming language gets highly popular is not always related to the quality of it. There are also other reasons. Consider Javascript for example. Before the ES6 specification, it was plainly a horrible programming language, full of pitfalls and missing features. You couldn't even be sure of the scope of the variable you just declared!! But it went popular, simply because it was the only programming language usable on all web browsers.

C, for example, was never a great programming language. But it ran efficiently on any hardware, so it started as a (very good) alternative to assembler. And then got more traction.

Then object-oriented programming got popular, because it allowed you to do nice stuff (on the Smalltalk language, where it was very well implemented). So somebody said: ok, i want C with object orientation, and C++ was invented, which wasn't a very good object oriented language, but since C was popular, and OOP was the next big thing, it got wildly popular.

C and C++ languages require you to manually manage memory, unlike in Smalltalk or Lisp, where the memory was automatically managed. So somebody at Sun said "ok, let's make a language with syntax similar to C++, but with automatic memory management", and Java was born, and thus, due to the small learning curve, and a LOT of marketing, went wildly popular, although many of the problems of C++ were present, plus it introduced limitations of its own. (I, as a student, loved Java when i learnt it, after having to use C++. How naive i was!!)

And the story goes on and on.

So it's more about riding the wave of popularity, rather than using the best tool for the job. It has also something to do with the triumph of UNIX over other operating systems. Otherwise, Smalltalk [what the groundbreaking Xerox machines used] and Lisp [what the groundbreaking Lisp Machines, and also the Xerox machines used] would be way more popular.

It also has something to do with speed -- Lisp (in the 60s) used to be a very slow language. Smalltalk (in the 70s and early 80s) used to run very slow as well. They also required a huge amount of memory. Nowadays they are not really memory hungry, and they can run very fast.

Some problems are much easier to express in Prolog, or Haskell, than Java or C++ or javascript; but they aren't popular languages. Popularity sometimes is harmful...

Re: Diminishing returns of static typing

#324

Post by lomnakkus »

y4mi wrote: post #226
gopalv wrote: post #201

Earlier quoted context omitted.

> 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…

> I still write 90% of my useful code in python, but that one week of debugging was exhausting & basically wouldn't have even compiled in a statically declared language.[...] nothing stops you from using static typing with python3

Well, nothing except almost the whole ecosystem of libraries not having type annotations, those type annotations that exist themselves being quite limited (IIRC), etc. etc.?

Can we stop pretending that adding type annotations to a 'dynamic' language solves the "good static typing" problem? It's just silly.

(About as silly as pretending that static types solve all problems.)

Re: Diminishing returns of static typing

#325

Post by berdario »

rbobrowicz wrote: post #203
enraged_camel wrote: post #143

Earlier quoted context omitted.

>>There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments. People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.

Personal anecdote: I worked on a small Python project some years ago and we had a type error in production despite having tests. We traced it back to a call to a third party library. It was supposed to return a list of results, and all of the test cases around it worked and always got a list back. In production however we encountered an error because if there was only one value to return, the library would not return…

I cannot reply to cdoconnor (probably some downvotes), so I'll write here:

That's the whole point: as it's often said "type checking keeps you honest"

I stumbled time and time again upon badly designed libraries... With a static type system, the painfulness will be obvious and felt the first time you'll try to build your code

with dynamic types, the pain might not be felt at all, until a crazy bit of code will be invoked, sometimes at the most unfortunate of times

Re: Diminishing returns of static typing

#326

Post by andrewaylett »

enraged_camel wrote: post #168
andrewaylett wrote: post #155

Earlier quoted context omitted.

Why would I write test-cases for something the compiler can catch for me? Yes, I need to write tests for all the correctly-typed cases, but there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case.

You don't write test cases specifically to check types. Your existing cases, if they are robust and thorough, will simulate your runtime and check those for you as a side effect.

My existing test cases, robust and thorough though they are, only test what happens when I feed in a correctly typed object. Because I can't write a test that exercises my code on an incorrectly typed input: the type system prevents that.

Re: Diminishing returns of static typing

#327

Post by Merovius »

walshemj wrote: post #108
cm2187 wrote: post #3

The benefit of static typing isn't just reliability. Tooling is another major argument. Won't appeal to certain hardcore programmers who think that even notepad has too many features. But it is great for refactoring, finding all references to a function or a property or navigating through the code at design time. Basically all the features visual studio excels at for .net languages. And I disagree with the barrier to…

Also the article does not take into account the much higher cost fixing a bug in live compared to development

It does (though admittedly not very explicitly), it just rolls it into the "benefit" (i.e. not shipping broken code is a benefit) and the "weight given to stability". If a bug discovered in prod (or even qa/canary) has a significantly higher cost than a bug discovered early, that will influence the weight you are putting on stability. In that way, this factor is subsumed in one of the other graphs.

As you might've noticed, I have been intentionally light on the details and only talked pretty abstractly about the specific scales and factors involved.

Re: Diminishing returns of static typing

#328

Post by crdoconnor »

wstrange wrote: post #314
crdoconnor wrote: post #299

Earlier quoted context omitted.

>there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case. By adding sanity checking asserts in a dynamically typed language you can achieve more or less the same result.

If you are going to add a bunch of asserts, why not just use types?

I don't particularly see the need to extend this approach to every single variable in my code base. I usually just stick it on boundary code.

Re: Diminishing returns of static typing

#329

Post by tom_mellior »

naasking wrote: post #181
tonyg wrote: post #142

Earlier quoted context omitted.

Not unless you think assembly language or machine code are statically typed.

Assembly is typed. The types are machine words and usually floating point types are also available. Basically, the machine types are the types of data that the register files can hold.

That's not a useful notion of type. If I cannot tell statically by inspecting a register name nor dynamically by inspecting a bit pattern whether a given register holds a pointer or an integer or a floating-point value, that's pretty much the definition of "untyped".

Re: Diminishing returns of static typing

#330

Post by orthecreedence »

icebraining wrote: post #171
always_good wrote: post #117

Earlier quoted context omitted.

You're kinda damning it with faint praise when you say that you can use dynamically typed languages on small projects that fit in your head (and are also probably written by a single developer). You can pretty much use any language in that scenario. But the chickens come to roost around day 30+ or so.

A large project is a poorly decoupled set of small projects.

True, once my libraries get bigger than five or six assembly instructions, I tend to break them down to a more manageable size.
Post reply on HN