8 ms·

A lot of people are making comments about how they can code "faster" without types. But for the majority of the code we write, inital speed isn't that importan

• skohan 6y ago
  > Understanding other people's code is at least half the job of a programmer This was one of the pain-points when I was working more with node.js: the function signature told you nothing - like whether the function would even return or not would sometimes be a mystery. In very, very short scripts you can get away without types (like in a notebook for example), but once a project starts to get even medium size the tiny amount of time you put into writing a type name explicitly here and there is more than made up for by the degree it helps with the structure and correctness of your program.
  • bo1024 6y ago
    This kills me about python. So many times I cannot figure out what exactly a functions expects and what it returns, sometimes even from reading the documentation! Matplotlib is especially bad.
    • arvinsim 6y ago
      Didn't Python 3.5 introduce optional typings?
      • dilawar 6y ago
        Only annotations which can be checked by mypy or other linters. I think cpython doesn't check them at runtime.
        • ben-schaaf 6y ago
          Python indeed doesn't check them. Really they're just syntactic sugar for what you'd otherwise put in documentation.
        • throwaway894345 6y ago
          And mypy is still very immature. You can’t denote a recursive type (e.g., a JSON type) or specify a callback that takes keyword arguments. Even getting it to load type annotations from third party packages is hard in many cases. Worse, it seems to be improving at a snail’s pace if at all.
          • zo1 6y ago
            A "JSON" type in Python is just an untyped dictionary. Is that not what you're looking for? Also, python's type-hinting supports forward-references which are what you would use for recursive or "self-referencing" types. Personally, I like the slow pace they're taking with the typing. It's touching the core usage of the language in a fundamental way and I don't think that can be rushed. We're seeing lots of community growth around the type-hinting, even using them at run-time, which is amazing to watch and marvel at.
            • throwaway894345 6y ago
              Untyped dictionaries are a superset of JSON. JSON is (more or less) precisely: Dict[str, JSON] | List[JSON] | str | float | int | bool | None
      • IshKebab 6y ago
        Yes but hardly any code uses them yet. Hell there's still lots of code on Python 2 (yes really, no I'm not imagining it).
    • throwaway894345 6y ago
      Good grief, matplotlib and the whole scientific computing stack are abysmal. Every function takes dozens of arguments, but any given call only has to pass some subset, and depending on the subset and their runtime types, the function just tries to guess what the caller wanted to do. I get that this stuff was written by amateurs, but in a saner world this stuff would have been addressed by now. Anyway, I moved on from Python to Go and I’m super happy (!!performance!!, !!package management!!, editor tooling, top notch document generation, quality ecosystem, !!static binaries!!, and types—even if Go’s type system isn’t as robust as Rust’s, it still goes a long way).
    • mettamage 6y ago
      I use a Python debugger in VSCode and hit the necessary breakpoints to figure it out. Yes, it's bad, but it works. I hope there are better ways of doing it, but this is my way.
    • 6gvONxR4sf7o 6y ago
      kwargs makes me so angry in docs. Pass in anything! Learn the whole library to use this function!
    • krzat 6y ago
      This is the most ridiculous thing about dynamic languages, I don't understand how people can be productive in such environment. Meanwhile I just press few keys and IDE shows my all about I need to know about that function. Oh, and it also runs 100x faster.
  • GordonS 6y ago
    > the function signature told you nothing - like whether the function would even return or not would sometimes be a mystery Yes! This drives me nuts about JavaScript! Untyped parameters are one thing, but having to read the entire function just to know if it returns anything is ridiculous.
    • eyelidlessness 6y ago
      To be fair, JS’s dynamic types aren’t solely to blame for this. There are dynamically typed languages that don’t require you to read an entire function body to know if it returns something. But, those are languages without statements, and all functions return something.
