I’m not missing your points, even as you change them. I’ve agreed that JS sucks. I’ve agreed that errors can be more helpful. I’m not trying to argue with you about that. What I have said, from the beginning, is that in the code you originally presented a behavioural change for setMonth will not help you find the problem any faster. Test failures for the wrong output occur just as often as test failures for errors, on exactly the same few days each year. The API change gives no advantage for the specific function this discussion started with in this regard. However, an approach that avoids inconsistency will, because in this particular instance, that is the real source of the problem. That is all.
In that context—the one you started with—it does not matter that there is often good reason to call Date()without arguments. The getMonthName function presented, effectively an array lookup, should produce the same output for any given input every time. It has no reason to engage in any behaviour that varies from day to day.
There is absolutely nothing wrong with getting the current date.
Bluntly, the code you presented fails precisely because it gets the current date where it should create a more specific one, and then fails to deal with that variation appropriately. You can keep distracting yourself with language design decisions, but that won’t help you avoid this particular type of problem in the future because that’s not where it is.
Getting the current date is often fine. In this specific instance, it is not. That is why the function doesn’t work. If you are missing that point, as much as I appreciate your enthusiasm in continuing the conversation, I will take the L (and the code that actually works) and move on.
What I have said, from the beginning, is that in the code you originally presented a behavioural change for setMonth will not help you find the problem any faster.
Yes, it would help find the problem faster because the first time invalid date is passed in the program will crash. The current behavior means the program will keep running and the only time it will become apparent that there is an error is when somebody notices that the month is wrong. You keep saying you’re not missing my points, but here we are.
In that context—the one you started with—it does not matter that there is often good reason to call Date() without arguments. The getMonthName function presented, effectively an array lookup, should produce the same output for any given input every time. It has no reason to engage in any behaviour that varies from day to day.
Again, the point that was actually being made is that this whole scenario can be avoided by rejecting invalid inputs for the date of the month.
Bluntly, the code you presented fails precisely because it gets the current date where it should create a more specific one, and then fails to deal with that variation appropriately.
Bluntly, I’ve already explained to you that the code presented is not the problem and is a valid use case.
Getting the current date is often fine. In this specific instance, it is not.
This specific instance is a legitimate use case for getting the current date because the intent of the code is to get the previous month RELATIVE to the current date. The code you provide simply hacks around this problem by hard coding the date.
the intent of the code is to get the previous month RELATIVE to the current date.
But that isn’t what it does. From the original post:
function getMonthName(monthNumber) {
const date = new Date();
date.setMonth(monthNumber - 1);
return date.toLocaleString([], { month: 'long' });
}
That is a function which is meant to take a number (presumably 1 to 12) and return a localized name for it. This is essentially an array lookup and should return the same output for a given input (and locale) every time it is called. If the intent is to return a value relative to the current date, it is even more wrong, since it should gather the month from the current date, not the function paramenter. This claim of intent, not present in the original post, is an example of you changing your story over time.
Yes, it would help find the problem faster because the first time invalid date is passed in the program will crash.
No, it wouldn’t. As I have said before, testing for unexpected return values is just as effective as testing for errors, that is, not very with the function originally presented under sensible assumptions. If the function actually did look like the intent you claim, the tests would be different, necessarily replacing Date for consistent runs, but would be equally likely to catch the problem whether failing on value or error. And if you are eschewing testing and relying on runtime crashes, you have bigger problems.
Given that I have agreed and commiserated, and neither of us can change JavaScript, there is nothing to be gained from pursuing this complaint. In contrast, what I have tried to say, if followed, would give you an approach that leads to more reliable code, even in the face of undesirable APIs.
I had thought that worth pursuing, and had thought you worth investing my considerable time. Alas, I can only lead you to the water…
But that isn’t what it does. From the original post:
The problem would be the same if you were just doing an offset from the current month. You’re now nitpicking the example while ignoring the point being made. Perhaps this version will help clarify the problem for you better:
function getLastMonthName() {
const date = new Date();
date.setMonth(date.getMonth() - 1);
return date.toLocaleString([], { month: 'long' });
}
No, it wouldn’t. As I have said before, testing for unexpected return values is just as effective as testing for errors, that is, not very with the function originally presented under sensible assumptions.
I’ll repeat this again, the failure case is not obvious and you can easily miss the test for it. Throwing an error makes it much easier to identify that there is a problem, and that’s why APIs in sane languages such as Java behave this way.
This claim of intent, not present in the original post, is an example of you changing your story over time.
Nobody is changing the story over time, you’re just incapable of acknowledging being wrong.
Given that I have agreed and commiserated, and neither of us can change JavaScript, there is nothing to be gained from pursuing this complaint.
Which is precisely why I posted this on Programmer Humor. Js is a garbage language, and it’s obviously beyond fixing, but I can laugh at it.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
I’m not missing your points, even as you change them. I’ve agreed that JS sucks. I’ve agreed that errors can be more helpful. I’m not trying to argue with you about that. What I have said, from the beginning, is that in the code you originally presented a behavioural change for
setMonthwill not help you find the problem any faster. Test failures for the wrong output occur just as often as test failures for errors, on exactly the same few days each year. The API change gives no advantage for the specific function this discussion started with in this regard. However, an approach that avoids inconsistency will, because in this particular instance, that is the real source of the problem. That is all.In that context—the one you started with—it does not matter that there is often good reason to call
Date()without arguments. ThegetMonthNamefunction presented, effectively an array lookup, should produce the same output for any given input every time. It has no reason to engage in any behaviour that varies from day to day.Bluntly, the code you presented fails precisely because it gets the current date where it should create a more specific one, and then fails to deal with that variation appropriately. You can keep distracting yourself with language design decisions, but that won’t help you avoid this particular type of problem in the future because that’s not where it is.
Getting the current date is often fine. In this specific instance, it is not. That is why the function doesn’t work. If you are missing that point, as much as I appreciate your enthusiasm in continuing the conversation, I will take the L (and the code that actually works) and move on.
What points have I changed, please be sepcific.
Yes, it would help find the problem faster because the first time invalid date is passed in the program will crash. The current behavior means the program will keep running and the only time it will become apparent that there is an error is when somebody notices that the month is wrong. You keep saying you’re not missing my points, but here we are.
Again, the point that was actually being made is that this whole scenario can be avoided by rejecting invalid inputs for the date of the month.
Bluntly, I’ve already explained to you that the code presented is not the problem and is a valid use case.
This specific instance is a legitimate use case for getting the current date because the intent of the code is to get the previous month RELATIVE to the current date. The code you provide simply hacks around this problem by hard coding the date.
But that isn’t what it does. From the original post:
That is a function which is meant to take a number (presumably 1 to 12) and return a localized name for it. This is essentially an array lookup and should return the same output for a given input (and locale) every time it is called. If the intent is to return a value relative to the current date, it is even more wrong, since it should gather the month from the current date, not the function paramenter. This claim of intent, not present in the original post, is an example of you changing your story over time.
No, it wouldn’t. As I have said before, testing for unexpected return values is just as effective as testing for errors, that is, not very with the function originally presented under sensible assumptions. If the function actually did look like the intent you claim, the tests would be different, necessarily replacing
Datefor consistent runs, but would be equally likely to catch the problem whether failing on value or error. And if you are eschewing testing and relying on runtime crashes, you have bigger problems.Given that I have agreed and commiserated, and neither of us can change JavaScript, there is nothing to be gained from pursuing this complaint. In contrast, what I have tried to say, if followed, would give you an approach that leads to more reliable code, even in the face of undesirable APIs.
I had thought that worth pursuing, and had thought you worth investing my considerable time. Alas, I can only lead you to the water…
The problem would be the same if you were just doing an offset from the current month. You’re now nitpicking the example while ignoring the point being made. Perhaps this version will help clarify the problem for you better:
I’ll repeat this again, the failure case is not obvious and you can easily miss the test for it. Throwing an error makes it much easier to identify that there is a problem, and that’s why APIs in sane languages such as Java behave this way.
Nobody is changing the story over time, you’re just incapable of acknowledging being wrong.
Which is precisely why I posted this on Programmer Humor. Js is a garbage language, and it’s obviously beyond fixing, but I can laugh at it.