6 ms·

I like to add some more. That's correct that the type system is the crucial attribute as a platform language. But that's not the only reason. It's also for cor

by eonil 13y ago

I like to add some more. That's correct that the type system is the crucial attribute as a platform language. But that's not the only reason. It's also for correctness, safety, productivity and manageability. That's because a platform is huge and complex monster. So all those properties are archive-able only by automated tools, and those tools need rich metadata for each word of code. Type information is crucial metadata, and it's mostly impossible to make high quality tools without those informations. That's why all the designed modern platform (=system) languages are all mostly typed. From C/C++/Objective-C, to Java, C#, Go, Rust, Dart, TypeScript… In fact, it doesn't matter the language actually statically typed, dynamically typed, duck-typed, or completely untyped. The point is an ability to offer accurate metadata for automated tools, and type system is the best ever invented. So languages lacks the ability cannot be a platform's primary language.

nawitus 13y ago
Exactly. I've never understood why someone would prefer a untyped language. It's just a bad developing experience, code needs more debugging, it is harder to maintain and overall productivity is lower. Untyped languages are fine only for small scripting languages.
- vidarh 13y ago
  I doubt you really mean untyped languages. Untyped languages includes many assembly languages, BCPL and some Forths. It does not include typical scripting languages like Perl, Ruby or Python - all of which are strongly typed.
  - chrismonsanto 13y ago
    To be pedantic, assembly languages do generally have multiple types, if by 'type' we mean 'a set of values disjoint from other sets of values'. For example, x86 has the types integer, floating point, MMX, SSE, and registers of these types cannot be confused for each other. It's just that these classifications/types aren't so useful, and we can't make our own (and perhaps all we really wanted was a distinction between integer and pointer)
    - justincormack 13y ago
      Historically they didnt, until hardware floating point wired up some registers to special hardware. Which is why C lets you cast; BCPL just has bit patterns.
  - yason 13y ago
    I don't know about Ruby but Perl certainly isn't strongly typed. You can run 'print "5.0" + 6' and get 11 as the answer. That's weak typing and types are implicitly converted to whatever. Python is strongly typed only for the basic scalar types. With objects and classes there are just objects that may or may not have certain bound functions and attributes. Duck-typing is mostly perfectly sufficient since any errors do come out in practice, and there's no need for interfaces or classes as unique types, but what would be really helpful would be to have Clojure-like multimethods where dispatching of a function is itself a function of the arguments given in. That would be what would most alleviate the problems that arise from everything being a object() in Python.
    - jsmeaton 13y ago
      Sorry, but what are the problems with everything being an object? That's a feature. Python 3.4 now has @singledispatch, though I don't know where I'd use that yet.
    - eonil 13y ago
      Ruby is strongly typed. I am not sure that's static or dynamic, but regardless of how it is implemented, Ruby lacks ability to offer type information to code-writing level toolsets because it doesn't force retaining of type information on field and function parameters. So regardless of whatever actually happens, to the tools, each Ruby function is just all dealing with unknown type parameter objects. As a conclusion, Ruby has type, but has no way to utilize it. I think any other popular scripting language - such as Python, JS, Lua… are in same situation. V8 does speculative strong dynamic typing, but the those generated informations are completely useless to code-writing level tools.
      - jsmeaton 13y ago
        And users of dynamically typed languages will sometimes argue that the need for code generation tools is less necessary. You lose the ability to have tools do a lot of the work, but you also lose the need to have tools do a lot of the work. It's a trade off. Type [an]notations are also useful for compilers when generating performant code. But projects like pypy and V8 (javascript) show that a well written interpreter can do run-time analysis, and generate performant code, just like a static analysis.
  - dasil003 13y ago
    What about javascript?
    - eonil 13y ago
      Javascript is, 1. Dynamically strongly typed, but typing is limited to primitive types. 2. So actually it's untyped for objects which is really needs type information. 3. As it lacks class/interface concept at all, type (an)notation is fundamentally impossible, type tracking is also impossible. 4. So lacks ability to offer type information to toolset. You don't have automated tooling support on Javascript about type, and it will degrade your productivity. So big companies interested on JS platform, are all offering JS with type notation - 1. Google = Dart, 2. MS = TypeScript, 3. Mozilla = Emscripten(in very unique way!)
      - andreasvc 13y ago
        Javascript is typically described as weakly typed; e.g., "2" + 2 is valid Javascript.
  - nawitus 13y ago
    Yeah, sorry, I should've used the term dynamic typing.
    - eliben 13y ago
      http://eli.thegreenplace.net/2006/11/25/a-taxonomy-of-typing-systems/ http://eli.thegreenplace.net/2006/11/25/a-taxonomy-of-typing...
    - eonil 13y ago
      I think you originally intended explicit type notation. I recently discovered actual type doesn't matter that much, and the point is having an interface/protocol which enable compiler validation and tooling support. I learned this truth from Objective-C and Go. That's why I told actual typing system itself not important. Objective-C protocol is nothing about type, but defines nice interface for tooling support. Go interface defines set of promises, so actual object structure doesn't matter. Furthermore, recent languages offer automatic type inference - Haskell, Go, C++11. They force to retain type information, but also permit to elide them where accurately inference-able/deduce-able. This is completely different with not forcing type notion such as Python, Ruby, Lua, JS. In these languages, it is fundamentally impossible to track complete type information. But in explicitly type notated languages, it's possible to track complete type informations even they're elided. I think those type-(notation)-less languages are making some efforts to offer type informations by adding annotations. But I don't think that's really meaningful, because that's not enforced, and community doesn't care much.
