4 ms·

I think of it like typing the units in physics class. Sure, you can leave them out. But how much time are you really saving? A lot of these languages make for

by tacos 12y ago

I think of it like typing the units in physics class. Sure, you can leave them out. But how much time are you really saving? A lot of these languages make for lovely blog posts and also happen to be fantastic for gluing things together. But I fear there's an entire generation that's unaware that C# looks like a lot of boilerplate in a textbook but actually requires fewer keystrokes than most equivalents. And once you get fast at it, it's pretty amazing. I use lots of Python. And Matlab. And of course Javascript. But as you get older you realize that tools matter. And the tooling around dynamic languages by definition cannot beat what's possible when you declare a more rigid contract of what you're actually trying to get the machine to do.

seanmcdirmid 12y ago
If you are writing avionics and/or are dealing with lots of conversions, then units are very useful in both dynamic and static languages. But if you are writing a simple game without many or any unit conversions, you might not find them useful at all.
- tacos 12y ago
  Interesting choice as game engines are famously C++ and the scripting languages -- even the one-offs custom made by the devs -- are less "scripty" than you'd think given the development pressures. From Wolf3D to Unity they land on a consistent set of squares here. Games are an interesting example because of 1) strong tooling requirements 2) small but diverse teams 3) cross-platform requirements and 4) performance requirements. Under these constraints they made their choices. And it wasn't because Python wasn't available.
  - seanmcdirmid 12y ago
    Python has plenty of game too, as does c#, Java, and so on. Ask a game developer if they need unit types, and I'd think it wouldn't be a top priority (though indeed useful).
    - tacos 12y ago
      Ah, my metaphor wasn't clear. I wasn't arguing for unit types (user-defined literals didn't appear in C++ until C++11...) I was pointing out that reconciling units in physics is common sense. People don't debate whether writing down "meters" or "seconds" next to a quantity is useful or not. You just do it, then cancel the units as a basic sanity check. Yet so much of the "strong typing is for people with weak memories" debate incorrectly centers around the equivalent of "len = 3.1" vs "Kilometers len = 3.1" (or, heck, "auto Distance = 3.1_km"). I'm not sure why people think this is some sort of ordeal but my hunch is they'll learn. Timezones, Unicode, Database Schema, Float vs Decimal: you can deal with it now or you can deal with it later. If there were a lightweight language that actually solved this we'd all be using it, not arguing about it.
      - seanmcdirmid 12y ago
        If type systems weren't so darn annoying, I'm sure everyone would be using them. As it is now, it's a trade off and not always a clear win. Give game developers easy access to unit types, for example, and they would probably use and benefit from them. But if they are a PITA to use, then of course, they would just say no way! For type systems, we really need much better type inference than we have now...something that works with the subtyping that many of us prefer to work with.
        tacos 12y ago
        Agreed. Nerds in generally tend to make a lot of ... odd ... short term decisions. Perhaps time to admit that a lot of what we do all day is "annoying" while balancing that with the fact that we're some of the best-paid people on the planet. Enjoying that economic windfall while doing what's all but scientifically provable as a half-assed job raises issues around quality and ethics. (Something as a community we're also a bit famous for tiptoeing around...)
        seanmcdirmid 12y ago
        The current state of PL is very annoying, less so than a decade ago, but still annoying. Most programmers don't really care, there are plenty of other annoying ways to spend life for less money. But improvement is so possible, not everything significant in PL was invented 20-30 years ago, yet that is what we are stuck on.
taeric 12y ago
By definition? Many of the tooling tricks you probably like about static languages are just as possible in so called dynamic languages. The trick is usually to hook into the environment while it is running. At this point, there are precious few things that can't be known by the editing environment.
- stickfigure 12y ago
  Rubbish. Create a new library function that takes 'fruit' as a parameter. What methods are available on 'fruit'? The IDE can't help you; the contract is unspecified. In addition to Java, I regularly write Python, Ruby, and Javascript using IDEA. The code navigation and code completion functions in those last three are utterly hopeless and fallback to grep-like behavior most of the time. Ruby deserves special mention because pretty much anything can get redefined at anytime anywhere. The poor IDE doesn't have a chance.
  - taeric 12y ago
    And this is where things are kind of funny. You are, of course, correct in a major especially static sense. However, for many programs it is entirely conceivable that the IDE can tell you all of the members available on all objects that are actually passed to said function. Or, inverted, check that all of the necessary items are available on any item you call it with. Now, in dynamic languages this is typically done at runtime. That is kind of the whole point of dynamic runtimes; that you can hook into them. Curious what all properties are available on the object represented by a given symbol? Essentially, ask it. However, as computers get more and more powerful, this can be done by simulation statically for many programs. No, not all. Just many. Is it enough, though?
    - tacos 12y ago
      (I don't think that's the whole point of dynamic languages. C++ has RTTI and .NET shipped with reflection as a fundamental construct...) I need to write code that talks to libraries today. I press dot and within 10 milliseconds I see an encyclopedic list of functions, complete with verifiable hints as to their structure. I type what looks like it makes sense, run the compiler that takes as much time to compile than python.exe takes to load, and a lot of the time, if the code compiles it just runs perfectly. I do not need to wade through verbose Doxygen boilerplate, nor page through source code, nor dance around fake json schemas. I do not need to write unit tests that, in many cases, serve merely to exercise the interpreter to make sure it hits everywhere I might have forgotten a parenthesis. It just friggin' works because a community has decided it's important to do things this way. So many of these "time-saving" languages are a full decade behind this reality. Right now it's definitely not enough. There's 30 years of idiotic cruft behind Windows bitmaps and it's STILL faster and easier to resize a jpeg in C# than using the insane Python libraries. Meanwhile C++ got "auto" and C# got "var" and "dynamic." At that point I picked my winners, there are of course other options. And when I write a library, doing it this way just seems like basic human respect. Sure: you're welcome to the source and here are some lovely docs. But if the only way to say whether something takes a string or bytes and that it varies between Python 2.7 and 3.x is in a README file, something's gone wrong. Like environmentalism we need to look at "total cost" before we declare something a net savings of energy.

by tacos 12y ago

seanmcdirmid 12y ago

If you are writing avionics and/or are dealing with lots of conversions, then units are very useful in both dynamic and static languages. But if you are writing a simple game without many or any unit conversions, you might not find them useful at all.

tacos 12y ago
Interesting choice as game engines are famously C++ and the scripting languages -- even the one-offs custom made by the devs -- are less "scripty" than you'd think given the development pressures. From Wolf3D to Unity they land on a consistent set of squares here. Games are an interesting example because of 1) strong tooling requirements 2) small but diverse teams 3) cross-platform requirements and 4) performance requirements. Under these constraints they made their choices. And it wasn't because Python wasn't available.
- seanmcdirmid 12y ago
  Python has plenty of game too, as does c#, Java, and so on. Ask a game developer if they need unit types, and I'd think it wouldn't be a top priority (though indeed useful).
  - tacos 12y ago
    Ah, my metaphor wasn't clear. I wasn't arguing for unit types (user-defined literals didn't appear in C++ until C++11...) I was pointing out that reconciling units in physics is common sense. People don't debate whether writing down "meters" or "seconds" next to a quantity is useful or not. You just do it, then cancel the units as a basic sanity check. Yet so much of the "strong typing is for people with weak memories" debate incorrectly centers around the equivalent of "len = 3.1" vs "Kilometers len = 3.1" (or, heck, "auto Distance = 3.1_km"). I'm not sure why people think this is some sort of ordeal but my hunch is they'll learn. Timezones, Unicode, Database Schema, Float vs Decimal: you can deal with it now or you can deal with it later. If there were a lightweight language that actually solved this we'd all be using it, not arguing about it.
    - seanmcdirmid 12y ago
      If type systems weren't so darn annoying, I'm sure everyone would be using them. As it is now, it's a trade off and not always a clear win. Give game developers easy access to unit types, for example, and they would probably use and benefit from them. But if they are a PITA to use, then of course, they would just say no way! For type systems, we really need much better type inference than we have now...something that works with the subtyping that many of us prefer to work with.
      - tacos 12y ago
        Agreed. Nerds in generally tend to make a lot of ... odd ... short term decisions. Perhaps time to admit that a lot of what we do all day is "annoying" while balancing that with the fact that we're some of the best-paid people on the planet. Enjoying that economic windfall while doing what's all but scientifically provable as a half-assed job raises issues around quality and ethics. (Something as a community we're also a bit famous for tiptoeing around...)
        seanmcdirmid 12y ago
        The current state of PL is very annoying, less so than a decade ago, but still annoying. Most programmers don't really care, there are plenty of other annoying ways to spend life for less money. But improvement is so possible, not everything significant in PL was invented 20-30 years ago, yet that is what we are stuck on.

taeric 12y ago

By definition? Many of the tooling tricks you probably like about static languages are just as possible in so called dynamic languages. The trick is usually to hook into the environment while it is running. At this point, there are precious few things that can't be known by the editing environment.

stickfigure 12y ago
Rubbish. Create a new library function that takes 'fruit' as a parameter. What methods are available on 'fruit'? The IDE can't help you; the contract is unspecified. In addition to Java, I regularly write Python, Ruby, and Javascript using IDEA. The code navigation and code completion functions in those last three are utterly hopeless and fallback to grep-like behavior most of the time. Ruby deserves special mention because pretty much anything can get redefined at anytime anywhere. The poor IDE doesn't have a chance.
- taeric 12y ago
  And this is where things are kind of funny. You are, of course, correct in a major especially static sense. However, for many programs it is entirely conceivable that the IDE can tell you all of the members available on all objects that are actually passed to said function. Or, inverted, check that all of the necessary items are available on any item you call it with. Now, in dynamic languages this is typically done at runtime. That is kind of the whole point of dynamic runtimes; that you can hook into them. Curious what all properties are available on the object represented by a given symbol? Essentially, ask it. However, as computers get more and more powerful, this can be done by simulation statically for many programs. No, not all. Just many. Is it enough, though?
  - tacos 12y ago
    (I don't think that's the whole point of dynamic languages. C++ has RTTI and .NET shipped with reflection as a fundamental construct...) I need to write code that talks to libraries today. I press dot and within 10 milliseconds I see an encyclopedic list of functions, complete with verifiable hints as to their structure. I type what looks like it makes sense, run the compiler that takes as much time to compile than python.exe takes to load, and a lot of the time, if the code compiles it just runs perfectly. I do not need to wade through verbose Doxygen boilerplate, nor page through source code, nor dance around fake json schemas. I do not need to write unit tests that, in many cases, serve merely to exercise the interpreter to make sure it hits everywhere I might have forgotten a parenthesis. It just friggin' works because a community has decided it's important to do things this way. So many of these "time-saving" languages are a full decade behind this reality. Right now it's definitely not enough. There's 30 years of idiotic cruft behind Windows bitmaps and it's STILL faster and easier to resize a jpeg in C# than using the insane Python libraries. Meanwhile C++ got "auto" and C# got "var" and "dynamic." At that point I picked my winners, there are of course other options. And when I write a library, doing it this way just seems like basic human respect. Sure: you're welcome to the source and here are some lovely docs. But if the only way to say whether something takes a string or bytes and that it varies between Python 2.7 and 3.x is in a README file, something's gone wrong. Like environmentalism we need to look at "total cost" before we declare something a net savings of energy.