Programming Languages Have Social Mores Not Idioms • Hacker News Board

Re: Programming Languages Have Social Mores Not Idioms

#161

Post by sp4rki » Mon, Aug 20, 2012, 3:40 PM UTC

judofyr wrote: post #151

sp4rki wrote: post #132

Earlier quoted context omitted.

Understanding how to drive vs building a car is the same thing as understanding how to use a program vs building the program. Once again the point is that if you want to learn how to program in a specific language, you need to understand it's concepts and patterns. It's akin to the fact that if you want to learn how to build a car, you need to understand it's mechanics. You can easily take whatever you find in the in…

> Once again the point is that if you want to learn how to program in a specific language, you need to understand it's concepts and patterns. And it's perfectly fine to initally learn that `.each { |name| … }` as a concept for looping over something. > That's OK if you need a quick solution for a small problem, but it's not when your goal in itself is to learn how to program (in Ruby)... I'm not sure what kind of new…

Actually I agree that new programmers are better of starting with .each, and also that experienced ones can also benefit from an overload of .each to change the patterns they are used to. I commented on why I disagree with Zed's decision that each should be taught later before even getting to this "trollish" thread.

Regarding your second and third bullet points: As I've tried to explain before, there is a tremendous difference between someone reading "The Ruby Programming Language" and "The Ruby Way" trying to "learn" the Ruby programming language, and a person who goes from tutorial, to example, to tutorial, to built product. I can certainly relate to the latter since I started learning C and even a little Asm (thank you SoftIce) by myself when I was 12 thanks to a small stint in a cracking group. These days, though, after programming for around 17 years, when I want to use a new programming language I read on it's syntax, it's methodology, it's patterns... Let's do the analogy thing here: If you want to "learn" multiplication as a child, you have two options. Memorize the multiplication tables, since it's improbable that you'll need anything higher, or actually learn the mechanics of multiplication and how to carry numbers up to the next order of magnitude. There are two completely different monsters. In one you learn what you need to do to create something specific. In the other you learn everything there is to learn about a topic to further your understanding of a topic. Learning the how and the why are two completely different things that get emphasized depending on you needs. My point here is that we're trying to discuss the best methodology for the teaching of a language. In a book. Generally meant to leave students with a complete understanding of the subject at matter.

A small aside, I didn't mean ruby blocks on that last section, I just meant block in the general sense. In any case, I totally agree on the last line you typed. And that's what I've been trying to get the OP to understand. I agree to teach each first because of a plethora of reasons I've already discussed here, but I don't agree Zed is a "troll" because he thinks the explanation of core concepts in his book should be more linear.

Re: Programming Languages Have Social Mores Not Idioms

#162

Post by gruseom » Mon, Aug 20, 2012, 5:09 PM UTC

batista wrote: post #156

gruseom wrote: post #15

I don't know where on earth he got "By definition an idiom is something you remove from good clean writing," which is obviously not true (edit: and itself contains an idiom, "good clean", which you can recognize as an idiom simply by reversing the two words), but I think he's right about the important thing, programming language mores. It's crazy odd how what appear as purely technical constructs become nuclei for al…

> I don't know where on earth he got "By definition an idiom is something you remove from good clean writing," which is obviously not true Maybe from all those classic books on writing, like the "Chicago Manual of Style", "On Writing Well" and "The Elements of Style", which all agree on the point. Where you got this bizarro impression that idioms are NOT to be avoided in writing? Idioms are cliches, and they needless…

I suppose it's foolish to belabor the point, but (a) is it just me or are you sounding a bit of a bully? and (b) everything you wrote is untrue.

My impression comes from observing language: it is saturated with idioms. You can't throw them all out (without a lot of unnatural effort) nor is there any need to. You might as well say that a musician should use only notes and not chords, or avoid standard chord progressions. If you can find any significant piece of writing that avoids idioms, I'd like to see it.

Idioms are not cliches. An idiom is a phrase whose meaning is more than the sum of its words. A cliche is a phrase that has become hackneyed through overuse. (Nor, by the way, are cliches necessarily obfuscatory. "Get your ducks in a row" is, but "Live and learn" is not.)

