5 ms·

A couple decades ago everyone was on static types. But then people got sick of the boilerplate, and in what I think was a backlash, dynamic languages like JavaS

• agumonkey 5y ago
  What you see as innovation is just slow diffusion into mainstream, the last decade is basically 80s sml family. The funny .. or sad.. part is that the c#9 explicit ~verbose style would have been the only one accepted before. If you wrote implicitely typed variables people would get angry (I think there are many online articles about how java 9 `var` was bad)
  • brundolf 5y ago
    > What you see as innovation is just slow diffusion into mainstream It can be both. Type inference isn't a brand-new idea, but it still takes work to diffuse it into mainstream, practical languages, especially retrofitting it onto existing languages that weren't designed for it. That still counts as innovation in my book.
    • agumonkey 5y ago
      Yeah fair point. I'm just a bit salty that a lot of people only see the late stage effect onto their language and might assume that it came out of a vacuum you know. Then they look at you weird with your scheme, sml and prologs. Alas
• spaetzleesser 5y ago
  I love type inference. Strong typing makes maintenance and refactoring much easier and with type inference the code looks very good. I still remember how ugly and tedious STL iterators were in C++. Now it’s just “auto”. LINQ also wouldn’t work without type inference.
• marcodiego 5y ago
  Some form of type inference was proposed for C: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2735.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2735.pdf
• fendy3002 5y ago
  Exactly my experience. Coming from C# around year 2014s to php then nodejs (due to company setup), typescript is the best of both worlds. Won't be back to static typing for a while unless I'll need higher precision and higher reliability module.
  • dgellow 5y ago
    Damn, I’m missing Union Types in C# so much! Typescript make it so simple to compose types.
    • fendy3002 5y ago
      Indeed. Union, intersection types are godsend. Furthermore arguments don't need to be class instances / explicit type, object with fulfilled properties are enough. It's much much easier to work especially during templating / developing engine.
• 5e92cb50239222b 5y ago
  Static type systems with global type inference haven't had this problem since the beginning (for example OCaml, right around the time Java came out). However, for some obscure reasons the shittier the technology, the more chances it has at becoming popular. Try Elm as a simple example (can be done in a weekend), it'll probably blow your mind. You don't have to write type annotations at all, but the compiler complains at build time if the same function is called with two different types in two places.
  • thomasz 5y ago
    Local inference is a gift sent from heaven, global inference not so much. Reading OCAML (and F#) is exhausting because you have to look into the implementation of each function (or into a separate interface file) to figure out how it's supposed to be called and what it is going to return.
    • pharmakom 5y ago
      My IDE puts annotations on every function and I can hover over values. Typing them out seems pointless with the right tooling.
      • ahartmetz 5y ago
        You can hover one thing at a time, you can skim a page with your eyes very quickly. Making important information cumbersome to access is a terrible idea.
    • TheMatten 5y ago
      One could argue that this is better covered by IDE/tooling showing you inferred types / suggestions.
      • lamontcg 5y ago
        If the function is printed in a journal article, or you just use something like 'less' to look at the file all that information is not available. I find it kind of weird that we've normalized not being able to read the code outside of the proper program for it. Since those IDEs often cost money it starts to feel a bit like steps towards a walled garden to me, and I'm not sure its good for actual computer science.
• DeathArrow 5y ago
  C# has type inference since a very long time ago.
• quickthrower2 5y ago
  Haskell has been quietly doing this since the 90s though. I guess being a research-first language it isn’t held back by trying to have mass appeal (eg to be C-like to be familiar)
  • vicda 5y ago
    Haskell is held back by pushing category theory into their tutorials. Want to do IO? Great, first learn about monads.
    • kqr 5y ago
      That's not true and never has been. Want to do I/O? main = do putStrLn "Who are you?" name <- readLn putStrLn ("Hello, " ++ name) There. Do you really need to know something about monads to understand that example? No. Do you need to know how do syntax and the assignment operator <- works? Sure. But that has nothing to do with category theory. That's just syntax.
      • d3nj4l 5y ago
        Cunningham's law in action, everyone!
      • quickthrower2 5y ago
        To be fair, once you get a compiler error you’ll at least need to know: a. do notation is converted to haskell b. what the bind and return functions do, for IO So you can figure out; c. Why your types are not lining up To understand Haskell in general you need to realise do, bind and return are generic and can be used for not just IO but say for Maybe, List etc. Basically you need to know most practical things about monads! I had a bad time writing Haskell do notation until I understood monads. I used to write imperative code, try =, try <-, always undo typing back to known working states etc. to try and magic the code into compiling.
        • kqr 5y ago
          That's a good point. It was long enough since I learned this stuff that I mentally translate "Monad m => m a" into "IO String" for example in type errors, to the point of not even noticing how cryptic the generic types can be!