4 ms·

Having worked with (and sometimes implemented) different flavors of both static and dynamic languages over the course of my 20+ years in programming, I still fe

by Udo 11y ago

Having worked with (and sometimes implemented) different flavors of both static and dynamic languages over the course of my 20+ years in programming, I still feel a little guilty about not coming down on one extreme side like most of my colleagues. I do like the fact that static typing gives me more confidence when refactoring things, and I do appreciate the speedier execution, but at the same time when programming in a dynamic languages I only rarely run into bugs that could have been avoided by a (moderately strict) type system. To me, the best feature of dynamically-typed languages are dynamic container objects (JS object literals, PHP arrays, Lua tables, Lisp/Scheme lists), because instead of having every single container be a purpose-built one-off abstraction that is often not even completely inspectable, much less extendable, I can just have one standard structure for any data. In the end though, both paradigms are tools to be used appropriately. While there is a great deal of problems that can be solved with either of them, they clearly each have strengths and weaknesses to be understood within the context of the program's purpose.

svieira 11y ago
Ultimately, that's what makes HList / HMap / Records so interesting to my mind - heterogeneously typed containers without the manually-generated boilerplate.
RussianCow 11y ago
I'm in the same boat. For most of my career I've worked with dynamically typed languages, but I recently spent a year writing iOS apps with Swift. For me, the biggest win with statically typed languages isn't necessarily catching those obvious bugs (which, as you said, are fairly easy to avoid with discipline), but rather the increased discoverability. I can quickly glance at the type definition for a function/method and generally get an idea of how to use it, whereas the equivalent in dynamic languages usually involves reading documentation or looking at examples. And when this is integrated into your development environment like in the JetBrains products, Xcode, or Visual Studio, it's all seamless in a way that's not really possible with a dynamically typed language. Of course, the other side of it is that statically typed languages tend to be less expressive, which makes things like JSON processing needlessly verbose. So it goes both ways.
- neutronicus 11y ago
  This is my feeling as well. I _like_ looking at header files. They're a good, compiler-mandated summary of what all this code is _for_. Figuring out what Python code does is always such a pain. (I do, however, develop mostly in C++, so there's probably all kinds of workflow crap I don't know about in Python)
u320 11y ago
To me, the best feature of dynamically-typed languages are dynamic container objects (JS object literals, PHP arrays, Lua tables, Lisp/Scheme lists), because instead of having every single container be a purpose-built one-off abstraction that is often not even completely inspectable, much less extendable, I can just have one standard structure for any data. This is perfectly possible in static languages as well.
- Udo 11y ago
  It depends on the language and it depends on how it's idiomatically used. In theory, you can make capability claims about most languages interchangeably, but the question is if the language really affords it or not. For example, I would say that Rust's enum gives you a lot of this capability easily, whereas C/C++ usually does not - unions and explicit casting not withstanding. But I do fully acknowledge you could make that claim for almost any language, and be technically correct.
  - u320 11y ago
    Sure. I just mean that if you want to have that feature in your language, static typing will not prevent you. In practice almost no mainstream static language does this though.
- deleted 11y ago
  [deleted]
nine_k 11y ago
Some of the good statically typed languages give you type-safe inspectable one-off containers with minimal syntax: tuples. Combined with type inference, this tool is pretty powerful at passing bunches of disparate data around while preserving type safety. Unfortunately many industrial languages, like Java, C++, or Go, don't have this feature. .NET has them, though. Even in Python I greatly appreciate `collections.namedtuple` that helps me create cheap ad-hoc containers while preserving excellent readability of the code. The latter helps avoid bugs greatly: e.g. it is much harder to write `foo.bar` by mistake than to put a wrong index in `foo[2]`.
- Udo 11y ago
  It's been a while since I last wrote C# code, does it really allow for heterogeneous value types? If so, that's cool. However, from my recollection, the C# API itself is all about opaque objects and behaviors. That's not a criticism of the paradigm, and I remember liking the C# standard libs and structures a lot better than Java's, but it's not something I would equate to generic heterogenous containers in dynamic languages. It's not in question whether you can replicate some of that in .NET, it's more about whether that's a core language idiom or not. Edit: `collections.namedtuple` is Python, mixed that up.
  - jstimpfle 11y ago
    python, not C#
  - radicalbyte 11y ago
    C# doesn't have real tuples, it has a set of pre-made generic (template) implementations supporting up to around 15 arguments iirc. There is currently active discussion on github about adding true language-level support for tuples of arbitrary length.
    - mike_hearn 11y ago
      I must admit, the idea of an un-specialised tuple with 15 elements is pretty damn scary. If I saw that in a codebase it'd be a real WTF moment. After three or four fields you should really be naming them, and if your language makes defining small classes painful, it's better to fix that with a Scala-type case class syntax (or data classes in Kotlin).