Style manuals have their place but are hardly scripture, and there are countless examples of great writers breaking every rule in the book. Indeed, Strunk & White breaks its own rules, sometimes when describing the very rule it's breaking (which is part of its charm [1]). So even if your claim were correct, it wouldn't prove anything. But I'm pretty sure it isn't correct. Since you claim that Chicago, Zinsser, and Strunk & White all agree on the point, please show us where; I'd like to see. All three of those texts are searchable online and I couldn't come up with anything. But I only tried for a few minutes.

[1] Just for fun, here is an example: "Students of the language will argue that try and has won through and become idiom. Indeed it has, and it is relaxed and acceptable. But try to is precise, and when you are writing formal prose, try and write try to." How can anyone not love E.B. White?

Re: Programming Languages Have Social Mores Not Idioms

#163

Post by pbiggar » Mon, Aug 20, 2012, 5:48 PM UTC

evincarofautumn wrote: post #154

pbiggar wrote: post #140

Earlier quoted context omitted.

Not well. It's described for the entire final quarter of the article, in the section marked "Why .each Is A Horrible First Looping Construct".

“for” is the raw loopy stuff out of which other looping constructs are made—it’s fairly arbitrary. If you’re implementing an iteration construct, then by all means “for” is the thing to use. But in normal use it’s best to express your intent through more common, composable constructs such as maps, folds, and zips. There’s certainly less overhead in reading a non-trivial loop written as a composition than one written…

I have no dog in this fight, I was just calling out the hyperbole on the ancestor comment.

Re: Programming Languages Have Social Mores Not Idioms

#164

Post by yxhuvud » Mon, Aug 20, 2012, 6:07 PM UTC

cdcarter wrote: post #16

losvedir wrote: post #10

Earlier quoted context omitted.

I, too, think like that, although Ruby's nomenclature frequently confuses me. Coming from Scheme/Haskell I'm quite at home with 'map', 'filter', and 'fold'. However, Ruby uses the methods you mention, "collect" and "inject", and these in turn have a few synonyms. And as best I can tell, Ruby's 'filter' variant, 'find' collides with ActiveRecord. What's the general community take on these functions? Which name is comm…

I'd say that most Rubyists use #select, whereas #find is a more literate alias that few use outside of AR.

They are not synonyms. Find will only find one result.

Re: Programming Languages Have Social Mores Not Idioms

#165

Post by yxhuvud » Mon, Aug 20, 2012, 6:11 PM UTC

DannoHung wrote: post #97

.each isn't a looping construct. It is mapping function. Looping constructs allow control over the loop iteration. Mapping functions do not. People probably shouldn't confuse them. Does Ruby actually have a looping function?

while, until and begin .. end while/until.

And loop, of course.

Re: Programming Languages Have Social Mores Not Idioms

#166

Post by pacala » Mon, Aug 20, 2012, 7:01 PM UTC

sp4rki wrote: post #161

judofyr wrote: post #151

Earlier quoted context omitted.

> Once again the point is that if you want to learn how to program in a specific language, you need to understand it's concepts and patterns. And it's perfectly fine to initally learn that `.each { |name| … }` as a concept for looping over something. > That's OK if you need a quick solution for a small problem, but it's not when your goal in itself is to learn how to program (in Ruby)... I'm not sure what kind of new…

Actually I agree that new programmers are better of starting with .each, and also that experienced ones can also benefit from an overload of .each to change the patterns they are used to. I commented on why I disagree with Zed's decision that each should be taught later before even getting to this "trollish" thread. Regarding your second and third bullet points: As I've tried to explain before, there is a tremendous…

"OP" here. The troll characterization it earned by throwing things like "Mixins vs. Multiple Inheritance" in the list of prerequisites necessary to understand the .each example, plus the strong "indoctrination" rant that precedes.

One could troll the for do construct example to require understanding of operational semantics, denotational semantics and / or abstract interpretation and gaulois connections, plus deriving the arithmetic rules in the calculus of constructions starting from the simple (sic) datatype definition Nat = Zero | Succ (Zero). All while ranting about the indoctrination in the evil ways of Turing machines.

Re: Programming Languages Have Social Mores Not Idioms

#167

Post by thedufer » Mon, Aug 20, 2012, 7:02 PM UTC

pacala wrote: post #119

thedufer wrote: post #106

Earlier quoted context omitted.