• thurn 6y ago
  I agree with this for really large codebases, but I think you can get a surprising amount done before your program becomes "non-trivial" using a good dynamic language. For example, the website you are writing this comment on has been perfectly maintainable in lisp without any static typing for the past 15 years.
  • darksaints 6y ago
    It also hasn't changed much in 15 years. Now that could be (and probably is) a deliberate decision. But there are more than enough cases of projects that haven't changed because they can't...they've painted themselves into a corner, and every time they try to change something, something else breaks. I've felt this way with Python and Ruby and Node projects (it is a major complaint in the RoR community), but have never felt that way with Scala, Java, C#, F#, Rust, or OCaml. Most of the time, when I need to make a change, I just change it, iteratively eliminate any type errors, and once the type errors are gone, the tests magically pass too.
  • throwaway894345 6y ago
    I get the feeling that lisp doesn’t produce as many runtime type errors as Python or JS and I’m not really sure why that would be. Maybe there’s something to a functional style of programming that improves quality even apart from type checking?
    • remexre 6y ago
      Arc "feels" a lot more Scheme-like than Common Lisp-like, but pg is a CL guy afaik; my observations on the two: Scheme avoids type errors by writing programs which could be given static types with a sufficiently powerful type-checker. If a Scheme programmer needs to define two aggregates, both of which have a property "name," they're likely to define two different functions, foo-name and bar-name, to get at them. This, though it's noisy, makes type errors more obvious. CLOS helps avoid type errors too, since it encourages thinking not about how code interacts with a single type, but instead how it interacts with a whole _protocol_ of methods. I think multimethods in general are a powerful design tool that help avoid type errors in a dynamic setting, but I haven't had a chance to try them out in a language other than CL. Many CL implementations also have static type-checking. For example, when I try to define a function with a type error in SBCL: * (defun f (x) (+ 1 x (car x))) ; in: DEFUN F ; (CAR X) ; ; caught WARNING: ; Derived type of X is ; (VALUES NUMBER &OPTIONAL), ; conflicting with its asserted type ; LIST. ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 WARNING condition CL's philosophy here differs a bit from most typed languages: SBCL will emit a warning (not an error!) for code it can statically show is impossible to run without getting a type error, while e.g. GHC gives an error for any code it can't statically show doesn't get a type error. However, in my experience, many type errors are obvious enough that SBCL warns about them (e.g. passing a vector where a list was expected, a string where a symbol was expected, nil where a non-nil value was expected, etc.), so this helps quite a bit, especially when combined with the interactive editing one gets through SLIME/slimv. One can also attach type annotations to functions [0], and SBCL (and probably other implementations) will add a runtime CHECK-TYPE [1] unless you tell it to optimize for speed enough. [0]: http://www.lispworks.com/documentation/HyperSpec/Body/d_ftype.htm http://www.lispworks.com/documentation/HyperSpec/Body/d_ftyp... [1]: http://www.lispworks.com/documentation/HyperSpec/Body/m_check_.htm http://www.lispworks.com/documentation/HyperSpec/Body/m_chec...
• cannabis_sam 6y ago
  It’s honestly embarrassing to hear all the worthless arguments against types. The cognitive load of a dynamically typed (or unityped, or “untyped” or whatever) language is massive, yet the common argument is that types «increase» the cognitive load??? How does offloading a large majority of the trivial reasoning of a program over to a type system, ”INCREASE” the cognitive load??? It’s just so endlessly easier to program with types
  • marktangotango 6y ago
    I agree with this 1000%. Projects (note not programs or individual source files!) are simply easier to grok (maintain, enhance, debug, refactor) with statically (and strongly) typed languages than dynamic IMO. Five years ago when switching jobs I’d pursue “full stack” positions because I’d done a fair amount of front end dev in the past. No more, me personally, I’m backend all the way. Dynamic typing (vanilla js) is just harder; more time consuming more cognitive load, IMO.
    • lolinder 6y ago
      It's not perfect, but TypeScript goes a long way toward making frontend feel as safe as backend. You still have the potential for weird bugs when interacting with external JavaScript, but your internal code is pretty safe. Also, TypeScript's type system is impressively flexible, and I often find myself missing features (like unions) when working with other languages.
      • MiroF 6y ago
        > missing features (like unions) when working with other languages. Which languages are missing unions? Off the top of my head, they exist in C/C++ and mypy python.
        • a_humean 6y ago
          Typescript allows you to have literal type discriminators in their unions, which combined with control flow based type narrowing of unions effectively gives you sum types. That is what he is talking about, because most mainstream langauges don't have sum types and you need to go to strongly typed functional langauges (haskell, scala, etc...) or modern strongly typed langauges such as Rust to get access to such features.
• agumonkey 6y ago
  Warning this is in 2008 context: Types are cool but when I worked on eclipse apis (plugins) god forbid they were utterly useless. Design matter, having 32 intermediate classes to do just anything, 12 of which are totally unrelated and suddenly types don't help you much. Also it was full of Option types disguised as potentially empty arrays. I guess today things are better.
• csb6 6y ago
  I have had similar experiences with Python. What endlessly frustrated me when looking up the documentation for Python’s standard library (I was using the classes for working with emails/imap) was that what kind of thing to pass in as arguments wasn’t specified clearly. It made using the API so much harder because I had to trial/error to figure out how to construct the proper object that the API would accept.
• joe_the_user 6y ago
  For many enterprises, getting code out the door is a key win. So in an idealist conception, maintainability, correctness and good design are everything. In the practical reality of today, these often have to take a back seat to speed of implementation. What I'd like to see is a language that allows typeless programming to start but which is designed to allow the imposition of types at a later point.
  • easton 6y ago
    Python’s type hinting is specifically designed for this use case: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html Also, TypeScript is designed to work the same way, as it can coexist with untyped JavaScript code as you introduce it to the code base (it still has to run through a compiler, of course).
• throwaway316943 6y ago
  The reason people argue for being able to write and run code quickly is it helps with prototyping and iterating on a concept. For a lot of people, overly verbose typed languages kill that creative cycle. Type systems are great for data validation and self documenting code when you need those things but they essentially double the work when you’re first getting something off the ground.
• higerordermap 6y ago
  Also these days types are important for good IDE completion support, on-the-fly error checking and refactoring.