- jsmeaton 13y ago
  There's a difference between typed and statically typed. Python is a strongly typed language, but it is dynamic. > bad developing experience, code needs more debugging, it is harder to maintain and overall productivity is lower All of these observations are highly subjective. > Developing experience: I much prefer developing in python than java. If IDEs factor in, there are a number available for python, none of which I use, because I find a simple editor is usually enough. > code needs more debugging That's a function of the problem and the developer. The run, check, edit cycle in python is a lot quicker than using your IDE to run, check, edit, compile. There are debuggers available for nearly every language that allow you to step and inspect. > harder to maintain Disagree. When you have code 1/5th (number pulled from my ass) the size codebase, maintainability can be much better. Unit testing helps, regardless of the language. > productivity A developer proficient in language [X] should be just as productive as a different developer proficient in language [Y]. Creating a massive type hierarchy of classes and interfaces is a tonne of overhead when you are trying to express a simple idea. In a language like python, you might write a simple class (or two), and use dynamic typing appropriately. A java developer may use code generation and IDE shortcuts to lessen the amount of total code they have to write though. The advantages and disadvantages of dynamic and statically typed languages are fairly well known. Neither is perfect all the time and for each person. Just because you don't like dynamic languages, it does not mean they don't have their virtues.
  - msie 13y ago
    Working in C# right now and agonizing over the class hierarchy...
    - jsmeaton 13y ago
      I love C#, but when moving between it and python, I find I focus too much on the types and hierarchies.
      - droidist2 13y ago
        I used to be like this before I realized I used class inheritance way too much and shifted to using composition in the majority of cases.
- _pferreir_ 13y ago
  Are we really going to discuss this again? > code needs more debugging, it is harder to maintain and overall productivity is lower References?
  - _random_ 13y ago
    Isn't it why Python guys are trying to use more annotations? To patch it with some sort of semi-decent static analysis? Check the Dropbox's pain presentation: https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.pptx https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.p...
    - deleted 13y ago
      [deleted]
    - Macha 13y ago
      A small number of Python guys are trying to use more annotations for a sort of closer-to-staticly-typed Python. It's certainly not universal, or even a majority of developers.
  - nawitus 13y ago
    I found one study[1] which concludes that unit tests are not enough to reveal all errors which would be revelead when using a statically typed language. 1. https://docs.google.com/file/d/0B5C1aVVb3qRONVhiNDBiNUw0am8/edit?usp=drive_web&pli=1 https://docs.google.com/file/d/0B5C1aVVb3qRONVhiNDBiNUw0am8/...
