Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't let dicts spoil your code

roman.pt

Post reply on HN
Print view View original

81–90 of 121 posts

Re: Don't let dicts spoil your code

#81

Post by pistoleer »

dwattttt wrote: post #52
pistoleer wrote: post #44

Earlier quoted context omitted.

You would still have to update everything if you rename a field in a struct, what do you mean you never have to worry?

If you use type checking, the breakage occurs when you introduce the change: the author of the change is the one who can figure out what it means if 'foo' is no longer being passed into this function. If you're duck typing, you find this out in the best case when your unit tests exercise it, and in the worst case by a support call when that 1/1000 error handling path finally gets exercised in production.

I agree with that, in the context of dynamically typed languages.

Slowly but surely, new languages are starting to develop with static duck typing. Implicit interfaces if you will.

Re: Don't let dicts spoil your code

#82

Post by consp »

jrjrjrjrj wrote: post #65
jmorenoamor wrote: post #64

Earlier quoted context omitted.

Dynamic languages demand self discipline, they teach you to respect runtime and think ahead of execution time. I've written software with both typed and untyped languages and never had problems (out of the ususal) with them.

I would argue that dynamic languages make a compile time problem a run time problem... So yeah that small not hit portion of code can always be a time bomb if it does not get tested...

> So yeah that small not hit portion of code can always be a time bomb if it does not get tested...

That has nothing to do with the language, and can happen in any language.

Re: Don't let dicts spoil your code

#83

Post by Kinrany »

cardanome wrote: post #17

This is absolute key advice. Another way to look at it is the functional core, imperative shell pattern. Wrapping up your dict in a value object (dataclass or whatever that is in you language) early on means you handle the ugly stuff first. Parse don't validate. Resist the temptation of optional fields. Is there really anything you can do if the field is null? No, then don't make it optional. Let it crash early on. C…

There's little to disagree with here, and yet this comment reads like a slogan soup.

Re: Don't let dicts spoil your code

#84

Post by scotty79 »

> Ignore fields coming from the API if you don’t need them. Keep only those that you use.

This is great if you know what you need from the start. If you only find out what you need after passing your data through multiple layers and modules of your system then you need to backtrack through all your code to the place of creation.

If you have immutable data structures then you have to backtrack through multiple places where your data is used from previous structures to create new ones to pass your additional data through all that.

So if your data travels through let's say 3 immutable types to reach the place you are working on then even if you know exactly where the new field that you need originates, you need to alter 3 types and 3 places where data is read from one type and crammed into another.

If you have a dict that you fill with all you got from the api there's zero work involved with getting the new piece of information that you thought you didn't need but you actually do. It's just there.

Re: Don't let dicts spoil your code

#85

Post by mcdeltat »

cardanome wrote: post #17

This is absolute key advice. Another way to look at it is the functional core, imperative shell pattern. Wrapping up your dict in a value object (dataclass or whatever that is in you language) early on means you handle the ugly stuff first. Parse don't validate. Resist the temptation of optional fields. Is there really anything you can do if the field is null? No, then don't make it optional. Let it crash early on. C…

The "loosey-goosey" approach to data in coding is one of my biggest pet peeves. Some people absolutely insist on making everything as dynamic as possible, and then wonder why we end up with a buggy mess. I always found it very natural to move as much as possible into the type system, because why wouldn't I want the machine to find all my inevitable mistakes for me?

Re: Don't let dicts spoil your code

#86

Post by scotty79 »

bloppe wrote: post #61
ungamedplayer wrote: post #51

Can someone educate me in why dicts are uncool for explained reasons, but clojure (which seems to be highly recommended on hn) seems to suffer the same issues when dealing with a map as a parameter (ring request etc). I know how to deal with missing values or variability in maps, and so do a lot of people.. what am I missing here?

Dicts are great when the data is uniform and dynamic, like an address book mapping names to contact info. You never assume that a key must be in there. Lookups can always fail. That's normal for this kind of use-case. When the data is not uniform (different keys point to differently-typed values), and not as dynamic (maybe your data model evolves over time, but certain functions always expect certain keys to be prese…

I think the problem is that different data containers have completely different interfaces.

If getting a filed of your object had the same syntax as getting a value from a dict you could easily replace dicts with smarter, more rigid types at any point.

My dream is a language that has the containers share as much interface as possible so you can easily swap them out according to your needs without changing most of the code that refers to them. Like easily swap dict for BTreeMap or Redis.

I think the closest is Scala but it fallen out of favor before I had a chance to know it.

Re: Don't let dicts spoil your code

#87

Post by kabes »

ktosobcy wrote: post #78
Jean-Papoulos wrote: post #56

>"unstructured data is problematic" >"solution : use dataclasses" Damn, it's almost like using an untyped language for large projects is not a great idea.

And yet we are overwhelmed by javascript nonsense... I get it - it's so easy to get up to speed with tiny snippets but it quickly becomes hot mess. Yes, decades ago I was also fascinated by python and it's ease of doing stuff (compiler doesn't complain that I missed something) but with time I grew fond of statically typed languages... they simply catch swaths of errors earlier...

Are we still overwhelmed by js? I almost only see TS code these days.

Re: Don't let dicts spoil your code

#88

Post by [deleted] »

mcdeltat wrote: post #85
cardanome wrote: post #17

This is absolute key advice. Another way to look at it is the functional core, imperative shell pattern. Wrapping up your dict in a value object (dataclass or whatever that is in you language) early on means you handle the ugly stuff first. Parse don't validate. Resist the temptation of optional fields. Is there really anything you can do if the field is null? No, then don't make it optional. Let it crash early on. C…

The "loosey-goosey" approach to data in coding is one of my biggest pet peeves. Some people absolutely insist on making everything as dynamic as possible, and then wonder why we end up with a buggy mess. I always found it very natural to move as much as possible into the type system, because why wouldn't I want the machine to find all my inevitable mistakes for me?

[deleted]

Re: Don't let dicts spoil your code

#90

Post by Attummm »

Python has made its rise as an antithesis to Java thinking. Classes used to be seen by some in the community as an anti-pattern. [0] The coding style used to focus on "Pythonic-ness," which meant using Python's expressiveness to write code in such a way that type information could be inferred without explicitly stating the type.

Most developers will carry their previous language paradigms into their new ones. But if types, DDD (Domain-Driven Design), and classes are what you're looking for, then Python isn't the best fit. Python doesn't have compiler features that work well with those paradigms, such as dead code removal/tree shaking. However, starting out with dictionaries and then moving over to dataclasses is a great strategy.[1] As a small note, it's kind of ironic that the statically typed language Go took inferred typing with their := operator, while there is now a movement in Python to write foo: str = "bar".

[0] https://youtu.be/o9pEzgHorH0?si=pv0QQyM-iBrHuXUN

[1] https://docs.python.org/3/library/dataclasses.html

Post reply on HN