These really aren't idioms. An idiom in natural language is a phrase or saying whose meaning cannot be understood without someone telling you what it's supposed to mean (that is, you can't figure it out just by reading the words).<p>In programming, an idiom is a common, accepted way of accomplishing a task which you wouldn't figure out to do all on your own and whose meaning isn't obvious to programmers of other languages.<p>I suppose you could argue that certain idioms are more or less universal: using "i" as the index in a loop isn't obvious even if you know a lot of math (why not use j?).<p>But no one who doesn't program Python is going to figure out the first thing you do in any new Python project is write the line:<p><pre><code> if __name__ == "__main__":
main()
</code></pre>
The fact that it's impenetrable if it's not first explained to you that you should do that is what makes it idiomatic.<p>Idiomatic also means particular to a specific person or group. If your website is based on comparing the same idiom in multiple languages, that's a good indication it's not actually idiomatic. That's probably just a common task.
First example I've checked is wrong [1]. Shuffle a list, with a static Random object initialization. Using a static random object is not thread-safe in .NET.<p>"One common solution is to use a static field to store a single instance of Random and reuse it. That’s okay in Java (where Random is thread-safe) but it’s not so good in .NET – if you use the same instance repeatedly from .NET, you can corrupt the internal data structures." [2]<p>Very often the very same resources which claim to be the source of truth provide bad code examples.<p>[1] <a href="https://www.programming-idioms.org/cheatsheet/Csharp" rel="nofollow">https://www.programming-idioms.org/cheatsheet/Csharp</a><p>[2] <a href="https://codeblog.jonskeet.uk/2009/11/04/revisiting-randomness" rel="nofollow">https://codeblog.jonskeet.uk/2009/11/04/revisiting-randomnes...</a>
I'd like to draw people's attention away from this and to Rosetta Code[1].<p>Programming Idioms has a slightly more modern interface, but what matters more is the content. Rosetta Code has <i>more</i> content and <i>better</i> content. If you don't like Rosetta Code's interface, I'd rather you tried to improve Rosetta Code rather than splintering the already-small community of people producing this sort of content.<p>[1] <a href="https://rosettacode.org/wiki/Rosetta_Code" rel="nofollow">https://rosettacode.org/wiki/Rosetta_Code</a>
Cool project.<p>I'm a bit reluctant to trust the quality of this, however.<p>The first example I looked up was "Format date YYYY-MM-DD" in Python, which wanted me to use "isoformat()", which produces something else.<p>It was easy to correct, but I'd like to see a more "democratic" approach to getting correct examples, not just taking the latest one as fact.<p>edit: Sorry, more precise critique of the usage of "isoformat" would be "which _might_ produce something else" (it depends on the resolution of info in the date object).
Hm... <i>Idiom #186 Exit program cleanly</i> for <i>Python</i>:<p><pre><code> import sys
sys.exit(0)
</code></pre>
Well, I guess I've been reinventing the wheel for my whole career... and thank god I did, my wheel is not only more performant, but also shorter and produces cleaner code (in my subjective opinion). As simple as:<p><pre><code> # nothing</code></pre>
If people didn't re-invent the wheel we'd still be using wheels made of rock like the Flintstones (or at best wooden wheel, like 4 millennia ago).
The reason I re-invent wheels is because I don't know the idiom I need to Google for.<p>I know what I need. I don't know what it's called in English. It's faster to re-implement it than to learn the vocabulary.
The C implementation (and probably most of the other implementations) of Idiom #41 (reverse a string) doesn't correctly handle UTF-8; it just reverses an array of bytes. Normally I wouldn't take objection to this, but:<p>1) The problem description specifies "Each character must be handled correctly regardless its number of bytes in memory.", for which the C implementation rather plainly fails.<p>2) UTF-8 is so ubiquitous nowadays that any string-manipulating function that fails to correctly handle multibyte UTF-8 characters ought to be considered broken.
I love the "check if integer addition will overflow" in Python:<p>def adding_will_overflow(x, y):
return False<p>I have no idea if it's actually true but I find that funny.
Do these count as “idioms”? Are these problems commonly messed up? I sampled a dozen or so and all the ones I saw are snippets for doing really basic tasks, but didn’t seem particularly idiomatic, nor like tasks that cause a lot of bugs...
If you're going to list Fortran, COBOL, Prolog, Ada, Lisp, etc - I'm of the opinion that you need to list BASIC as well.<p>You list VB - but you don't say if this is VB.NET, or prior VB versions (3,4,5,6)? VB.NET isn't quite identical to the others...<p>...and VB is nothing like plain-old BASIC (and later dialects). In fact, you might lump them all under BASIC, as VB owes more to BASIC than being it's own thing (though VB.NET seems more a name than being BASIC - just my opinion, though, as a long time ago VB3-6 coder - I'd call it "BASIC-ish").<p>Other than that - this looks interesting. UI could use a bit more work, but seems like a good start.
Quality of the site aside, this concept would be great with JSON-API or something so it can be integrated with <insert favorite editor/IDE here>.
Hey, it's a neat project. Of course it could use improvements and a few disclaimers, but hey. Good on you for making it.<p>Added a request for Racket support!
The wheel is, in terms of elegance and function, a perfect machine - it can't be simplified, nor can it be improved upon. The point of the idiom being that any attempt to do so will either lead back to the wheel, or an inferior, unnecessarily complex alternative.<p>The problem with applying this to programming is the implication that there are languages, frameworks, patterns, and idioms which are equivalent to the wheel, in that there always exists one objectively correct, perfect solution which can't be improved upon. I don't believe programming has the equivalent of a wheel, yet.<p>What people tend to mean when they say "don't reinvent the wheel" in the context of programming is either "don't waste time writing code that already exists and is <i>adequate</i>" or "don't use $X because I like $Y."
I think what happens with this is too much context is lost and in the end you can't really describe what the "right way" to do things is.<p>Is the right way to delete a file<p><pre><code> result = os.deletefile(path)
</code></pre>
or is it<p><pre><code> try { os.deletefile(path) } catch (ex) { log(ex) }
</code></pre>
and what is the difference? Both may be valid and idiomatic <i>in the same language</i>. With more context such as a forum dialog or a StackOverflow question, these things are usually ironed out. But trying to do the same thing in Haskell (where you might have monadic error handling) or java (where you might have some exception handling chain) is very different even though the same function call is used in the end to actually delete a file.
It seems like the checklist blurs the lines between a language and standard libraries, something that shouldn’t be controversial but should be noted.<p>The checklist also seems to favor dynamic languages. E.g. does Go deserve to miss a checkmark because you can’t determine if a variable exists at runtime (only at compile time)? I can sorta see the source inclusion checkbox, but it’s not entirely clear from the example if this is testing for a macro support, AOP, or dynamic loading of libraries.
The idea is great. But the low quality of many code examples puts me off. For me it would only work if the examples shown are made by a selection of top level developers. Then it would be really nice actually.<p>About the site design, the little menu on the left should better not move the content window to the right. Now, when you scroll down in 'all idioms' for example, the list is right aligned and left has useless whitespace. A horizontal menu or dropdown would be better I guess.
This submission being popular in HN caused an interesting traffic spike in Programming Idioms. Here is a detailed recital of the technical and financial consequences: <a href="https://medium.com/google-cloud/surviving-traffic-spike-from-hacker-news-my-dreaded-google-cloud-invoice-6b940dd9eba6" rel="nofollow">https://medium.com/google-cloud/surviving-traffic-spike-from...</a>
This site would really gain by having an upvote mechanism, this way users would know what is the "best" way of doing things. Plus, needs more languages.
I took a gander at a bunch of the C++ ones. They are pretty horrible. It looks like direct translations from generic snippets (just a syntax transformation).
Fancy data structure manipulation perhaps should be part of a library (API) and not "built in" to the base language. The best languages make it easy to use vast API's rather than hard-wire features into syntax.
Well, I knew it was only a matter of time before someone made this. This was one of my favorite "some day I'll have time and can make this site" ideas.
Reinventing the wheel is a good idea. It's how you learn. Programmers who say "don't reinvent the wheel" don't understand how the craft of wheel making works.
i like looking at how other languages do things. i'm pushed away from Go and pulled toward Rust, the two languages i've been thinking of getting deep into. like the currying example. that move keyword seems pretty nice.
Reminds me of <a href="http://www.rosettacode.org/wiki/Rosetta_Code" rel="nofollow">http://www.rosettacode.org/wiki/Rosetta_Code</a>