Hacker News Reader

> Do people who prefer dynamic languages actually use the benefits of dynamic typing in the first place? Changing variables from one type to another mid-stream. Dynamically adding properties to objects, using == instead of === etc.. Those things are a recipe for bugs, inconsistency, and unmaintainability right from the get go.

I think you are mixing some things there. The biggest advantage of dynamic typing is that it has no restrictions to how you are allowed to program. There are many cool language features that you can only use in a static language if its type system was designed to support it while in a dynamic language you can just implement it yourself (just hope it doesn't crash at runtime). For example, datatype-generic functions, object orientation (in all different variations), encoding JSON, etc.

Changing variables from one type to the other mid stream is usually a bad programming practice, so don't do that. Same thing for "==", although sometimes coercions really are convenient (for example wen you read data from an input field its often in string format).

Dynamically adding properties to objects is very useful if you are doing some "metaprogramming" stuff. For example, its trivial to write a "clone" method in Javascript because you can dynamically set properties. In a static language you would need language support for this.

> Static typing doesn't feel intrusive, it feels like a flashlight.

Which is why the Typescript project exists! When your programs are super small (for example, an inline onclick event handler) then dynamic typing wins because its concise (no type annotations), conceptually simple (no type system, type inference, etc) and doesn't get in the way. However, if you have a large program that can't fit all in your head at once then the types help a lot.

Dynamic property addition is super useful.

With the == vs === thing, I think you're confusing dynamic typing with weak typing. Weak typing is why == and === exist, and it totally sucks.

>I'm looking at a function parameter in a random file. How do I even begin to work with it?

First off, Duck Typing: The type of the parameter is the intersection of the types the functions it is called with contain.

Secondly, this is why you document your code and choose prescriptive variable names. Honestly, this is pretty bad even with types (the first question I had when I looked at my first chunk of real world C was, "what the hell is the variable 'int rv;', and what's it being used for?).

Even I'll admit that type annotations can be useful sometimes, but I don't need them.

Having a parameter 'user' doesn't infer what properties are on it. If you're going to document what properties it has you might as well create a type definition for it.

Duck typing (or checking types at runtime) is verbose and forces you to handle type mismatches at runtime. Which means you will probably end up throwing an error anyways when types end up missing the properties you expected.

If your code relies on properties added dynamically that might be useful for you, but god help anyone working with your code.

Well, obviously, I wouldn't document everything, but if the argument name is "user" and it's an object, as opposed to a string, than it's probably a user object. Not exactly rocket science.

That's not exactly what Duck Typing is, but that is possibly true. However, in an OO system, Duck Typing has massive benefits, as you don't have to depend on inheritance to see if an object can be passed to a function: polymorphism. This is the sort of thing Java's interfaces do, albeit clumsily.

>If your code relies on properties added dynamically that might be useful for you, but god help anyone working with your code.

Obviously, you have to be careful about it. But if you're marking nodes on a graph, or attaching metadata to a function, especially if it's temporary, it comes in handy.

You can totally simulate duck typing with Typescript, since it (only) supports structural typing. If your method only expects an object with an asString() method, you can do something like:

    function useAsString(foo: {asString: () => string}) {
        ...
    }

Note that the type we give for foo here is an anonymous type (though this would also work with an explicitly named type).

And now you can do this:

    interface SomeInterface {
       name: string;
       asString: () => string;
    }

    let bob: SomeInterface = { name: "Bob", asString: () => "Bob" };

    useAsString(bob);

And this works, because the interface SomeInterface has an asString() method. No inheritance in sight.

Huh. Pretty cool. Are the interfaces Go-style (must you declare a class/object as that interface, or is it just detected)?

Because if it's not, than it's not duck typing, is it?

Interfaces in typescript are implicit, or auto detected. You dont have to say that a class implements an interface, if it has the correct properties it automatically fulfills the interface. It's like type safe ducktyping and it's super awesome.

That's just compile-time verified duck typing.

Not bad.

Static weak types

No, because you're not doing implicit type conversion, which is what weak typing implies.

Sounds like it works just like Go-lang, then.

Is there a way to cast something anonymous, just a value read in from JSON, to such an interface? This would allow you to specify an important subset of things that an object needs to do, verify it in one place, then pass around the interface handle to anything that needed the underlying object in that role. Presumably, if the incoming object lacked the desired attributes, the "cast" would blow up sooner, during the assignment, rather than later, when the interface alias was used.

Unless you wrote the code yourself you pretty much have to run the program first and then REPL to see what the type actually is and the properties it exposes Slow, arduous, unnecessary.

If the code is well written, then no, to seeing what the type actually is. In a good environment like you have in many Smalltalks, you should be able to compose some implementors searches, then quickly know what you're dealing with. Then you quickly and easily debug the system just to be rigorous. In environments set up by smart people, these actions can be surprisingly quick and easy. (In the same way that git allows for using certain information much more quickly, quantity can become a different quality.)

Do people who prefer dynamic languages actually use the benefits of dynamic typing in the first place? Changing variables from one type to another mid-stream. Dynamically adding properties to objects, using == instead of === etc.. Those things are a recipe for bugs, inconsistency, and unmaintainability right from the get go.

None of those things are the benefits of a dynamic language, except maybe as super debugging tricks. No one who really knows how to write in a dynamic language puts stuff like that in typical code! That you say this makes me think you don't know what you're talking about, or your main exposure to dynamic langs has been through the code of yahoos.

If the code is well written...

In a good environment like you have in many Smalltalks...

No one who really knows how to write in a dynamic language puts stuff like that in typical code

That's the problem. You're talking about some hypothetical, Smalltalk environment, where some expert dynamic language programmers always do "the right thing".

Okay then, but if you're not documenting your functions, which is the most important thing, you shouldn't be working on a large project with other people in any case.

Documentation will not save you the day you decide to rename a function or change its signature. Static typing will.

...No, it won't. It might make the refactoring a little easier, but with various tools, you can check all the call sites and see if you fixed it. Sure, your compiler won't tell you what's wrong, but your REPL and your tests will.

Yes, given enough time for enough manual work, and enough tests, and enough code review....

The whole point is not to have to do this stuff manually, which is very error prone. Ad-hoc REPL work, and tests are very likely to have missed something.

Precisely.

It will absolutely save you, because it will complain loudly about every broken call site and prevent the broken code from making it to production (assuming you didn't use any tricks with any). Tests may or may not help (I have yet to see a codebase with perfect test coverage).

Sure, your compiler won't tell you what's wrong, but your REPL and your tests will.

If a REPL and tests make you powerful, then a type system that doesn't drag you down and good tooling around that will only make you more powerful.

It depends on your tools. I refactor JS stuff in intelliJ from time to time, no big deal, at least for rename. (1)

OTOH, if you don't have plugins for things like Struts or Spring (faking the desperately needed dynamicism in config files), good luck safely refactoring your "static" typed Java (2). But once have "trained" your IDE where to look, you are back in business again.

1: it's easier to refactor JS if you restrict the scope of identifiers, of course. For starters, this means NOT naively making every function and variable in the global namespace and/or scattered in inline <script> fragments.

2: many other languages dragged into these discussions since there is some general philosophy of compile time vs runtime types discussed on this page.

That's the problem. You're talking about some hypothetical, Smalltalk environment, where some expert dynamic language programmers always do "the right thing".

No, I'm talking about a place I've worked, certain subsets of code in other places I've worked, code at customer's shops, and most of the standard library of Smalltalk.

True, I've also seen what can go wrong in Smalltalk. But in my experience, this isn't worse than what can go wrong in other languages, dynamic and static.

I think the argument is not "You can't write something maintainable in a dynamic language" - it's more like "Given the majority of projects, static typing would have helped readability".

Since in SDLC maintenance is like 80%, and most of the time code isn't written amazingly, it seems pragmatic to have static typing.

I love Dynamic languages as much as the next guy (Ruby and clojure are pretty great in my book) but in my career, I get my guys to write in statically typed languages.

it's more like "Given the majority of projects, static typing would have helped readability".

Not so much readability. That comes mostly from good naming in Smalltalk, and thinking about, "What if I had to understand this through senders/implementors searches?" However, in my experience, it helps maintainability. In general, I didn't need type annotations to help me understand the system. Good Smalltalk is about message passing, so you understood the system through who sends what to whom. What I did experience a lack of, were 100% ironclad guarantees in a couple of instances where we needed to be 100% sure about something.

And yes, it is pragmatic to have static typing for the long term!

Some of those aren't even dynamic language things. And most of them are bad form.

But yeah, shoving a flag onto an object where there was no such flag can come in handy at times, if you're treating your objects as dicts or whatever (in JS). If you're doing Real OO, you'd want to put the flag into the class/prototype declaration, so that it's documented, but if you're not, or just need to attach some extra data to, say, a function, it's handy.

Also, in a well documented system, functions should note what types they except, even if it is just "any types that respond to these messages" in smalltalk, or your local equivalent.

> But yeah, shoving a flag onto an object where there was no such flag can come in handy at times, if you're treating your objects as dicts or whatever (in JS).

Ugh, no. I really don't want to be looking at code where properties appear after initialization and you have reason about when the damn thing is actually available, thank you.

> Also, in a well documented system, functions should note what types they except, even if it is just "any types that respond to these messages" in smalltalk, or your local equivalent

So, like specifying type signatures in Typescript, except probably out of sync because it's not automatically enforced?

Well, sometimes, which is why optional type signatures, like those in TS, can be useful. But even if you're not telling all the typing details, at least tell the world that your function works with strings, or whatever.

And if you're using the properties everywhere, yeah, define them, but if you need to extend an object, and the extension will only be used locally, than it's useful.

What infitessimally small numbers of us actually get to use a dynamic language that is on the Smalltalk end of the scale, vs the overgrown scripting languages like python, lua, ruby or javascript?

Many of those "overgrown scripting languages" owe a pretty big debt to Smalltalk. Ruby and JS, particularly, borrow heavily from Smalltalk and Self. Lua is very Schemey, and while many talk about JS's Scheme influences, Lua really does feel like Scheme sometimes, and reflects Scheme's values far more than JS (small number of primitives, TCO, emphasis on minimalism and flexability, etc.).

Yes, they don't have the refactoring toolkit Smalltalk does, and they can be slow, but don't discount them off the bat. The two ends of the scale are closer together than you think.

Sure, but to be kind, the tooling mostly sucks bogwater. Trying to detect usages of symbols or perform simple refactorings is considerably harder than even in languages with less than stellar static typing, like the C++/Java/C# enterprise workhorses, much less anything more powerful. Maybe I'm spoiled, but using find&replace and runtime errors feels as primitive as banging two rocks together.

Well, maybe I'm spoiled, but waiting forever for your code to recompile, just to discover that you misplaced a semicolon, as opposed to running it through a REPL as you develop feels a primitive as banging rocks together.

It's a tradeoff, and I didn't choose the refactoring side. Although refactoring did originate in Smalltalk...

It's funny that the guy that wrote the definitive catalog of refactoring techniques prefers to work in a dynamic language.

http://www.martinfowler.com/articles/rubyAtThoughtWorks.html

> Do people who prefer dynamic languages actually use the benefits of dynamic typing in the first place? Changing variables from one type to another mid-stream.

I don't think people use dynamic languages for that ability. It's more for the ability to not have to explicitly think about types -- it's more natural that way.

When you start typing user.. your brain is thinking about what type user is and the properties on it. How about not just keeping that knowledge in your brain, but write it down as a type definition so others can work with your code without having to become Sherlock Holmes.

First they tell you the types are optional.

Then one day the type declarations are not, and you have to define "JSON schemas" or some such thing for other people's glop that you just want to shovel over a fence without concern of what is in it for most of the code.

That's my nightmare, anyway.

There are plenty of things that bug me more than "intellisense" (auto-completion) not working. Although type inference in my IDE on JS actually works well most of the time. (and I get to skip transpiling and source maps)

YMMV, but if you want to understand how some of "The Other Side" feels, there you go.

> Unless you wrote the code yourself you pretty much have to run the program first and then REPL to see what the type actually is and the properties it exposes Slow, arduous, unnecessary.

I think this is true of statically typed languages as well, at least with anything larger than a single function.