- tbarbugli 13y ago
  Thats your opinion dude

by eonil 13y ago

nawitus 13y ago

Exactly. I've never understood why someone would prefer a untyped language. It's just a bad developing experience, code needs more debugging, it is harder to maintain and overall productivity is lower. Untyped languages are fine only for small scripting languages.

vidarh 13y ago
I doubt you really mean untyped languages. Untyped languages includes many assembly languages, BCPL and some Forths. It does not include typical scripting languages like Perl, Ruby or Python - all of which are strongly typed.
- chrismonsanto 13y ago
  To be pedantic, assembly languages do generally have multiple types, if by 'type' we mean 'a set of values disjoint from other sets of values'. For example, x86 has the types integer, floating point, MMX, SSE, and registers of these types cannot be confused for each other. It's just that these classifications/types aren't so useful, and we can't make our own (and perhaps all we really wanted was a distinction between integer and pointer)
  - justincormack 13y ago
    Historically they didnt, until hardware floating point wired up some registers to special hardware. Which is why C lets you cast; BCPL just has bit patterns.
- yason 13y ago
  I don't know about Ruby but Perl certainly isn't strongly typed. You can run 'print "5.0" + 6' and get 11 as the answer. That's weak typing and types are implicitly converted to whatever. Python is strongly typed only for the basic scalar types. With objects and classes there are just objects that may or may not have certain bound functions and attributes. Duck-typing is mostly perfectly sufficient since any errors do come out in practice, and there's no need for interfaces or classes as unique types, but what would be really helpful would be to have Clojure-like multimethods where dispatching of a function is itself a function of the arguments given in. That would be what would most alleviate the problems that arise from everything being a object() in Python.
  - jsmeaton 13y ago
    Sorry, but what are the problems with everything being an object? That's a feature. Python 3.4 now has @singledispatch, though I don't know where I'd use that yet.
  - eonil 13y ago
    Ruby is strongly typed. I am not sure that's static or dynamic, but regardless of how it is implemented, Ruby lacks ability to offer type information to code-writing level toolsets because it doesn't force retaining of type information on field and function parameters. So regardless of whatever actually happens, to the tools, each Ruby function is just all dealing with unknown type parameter objects. As a conclusion, Ruby has type, but has no way to utilize it. I think any other popular scripting language - such as Python, JS, Lua… are in same situation. V8 does speculative strong dynamic typing, but the those generated informations are completely useless to code-writing level tools.
    - jsmeaton 13y ago
      And users of dynamically typed languages will sometimes argue that the need for code generation tools is less necessary. You lose the ability to have tools do a lot of the work, but you also lose the need to have tools do a lot of the work. It's a trade off. Type [an]notations are also useful for compilers when generating performant code. But projects like pypy and V8 (javascript) show that a well written interpreter can do run-time analysis, and generate performant code, just like a static analysis.
- dasil003 13y ago
  What about javascript?
  - eonil 13y ago
    Javascript is, 1. Dynamically strongly typed, but typing is limited to primitive types. 2. So actually it's untyped for objects which is really needs type information. 3. As it lacks class/interface concept at all, type (an)notation is fundamentally impossible, type tracking is also impossible. 4. So lacks ability to offer type information to toolset. You don't have automated tooling support on Javascript about type, and it will degrade your productivity. So big companies interested on JS platform, are all offering JS with type notation - 1. Google = Dart, 2. MS = TypeScript, 3. Mozilla = Emscripten(in very unique way!)
    - andreasvc 13y ago
      Javascript is typically described as weakly typed; e.g., "2" + 2 is valid Javascript.