david-given 11y ago
I still regret the death of Strongtalk --- a gradually typed Smalltalk variant. It gave you dynamic types, when you wanted them; and Smalltalk is pretty much the most dynamic of dynamically typed languages. And it gave you static types, when you want them; including proper parametric types and polymorphism. So you got the best of both worlds. http://www.bracha.org/nwst.html http://www.bracha.org/nwst.html
mannykannot 11y ago
> I still feel a little guilty about not coming down on one extreme side like most of my colleagues. I applaud your rejection of simplistic, dogmatic dichotomies.
jernfrost 11y ago
Agree I like C, Scheme, Lua, Julia, Go and Swift so I am not totally wedded to one particular kind of language. In general though I do prefer simple languages which are somewhat pragmatic. That is why I dislike C++, Scala, Java and C#. C++ is way too complex and messy. Scala is purer and has lot of good ideas but made the whole thing too complicated. C# and Java keep adding features indefinitely and rely on huge libraries and IDEs. Go OTOH you can pick up in a few days and do useful stuff. It is pragmatic in adding the most used containers as part of the language. You are not forced to a particular programming style, like Java and C# which insists on everything being part of a class. C, Scheme and Lua all do their little thing well and are small enough languages to be able to easily fit in your head. They take some simple rules and let you combine them in very powerful ways. Swift is probably a bit atypical for me. It is definitely a bigger language than the others. And you typically program in an IDE. But supporting generics, static typing and popular functional features is going to make a language bigger. I think they struck a nice balance between practicality and purity. You use your old Objective-C stuff relatively easily, but it isn't trying to force you into making everything a class and coming up with Clunky solutions like inner classes to to deal with that wrong headed decision. My thoughts on Haskell are still confused. I kind of in awe by it but sometimes I also feel it is the emperors new clothes. There is this mathematical beauty to it and you almost got to masturbate at how short and elegant little code snippets you can make. But then you wonder, because that code often becomes totally unreadable a couple of weeks later and the mental overhead understanding the all this heavy theory seems a bit too much. You feel like it is a language not really made for us average developers but rather for your average genius. Is that a good or a bad thing? I dunno...
kqr 11y ago
I'm assuming you're talking about heterogenous collections, which while totally possible with powerful static type systems, I'd consider not to be a great idea. If even I don't know what's in my collections now (if I knew I could model it in the type system – it takes 30 seconds at most), how on Earth is my successor going to know in six months time? Heterogenous collections are a maintenance nightmare. I have only ever seen them used in a way where they should be refactored first thing in the morning.

by Udo 11y ago

svieira 11y ago

Ultimately, that's what makes HList / HMap / Records so interesting to my mind - heterogeneously typed containers without the manually-generated boilerplate.

RussianCow 11y ago

I'm in the same boat. For most of my career I've worked with dynamically typed languages, but I recently spent a year writing iOS apps with Swift. For me, the biggest win with statically typed languages isn't necessarily catching those obvious bugs (which, as you said, are fairly easy to avoid with discipline), but rather the increased discoverability. I can quickly glance at the type definition for a function/method and generally get an idea of how to use it, whereas the equivalent in dynamic languages usually involves reading documentation or looking at examples. And when this is integrated into your development environment like in the JetBrains products, Xcode, or Visual Studio, it's all seamless in a way that's not really possible with a dynamically typed language. Of course, the other side of it is that statically typed languages tend to be less expressive, which makes things like JSON processing needlessly verbose. So it goes both ways.

neutronicus 11y ago
This is my feeling as well. I _like_ looking at header files. They're a good, compiler-mandated summary of what all this code is _for_. Figuring out what Python code does is always such a pain. (I do, however, develop mostly in C++, so there's probably all kinds of workflow crap I don't know about in Python)

u320 11y ago

To me, the best feature of dynamically-typed languages are dynamic container objects (JS object literals, PHP arrays, Lua tables, Lisp/Scheme lists), because instead of having every single container be a purpose-built one-off abstraction that is often not even completely inspectable, much less extendable, I can just have one standard structure for any data. This is perfectly possible in static languages as well.

