Live data from Hacker News

Happy Birthday, Ruby

github.com

51–60 of 239 posts

Re: Happy Birthday, Ruby

#51
post #45

After getting tired of Java's verbosity in 2008, I switched to a Ruby job, where I was fortunate to work with an incredibly talented developer and Ruby expert. It was a joy coding in Ruby after 4 years of Java and XML. After that, I moved to Groovy, which seemed like a nice middle ground between Ruby and Java, or as I called it at the time: Java as it should have been. I don't hear much about Ruby and Groovy lately,…

that sucks you had to go back to java sorry to hear that.

Re: Happy Birthday, Ruby

#52
post #16

Ruby is the very least favorite of all the programming languages I've had to use regularly over my career. Its syntax strongly favors cuteness over familiarity. Wherever Ruby can diverge from expectations to give you a pointless little tickle of whimsical inventiveness instead, it seems to do so. Visually it looks like an unwanted love child of Pascal and Python. There's no clear rhyme or reason to the use of sigils…

Rails has an answer for the hashmap keys problem, HashWithIndifferentAccess.

Re: Happy Birthday, Ruby

#54
post #43

Earlier quoted context omitted.

I wholeheartedly agree. My main gripe is that people insist Ruby is 'easy', because it 'looks just like English'. Yeah, well, it doesn't. Programming languages are different from normal languages because they have different goals, different users and different requirements. The result in of this forced unification in Rails is something that resembles English, if you squint really hard, but in order to do so, it uses…

I've never heard anyone say Ruby "looks just like English". Do you have a source?

Definitely look up any of the great talks by "‎Jamis Buck"

Re: Happy Birthday, Ruby

#55
post #32

Earlier quoted context omitted.

> Ruby is the very least favorite of all the programming languages I've had to use regularly over my career. > Its syntax strongly favors cuteness over familiarity How do you define regular? I use both Ruby and JS almost daily, and have previously used Java and python for several years. I find ruby a joy to use and have no issues with 'familiarity'

If I used Ruby daily, I'd probably be used to it. Right now it's something I have to touch 2-3 times a week to implement specific features in a fairly large Rails codebase, and it always feels jarring to make the switch from the familiar JS/C++/Obj-C spheres of syntactic overlap.

Weird. It doesn't feel jarring for me to make that switch.

Re: Happy Birthday, Ruby

#57

Earlier quoted context omitted.

> having two distinctly different types of strings You must be talking about Python 2, the deprecated version for 12 years now, with support ending next year. Because last time I checked, current, modern Python only has one type of string.

Try passing a std::string in from C/C++ code. It treats it as a byte string, which you have to prepend with 'b', and Python 3 will not do any nice casting under the hood back and forth between the two types. Sure, I am picking out one particular use case, but it isn't uncommon to wrap C code in python scripts to mung data going in and out of it. You are right though. String manipulation does appear to be easier than…

b"" is not "a byte string". It's a raw byte sequence:

   >>> type(b"foo")
   
   >>> b'foo'[0]
   102
It can hold any bytes, it just happens that one way to contruct/represent it can be done with a string-like syntax as a convenience for developers. But you can actually built it in another way, or make it hold data in any other format:

    >>> bytes([102, 111, 111])
    b'foo'
    >>> struct.unpack('I', b'\x01\x01\x00\x02')
    (33554689, )

Also, std::string is exactly that, a raw byte sequence, with some string operations attached to it. But you don't have any encoding attached to it: https://stackoverflow.com/questions/1010783/what-encoding-do...

So it makes sense that Python is treating it has a raw bytes array (what you call "a byte string"): it has no way to know that it is UTF8 or CP850 if you don't tell it.

But because of c/c++ experience or habits from python 2, one tends to confuse the concept of text (represented with the type "str" in python) with some specific low level implementation (the raw bytes array).

Python explicitly avoid this problem, by defining that either you know what it is (utf8 text, big endian number, etc) or you don't (raw bytes array). Manipulating text as a raw byte sequence manually would be the equivalent of manipulating directly the IEEE 754 representation of a number: it's not what you want for a high level scripting language, and hence it's why Python 3 doesn't do that anymore.

Re: Happy Birthday, Ruby

#58

Earlier quoted context omitted.

> having two distinctly different types of strings You must be talking about Python 2, the deprecated version for 12 years now, with support ending next year. Because last time I checked, current, modern Python only has one type of string.

Try passing a std::string in from C/C++ code. It treats it as a byte string, which you have to prepend with 'b', and Python 3 will not do any nice casting under the hood back and forth between the two types. Sure, I am picking out one particular use case, but it isn't uncommon to wrap C code in python scripts to mung data going in and out of it. You are right though. String manipulation does appear to be easier than…

That's because std::string does not carry any sort of encoding information, std::string is basically a wrapper around bytes (hopefully I'm not misreading this, I'm far from an expert C/C++ programmer). Due to this, python can't make any assumptions about encoding/decoding without the possibility of getting it wrong.

"Note that this class handles bytes independently of the encoding used: If used to handle sequences of multi-byte or variable-length characters (such as UTF-8), all members of this class (such as length or size), as well as its iterators, will still operate in terms of bytes (not actual encoded characters)."

https://stackoverflow.com/questions/1010783/what-encoding-do...

http://www.cplusplus.com/reference/string/string/

Re: Happy Birthday, Ruby

#59

I discovered Ruby in 2005 and immediately fell in love with it. Then came across Rails which really tested that love, what with it's opinions and everything! And finally reached Sinatra, then Roda and love prevailed! Along the way, discovered and enjoyed working with so many gems both in Ruby as well as part of it's packages! So, after 13 years now, I'm glad I chose the right language. A language which always asks, i…

I’ve also been using Ruby full time for 13 or 14 years and I am really hoping its popularity and commercial viability continues for another 13 years (or another 25). I’m certain my level of mastery contributes to my enjoyment. And it’s not that I don’t like learning new things, I do! But Ruby is just an absolute pleasure to write, and it’s hard to imagine spending 8+ hours a day living in any other ecosystem.

definitely - it's not getting slower it's getting faster and more stable. ruby's here to stay

Re: Happy Birthday, Ruby

#60
post #3

> Ruby isn't the most beautiful language out there Huh, I sure think it is. I wonder what the author thinks the competition might be? Ruby has its issues for sure, but aesthetics ain't one of them - far and away my favourite out of any major language.

I'm not sure what language would be more beautiful than ruby, to be honest, and it's not even my favorite language to use. Let's do a mini code challenge in the thread -- implement fizzbuzz in the most beautiful way you can, in the most beautiful language you know:

    (defn fizz-buzz [n]
      (map #(cond (= 0 (mod % 15)) "FizzBuzz"
                  (= 0 (mod % 5))  "Fizz"
                  (= 0 (mod % 3))  "Buzz"
                  :else            %)
            (range 1 n)))
Post reply on HN