shirogane86x
Joined 6 years ago
Joined 6 years ago
At least in my job(s over the years), turning a flat list of db records into a more complex, nested (potentially on multiple levels) data structure before handing it off to the front-end is a very common. I've seen it done with "simple, fast code" (although not in go specifically, but in other languages), but it very quickly turned into huge messes of of long nested for loops and was very difficult to read. LINQ, Lodash, java's streams... I sincerely can't understand how go developers live without them. They make me a lot more productive both at reading and writing the code.
- gen 1 pokemon are very basic and probably some of the worst in the series (subjective)
- the games are extremely unbalanced, and many types have only one evolution line while others have a lot, there's no uniformity (gen 1 has only 1 dragon and 1 ghost line)
- the lack of physical special split hits many types insanely hard and they never balanced for it (i.e.: Ghastly line is a special attacker but is the only ghost type, ghost type is physical for some reason)
- gen2 is basically non linear for most of Johto, which completely destroys the levels on the gym leaders and the wild pokemon. The Kanto section has similar issues. And red is only difficult because it's insanely overlevelled compared to everything else
- gen 2 gym leaders don't have Johto pokemon (lol)
- trainer AI, especially in some instances, is very weirdly programmed (Blaine for example uses healing items on full HP pokemon for no reason)
- lack of moves means even late game, trainers have start-of-game moves ( blue has a rhydon with tail whip and leer, but no ground or rock moves. And an Exeggutor with no grass or psychic damaging moves. And he's the final boss)
- most of them are dynamically typed (thus don't need sum types, as there are no types). The ones that do have gradual type systems likely either implement some form of them (off the top of my head I can only remember typed racket, and I think it implements them through union types)
- not all lisps lean functional: I believe that's mostly a prerogative of scheme and clojure (and their descendants); something like CL is a lot more procedural, iirc
- in most lisps, thanks to macros, you probably don't need the language to support some sort of match construct out of the box: just implement it as a macro [1]
In general the "proper sum types" side of functional programming is just the statically typed one, but even in dynamically typed FP languages you end up adopting sum type-esque patterns, like elixir's error handling (which closely resembles the usual Either/Result type, just built out of tuples and atoms rather than a predefined type), and I assume many lisps adopt similar patterns as well
[1] https://github.com/clojure/core.match