Hacker News Reader

Comment by mandevil | Hacker News Reader

Not the writer, but based on what the author wrote, I think it's based on the author's experience with Java. It can be a hideous nightmare of java.util.Date versus java.sql.Date versus java.time.LocalDate (just to pick one very well known fiasco in the language- Java defenders please don't come after me) and all of them have to exist to avoid breaking things but you have to have different ways to handle each of them, so dealing at the boundaries between business logic and "infrastructure" is always a mess of converting types- oh this library is old enough that it needs a utilDate, so I need to convert it back down, then convert it back up at every boundary.

By contrast, duck-typing means that the intricacies of which exact type you are deserializing into is a lot less important in python.

View on HN

> By contrast, duck-typing means that the intricacies of which exact type you are deserializing into is a lot less important in python.

How do you explain the popularity of type hinting in Python then? Type hinting arose _because_ duck typing is horrible for large systems.

Not the OP but I explain it as former Java/C# programmers coming to Python for one reason or another.

I’ve come to Python 20 years ago after a short stint with PHP and I don’t really care if the incoming stuff I have to handle is a list or a tuple (let’s say) as long as it quacks and walks like the proverbial duck.

More generally, you could say Python the original language is the victim of its own success (the same goes for JavaScript in relation to TypeSctipt).

Well, the article is the author's attempt to answer that question. I'm not sure that it's convincing to me, but then again I have a preference for strongly-typed languages so I'm probably not the correct audience. I'm just trying to help someone else understand the author's argument, as I understand it.

Might not be the best example since Python made quite a mess of dates and date times (in fairness, like most languages), and duck typing didn't help at all.

No. The people make the mess. For persistence, only UTC without timezone makes sense. For UI, with few exceptions, only local time without time zone in ISO 8601 makes sense.

The only not so easy decision is: is it better to store as Unix epoch or as ISO string. That is a tradeoff between compactness and easy searching of date/time ranges.

Duck Typing always struck me as utterly absurd wishful thinking. Two different types built for the same task will almost certainly not happen to be API compatible.

Am I missing something?

There are cases where it can be useful. One thing that comes to mind is numerical code, where your algorithms are generic over things that have *,/,+,-,==,!=, conversion from 0 or 1 [or some subset thereof] do the "right thing". Trying to define proper interface types for what constitutes the "right thing" is somewhat tedious without much relative gain.

Yes, interfaces aren't just bags of data and methods. They have semantic meaning, too. An Employee, a Gun, and a ClayPot might all have a method named `fire()`, but they all mean different things. With structural typing, we can load our Employees into a Kiln and give HR a Gun to downsize the company, and nothing will stop us.

Its worked for us when dealing with local operations vs. cloud bucket operations. Protocols also help when you really don’t care to litter your code with some vendor specific object but instead just declare what functionality should be expected from the object passed in. It helps describe what you’re doing with it anyway, it’s why typing with Iterable can be helpful if you don’t care if it’s a list, set, or tuple.

I have bounced back and forth between typed and untyped languages in my two decades of employment history, and I prefer typed languages myself, even when I've been writing libraries nested deep in what I think the author would describe as the "infrastructure layer," but this is what I believe the original author of the linked piece is arguing.

No, in my experience you are trading off ease of coding for order of magnitude more production bugs.

So you do not write tests?

I absolutely do, and one of those effective tests is a simple type annotation.

In sequences, even just too calls like "more?" and "next" will let you entertain all kinds of strict and lazy possibilities.

Reply on news.ycombinator.com