Udo 11y ago
It depends on the language and it depends on how it's idiomatically used. In theory, you can make capability claims about most languages interchangeably, but the question is if the language really affords it or not. For example, I would say that Rust's enum gives you a lot of this capability easily, whereas C/C++ usually does not - unions and explicit casting not withstanding. But I do fully acknowledge you could make that claim for almost any language, and be technically correct.
- u320 11y ago
  Sure. I just mean that if you want to have that feature in your language, static typing will not prevent you. In practice almost no mainstream static language does this though.
deleted 11y ago
[deleted]

nine_k 11y ago

Some of the good statically typed languages give you type-safe inspectable one-off containers with minimal syntax: tuples. Combined with type inference, this tool is pretty powerful at passing bunches of disparate data around while preserving type safety. Unfortunately many industrial languages, like Java, C++, or Go, don't have this feature. .NET has them, though. Even in Python I greatly appreciate `collections.namedtuple` that helps me create cheap ad-hoc containers while preserving excellent readability of the code. The latter helps avoid bugs greatly: e.g. it is much harder to write `foo.bar` by mistake than to put a wrong index in `foo[2]`.

Udo 11y ago
It's been a while since I last wrote C# code, does it really allow for heterogeneous value types? If so, that's cool. However, from my recollection, the C# API itself is all about opaque objects and behaviors. That's not a criticism of the paradigm, and I remember liking the C# standard libs and structures a lot better than Java's, but it's not something I would equate to generic heterogenous containers in dynamic languages. It's not in question whether you can replicate some of that in .NET, it's more about whether that's a core language idiom or not. Edit: `collections.namedtuple` is Python, mixed that up.
- jstimpfle 11y ago
  python, not C#
- radicalbyte 11y ago
  C# doesn't have real tuples, it has a set of pre-made generic (template) implementations supporting up to around 15 arguments iirc. There is currently active discussion on github about adding true language-level support for tuples of arbitrary length.
  - mike_hearn 11y ago
    I must admit, the idea of an un-specialised tuple with 15 elements is pretty damn scary. If I saw that in a codebase it'd be a real WTF moment. After three or four fields you should really be naming them, and if your language makes defining small classes painful, it's better to fix that with a Scala-type case class syntax (or data classes in Kotlin).

david-given 11y ago

I still regret the death of Strongtalk --- a gradually typed Smalltalk variant. It gave you dynamic types, when you wanted them; and Smalltalk is pretty much the most dynamic of dynamically typed languages. And it gave you static types, when you want them; including proper parametric types and polymorphism. So you got the best of both worlds. http://www.bracha.org/nwst.html http://www.bracha.org/nwst.html

mannykannot 11y ago

> I still feel a little guilty about not coming down on one extreme side like most of my colleagues. I applaud your rejection of simplistic, dogmatic dichotomies.

jernfrost 11y ago

Agree I like C, Scheme, Lua, Julia, Go and Swift so I am not totally wedded to one particular kind of language. In general though I do prefer simple languages which are somewhat pragmatic. That is why I dislike C++, Scala, Java and C#. C++ is way too complex and messy. Scala is purer and has lot of good ideas but made the whole thing too complicated. C# and Java keep adding features indefinitely and rely on huge libraries and IDEs. Go OTOH you can pick up in a few days and do useful stuff. It is pragmatic in adding the most used containers as part of the language. You are not forced to a particular programming style, like Java and C# which insists on everything being part of a class. C, Scheme and Lua all do their little thing well and are small enough languages to be able to easily fit in your head. They take some simple rules and let you combine them in very powerful ways. Swift is probably a bit atypical for me. It is definitely a bigger language than the others. And you typically program in an IDE. But supporting generics, static typing and popular functional features is going to make a language bigger. I think they struck a nice balance between practicality and purity. You use your old Objective-C stuff relatively easily, but it isn't trying to force you into making everything a class and coming up with Clunky solutions like inner classes to to deal with that wrong headed decision. My thoughts on Haskell are still confused. I kind of in awe by it but sometimes I also feel it is the emperors new clothes. There is this mathematical beauty to it and you almost got to masturbate at how short and elegant little code snippets you can make. But then you wonder, because that code often becomes totally unreadable a couple of weeks later and the mental overhead understanding the all this heavy theory seems a bit too much. You feel like it is a language not really made for us average developers but rather for your average genius. Is that a good or a bad thing? I dunno...

kqr 11y ago

I'm assuming you're talking about heterogenous collections, which while totally possible with powerful static type systems, I'd consider not to be a great idea. If even I don't know what's in my collections now (if I knew I could model it in the type system – it takes 30 seconds at most), how on Earth is my successor going to know in six months time? Heterogenous collections are a maintenance nightmare. I have only ever seen them used in a way where they should be refactored first thing in the morning.