91–100 of 199 posts
*Yukihiro Matsumoto, creator of Ruby I'm not sure everyone is familiar enough with Ruby to know who Matz is.
If they don't know who Matz is, are they likely to know who Yukihiro Matsumoto is? EDIT: Interesting fact: I believe this is now my most downvoted comment in five years on HN, at effectively -7. Never would have guessed. I'm not exactly sure what it says, but I thought it was an interesting data point.
Earlier quoted context omitted.
Streaming, pattern matching, and regex combined in one sounds pretty damn cool. Might also be nice to borrow some of Scala's features for terser code than Ruby, like ary | { _ + 5 } instead of ary | { |el| el + 5 }
I prefer {|el| el + 5} more than { _ + 5 } the latter is too implicit for my taste, also I imagine it could become more confusing in a more complex context.
Compare:
ary.map(_ * 2)
ary.map(x => x * 2)
Of course, in a more functional language you could perhaps just write
ary.map(* 2)(-> (read) (eval) (print) (loop))
using python-sh in hy this is possible:
(-> (cat "/usr/share/dict/words") (grep "-E" "^hy") (wc "-l"))
Earlier quoted context omitted.
If they don't know who Matz is, are they likely to know who Yukihiro Matsumoto is? EDIT: Interesting fact: I believe this is now my most downvoted comment in five years on HN, at effectively -7. Never would have guessed. I'm not exactly sure what it says, but I thought it was an interesting data point.
I, for one, remember the full name but not "Matz"
Earlier quoted context omitted.
Really? I find that one line far more pleasant than the Python example above it, with variables being assigned, etc. Both are quite clear in their intention, I think, assuming you recognize "join". I don't even recognize the language of the one-liner, but it makes perfect sense to me as a reader. It looks like a Perlish solution, but the string method is strange, I think. Maybe Perl 6 or Ruby?
The one-liner is valid Python. It's slightly non-idiomatic in that it uses a list-comprehension where a generator expression would do, and uses range instead of xrange (in Python 2.x; in 3.x range is the idiomatic alternative).
Earlier quoted context omitted.
Well, its more direct in that, while it increases the number of branches, it minimizes the number of statements executed on any branch. It's also the solution that maps most directly to the problem statement, and, absent a strong technical reason to do otherwise, a direct mapping from requirements to code is a good thing.
I disagree that it maps most directly to the problem statement. You're performing a common factor computation in your mind, which may be more difficult given numbers other than 3 and 5. In my opinion, pattern matching offers the most direct solution and comes with an abundance of compiler optimizations. Here's an example in Rust... for i in range(1i, 101) { match (i % 3, i % 5) { (0, 0) => println!("Fizzbuzz"), (0, _…
Well, sure, explicitly calling out i % 15 rather than (i % 3) && (i % 5) or the equivalent has that problem.
> In my opinion, pattern matching offers the most direct solution and comes with an abundance of compiler optimizations.
Pattern matching is not available in many languages, but, sure, where its available, its a great choice. Note that this still has a distinct case for the case where both % 3 and % 5 are true, rather than just testing those cases independently and sequentially and concatenating, so I think it falls into the general class of solutions I was describing.
I am glad that someone is working on a new stream processing language, it is a very interesting paradigm. However I hope that they provide some very robust tools for controlling input splitting. As I have spent too much time fighting with awk and wishing it was more flexible(it is frustrating always having exactly two levels of splitting with only matchers on the first and only inverse splitting on the second). As is…
Awesome ! Let's call it sed ! Reference: https://www.gnu.org/software/sed/manual/sed.html#Examples Sorry, I couldn't miss that one. :) Really, check the example. Sed is most powerful tool and can do astonishing work.
If you ever meet Matz, talk to him about programming languages. While he gets some flak for all the problems of his original hobby project (Ruby), he obviously loves programming languages and gives things more thought then people give him credit for. I had the chance to talk to him while I was still a student and full of ideas how the language could be made "better" and he shot them all down. For good reasons, as I k…
Does he really get a "lot of flak" for Ruby? While I know not everyone loves Ruby, it seems crazy to me that people would denigrate Matz on a personal level...to me (admittedly, a novice in designing languages), Ruby always seemed well-thought out...that is, the trade-offs do not seem out of line given the philosophical benefits, and not everyone can make claim to turning a personal project into a worldwide language.…
The thing is they are hampering Ruby now because people want to use Ruby for all kinds of things he probably never intended it for.
E.g. I'm on a crazy multi-year journey towards doing an ahead of time compiler for Ruby. Ruby is not designed for that. It has dozens of issues that makes it incredibly hard to do that efficiently compared to many other languages.
At the same time, MRI was incredibly inefficient in earlier incarnations because it was simple. It interpreted the syntax tree. Easy implement. A nightmare to make fast.
Ruby's grammar is also a massive pain for people who want to implement Ruby. Great for developers mostly until you run into some of the hairy corner cases that are often a result of trying to be incredibly clever to make things flow very naturally when writing Ruby most of the time, which has led to a lot of byzantine rules.
I wouldn't give Matz flak over it, simply because some of it are part of what makes Ruby so pleasant to use, and others are simply artefacts of him meeting his needs while implementing Ruby rather than designing it to meet some ideal that wasn't necessarily very relevant to him then.
But I'm not surprised (a bit sad, but not surprised) if someone makes it personal.