6 ms·
> It’s hard to describe the experience of doing a major refactoring, having a really helpful and friendly compiler guide you along step by step and when finally
by Programmatic 10y ago
> It’s hard to describe the experience of doing a major refactoring, having a really helpful and friendly compiler guide you along step by step and when finally everything compiles it just works.
This is my experience in a nutshell, my "home language" has been Python since high school after trying to learn C/C++ and persisted through learning Java in college. It was easy to use and get started with, and didn't require a ton of extraneous typing in Vim or looking up class types and returns every time you tried to use something.
For simple projects as a beginner dynamic/implicit typing is wonderful because you need fewer references. Having gone the way of the IDE, however, having good autocomplete, safe refactoring, error flagging before compilation/runtime, and an easy reference for your libraries has made me incredibly efficient in explicitly typed languages. I'm not sure how much longer I'll be using Python as my home language...
- mordocai 10y agoTo be fair, at least good autocomplete + easy reference is quite possible in an IDE with dynamic languages. I have it for Common Lisp in emacs for example(it requires running a live repl and having the editor connect to it). Pre compilation errors are harder, and I personally don't feel safe refactoring in any language unless there are good automated tests. Static typing makes it better, but nowhere near full proof.
- Programmatic 10y agoIt is, but it has a lot harder time deciding what type of object I'm working with in a function vs. being able to specify the object's class in the function arguments. You can get that with docstrings but it's not as straightforward as just saying "def frobozinator(FooBar thing):"
- pekk 10y agoEither it's your code, in which case why don't you know what type of object you are passing, or it's a documented part of a framework or something. With polymorphism and inheritance in the mainstream languages, the method signature still doesn't exactly tell you what you are going to get, so you have all of the pain of micromanaging type annotations and you still don't really get an invariant. Also, Python has function annotations if your purpose is to document the signature without using docstrings. I'm unsure why you don't mention these because they are exactly analogous to what you say is straightforward.
- Programmatic 10y agoKnowing in my head and having it tab out are two different things. Interfaces will without a doubt tell you what you can do with a given object. With polymorphism you most assuredly know what types the arguments are inside each signature you write. Function annotations look like shit[0] and are not guaranteed to mean the same thing across projects. Don't get me wrong, I love Python and its idioms and have been using it for a rather long time. It pays the bills and I am productive in it. I just think that I've outgrown its implicit typing when I step into an explicitly typed language using modern tools and enjoy myself. [0]: https://www.python.org/dev/peps/pep-3107/#syntax https://www.python.org/dev/peps/pep-3107/#syntax
- jdmichal 10y ago> With polymorphism and inheritance in the mainstream languages, the method signature still doesn't exactly tell you what you are going to get, so you have all of the pain of micromanaging type annotations and you still don't really get an invariant. This is exactly what is addressed by the Liskov substitution principle [0] -- the "L" in SOLID [1]. If your subtype does not have the same semantics as the type it extends, then it fails this criteria. It is violating the (implicit) contract of the type it is extending. [0] https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle [1] https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 https://en.wikipedia.org/wiki/SOLID_%28object-oriented_desig...
- RodericDay 10y agoWhat do you use now?
- Programmatic 10y agoI haven't yet replaced Python, but I really enjoyed Dart using JetBrains' WebStorm IDE for a side project. Python maps really well to a lot of the problems that I'm tackling right now professionally, but I'm considering trying to use Java for a number of them. C# may wind up being viable for me as well; it has a chance of being a little more cross-platform with Xamarin's purchase by MS and overtures toward OSS and Linux by integrating Ubuntu.
- lmm 10y agoI used to be a huge Python fan until I found Scala. It can be as expressive as Python (slightly more so even), but as safe as Java (again, slightly more so).
- willtim 10y agoUnfortunately Java is far from safe, NullPointerException and ClassCastException abound. Which isn't surprising given that Java was originally inspired by ObjectiveC, a mostly dynamic language. Scala has a sort of ML subset which mostly avoids these errors, but unless you need the JVM, why not try OCaml or Haskell?
- jdmichal 10y agoDefault-nullable types and thereby having to check for null in every non-primitive argument is definitely a thing in Java, but I don't think I've seen a ClassCastException in the wild for a very long time... Generics pretty much solved the problems that led to bad casts, such as a integer sneaking into your list of strings.
- willtim 10y agoYes true, Generics helped a lot (thanks to Odersky and Wadler). But the language does seem to encourage more dynamic frameworks like Spring, that IIRC do perform a lot of casting.
- pekk 10y agoPython is apparently the first language you used in anger and now you want to use other things, but that simply doesn't mean that it is unsuitable for experienced people or complex projects.