4 ms·
I read the first example of Lily on the site. I found nothing offensive in the language at all - in fact there's a lot to like particularly the readability. S
by derriz 8y ago
I read the first example of Lily on the site. I found nothing offensive in the language at all - in fact there's a lot to like particularly the readability.
Side rant. Unfortunate I can't get past the decision to use exception handling to deal with non-existing keys in map. I'm of the exception-disliking school which is thankfully growing but I guess not yet universal. For me
using an exception to indicate the lack of a value corresponding to a key in a map (is it really exceptional for this to happen?) is a textbook example of exception-abuse where the code is obfuscated by the non-locality of the control flow.
- enitihas 8y agoWell, for good or for bad, python does the same.
- bpicolo 8y agoTo be fair, there's utility to avoid it: check first or do a .get(). That helps you be expressive about what you think should/should not exist
- p1necone 8y agoI can definitely see the use in that. In some situations a given key not being present would actually be exceptional.
- cpeterso 8y agoYou can use dict's get() method to get back a None for missing keys instead of throwing a KeyError exception. That avoids the overhead of checking `if key in dict` or catching KeyError.
- wool_gather 8y agoAnother option, it's very easy to wrap a dict in a defaultdict: class optionaldict(defaultdict): """ A defaultdict that disregards KeyErrors and returns None for missing keys. """ def __init__(self, *original, **kwargs): super().__init__(lambda: None, *original, **kwargs)
- deleted 8y ago[deleted]
- ummonk 8y agoSeems particularly weird given that it has "Algebraic data types (with Option and Result predefined)."
- staticassertion 8y agoRust makes a similar decision, despite having Option and Result. If you want the Option behavior, there's .get() Anyways, very cool looking language.
- Ar-Curunir 8y agoBut from what I've seen, most idiomatic Rust code doesn't use the `map[key]` syntax, but instead uses `map.get(key)`.
- steveklabnik 8y agoWe must look at very different code :)
- bpicolo 8y agoI actually didn't realize it was doable (not a heavy rust user - just an enthusiast). Kinda hidden away in docs under an example [0] and isn't in the book under hash maps [1]. Might be worth calling out somewhere explicitly? People getting started with rust probably aren't familiar with the trait-based operator overloading system yet. [0] https://doc.rust-lang.org/std/collections/struct.HashMap.html#examples-16 https://doc.rust-lang.org/std/collections/struct.HashMap.htm... [1] https://doc.rust-lang.org/book/second-edition/ch08-03-hash-maps.html https://doc.rust-lang.org/book/second-edition/ch08-03-hash-m...
- steveklabnik 8y agoYeah, might be worth it on the API docs, for sure. Maybe file a bug? :)
- simen 8y ago> For me using an exception to indicate the lack of a value corresponding to a key in a map (is it really exceptional for this to happen?) Sometimes it is, sometimes it isn't. Most languages allow you to choose whether you want a hash to throw a key error on non-existing keys or return a signal value. My favorite is the uber-flexible approach and nice syntax in Crystal: hash[foo] is sugar for hash.fetch(foo) hash[foo]? is sugar for hash.fetch(foo, nil) hash.fetch(foo) will return the default value of the hash table on nonexistent keys if one was assigned, otherwise raise keyerror hash.fetch(foo, nil) will return nil on nonexistent keys