Yes, bounds checking are unnecessary, you don't need those _s() functions - NSA director
However it's going to take some time to learn all the gotchas in string functions... Failing to zero-terminate strings (strncpy), potential buffer overflows (many), global internal buffer and overwriting an argument…
I think your comment is spot-on. A good Perl programmer can do wonders, but if you add just one average programmer to the team (without a very extensive training), he can write stupid things faster than the good…
Yeah, it's so annoying. Everytime I go to the moon I remember how I hate that uneven gravity!
+1 just because of "I would personally prefer to tinker with a Brainfuck implementation than spend any amount of time in any bar"
I guess they just ran out of names, after deprecating java.util.Date (remember that there's also java.sql.Date).
Never using a space before the paren is more consistent. I don't know why people put a space there...
Same here...
I don't see how that invalidates my explanation In F# I would certainly call it "callTwice" too: let callTwice aFunction y = aFunction (aFunction y)
So enlighten me.
If programmers of functional languages were better at naming things, it would be easy. Let's rename g to callTwice and h to aFunction: function callTwice(aFunction) { return function(y) { return aFunction(aFunction(y));…
Well, I guess this is going to be a fairly down-to-earth language.
What one can learn from Perl: When programming in a language you hate, don't take naming arguments for granted. It could be worse: you could be programming in Perl, where all arguments come in a flattened array.
I don't think that is a misconception. Perl is the language with the highest occurrence of "subtle" and "ambiguous" in its documentation and tutorials that I have ever seen. Humans may be subtle and ambiguous, but…
> bring a knife to a gun fight > If the goal of the competition is to slice apples What?
Perl eats C++'s "most vexing parse" for breakfast.
The standard music notation and the criticism this new notation receives here look to me as if we were stuck for centuries with only one programming language, C++, and nobody could change it. Sure, it has been working…
After your excelent suggestions for names (makeMapper and makeGetter, they make everything easier, thank you), I'll try answering this, with a F#-like syntax using redundant parentheses around arguments to make them…
Your example is great, but it would be even more convincing if it used list comprehension syntax such as totals = [order.total for order in orders] (like some other poster in this thread did) Then you don't even need to…
Can I upvote you twice? More than once I have found about a new technique in language A and thought: "Wow, this is clever". Then sometime later I learnt language B where that technique is not only common place, but has…
I went in the other direction and it was enlightening too. I learned how useful hash tables can be, and that a word count algorithm need not be a complicated assignment full of segmentation faults. :-) I also learned…
That logic is just a starting point (just to avoid the "I don't need it, why can't you be just like me?"), not the whole thing. Then you have to take into account a few other criteria, such as [1] internal coherence in…
Which is better?
I remember some years ago when I was glad Java 5 had got some really practical new features. I didn't program in Java back then, but I wanted the language to evolve (maybe I was going to need it in the future). Now I do…
> Thus, getters and setters should not be encouraged. Damn, so why are they encouraged in Java? 11 out of 10 frameworks insist that you write getters/setters so properties can be accessed from outside. Java…
Yes, bounds checking are unnecessary, you don't need those _s() functions - NSA director
However it's going to take some time to learn all the gotchas in string functions... Failing to zero-terminate strings (strncpy), potential buffer overflows (many), global internal buffer and overwriting an argument…
I think your comment is spot-on. A good Perl programmer can do wonders, but if you add just one average programmer to the team (without a very extensive training), he can write stupid things faster than the good…
Yeah, it's so annoying. Everytime I go to the moon I remember how I hate that uneven gravity!
+1 just because of "I would personally prefer to tinker with a Brainfuck implementation than spend any amount of time in any bar"
I guess they just ran out of names, after deprecating java.util.Date (remember that there's also java.sql.Date).
Never using a space before the paren is more consistent. I don't know why people put a space there...
Same here...
I don't see how that invalidates my explanation In F# I would certainly call it "callTwice" too: let callTwice aFunction y = aFunction (aFunction y)
So enlighten me.
If programmers of functional languages were better at naming things, it would be easy. Let's rename g to callTwice and h to aFunction: function callTwice(aFunction) { return function(y) { return aFunction(aFunction(y));…
Well, I guess this is going to be a fairly down-to-earth language.
What one can learn from Perl: When programming in a language you hate, don't take naming arguments for granted. It could be worse: you could be programming in Perl, where all arguments come in a flattened array.
I don't think that is a misconception. Perl is the language with the highest occurrence of "subtle" and "ambiguous" in its documentation and tutorials that I have ever seen. Humans may be subtle and ambiguous, but…
> bring a knife to a gun fight > If the goal of the competition is to slice apples What?
Perl eats C++'s "most vexing parse" for breakfast.
The standard music notation and the criticism this new notation receives here look to me as if we were stuck for centuries with only one programming language, C++, and nobody could change it. Sure, it has been working…
After your excelent suggestions for names (makeMapper and makeGetter, they make everything easier, thank you), I'll try answering this, with a F#-like syntax using redundant parentheses around arguments to make them…
Your example is great, but it would be even more convincing if it used list comprehension syntax such as totals = [order.total for order in orders] (like some other poster in this thread did) Then you don't even need to…
Can I upvote you twice? More than once I have found about a new technique in language A and thought: "Wow, this is clever". Then sometime later I learnt language B where that technique is not only common place, but has…
I went in the other direction and it was enlightening too. I learned how useful hash tables can be, and that a word count algorithm need not be a complicated assignment full of segmentation faults. :-) I also learned…
That logic is just a starting point (just to avoid the "I don't need it, why can't you be just like me?"), not the whole thing. Then you have to take into account a few other criteria, such as [1] internal coherence in…
Which is better?
I remember some years ago when I was glad Java 5 had got some really practical new features. I didn't program in Java back then, but I wanted the language to evolve (maybe I was going to need it in the future). Now I do…
> Thus, getters and setters should not be encouraged. Damn, so why are they encouraged in Java? 11 out of 10 frameworks insist that you write getters/setters so properties can be accessed from outside. Java…