In a very real sense, imperative programming _is_ natural. Its much closer to how computers work. Whether this means that its an easier way to learn is up for debate. (For the record, I think it is easier for a majority of people, but that functional would be easier for a significant minority.) Your phrasing of that part just kind of bothered me. I think we already teach beginners that you calculate the sum of the sq…

Natural != how the machine works. Few of us have the faintest clue about how the laws of thermodynamics apply to the internal combustion engine or how solid state physics leads to semiconductors leads to electronics leads to electronic injection. Yet we all drive cars as naturally as we walk.

I'd argue that your analogy strengthens my point. In their original form, cars involved people manipulating the mechanical parts as directly as possible (the steering wheel was completely tied to the front axle, the gas pedal, brake, starting crank all directly controlled a single aspect). And yet, we drive cars so naturally. I think using the word natural in this sense makes a lot of sense.

Re: Programming Languages Have Social Mores Not Idioms

#168

Post by thedufer » Mon, Aug 20, 2012, 7:05 PM UTC

webreac wrote: post #137

tsurantino wrote: post #114

Earlier quoted context omitted.

I just spent the last two weeks learning the Ruby language (but I come from other programming languages). I'd argue that learning .each vs. normal looping has numerous benefits. First, this is the way most people loop most things in Ruby. More importantly, however, teaching .each enabled me to be more openminded towards learning "yield" and blocks. In a way, without having learned about .each first, and coming into R…

Learning a new language requires that you adapt your way of thinking. Idioms are a way to familiarize with the spirit of a language. Starting to teach languages avoiding what makes the language so special is counter productive. As soon as your students know a basic way to program, they won't be inclined to learn the "good way".

I'm not sure how else to say this, but taking things out of context still does not make them wrong. This is about teaching the concept of programming. If you're learning a particular language, yes, use the idioms. If you're teaching someone how to code, teach concepts that cross languages.

Re: Programming Languages Have Social Mores Not Idioms

#169

Post by ebiester » Mon, Aug 20, 2012, 7:11 PM UTC

pacala wrote: post #158

ebiester wrote: post #144

Earlier quoted context omitted.

"Basic elementary concept, if you don't get this, you should not be coding yet." The target audience of his book has just learned what a variable and an array is. Since the book as advertized as learning "the hard way," it seems to explicitly attempt to give an insight to what the computer is doing when you tell it to do something. That is, I sure as hell could translate a for loop to psuedo-assembly, and I could pro…

You can teach .each { | | } exactly as you would teach for in do end. The .each variant allows the student to discover a rich palette of correlations as he progresses, the for do end variant is a dead end he needs to forget sooner or later. As a student, I know precisely which variant I'd chose. Do you?

So, define a closure in terms that someone who has just learned what a variable is can understand.

"Just memorize this syntax and do it" is not allowed.

Re: Programming Languages Have Social Mores Not Idioms

#170

Post by tptacek » Mon, Aug 20, 2012, 7:32 PM UTC

gruseom wrote: post #162

batista wrote: post #156

Earlier quoted context omitted.

> I don't know where on earth he got "By definition an idiom is something you remove from good clean writing," which is obviously not true Maybe from all those classic books on writing, like the "Chicago Manual of Style", "On Writing Well" and "The Elements of Style", which all agree on the point. Where you got this bizarro impression that idioms are NOT to be avoided in writing? Idioms are cliches, and they needless…

I suppose it's foolish to belabor the point, but (a) is it just me or are you sounding a bit of a bully? and (b) everything you wrote is untrue. My impression comes from observing language: it is saturated with idioms. You can't throw them all out (without a lot of unnatural effort) nor is there any need to. You might as well say that a musician should use only notes and not chords, or avoid standard chord progressio…

This is probably completely apparent to anyone who's had to learn an ancient language (4 years Jesuit high school Latin can I get a qui qui?!) --- to understand ancient Latin you need to learn the idiom, not because the Romans were overly fond of cliche, but because they were speaking in a different historical context in which their audience could be expected to understand that "nut" was synonymous with "toy", or Greeks could be expected not to track dates on calendars.

So just as reading the simply Yacc grammar for MRI Ruby is not a particularly great plan for mastering Ruby, learning the rules of grammar and memorizing individual vocabulary words isn't going to give you convincing conversational mastery of a spoken language.