4 ms·

> "A language that doesn't affect the way you think about programming, is not worth knowing" Makes a good quote, but I don't buy it from a practical perspectiv

• rauljara 14y ago
  I mostly agree with you in that there are perfectly valid reasons for learning similar languages. The quote is too strong, too absolute. But I still have a weakness for the quote because learning languages that alter your thinking is so much more useful than learning ones that don't. As to ruby/python, I only have a superficial knowledge of Python, so please correct me if I'm wrong, but my understanding is that ruby blocks let you do thinks you can't in python. Rspec is one of the examples that gets talked about a lot. But if I were asked to sum all the numbers divisible by both 3 and 5 between 1 and 100 in Ruby, I'd do it like this (1..100).select{|a| a % 3 == 0}.select{|a| a % 5 == 0}.inject(&:+) In my mind, that is a completely different way of solving the problem than by running a loop. My understanding is that you can't really do something like that conveniently in Python. Though, like I said, I really don't know python, so please do correct me if I have that wrong.
  • Thrymr 14y ago
    sum([x for x in xrange(1, 101) if x % 3 == 0 and x % 5 == 0]) edit: actually sum the list. Of course, it's even shorter if you realize you can write it as: sum([x for x in xrange(1, 101) if x % 15 == 0])
    • jgeralnik 14y ago
      You're better off making that a generator: sum((x for x in xrange(1, 101) if x % 3 == 0 and x % 5 == 0)) Notice the parenthesis instead of square brackets. Your version actually creates a list in memory. A generator generates the items one by one and doesn't need to store them all at the same time.
      • dbaupp 14y ago
        You can just write it as sum(x for x in xrange(1,101) if x % 3 == 0 and x % 5 == 0) and skip the inner set of parenthesis; the parenthesis on a generator expression are not needed if it is the only argument to a function.
        • darkestkhan 14y ago
          Can't you all think for a bit? All of These solutions are O (n) in both time and space... there is solution that will take O (1) time and space - and I think that you learned it in math class at (latest) high school (hint: arithmetic progression)
          • dbaupp 14y ago
            Seriously? The discussion is about language features, not optimal algorithms. One could imagine the question was actually "sum BusyBeaver(n) for n divisible by 3 and 5 between 1 and 100", i.e. no closed form. In Python: sum(BusyBeaver(x) for x in xrange(1,101) if x % 3 == 0 and x % 5 == 0) (And yes, if one was being really pedantic, one could replace the condition with x % 15 == 0.)
            • darkestkhan 14y ago
              The thing is that people start using those libraries w/o thinking before - and theirs' solutions end up doing much more work than is needed
              • delinka 14y ago
                This could be said of most anything high level.
      • deleted 14y ago
        [deleted]
      • the_cat_kittles 14y ago
        true, but xrange(1,101) is so tiny, who cares!
  • RegEx 14y ago
    Despite the answers provided by fellow HNers, even if there wasn't a loop-less way to handle the scenario in Python, I assert that taking advantage of a language feature doesn't necessarily equate to "altering your thinking". You may find yourself, though, altering your thinking after defining language features have accumulated to a certain degree.
    • Thrymr 14y ago
      I agree, the quote is more applicable to conceptually very different languages (e.g. Lisp, Forth, and Smalltalk) than to clever features of particular languages.
  • deleted 14y ago
    [deleted]
  • vuknje 14y ago
    Or in javascript.. new Array(100).join(1).split(1) .map((function() { var i = 0; return function() {return ++i;}})()) .filter(function(x) { return !(x % 15); }) .reduce(function(x, a) { return a += x; }, 0);
• zohebv 14y ago
  Some examples 1. Purely declarative animations in a general purpose language http://conal.net/fran/tutorial.htm http://conal.net/fran/tutorial.htm 2. A recursive descent parser where you can declare your grammar as in yacc i.e. it is not a separate compiler generator but a regular library, and the code is type safe unlike yacc. The best part is that the actual library is just 2 lines of code, thanks to the magic of lazy evaluation and a powerful type system. result v = \inp -> [(v,inp)] p `bind` f = \inp -> concat [f v out | (v,out) <- p inp] http://eprints.nottingham.ac.uk/237/1/monparsing.pdf http://eprints.nottingham.ac.uk/237/1/monparsing.pdf