5 ms·

"This is the problem with dynamic syntax in, well, dynamic languages. As Philips puts it, ignorance is strength, and freedom is slavery..." Hey man, that's lik

by islon 13y ago

"This is the problem with dynamic syntax in, well, dynamic languages. As Philips puts it, ignorance is strength, and freedom is slavery..." Hey man, that's like... your opinion In my opinion types are a poor man's schema, my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo". I use schema libraries and asserts to both document the code and make sure you can't feed it wrong data. I even generate automatic html documentation out of my schema so my clients know what to send me, and this only in the places I need, no need to a schematize or assert every simple function with obvious parameters. Maybe type annotation is more useful in OO languages, but as a clojure programmer, for me, data is just data, there's no behavior associated. If I really want type safety at compile time I can use core.typed only in the places I need it. As a former long time java programmer (who tried scala for months) I welcome my new found freedom from type slavery, but that's just... my opinion.

adamnemecek 13y ago
> I use schema libraries and asserts to both document the code and make sure you can't feed it wrong data. Dependent types to the rescue!
- danieldk 13y ago
  Dependent types to the rescue! Dependent types are nice, but much what the grandparent wants can be achieved fine with normal types. E.g. in Haskell, define the Longitude type and some helper functions newtype Longitude = Longitude Double fromDouble :: Double -> Maybe Longitude ... And don't export the Longitude constructor to maintain invariants. Obviously, the same can be done in OO languages that allow you to hide members, C (via opaque pointers), etc.
