It really feels like they’re just reaching for Rust and don’t know it yet
Please do not attempt to simplify this code
301–310 of 327 posts
Re: Please do not attempt to simplify this code
#302Earlier quoted context omitted.
"Else" is for when the if condition is false. A resumable exception initiated in the "then" part of an if will not go to "else" when control resumes; it will go to the next statement after the if.
I did not say exceptions could be resumed (correctly 'restarted'); I said conditions could. Most languages with which I'm familiar do not have the latter. One typically available restart is to ignore the condition and resume execution immediately after, as you describe. Another is to re-evaluate the form in which the condition was signaled. In that case, the conditional may well be itself re-evaluated with a differen…
An if-like conditional construct will not, by itself, re-evaluate the condition when an exception occurs, unless it is a special exception-aware construct (a weird macro someone made). The conditional construct would itself have to have an internal restart point around the conditional expression, which intercepts the exception.
"Condition" is just a silly name for "exception". It does not mean "restartable exception". It's a terminology that Common Lisp copied from PL/I. At the time Common Lisp was being standardized, it was not a common programming language feature, so the naming didn't matter. In the decades since, the world went to "exception".
The word "condition" already has a clear meaning in computing, referring to a logical state ("condition control register", "conditional branch", ...). The "condition variable" synchronization primitive (which has no condition-like state!) is bad enough; we don't need to heap more meanings on those words.
Note that processor instruction sets have exceptions, precisely restartable, down to the instruction, without requiring a cooperating restart point. E.g. any code can hit a page fault: the exception handling will fix it up, making a page present at the faulting address, and then restart the instruction that faulted.
Re: Please do not attempt to simplify this code
#303Earlier quoted context omitted.
Outdated comments are great, because it means you probably have a bug right there. If the comment didn't get updated, the code change probably didn't look at all the context and missed things. Pretty sure I'm guilty of that pretty often.
Looking at someone else's code, how would you know which was out of date, the code or the comment?
git blame will show when lines in a file were last changed, and the commit that changed them
Re: Please do not attempt to simplify this code
#304Earlier quoted context omitted.
Your Elixir feedback is strange. I find it very explicit. Can you give some examples what you find clever / implicit about it?
I think it's super subjective, and I'm sure it's just my mental block from 30 years of C style languages. I have trouble with the equals sign being "pattern matching". There are other syntax things like that, where it seems like too much is being done in odd (to me) ways that are hard to grok. I know a lot of people love it, and I really did try, but for whatever reason the syntax just doesn't work for me.
You are kind of backtracking here because I don't see anything about implicitness. I mean okay you can't get used to the syntax and you don't want to -- not something I'd deem a serious reason to drop a language but it's fair enough and it's obviously your right so cool.
But Elixir is anything but implicit. If anything, people periodically raise a stink about wanting some magic in there, and we the wider community just reject them.
Re: Please do not attempt to simplify this code
#305Earlier quoted context omitted.
Let's say you've tested this thing 1 million times. Each time the output was automatically checked by five different and independently-developed test suites. You're ready to swear there's no possible way for it to fail. And then someone tries it with a ulimit of 16kB. Does it run? Do you _know_? Do you even know what is correct behavior in this situation?
The system it runs on is part of the specification. A program is correct if fulfills all specified requirements. You're saying a car is defective because it breaks when you put sugar in the tank.
[deleted]
Re: Please do not attempt to simplify this code
#306Earlier quoted context omitted.
I think it's super subjective, and I'm sure it's just my mental block from 30 years of C style languages. I have trouble with the equals sign being "pattern matching". There are other syntax things like that, where it seems like too much is being done in odd (to me) ways that are hard to grok. I know a lot of people love it, and I really did try, but for whatever reason the syntax just doesn't work for me.
You are kind of backtracking here because I don't see anything about implicitness. I mean okay you can't get used to the syntax and you don't want to -- not something I'd deem a serious reason to drop a language but it's fair enough and it's obviously your right so cool. But Elixir is anything but implicit. If anything, people periodically raise a stink about wanting some magic in there, and we the wider community ju…
Sure, people find different things complex.
For example, I can't make heads or tails of rxjs, and honestly have zero motivation to do so.
Other people see it and find it intuitive.
Shrug.
Re: Please do not attempt to simplify this code
#307Earlier quoted context omitted.
I dunno, the "why" for me is "why are we doing this, and doing it this way?". If that changes, but somehow the comment isn't changed, that would feel really strange. It's not just tweaking a few lines, it's rewriting the whole routine. If all the code changed but not the comment, that would have to be deliberate, and definitely picked up in code review. Though, obviously, accidents happen, etc. But then that also hap…
So I actually find this helpful because if the why doesn't match the what (code), I know to look back at the history of changes and see why there is a mismatch. This is honestly a great signal that something might have gone sideways in the past while I'm trying to triage a bug or whatever. So even if the comments are out of date, they're still helpful, because I know to go look at why they're out of sync.
really good point, and well worth mentioning in the "code should be self-documenting and comments are unnecessary" debate.
Re: Please do not attempt to simplify this code
#308When, oh, when, will we get a programming language that actually supports state machines properly ...
What does supporting state machines properly look like?
Dunno. Maybe a table with functions and conditions?
The point isn't the specific form that support would take. The point is that it has some form that implies the intent of the programmer.
It has N states and they are enumerated. It has code that runs on transition and state. It has these variables which make up conditions. The state doesn't become a dead end and all states are reachable. etc.
The point is to enable the compiler to know "Hey, this is a state machine. You can check because it is a state machine.
Re: Please do not attempt to simplify this code
#309Earlier quoted context omitted.
Let's say you've tested this thing 1 million times. Each time the output was automatically checked by five different and independently-developed test suites. You're ready to swear there's no possible way for it to fail. And then someone tries it with a ulimit of 16kB. Does it run? Do you _know_? Do you even know what is correct behavior in this situation?
The system it runs on is part of the specification. A program is correct if fulfills all specified requirements. You're saying a car is defective because it breaks when you put sugar in the tank.
This is a no true Scotsman fallacy. Any time it runs incorrectly, it was invoked with the wrong operating conditions — which seem to be defined as any conditions that cause it to run incorrectly.
Sugar in the tank is an agreeable example because of how obvious it is, but what about something more subtle? An odd condition that leads to the wrong resonant frequency. An unknown software bug that makes the brakes lock up on Tuesdays at 12:00 AM on one specific backroad in a remote part of Virginia. The combinatorial possibilities of operating conditions are too numerous to exhaustively test.
I guess you could say that every function has every quality that it happens to have, so that functions need only exist in order to be “correct.”
Re: Please do not attempt to simplify this code
#310Earlier quoted context omitted.
“Program testing can be used to create 1 the presence of bugs, but never to show their absence” 1) edited
That is wrong in general. With enough tests you absolutely can show the absence of bugs for certain programs. It is for example easy to test „hello world“ exhaustively.
I agree, but the word “certain” really needs to not be overlooked in this statement.