10 ms·
I think dynamic typing proponents get hung up on the auto-complete aspect. The real benefit is when you find someone writing a property with a common-ish name t
by Eridrus 9y ago
I think dynamic typing proponents get hung up on the auto-complete aspect. The real benefit is when you find someone writing a property with a common-ish name to a data structure and you want to know "who the hell uses this", you can answer that question pretty easy in statically typed languages. In dynamically typed languages you kind of just grep and hope the name is not too common.
- Eire_Banshee 9y agoThis. Not just, "who the hell uses this", but "where the hell is this defined" as well.
- flavio81 9y ago>Not just, "who the hell uses this", but "where the hell is this defined" as well. On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition. So this isn't exclusive to statically typed languages.
- Eire_Banshee 9y agoLets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp. We are talking about JS and Python almost exclusively.
- amirouche 9y agoPython has jump to definition too.
- adamnemecek 9y agoYou mean there’s an ide with that feature? It’s never as good as with any statically type language.
- catnaroek 9y agoDoes it work in the presence and (ab)use of dynamic features? (e.g., when you have lots of decorated functions) Or is it just a best effort thing? (i.e., only works when your code would actually be expressible in a static way)
- fulafel 9y agoThis is a continuum... in many statically typed languages there are regularly used paths that lead outside the realm of the language-defined type system as well. Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc.
- catnaroek 9y ago> This is a continuum. It is not. A language feature is either amenable to static analysis (not necessarily type checking) or it is not. > Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc. This actually emphasizes my point. Features that are not amenable to static analysis are problematic for tooling.
- pvorb 9y agoIntelliJ/WebStorm is also pretty good at this (with JavaScript at least) by indexing a whole project and its dependencies. Refactoring doesn't work that well, though.
- fulafel 9y agoThere have been references to Clojure, Elixir, Smalltalk, Common Lisp in the comments here, what makes you think just Javascript & Python?
- yellowapple 9y agoIt's worth noting that Elixir (by descent from Erlang) can emulate at least a basic static typing system pretty easily through pattern matching. You miss out on some features common in more traditionally-object-oriented languages (namely: subtypes), but tagged tuples and structs do provide a lot of the same safety benefits in runtime (and tools like Dialyzer can - last I check - use such pattern matching as a basis for static verification).
- nv-vn 9y agoElixir and Erlang still lack the ability to typecheck any process behaviors because messages can take any type anywhere.
- yellowapple 9y agoYou can still pattern match when receiving, though (in fact, 'receive' in both Erlang and Elixir does pattern matching already in the same vein as 'case'); just match messages based on a tagged tuple or a record (Erlang) / struct (Elixir) signature or however else you want to define your "types".
- flavio81 9y ago>Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp. How can it be a niche language, if it's an ANSI standard, has more than 8 or 10 fully feature, standard-conformant implementations, runs on most CPU types, and has been proven to work in production systems for spaceship guiding, worldwide airfare reservation and credit card transaction verification? You use Js and Python because you choose to use it, but it's not the only choice. Not only Common Lisp, you could also be working in Clojure with many benefits.
- hellofunk 9y agoWhy would you say that? There are far more dynamically typed languages in widespread use than those 2!
- deleted 9y ago[deleted]
- KMag 9y agoBut if the compiler doesn't enforce that types are statically determinable, there will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language. Maybe good tools are able to perform some static analysis and rule out some of the methods with the same name but impossible types, but the language doesn't rule out situations where the best the tool will be able to do is show you all of the function definitions with the same name as the (dynamically dispatched) function call site you're looking at. Let's say you have seven different type hierarchies having dynamically dispatched functions named "run", with 5 definitions in each hierarchy, for a total of 35 functions named "run". In a statically typed language, if the code compiles, it's possible to narrow down the type for a given call site to either one of the hierarchies or one definition, meaning you have to look at either 1 or 5 definitions. In a dynamically typed language, there are situations where legal code results in the tool having to throw up its hands and show you all 35 definitions. The flip side is that if you really have a spot where you'll need to dispatch to any of the different hierarchies, then in a strong statically typed language, you'll need to either create an algebraic sum type covering all 7 hierarchies, or you'll need something like a typecase / typeswitch statement to enumerate out your possibilities.
- ubernostrum 9y agothere will be cases where the tool will have to show you more potential definitions for function definitions than would be shown for a statically typed language. And even in a statically-typed language there will be cases where the tooling can only determine fairly generic things statically. I don't see anyone advocating for abandoning static typing over that occasional limitation. Yet I do see people proposing similarly-infrequent issues as cause to abandon dynamic typing.
- jaggederest 9y agoWhen $problem happens to $language_I_prefer, it's an unavoidable difficulty that is easy to work around. When $problem happens in $language_I_dislike, it's a clear sign that the language itself is inherently broken.
- caseymarquis 9y agoI had to do a decent amount of setup and wrote a quick script to run the tools which generate ctags to make this happen in CL using slimv. With top tier ides for static languages, this is built in from day 1 with no effort. You can't not have it. That said, a top tier repl for development is missing in languages like C#. I'd love to see that gap bridged.
- dvlsg 9y agoYou can even do this with Javascript, too. And without doc types. At least in vscode, anyways. Well, usually. It gets a little confused when you start using dependency injection containers, or dynamic requires, or anything like that.
- Eridrus 9y agoI think it's telling that while there are Lisp aficionados in this thread telling us how great it is, none of these ideas have been implemented in Python or JavaScript or Ruby, the most common dynamically typed languages. And that's really all I care about, I'm not about to start writing production code in Lisp.
- fulafel 9y agoThe module system makes it very easy to find definitions, because one namespace = one source file. And the other way around: Statically typed languages without module systems, such as C, exhibit this problem too.
- icebraining 9y agoPyCharm gets it right 99% of the time. That 1% is hardly worth switching the a different language.
- kodablah 9y agoIME, add that 1% to another "1% isn't worth switching" argument with some other Python deficiency and then to another and so on, and reasonable case for choosing other languages can be made. I'm not saying Python should be abandoned for all projects, but we should be careful with "but if we make everyone use this one tool, and this one tool does it right almost all of the time, so we're good" arguments.
- icebraining 9y agoI'm reading Type-Driven Development with Idris right now exactly because I don't think Python is always the correct choice. I just don't find slight improvements in IDE features to be relevant.
- sidlls 9y agoWhat about the time accounted for in each of those buckets? If "that 1%" accounts for more than 1% of debugging, error chasing, and related time it starts to look more important, yes?
- deleted 9y ago[deleted]
- Peaker 9y agoFor someone paranoid about correctness, that's 1% of lingering doubt about every single operation in the IDE. The 99% stat is quite likely a big exaggeration. Refactoring is far far harder to do reliably, and more straining as so much more responsibility on the programmer.
- dkersten 9y agoFor me, what I miss when using dynamic languages is good, solid refactoring tools that can inline functions/methods, rename across source files, etc. In my experience, in both Python and Clojure, the refactoring tools simply don't come close to those of languages like C++, C# and Java. And I say this as a major Clojure fanboy...
- joncampbelldev 9y agoNamespaced keywords can really help with refactoring your domain model. Usually I use normal keywords for throwaway or glue code, but anything important (my actual domain entities) will be namespaced, allowing (relatively) pain free refactoring. Cursive has a few good refactoring tools/shortcuts, but I would also like to see extract/inline/move for functions.
- dkersten 9y agoI'm not saying that I don't have facilities or tools (clj-refactor) to do refactoring, just that they are, in my opinion and experience, not as good or full featured as in the mainstream static languages (and this experience seems to translate between other dynamic languages, eg, Python: I have refactoring tools, but they're not as good as what I can do in, say, Java). Its not a huge problem, just something I miss from the static languages.
- mozey 9y agoAnd "what the hell is this?" when you see a data structure called "options"
- sly010 9y agoAnd "why? oh, why?" when that data structure is unvalidated json and the only way to enumerate all options is to read all the code
- geofft 9y agoWhat are your favorite tools for doing this in C/C++ (which are extremely statically typed, if not very strongly typed)? I think the best thing I've found for this personally is coccigrep, which works but I've only used it a couple of times. I'd like something I'd reach for about as often as I reach for grep. (Also I think these days you'd want it to be based on clang or something.) One thing that does seem to be true is that the requirement to name types means that a textual grep is way more reliable than it is in C. If I want to find all places where a Python class is used in a large codebase, I might as well give up.
- bpicolo 9y agoI imagine CLion is a popular answer here: https://www.jetbrains.com/clion/ https://www.jetbrains.com/clion/
- geofft 9y agoOooh, I've heard of people using it but for some reason I just thought it was an editor. I'll have to give it a try.
- stagger87 9y agoQtCreator
- jcelerier 9y agoHere are the refactorings available : http://doc.qt.io/qtcreator/creator-editor-refactoring.html http://doc.qt.io/qtcreator/creator-editor-refactoring.html Also they are backed by Clang and muuuuuuuuuuuch faster than in Visual Studio + whatever paid extension A very nice feature it has and that I didn't see elsewhere is the optional case-sensitive renaming. eg renaming Foo to Bar will also change foo to bar and FoO to BaR.
- deleted 9y ago[deleted]
- Ace17 9y agoActually, refactoring browsers were pioneered by Smalltalk people.
- imtringued 9y agoI don't understand this argument. In smalltalk the parameter names are part of the function name to reduce the likelyhood of name clashes. You still have the same problem when you have two functions with the same name and parameters.
- josephv 9y agoYou understand, someone will always claim that everything was invented by smalltalk at some point.
- hinkley 9y agoAnd smalltalk had to leave trampolines in place to deal with renames that it couldn't finish deterministically. No thank you. Nobody ever talks about that little horror when they bring up how Smalltalk could to refactoring JUST FINE without static types. It wasn't just fine, turns out.
- gopalv 9y ago> In dynamically typed languages you kind of just grep and hope the name is not too common. For four days, I spent debugging a python production script because in one place I had typo'd ".recived=true" on an object and just couldn't understand why my state machine wouldn't work. And very quickly, the whole team became fans of __slots__ in Python. I still write 90% of my useful code in python, but that one week of debugging was exhausting & basically wouldn't have even compiled in a statically declared language. Even in python, the error is at runtime, after I got the __slots__ in place.
- y4mi 9y ago> I still write 90% of my useful code in python, but that one week of debugging was exhausting & basically wouldn't have even compiled in a statically declared language.[...] nothing stops you from using static typing with python3
- nightski 9y agoI haven't used optional typing in python. However, the problem I see with optional typing is that while I may choose to use it my team mates might not. Even more importantly, the 3rd party dependencies I use probably don't. So the amount of code that actually uses the types would be very limiting. Saying the choice is entirely up to you personally is a misnomer.
- gipp 9y agoStrict use of type annotations has to be a team decision, yes. Checking for them can be integrated into a CI build, though. The typing spec provides for supplementary "stub files" that can be provided for third-party dependencies without their own annotations. The typeshed project provides these for a fair and quickly increasing number of common dependencies, and is plugged into pycharm and mypy by default: https://github.com/python/typeshed https://github.com/python/typeshed
- yawaramin 9y agoI think GP meant 'you' as in 'your team'. Anyway, Python has a type repository for popular libraries, just like TypeScript does. And mypy can still typecheck your code even without type annotations.
- hinkley 9y agoI work with an in-house framework written in Javascript. You would think by looking at the code that the creators had a 30 word vocabulary, because 80% of the code uses the same six nouns and four verbs to pass data around and what you use those for depends on the context of who is calling it. Oh, but the entire thing is written using promises, so most of your function calls have no context. It's hell, and I'm starting to worry that Node has dug itself a reputation hole it will never get out of.
- flavio81 9y agoI can feel your pain, but note that this isn't a fault of dynamic typing per se. This is bad coding (for example, no good use of modules) plus the problem of Javascript itself having many issues; not to mention the wildly different levels of quality within the JS library ecosystem.
- Eridrus 9y agoI don't think Node is doomed; Typescript + async/await makes code make sense.