101–110 of 127 posts
> the programmer ends up with less to specify I don't see how this can be true. Wouldn't there be less to specify if the programmer didn't have to specify types at all?
I've recently joined a team writing primarily in Clojure, whose proponents often tout repl-driven programming as a unique benefit to the language. In a statically typed language (the stronger the better), aided by a good IDE, I don't need to be constantly executing my code against data during development; My editor is constantly validating my code, and when it stops complaining, my code will work. And months later wh…
with F# you have a REPL, it is not only prerogative of dynamic typed languages.
"This is sort of a subtle point: when programming in a static language, you always have a choice about what information you encode in the types, and how you encode things. ... In a static language, you do always have the option of building a less typeful API, where less is enforced by the types, but it is often tempting to spend more time encoding things statically (and then proving things to the typechecker) than wo…
It's frustrating that this static vs dynamic 'battle' still goes on. The longer everyone thinks this is actually a problem, the longer we have to wait for innovations to happen. Look at the web in 2016, the technology is a complete disarray. Look at the game industry in 2016, where C++ is thrown around as the the cause and solution to all life's problems. A language created 33 years ago now with no intention of being…
> A language created 33 years ago now with no intention of being used as it is today. You know that they update the language regularly, and have a games sig? https://groups.google.com/a/isocpp.org/forum/#!forum/sg14
It could really use profiles. Strict mode or something, where the code should only use N "good practice" features.
One of my problems with static types in a lot of languages is that they're usually very limited in what they allow you to express. For example: a function that takes an integer between 1 and 100. That's a straightforward constraint! Elixir is an example of a language that lets you express some of those kinds of constraints, by using guard clauses. Along with its powerful pattern matching, you end up with very nice co…
Even though that may be factually correct, it doesn't seem to be related to static typing. Haskell has guards but they are slightly different.
> Some tasks, especially around generic programming, can be very easily expressed in a dynamic language, but require more machinery in a static language. I think this is not generally true and not a point against static typing, but rather against statically typed languages with poor support for generics. Java stands out as the poorest implementation of generics I have ever seen. > For instance, a generic serializatio…
* Introduce new generic types in a new namespace. .NET did this with `System.Collections` and `System.Collections.Generic`.
* Default unspecified generics to `Object`, including usage of generic types in bytecode tagged with pre-1.5 versions.
Earlier quoted context omitted.
> Personally, type errors haven't been the kind of errors that haunt my dreams. The point of strongly-typed systems is that you can represent your constraints as types. This takes extra thinking and work, but gives you almost almost unlimited expressive power (ref: agda). Simple example: meters and feet as different numerical types. When you multiply them, you get a silly unit (foot-meters) that doesn't fit with what…
I haven't met anyone other than Haskellians that would create separate types for meters and feet. I also wonder when you would make that distinction in the lifecycle of your application. I suspect not until you first encounter the bug of accidentally mixing units. If so, we'd be solving the problem at the same time, just using different techniques.
It's frustrating that this static vs dynamic 'battle' still goes on. The longer everyone thinks this is actually a problem, the longer we have to wait for innovations to happen. Look at the web in 2016, the technology is a complete disarray. Look at the game industry in 2016, where C++ is thrown around as the the cause and solution to all life's problems. A language created 33 years ago now with no intention of being…
With static typing the computer doesn't "understand" your code. It just automatically checks the correctness proof you've presented to it. And the correctness is limited only to certain properties of the program, that a given type system supports.
One of my problems with static types in a lot of languages is that they're usually very limited in what they allow you to express. For example: a function that takes an integer between 1 and 100. That's a straightforward constraint! Elixir is an example of a language that lets you express some of those kinds of constraints, by using guard clauses. Along with its powerful pattern matching, you end up with very nice co…
Even though that may be factually correct, it doesn't seem to be related to static typing. Haskell has guards but they are slightly different.
Consider the following: I have a "rating" type, which is a whole number from 0 to 5. If you try rendering a view with a number outside of that range, that's a bug! Which means you probably made a mistake somewhere.
I want software to help me catch bugs. If something can't be confirmed with a linter or compiler, getting a good error message during runtime is also fine. Once I've established that I expect some value, I don't want to write extra checks to confirm that my expectations are met.
Earlier quoted context omitted.
You are right - in a tautalogical way - that type systems only catch type errors. However, in modern languages (including Haskell, Scala, as well as newer, more experimental languages like Idris), those type errors can be extremely powerful. Many people assume that 'types' are simply primitives like Int and String, and that a type checker just makes sure you don't pass an Int to a function expecting String. However,…
You make a good point, so I'll answer in parts. First, when most people talk about static typing, they're talking about the near-useless version -- just types like Int and String. I think we agree there, so I won't mention it further. Second, a dynamically typed language like Python has more typing information than some folks first assume. Python's AttributeError is quite similar to a TypeError. In fact, with old-sty…
I don't agree. Who is "most people"? Certainly not PL designers and not most of what I've seen here in HN. More importantly, it's also not what the article under discussion is saying, either.
> Static typing errs on the side of safety, dynamic typing errs on the side of flexibility. Both can mimic the other. Arguing that one is better is like saying linear regression is better/worse than k-nearest-neighbors.
In my experience, this isn't true. Modern statically typed languages have all the convenience of dynamically typed ones, such as REPLs and elegance, plus the safety of early warnings and the guidance that static types give you while writing your code (if you've ever written code like this, you'll know the feeling of working with building blocks that "fit" with each other). So you can have your cake and eat it, too.
Also in my experience, not having experience with these languages is what leads some people to think their type systems can only state trivial things such as "this is a String". They can do more. They can say things such as "this expression/function doesn't write to disk as a hidden side effect", which is useful!