octo_t 13y ago
Dependent types to the rescue! Unfortunately dependent types are incredibly difficult to get working (Scala's type system is already turing complete (and can handle path-dependent types) and true dependent types would make reasoning about nigh-on impossible). I would argue that you're dealing with a sub-typing problem here, Email <: String, LongLat <: (Int, Int)* * I would say in Scala: case class LongLat(longitude: Int, Latitude: Int)
- islon 13y ago
  Scala doesn’t support dependent types AFAIK
  - octo_t 13y ago
    http://stackoverflow.com/questions/2693067/what-is-meant-by-scalas-path-dependent-types http://stackoverflow.com/questions/2693067/what-is-meant-by-... they are kinda cool, but also limited as hell.
  - andrewcooke 13y ago
    if it's type system is turing complete, how can it not? presumably it just doesn't have a short syntax for them? if so, given what i know of the rest of scala, i'm surprised one can't be defined...
ShardPhoenix 13y ago
You realize you can define your own types, right?
lmm 13y ago
> In my opinion types are a poor man's schema What's the distinction you're drawing here? > my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo" I fully agree. Those sound like exactly the kind of thing I would enforce using types. > and this only in the places I need, no need to a schematize or assert every simple function with obvious parameters. How do you enforce that all code paths go via your schema? Just visual inspection?
pjmlp 13y ago
Have you ever worked in enterprise projects with distributed teams, around > 30+ developers per site, grokking hundreds of code lines in a dynamic language without unit tests, because they are a waste of employee salary time? I really value strong typed languages in such projects.
- islon 13y ago
  If you don’t have unit tests in a distributed team of 30+ devs per site you are screwed in ANY language.
  - mercurial 13y ago
    That's a fact. But there are languages you are more screwed in than others. Even a tiny amount of refactoring in a dynamically typed language makes it easy to break your build, while it's much less risky in a statically typed language. And if your hypothetical team has this codebase without unit tests, we can likely assume that other best practices, such as the notion of separation of concerns, is also considered a waste of time. If you can start refactoring the existing codebase with a more modular design AND be (relatively) confident that you're not breaking your app, you'll make it possible to introduce unit tests.
    - yogthos 13y ago
      The way Clojure mitigates this is by having a REPL. Whenever I work on any code I can always run it immediately in the context of the application. Let's say I'm refactoring a function, I can run it to see what it actually does and I can write a new function and test it immediately on the spot to make sure it has the same behavior. When you're working in a REPL you always have confidence that whatever change you made does what you want immediately. There's no recompile cycle, you don't have to restart your application and build up the state to see what effect the change has. This allows you to refactor things and be very confident that you're not breaking anything. Coupled with high level integration tests you can be confident that all the use cases work correctly without having to have a ton of unit tests. Having worked with Clojure it really shocks me that most modern languages do not have any REPL integrating in the editor and you still have the code/compile/run cycles.
coldtea 13y ago
>In my opinion types are a poor man's schema, my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo". Err, you know that a type system could take care of all of those contraints, right? Because you come across as types for you are restricted to be just the known scalar or barebones object types. Having an email just as a string if far from the exhausting the specialization you can do using an "email" type.
hrvbr 13y ago
> my email is not a string, it's a email Here's the documentation for custom types in F#: http://fsharpforfunandprofit.com/posts/conciseness-type-definitions/ http://fsharpforfunandprofit.com/posts/conciseness-type-defi... http://fsharpforfunandprofit.com/series/understanding-fsharp-types.html http://fsharpforfunandprofit.com/series/understanding-fsharp... http://fsharpforfunandprofit.com/series/designing-with-types.html http://fsharpforfunandprofit.com/series/designing-with-types... Types are a very good way to model your data strictly.
stormcrowsx 13y ago
Types are generally a hindrance for a small scale app. They pay off when your working on an app that has 30-40 developers and millions of lines of code. Use the right tool for the job, and there are jobs where Types are the right tool.
- the_af 13y ago
  Is correctness less important in small scale apps?
  - louthy 13y ago
    It's easier to manage and have a mental picture of where something is likely to go wrong on a smaller project. Once your project gets to a certain size then it's nice when the compiler tells you ahead of time that you've screwed up. Because you will screw up.
- dragonwriter 13y ago
  > Types are generally a hindrance for a small scale app. I don't think that's true. I think that the ritual incantations to the type system required in, particularly, C++/Java-style languages are a hindrances that outweighs the benefits of static typing on very small projects. And the limitations of limited static type systems can also be a hindrance. But when you have a richer type system and/or type inference that reduces the necessary incantation, the size of project on which static typing becomes a net positive drops.

by islon 13y ago

adamnemecek 13y ago

> I use schema libraries and asserts to both document the code and make sure you can't feed it wrong data. Dependent types to the rescue!

danieldk 13y ago
Dependent types to the rescue! Dependent types are nice, but much what the grandparent wants can be achieved fine with normal types. E.g. in Haskell, define the Longitude type and some helper functions newtype Longitude = Longitude Double fromDouble :: Double -> Maybe Longitude ... And don't export the Longitude constructor to maintain invariants. Obviously, the same can be done in OO languages that allow you to hide members, C (via opaque pointers), etc.

octo_t 13y ago

Dependent types to the rescue! Unfortunately dependent types are incredibly difficult to get working (Scala's type system is already turing complete (and can handle path-dependent types) and true dependent types would make reasoning about nigh-on impossible). I would argue that you're dealing with a sub-typing problem here, Email <: String, LongLat <: (Int, Int)* * I would say in Scala: case class LongLat(longitude: Int, Latitude: Int)

islon 13y ago
Scala doesn’t support dependent types AFAIK
- octo_t 13y ago
  http://stackoverflow.com/questions/2693067/what-is-meant-by-scalas-path-dependent-types http://stackoverflow.com/questions/2693067/what-is-meant-by-... they are kinda cool, but also limited as hell.
- andrewcooke 13y ago
  if it's type system is turing complete, how can it not? presumably it just doesn't have a short syntax for them? if so, given what i know of the rest of scala, i'm surprised one can't be defined...

ShardPhoenix 13y ago

You realize you can define your own types, right?

lmm 13y ago

> In my opinion types are a poor man's schema What's the distinction you're drawing here? > my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo" I fully agree. Those sound like exactly the kind of thing I would enforce using types. > and this only in the places I need, no need to a schematize or assert every simple function with obvious parameters. How do you enforce that all code paths go via your schema? Just visual inspection?

pjmlp 13y ago

Have you ever worked in enterprise projects with distributed teams, around > 30+ developers per site, grokking hundreds of code lines in a dynamic language without unit tests, because they are a waste of employee salary time? I really value strong typed languages in such projects.

islon 13y ago
If you don’t have unit tests in a distributed team of 30+ devs per site you are screwed in ANY language.
- mercurial 13y ago
  That's a fact. But there are languages you are more screwed in than others. Even a tiny amount of refactoring in a dynamically typed language makes it easy to break your build, while it's much less risky in a statically typed language. And if your hypothetical team has this codebase without unit tests, we can likely assume that other best practices, such as the notion of separation of concerns, is also considered a waste of time. If you can start refactoring the existing codebase with a more modular design AND be (relatively) confident that you're not breaking your app, you'll make it possible to introduce unit tests.
  - yogthos 13y ago
    The way Clojure mitigates this is by having a REPL. Whenever I work on any code I can always run it immediately in the context of the application. Let's say I'm refactoring a function, I can run it to see what it actually does and I can write a new function and test it immediately on the spot to make sure it has the same behavior. When you're working in a REPL you always have confidence that whatever change you made does what you want immediately. There's no recompile cycle, you don't have to restart your application and build up the state to see what effect the change has. This allows you to refactor things and be very confident that you're not breaking anything. Coupled with high level integration tests you can be confident that all the use cases work correctly without having to have a ton of unit tests. Having worked with Clojure it really shocks me that most modern languages do not have any REPL integrating in the editor and you still have the code/compile/run cycles.

coldtea 13y ago

>In my opinion types are a poor man's schema, my email is not a string, it's a email, and my longitude/latitude pair are not just ints they have specific ranges, saying that longitude is 500 is as wrong as saying it's "foo". Err, you know that a type system could take care of all of those contraints, right? Because you come across as types for you are restricted to be just the known scalar or barebones object types. Having an email just as a string if far from the exhausting the specialization you can do using an "email" type.

hrvbr 13y ago

> my email is not a string, it's a email Here's the documentation for custom types in F#: http://fsharpforfunandprofit.com/posts/conciseness-type-definitions/ http://fsharpforfunandprofit.com/posts/conciseness-type-defi... http://fsharpforfunandprofit.com/series/understanding-fsharp-types.html http://fsharpforfunandprofit.com/series/understanding-fsharp... http://fsharpforfunandprofit.com/series/designing-with-types.html http://fsharpforfunandprofit.com/series/designing-with-types... Types are a very good way to model your data strictly.

stormcrowsx 13y ago

Types are generally a hindrance for a small scale app. They pay off when your working on an app that has 30-40 developers and millions of lines of code. Use the right tool for the job, and there are jobs where Types are the right tool.

the_af 13y ago
Is correctness less important in small scale apps?
- louthy 13y ago
  It's easier to manage and have a mental picture of where something is likely to go wrong on a smaller project. Once your project gets to a certain size then it's nice when the compiler tells you ahead of time that you've screwed up. Because you will screw up.
dragonwriter 13y ago
> Types are generally a hindrance for a small scale app. I don't think that's true. I think that the ritual incantations to the type system required in, particularly, C++/Java-style languages are a hindrances that outweighs the benefits of static typing on very small projects. And the limitations of limited static type systems can also be a hindrance. But when you have a richer type system and/or type inference that reduces the necessary incantation, the size of project on which static typing becomes a net positive drops.