5 ms·

Yes! I love that quote - so true. Linus has the same opinion: "Bad programmers worry about the code. Good programmers worry about data structures and their rel

• AceJohnny2 12y ago
  > not easily being able to see the types of the arguments to a function in Python. [2] That's because of Duck Typing [1]. I really like Python for how quick and easy it is to make small pieces of software, but I fully agree that Duck Typing can become more of a hindrance on larger projects. [1] http://en.wikipedia.org/wiki/Duck_typing http://en.wikipedia.org/wiki/Duck_typing
  • MichaelGG 12y ago
    Nothing about duck typing requires a python-like type system. F# has duck typing via inlining (hacky sorta), C# has it too, but only for compiler use, not end user code (because why build generic features, when you can hack one-offs into the compiler). It'd be great to have more static duck typing. I suppose that's the point of traits and mixins, to some extent. But it'd be nice to have on-the-fly constraints created and enforced.
    • CountSessine 12y ago
      I thought that F# used type-inferencing? If not, then its not nearly as similar to Haskell and OCaml as I've been led to believe. Unless you're referring to type-inferencing when you use the term static duck-typing. The term duck-typing was never meant to refer to type-inferencing - duck-typing is type-opacity right into the runtime. The whole point of duck-typing is that objects can be referred to generically even in cases where their underlying type would be undecidable. Type-inferencing gives you some of the source-level flexibility of not having to refer directly to an object's type much like duck-typing, but without many of the crazy runtime disasters that you can get with duck-typing.
      • Nevor 12y ago
        Parent comment is referencing the "let inline" construction that in addition to inline code allows to constrain generic types structurally over member definition[1] instead of by name as usual. This gives us poor's man type classes which is useful nonetheless. I guess the conclusion is that the definition of duck typing is fuzzy and misleading. [1] https://msdn.microsoft.com/en-us/library/dd548046.aspx https://msdn.microsoft.com/en-us/library/dd548046.aspx
    • rjbwork 12y ago
      C# Actually does have duck typing via the DLR (Dynamic Language Runtime) now. You can totally define a method as public dynamic DoDynamicStuff(dynamic wooDynamix) { Console.WriteLine(wooDynamix.DynamicProperty1); }
      • MichaelGG 12y ago
        Right but it doesn't have the static kind the compiler uses for foreach loops or dictionary initializers.
• squeaky-clean 12y ago
  Off topic from the article, but this is something I literally just spent my morning wrestling with and fixing, so I'd like to talk/rant about it a little. My apologies in advance for rambling. You can use doc comments to signify types. You mention you use PyCharm in your article, and it supports doc comments in it's autocomplete and code analysis, I find most popular libraries are commented well enough that PyCharm can understand them. I also always try (and encourage others) to use names that are declarative for both purpose and type. Of course, you can't always rely on third party libraries (or even colleagues) to be so nice, but I find a good name (almost) always removes all the confusion that normally comes from a lack of static typing. For example, one of Codecademy's very first Python lessons includes some code like this: meal = 44.50 tax = 0.0675 tip = 0.15 Which I think is unclear. Imagine these were function arguments. calc_total(meal, tax, tip) is vague. Is meal an object, or a numeric value? (I could possibly see it containing a list of all items in the meal with prices). Tax is almost always a percentage, but what about tip? Judging by the the above values, we can assume a 15% tip, but we don't know if the customer was stingy and tipped $0.15, and by just name alone, we can't tell at all. calc_total(meal_cost, tax_percent, tip_percent) It's now immediately clear to me the type and range of values it accepts. The tip_percent is also an example of when a good name can provide info that even static typing could not, because in either case it is a floating point (please let's not get into a debate about Decimal or currency types :P ). This is a very basic example, but it applies at all levels. Don't call the parameter "users" if the function is not expecting an iterable of User objects. Maybe "usernames" would be better. Etc. But of course, this only helps if the code you're working with is named well. In something like Java, you have better protection and tools when working alongside lower quality code. I also completely agree with you on point #2 about No Static Types. Navigating through my editor is so much easier in a static language than it is in PyCharm with large projects. And the most annoying thing is that autocomplete breaks with ORMs, and most ORM usage is actually flagged as a warning or error. Ugh. I also feel very confident in the automated refactoring in something such as an IntelliJ Java project, or ReSharper, but am apprehensive about using PyCharm to refactor anything with usages spanning more than one file. Same goes for Javascript (or any other dynamic language, I suppose. Those are just the two I use). Enjoyed the posts by the way, adding your blog to my reading list.
  • 12y ago