Interesting distinction between idioms and mores. ( I was not aware of it.) However a difference between social mores and technical ones is, that technical mores can acquire meaning since more time is spend to optimize the preferred way.
Programming Languages Have Social Mores Not Idioms
91–100 of 179 posts
Re: Programming Languages Have Social Mores Not Idioms
#92Earlier quoted context omitted.
To clarify, I don't think my original post implied that you were against teaching people how to learn each. Nor do I want to start out teaching beginning rubyists everything all at once. It was more to point out how important the mindset of each is. That's the mindset that you want to reach. And I'm not sure that teaching a construct that you'll never end up using is helpful. I think it just creates a mental construc…
> I'm not sure that teaching a construct that you'll never end up using is helpful. But that was precisely Zed's point! You will certainly end up using it, though you may never use it in Ruby . .each is not transferable, and for-loops are. Zed's teaching Ruby as an introduction to programming , not just to Ruby in itself.
each is definitively transferable for many languages.
Javascript has Array.map(), which is almost the same:
var numbers = [1, 4, 9];
var roots = numbers.map(Math.sqrt);
/* roots is now [1, 2, 3], numbers is still [1, 4, 9] */
IEnumerable squares = Enumerable.Range(1, 10).Select(x => x * x);
/* squares is [1, 4, 9, 16, ...] */
names = ["mary", "john"]
caps = map(lambda name: name.upper(), names)Re: Programming Languages Have Social Mores Not Idioms
#93I disagree about the 'each' being a 'social more' as opposed to 'for'. The most important thing you will ever learn about conditional loops is that effectively they are all shorthand for combinations of compare statements and conditional jumps in assembly. Past that really, none are more conceptually simple than any other... So the analogy of 'each' being "piece of cake" to 'for' being "easy" doesn't really hold to m…
Well, at least in Ruby, there's one way in which each is more abstracted than for; each creates a new scope, while for does not. This actually is a reason I'd prefer to teach each.
On the other hand, I agree with Zed that for is a better abstraction than each, and I disagree that each and for are at the same level of abstraction. If you're approaching it in the abstract, sure, they're both pretty high-level. But each is as close to pure functional as you get and for is plain iterative.
And assembly is iterative, so I'd call for better for giving people a sense of how the metal works. Which, I think, is important for newbies.
Re: Programming Languages Have Social Mores Not Idioms
#94Why would you need to teach inheritance, mixins, message passing, enumerable, etc. to teach .each as a first looping construct? (And why don't you have to teach whatever powers Ruby's for ... in loop to teach it ?) That seems to be like saying that before you can teach `main = putStrLn "Hello World"` as a Haskell hello world program, you need to go into the theoretical grounding for monads.
Well, I think it depends on the person who you're trying to teach. I, for one, spent nearly two years before I even started learning Haskell, precisely because I can't bear the thought of using constructs I don't understand. In this two years time I learned OCaml, Scheme and Erlang, not to mention read countless implementations of monads in these and other languages, just so I could start learning Haskell.
As a side effect (haha) I realized that a) a monad is very interesting and useful concept, no matter in which language; b) Haskell "cheats" heavily in order to be able to do I/O (and side effects) and c) it's this cheating (ie. IO part of IO Monad) which makes it hard to understand (I really prefer Clean's approach, where you get explicit 'world' object to manipulate). As a result I don't know when or even if I'll learn Haskell - and it's caused solely by the lack of full, up-front explanation of Haskell I/O model in most (all?) learning materials for the language.
So, for me, yes - you need to teach me "theoretical grounding of monads" and more or you'll lose me. I never read Zed's books, but I think he's targeting people like me, so your criticism is invalid.
Re: Programming Languages Have Social Mores Not Idioms
#95Before I learned Ruby, I knew C, Obj-C, C++, Java...all languages that have and use "for" extensively. Coming to Ruby and learning "each" was an eye opening experience for me. Suddenly, the whole notion of iterators become clear to me. (While I had used them in the past, I had only marginally understood them.) After using "each" for a while, I came to realize that I was programming in a functional style without even…
Just to be pedantic, it is actually the Smalltalk "do:". :)
As is ruby's entire object model basically. It's Smalltalk with a pythonish basic'ish pearlish syntax.
Re: Programming Languages Have Social Mores Not Idioms
#96Earlier quoted context omitted.
You are right, and once again I am not against using functional programming, OOP, message passing, or any of the things I mention about .each. I'm against using .each as a first looping construct. In fact, go look at your supposedly better last line of code and tell me if you think a newbie would even begin to comprehend that? Hell I'm a programming veteran and Ruby veteran and I want to metaphorically punch you in t…
I'm guessing Zed first learned to program using for loops so they look "natural" and easier for beginners to learn than functional callbacks. That seems like a testable proposition, but I'm guessing it isn't so. There aren't too many situations in life outside programming and racing where people go around in circles to get something done. Furthermore, the choice of print in the example begs the question. Are you teac…
FWIW I learned on BASIC. "GOTO" looks natural to me. It's also much closer to the machine. Structured programming is a prettification of test-and-jump, and you have to be able to see through it, to use it well.
Functional programming, on the other hand, is a bit of a conceptual leap away from the metal. If you're mapping two functions over a stream of data how many loops is it? In a dumb language like Ruby, it will be as many as your map() calls. But in Haskell, it will fuse them into one loop doing two operations. And the thing with functional programming is, you're not supposed to care - except, you do have to. Generating an endless unresolved series of thunks in Haskell is a beginner mistake. But if you can't see through the functional list-flipping to the generation and consumption of callable heap objects in a test-and-jump cycle, you're going to be scratching your head.
My answer would be to teach both assembler and FP, and step up and down simultaneously. Start on Excel and move to Haskell, while also starting on 6502 or some such toy assembler, and moving to C, and meet in the middle at Scheme.
Re: Programming Languages Have Social Mores Not Idioms
#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?
Re: Programming Languages Have Social Mores Not Idioms
#98Why would you need to teach inheritance, mixins, message passing, enumerable, etc. to teach .each as a first looping construct? (And why don't you have to teach whatever powers Ruby's for ... in loop to teach it ?) That seems to be like saying that before you can teach `main = putStrLn "Hello World"` as a Haskell hello world program, you need to go into the theoretical grounding for monads.
Well, I think it depends on the person who you're trying to teach. I, for one, spent nearly two years before I even started learning Haskell, precisely because I can't bear the thought of using constructs I don't understand. In this two years time I learned OCaml, Scheme and Erlang, not to mention read countless implementations of monads in these and other languages, just so I could start learning Haskell. As a side…
And yet Zed seems to think he can teach the basis by which Ruby's for ... in works without laying nearly the same amount of groundwork. That's the real question---why do you need to go over so much in so much detail in the one case, but somehow the other is significantly simpler? (Especially if the second is actually syntactic sugar for the first!)
"As a result I don't know when or even if I'll learn Haskell - and it's caused solely by the lack of full, up-front explanation of Haskell I/O model in most (all?) learning materials for the language."
The IO monad is just like the State monad, except you can't get the State back out. You're passing around RealWorld. (In any event the "theoretical grounding of monads" doesn't tell you anything about IO. It would tell you things about monads in general---monadic bind and return and join, etc. Haskell may be doing weird things with its IO monad, but your objection actually bypasses what I was talking about, which is the category theory shee that Haskell is known for, but is also found in, say, Scala, where IO is not done through a special monad.)
ETA: given that these books are apparently for people who might need to be taught about variables in the first place, I wonder how accurate your conception of how like you they are is, and how much that resemblance applies to the case at hand. To reiterate, I can't really understand why any explanation that would pass muster with Zed for adequately explaining how "for foo in bar" works in Ruby, including the binding of the name foo, the repeated execution of the body, etc., couldn't be straightforwardly adapted to "bar.each { |foo| ... }". Would the adaptation not get into the weeds of the .each method? Indeed it would not. But then, the explanation of "for ... each" also didn't get into the weeds of that. Both should be acceptable if either is.
Re: Programming Languages Have Social Mores Not Idioms
#99The word "idiom" has two different senses. First, there's the sense that the author is discussing. In this sense idioms are expressions whose meanings aren't derivable from the meanings of their parts (linguists call this "non-compositionality"). The other sense of "idiom" simply means "an expression that characterizes idiomatic speech. Now "idiomatic" also has two senses. First, it can mean "having to do with idioms…
Looking at your own linked definition I think you're wrong: 1 : of, relating to, or conforming to idiom 2 : peculiar to a particular group, individual, or style That again says it's a local construct that isn't a clear universal usage. If you want to be clear in your writing then you avoid idiomatic speech. This also doesn't disprove my point that the way these supposed "idioms" cause derision and overreaction says t…
I think the use of 'idiomatic' that daviddaviddavid had in mind is this one[1]:
1. a. Peculiar to or characteristic of a given language. b. Characterized by proficient use of idiomatic expressions: a foreigner who speaks idiomatic English.
That use of the word 'idiomatic' is very common, and although it's related to the word idiom, it's not quite the same thing. An idiom, as you say, is a phrase that you can't guess the meaning of just by glossing each of the individual words (a favorite example - in Puerto Rico, though not all Spanish-speaking countries, a flatterer is a 'lambeojo', literally 'eye-licker'). But someone who speaks Spanish idiomatically or who writes idiomatic French does so 'like a native'. It's a good thing. So when someone says that 'each' is 'idiomatic Ruby', that's probably what they have in mind.
All of that said, I can understand wanting to teach beginners the for loop first. But I don't think a Ruby course should finish without looking at each. If a person plans to read any real Ruby, they had better be ready for lots of iteration with each.
Re: Programming Languages Have Social Mores Not Idioms
#100.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?
Going out on a limb here, but I think "for" is a looping function.