Live data from Hacker News

Programming Idioms

programming-idioms.org

41–50 of 99 posts

Re: Programming Idioms

#41
post #28

Surprisingly many failures of reading comprehension in the implementations here: https://programming-idioms.org/idiom/184/tomorrow I’ve always found it interesting to consider the simplest possible spec you could give 100 programmers and receive no bugs in return.

What do you call a spec that any programmer can understand and correctly describes the problem and its desired outcome exactly?

A program

Re: Programming Idioms

#42
post #40

Earlier quoted context omitted.

That is one of the most confusing pieces of C code I have seen lately. And it fails on an empty string: I would expect it to set b to 1 for an empty string, but it sets it to 0. Of course that could easily be fixed by setting b to 1 at the top. Also, code like this should always be put inside a function that returns a value, not just written inline. Making it a function allows simpler and more understandable code too…

You do realize it returns 1 for an empty string right? I mean it doesn't have any digits in it... What about adding a check of str[0] == 0 -> return 0 Also, giving char str[] will make it char* str. Which can be null. This may cause reading a random memory location (possibly segfault or use-after-free) edit: I get the comments but empty string still contains no digits. Given the regex would be ^[0-9]+ (+ instead of *…

Empty string contains no non-digits. Therefore it is only digits.

Re: Programming Idioms

#43
post #16

Earlier quoted context omitted.

Not to mention that proper idiom for this task would be: int n = strspn(s,"0123456789"); BOOL b = (s[n] == 0);

That is nice and simple, but it makes ten comparisons for each character in s, where only two are needed. Of course it would be a good approach if the set of characters you're testing against is not contiguous, unlike 0..9.

Good news then, it’s also linear time like the marginally faster but enormously grotesque for loop provided previously. I would take that clarity of intent a hundred times over squeezing a couple of comparisons out.

Re: Programming Idioms

#44
post #28

Surprisingly many failures of reading comprehension in the implementations here: https://programming-idioms.org/idiom/184/tomorrow I’ve always found it interesting to consider the simplest possible spec you could give 100 programmers and receive no bugs in return.

Hmm. There are more wrong implementations than correct ones as by now.

The core of the problem was noted already: Obviously most people can't read.

That's especially "funny" when thinking about all the fuss that is made about teaching children programming in school. They should start with teaching them reading.

I don't even mean this snarky. The state of affairs is actually depressing and I would welcome it very much if more people around would be able to read, understanding what's written. Would make a lot of things easier for everybody I guess.

Re: Programming Idioms

#45
post #40

Earlier quoted context omitted.

That is one of the most confusing pieces of C code I have seen lately. And it fails on an empty string: I would expect it to set b to 1 for an empty string, but it sets it to 0. Of course that could easily be fixed by setting b to 1 at the top. Also, code like this should always be put inside a function that returns a value, not just written inline. Making it a function allows simpler and more understandable code too…

You do realize it returns 1 for an empty string right? I mean it doesn't have any digits in it... What about adding a check of str[0] == 0 -> return 0 Also, giving char str[] will make it char* str. Which can be null. This may cause reading a random memory location (possibly segfault or use-after-free) edit: I get the comments but empty string still contains no digits. Given the regex would be ^[0-9]+ (+ instead of *…

“contains only digits” isn’t synonymous with “not (doesn’t have any digits)”

It is synonymous with “none of the characters is a non-digit”, which is true for the empty string.

Re: Programming Idioms

#46
post #41
post #28

Surprisingly many failures of reading comprehension in the implementations here: https://programming-idioms.org/idiom/184/tomorrow I’ve always found it interesting to consider the simplest possible spec you could give 100 programmers and receive no bugs in return.

What do you call a spec that any programmer can understand and correctly describes the problem and its desired outcome exactly? A program

That description doesn't apply for most programs though.

* Not all programmers can understand all programs

* Most programs don't describe the problem exactly

* Almost no program describes the desired outcome exactly

Re: Programming Idioms

#47
post #41

Earlier quoted context omitted.

What do you call a spec that any programmer can understand and correctly describes the problem and its desired outcome exactly? A program

That description doesn't apply for most programs though. * Not all programmers can understand all programs * Most programs don't describe the problem exactly * Almost no program describes the desired outcome exactly

I think the point is that the implementation of the program exactly describes the behaviour of the program. If you take the program as a description of what the program is supposed to do, then what it is supposed to do is pretty unambiguous!

(Also debatable, for example if correct operation of the program depends on some property of its environment that can't always be relied upon.)

Re: Programming Idioms

#48
I found out that a good way to learn idioms for a given language is to do some simple katas on codewars.com and then review the most upvoted solutions.

Re: Programming Idioms

#49
post #26

There's a similar project http://rosettacode.org/wiki/Rosetta_Code .

I made something similar myself, although it's only printing. https://github.com/FormerlyChucks/jello

Your github username is a nazi, alt-right dogwhistle. Mods, please handle this.

Re: Programming Idioms

#50
post #41

Earlier quoted context omitted.

What do you call a spec that any programmer can understand and correctly describes the problem and its desired outcome exactly? A program

That description doesn't apply for most programs though. * Not all programmers can understand all programs * Most programs don't describe the problem exactly * Almost no program describes the desired outcome exactly

It's a joke - the point behind it is that most of programming around specs is refining the spec until it is sufficiently well defined as a program.
Post reply on HN