- nawitus 13y ago
  Yeah, sorry, I should've used the term dynamic typing.
  - eliben 13y ago
    http://eli.thegreenplace.net/2006/11/25/a-taxonomy-of-typing-systems/ http://eli.thegreenplace.net/2006/11/25/a-taxonomy-of-typing...
  - eonil 13y ago
    I think you originally intended explicit type notation. I recently discovered actual type doesn't matter that much, and the point is having an interface/protocol which enable compiler validation and tooling support. I learned this truth from Objective-C and Go. That's why I told actual typing system itself not important. Objective-C protocol is nothing about type, but defines nice interface for tooling support. Go interface defines set of promises, so actual object structure doesn't matter. Furthermore, recent languages offer automatic type inference - Haskell, Go, C++11. They force to retain type information, but also permit to elide them where accurately inference-able/deduce-able. This is completely different with not forcing type notion such as Python, Ruby, Lua, JS. In these languages, it is fundamentally impossible to track complete type information. But in explicitly type notated languages, it's possible to track complete type informations even they're elided. I think those type-(notation)-less languages are making some efforts to offer type informations by adding annotations. But I don't think that's really meaningful, because that's not enforced, and community doesn't care much.
jsmeaton 13y ago
There's a difference between typed and statically typed. Python is a strongly typed language, but it is dynamic. > bad developing experience, code needs more debugging, it is harder to maintain and overall productivity is lower All of these observations are highly subjective. > Developing experience: I much prefer developing in python than java. If IDEs factor in, there are a number available for python, none of which I use, because I find a simple editor is usually enough. > code needs more debugging That's a function of the problem and the developer. The run, check, edit cycle in python is a lot quicker than using your IDE to run, check, edit, compile. There are debuggers available for nearly every language that allow you to step and inspect. > harder to maintain Disagree. When you have code 1/5th (number pulled from my ass) the size codebase, maintainability can be much better. Unit testing helps, regardless of the language. > productivity A developer proficient in language [X] should be just as productive as a different developer proficient in language [Y]. Creating a massive type hierarchy of classes and interfaces is a tonne of overhead when you are trying to express a simple idea. In a language like python, you might write a simple class (or two), and use dynamic typing appropriately. A java developer may use code generation and IDE shortcuts to lessen the amount of total code they have to write though. The advantages and disadvantages of dynamic and statically typed languages are fairly well known. Neither is perfect all the time and for each person. Just because you don't like dynamic languages, it does not mean they don't have their virtues.
- msie 13y ago
  Working in C# right now and agonizing over the class hierarchy...
  - jsmeaton 13y ago
    I love C#, but when moving between it and python, I find I focus too much on the types and hierarchies.
    - droidist2 13y ago
      I used to be like this before I realized I used class inheritance way too much and shifted to using composition in the majority of cases.
_pferreir_ 13y ago
Are we really going to discuss this again? > code needs more debugging, it is harder to maintain and overall productivity is lower References?
- _random_ 13y ago
  Isn't it why Python guys are trying to use more annotations? To patch it with some sort of semi-decent static analysis? Check the Dropbox's pain presentation: https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.pptx https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.p...
  - deleted 13y ago
    [deleted]
  - Macha 13y ago
    A small number of Python guys are trying to use more annotations for a sort of closer-to-staticly-typed Python. It's certainly not universal, or even a majority of developers.
- nawitus 13y ago
  I found one study[1] which concludes that unit tests are not enough to reveal all errors which would be revelead when using a statically typed language. 1. https://docs.google.com/file/d/0B5C1aVVb3qRONVhiNDBiNUw0am8/edit?usp=drive_web&pli=1 https://docs.google.com/file/d/0B5C1aVVb3qRONVhiNDBiNUw0am8/...
tbarbugli 13y ago
Thats your opinion dude