@Bubbler I originally designed it as a De-Operator, which takes an Operator and makes it a function. Eg, @+ would be roughly equivalent to (a,b)=>a+b. But only using it for such a narrow reason, I felt I could give it new life as an equivalent to ()=>
I mean how big of a scale are we talking about. A single line? The whole code block? Should I be rethinking my whole terrain generator to avoid choosing a lake's radius based on a boolean?
Checking if a "how many more lakes to make big" counter is nonzero
I could duplicate my lake generator stage and do N big lakes then N small lakes, or I could reuse all of the code except a single thing to decide on a radius
Not knowing the specifics of what differentiates a big lake and a small lake, I can't really comment on how to refactor it, but an if/else or ternary is probably fine
I can't just do big_lakes += 1; total_lakes -= 1;, I have to search through the array to find which one is the big lakes, and if I ever change the size of the big lakes, now how do I know which is the big lakes to increment it? I need a third item to identify them, or better, I just decide on the number of big and small lakes first and then...have what I currently do
But just because *mumble mumble* extensibility you're saying I should take those, put them in tuples, stick those in an array, which I'd need to do with repeated code anyway, then iterate over that array whose size will always be known when I'm writing the code, no matter how many lake sizes there are?
Well I'm simplifying, the lake sizes are actually maximum sizes, there's additional randomization of the sizes
But there's differences in what structures can spawn in and around big and small lakes later on, and any sizes in between really small and really big looked weird, so having the distinction makes sense
@ATaco Yeah, this style of conversation in which one person holds all the information about the code is not very productive imo. It's really hard to suggest good improvements if you know none of the details. Especially if the conversation is framed as adversarial.
But basically I'm saying, picking between two values is a perfectly valid thing to want to do, and when you have the option to do it elegantly, it becomes a good way to frame lots of problems
I'm not really sure what y'all's suggested alternative is, but there's plenty of code where nice little functional or OOP style abstractions aren't an option or would be more trouble than they're worth. More abstraction != more good, sometimes you just know what your code should do and want to do it.
What I'd say here is that picking between two values very easily generalizes to picking between N values, though it may or may not apply to your problem
@Bubbler But there's plenty of situations where a bool's the only reasonable set of options. E.g., if you want to return one of two strings based on whether an external program succeeds or not. Sure maybe later you'll add more based on what code it returned, but you'll be rewriting way more than the ternary in that case anyway.
This is heresy but I don't really like enums for a lot of things. They're just so big. I know the "you're just being a code golfer lol" joke is easy to reach for, but small code is nice.
You need to define them, which is space wasted (and also usually somewhere fairly far from where you use it, meaning you have to move away from what you're reading for context), and LakeSize::Small is a lot bigger than 0 (or false but bool literals are for cavemen)
I'm going to start using VS Code on my new desktop, but things like "do you want to open this file in secure mode" or whatever for a fking text editor is just ridicolous
It's more important for code to be maintainable by the devs working on it, not for it to be able to be stuffed into one file so people don't need an IDE to read it (although making code simpler is generally a good idea)
when the number of choices doesn't exactly correspond to the number of values in an existing type then using an existing type also means you have extra impossible values to consider everywhere
unless you're working in a language that has refinement types but that's just even sillier lmao
And then if you're using int literals, what happens if you decide that actually I need to swap the meaning of integers. What if lake size small for some reason is better suited as being 4 than 0. Using just literals means you have to find all instances where 0 means lake size small, which may not be immediately obvious
C complains even if you account for all enum values, because you need to handle values outside the enum if some idiot passes in an arbitrary number cast to that enum or something
also for what it's worth i hate having to spell out what the enum's from too lmao i don't know why rust doesn't make stronger inferences with that kind of stuff but haskell's usually pretty good about it... granted it also doesn't really let you have constructor names collide so maybe that's a bad example :P
if you do have some weird one off kind of loop where you do still have a piece of state that is "the loop variable" the general c-style for loop providing an obvious way to handle the scope is nice, but that's pretty rare
i occasionally do end up having one section empty in for loops in c just because i'd rather have an empty condition/increment than either have the loop variable in the enclosing scope or add extra brackets/indentation :P
but it definitely does have a readability tradeoff
@WheatWizard only problem is you might forget to do the incrementing part because it’s not right at the top, but an ide would warn you about that anyway
i think one slight readability boost for a conventional use of for versus using while for the same thing is that all of the "loop logic" is in the "same place" but that isn't enforced so it's really just a hint to the reader and any conventional use of a c-style for can just be anything range-based instead
@RadvylfPrograms If a construct is present people will use it. The number of wizards writing code from an ivory tower where they don't have to interact with other people is negligible and shouldn't really be a consideration when designing language.
@RadvylfPrograms Problem with this approach is that readers have to be aware of all the syntaxes used in the wild, and the users of the language will constantly fight over which is better
They fit my coding style, they look cool, and they can aid readability when used in place of some while loops. If I was designing a language, that's why I'd include them.
I think a big factor here is familiarity honestly. If you come from a C/Java/JS background, you'll be more familiar with C-style for loops, like how they look as a result, and have used them more so be more biased to think they're necessary and commonly used. I think that's why Steggan and I both like them and y'all don't. The real answer's probably somewhere in the middle, where they on average don't necessarily hurt readability but probably aren't all that necessary nowadays either.
If I designed a language I'd definitely include them, but that's just because I'd be starting from a language I know I mostly like, JS, and refining it to add things from other good languages (Rust) and removing things that are clearly bad (most of JS besides the syntax)
I do think they should be included in Rust, which like Go feels kind of uncanny valley to me since they're going for a C-style look but with little things slightly different
But like, I wouldn't argue Python would benefit from C-style for loops :p
The general SAT (boolean satisfiability) problem is NP-complete. But 2-SAT, where each clause has only 2 variables, is in P. Write a solver for 2-SAT.
Input:
A 2-SAT instance, encoded in CNF as follows. The first line contains V, the number of boolean variables and N, the number of clauses. ...
Given two rectangles, which are possibly not in the orthogonal direction, find the area of their intersection.
Input
You may take the rectangles as input in one of the following ways:
The coordinates of the four vertices of the rectangle. These coordinates are guaranteed to represent a rectangl...
The general SAT (boolean satisfiability) problem is NP-complete. But 2-SAT, where each clause has only 2 variables, is in P. Write a solver for 2-SAT.
Input:
A 2-SAT instance, encoded in CNF as follows. The first line contains V, the number of boolean variables and N, the number of clauses. ...
Given two rectangles, which are possibly not in the orthogonal direction, find the area of their intersection.
Input
You may take the rectangles as input in one of the following ways:
The coordinates of the four vertices of the rectangle. These coordinates are guaranteed to represent a rectangl...
