5 ms·
Tangentially -- use languages that have great enum support. Well you knew what was coming -- Rust enums are excellent[0], and so are Haskell's[1] (try and spot
by hardwaresofton 2y ago
Tangentially -- use languages that have great enum support.
Well you knew what was coming -- Rust enums are excellent[0], and so are Haskell's[1] (try and spot the difference between an enum and a record type!)... But that probably won't help you at $DAYJOB.
A bit more on topic though -- I'd like to see a strong opinion on Option<SomeEnum> versus SomeEnum containing a Missing variant. I usually lean towards Option<SomeEnum> but I wonder if there are any devout zero value proponents.
I don't like how golang does/requires zero values, but in more expressive languages I do waver sometime between Option<T> and T w/ a "missing" indicator variant inside.
[0]: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html
[1]: https://wiki.haskell.org/Type https://wiki.haskell.org/Type
- teaearlgraycold 2y agoTypescript is great for this. function operation(user: User, state: “active” | “inactive”): void Boom. Done. Enum defined. You want people to use enums? Remove all context switching from the definition process.
- leobg 2y agoSame in Python, no? def foo(bar: Literal["active", "inactive"])
- hardwaresofton 2y agoWhat's the best Python type checker these days? Seems like there are at least 4: Mypy, Pytype, Pyright, and Pyre
- Terretta 2y agobasedpyright: https://github.com/DetachHead/basedpyright https://github.com/DetachHead/basedpyright (assuming you can't/don't use MSFT's pylance)
- hardwaresofton 2y agoAh I love Typescript (IMO JS is the best "scripting language" out there, and has been for a very long time, but that's a different discussion). That said, I hate that typescript has many ways of doing it. That's the biggest problem. There's: enum SomeEnum { First, Second, } const enum SomeConstEnum { A = 1, B = A * 2, } type SomeEnumType = "first" | "second"; const SomeObjectThatIsAnEnum = { "first": 1 "second": 2 } as const I always lean towards the `enum` keyword, because I am of the opinion that if you're optimizing for less generated JS (and enums are actually worth optimizing for in this way) you're probably using the wrong language to begin with (unless you're in the browser and have no choice, etc).
- ikekkdcjkfke 2y agoTypescript type system is probably gold standard, you can enforce so much statically
- hardwaresofton 2y agoAs far as gold standards go for typesystems... ML languages probably take it, with Haskell being the closest to widespread real world use.
- teaearlgraycold 2y agoIt's the gold standard for languages you'll be able to use at work.
- CharlieDigital 2y agoTypeScript enums, from personal experience, should be avoided in cases where the value is stored. The reason is that the compilation from `SomeEnum` to JS involves conversion to an object indexer[0]. Should you, in the future, need to (or accidentally) remove or change an enum option, this will fail with an index out of range exception at runtime that is not obvious to track down. Put it another way: it leaves behind an artifact in the output JS that can be a source of exceptions. [0] https://www.typescriptlang.org/play/?ssl=5&ssc=2&pln=1&pc=1#code/KYOwrgtgBAwg9gGzgJwM5QN4Cgq6gJWABMAaHPAcWWFDLygCEExgsBfIA https://www.typescriptlang.org/play/?ssl=5&ssc=2&pln=1&pc=1#...
- ivan_gammel 2y agoThat’s the worst way to define enums. Now you have to make sure your codebase is using the same string literals everywhere and carry the potentially long type definition to every parameter, variable or function return type. And no, compile-time checks won’t cover 100% of cases.
- teaearlgraycold 2y agoObviously if this gets reused you need to put it in a central definition.
- SkyPuncher 2y agoThe only place I believe this pattern is acceptable is option props in React components. Otherwise, it becomes an absolute mess of “almost” defined correctly.
- ivan_gammel 2y agoHow wouldn’t it be reused? Besides, what will happen if you need to change a constant in the enum from „a“ to „b“? Compiler won’t help you to spot all the places like ˋˋˋif (value == „a“)ˋˋˋ, it will quietly become unreachable in runtime.
- teaearlgraycold 2y agoYou underestimate TypeScript. Your example will give a compiler error: This comparison appears to be unintentional because the types '"a"' and '"b"' have no overlap.(2367) https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAZiEAuGAiAhqmBeNmDcAUIQJZwwAUCIO2uqARqgJQwDehMXMokIANgFMAdPxABzChgCeIFkQC+hIA https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAZiEAu... It's features like these that make Python/Ruby/etc. type-checkers insufficient substitutes for TypeScript. I think my example wasn't the best. Of course "active" | "inactive" would get reused. But if it's just a little function flag it could easily be a one-off.
- the_gipsy 2y agoAn Option<Enum> has the advantage that you con chain it with other Option/Result operations like map, and_then, etc. I think this would be called being "monadic". The advantage of Enum with Missing variant is that it's more expressive, and that you don't have to nest access in the Some matching. Generally I prefer Option<Enum>, and often you can match directly with Some(Variant) to avoid nested matches.
- simondw 2y ago> map, and_then, etc. I think this would be called being "monadic". Strictly speaking, I think providing "map" just makes it functorial. Monadic would need a flatmap. (In addition to the other functor and monad requirements, of course.)
- hardwaresofton 2y agoYou're right, and I'd add on that monads only need pure and bind (>>=), das it! pure :: Monad m => a -> M a (>>=) :: Monad m => M a -> (a -> M b) -> M b pure is sometimes called return and >>= is sometimes called bind and flat map. I was unsure that bind was the same as flatmap but it looks like it is.
- the_gipsy 2y agoSo what would you call something like "it implements some common operations", like these? For example, the Option and Result type both have functions like "map", they do the same thing just on different types. They're not quite generic in that sense, but on a high level they seem so. Another example are reactive libraries. Everything is pegged into some common operations like map, take, and so on.
- tubthumper8 2y agoThe "and_then" that they mentioned is the flatmap
- mrkeen 2y ago> I'd like to see a strong opinion on Option<SomeEnum> versus SomeEnum containing a Missing variant. Java $DAYJOB here. If I'm a caller, I probably won't realise that SomeEnum.Missing exists. I'll just see that a function accepts a SomeEnum (which I don't have) so I won't call it.
- hardwaresofton 2y agoThis is a good point -- Option<T>is much better in a fn signature for comprehension. This probably clinches it. Funnily enough, Java 1.8 is what really made me start taking Haskell and languages with better type systems more seriously -- seeing that Option actually deserved to be basically everywhere broke my frame.
- junon 2y agoOption is the better of the two. With a missing variant, there's no way to encode "infallibly successful". All call sites would have to check for a missing variant in all cases.
- danhau 2y agoThis. Enum with a “missing“ variant is basically the billion dollar mistake again… kinda.
- smitty1e 2y agoPython's enum support[0] seems quite comprehensive, as well. The nice thing about a class is that when some bizarre edge case comes up (and whose Extract, Transform, Load process has not?) one can isolate the weirdness. [0] https://docs.python.org/3/library/enum.html https://docs.python.org/3/library/enum.html
- nivertech 2y agoOption/Maybe/Result is a Boolean in disguise. It has the same problem as Booleans by supporting only two branches: single happy path and single unhappy path, when real life may have many paths, and it’s not always clear which of them are happy or unhappy (from the business logic point of view). Even for purely technical errors, simple OK | ERROR isn’t enough, but should be something like OK | RETRY | UKNOWN_ERROR | FAILED.
- hardwaresofton 2y agoYup, definitely a case for enums there -- I don't think the rule is absolute (I'm not sure you should always use enums over booleans), but much of the time it seems to be true.