Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Heh, I understand the Blub paradox quite well. And, as I acknowledged, everything has design tradeoffs or even mistakes. Just because there are design tradeoffs or warts, doesn't mean they rise to the level of active dislike.

For instance, most implementations of Ruby are relatively slow. Do I care? Generally, no ... certainly not enough to say it's something I "dislike." It's entirely possible to build tons of web apps (for example) and never bump against any language "mistakes" or "tradeoffs" that are relevant.



"Dislikes" may be stronger than you want, but would you agree if it were changed to "recognized shortcomings"?

Let's use Ruby for an example. You discounted performance because it never matters in web development. Fine. Here are 5 more issues that do come up in web development. Not using native threads makes it easy for a poorly coded C extension (for instance a database driver) to block all threads. Common classes of errors (eg typos in variable names) can only be caught at run-time. Some widely used libraries use monkey patching, and with dependencies it is very easy to pull one in without realizing it, only to get burned later in what should be an unrelated library. By default gem does not run unit tests at installation, which makes it less likely that developers will get prompt feedback about issues like platform-specific code or unspecified dependencies. While mix-ins are convenient, they provide opportunities for conflicts and make it harder to track down the source of a method when you're trying to debug something.

I don't even use Ruby very much. If I did, I could easily come up with a much larger list. (My primary language is Perl. You should see the list of complaints I have about it! Yet I still like it. And for the record I like Ruby as well.)

Edit: I only included 4 issues initially, so I just added another.


"Dislikes" may be stronger than you want, but would you agree if it were changed to "recognized shortcomings"?

Yup.


Maybe dislike is too strong in your vocabulary - but in mine it's "things I don't like; and would not cry if they got better/changed tomorrow". I'm not talking about hate here - sure, people are able to uncompromisingly happy (as I am, when I'm working on python) but the poster above pointed it out - If you have not found those things yet, then you don't know your language and tools that well. Or else you don't know what is possible with other languages and tools.

So, attribute any emotional level you want - in my book, dislike is far from hate, and means you would actively work to change the item if question, if given the power.

I love working with Python, with Django, with Linux/OSX, VIM, Textmate, etc, etc. I love working with them, but each has it's failings, and it's important I know them. Sometimes knowing your own limitations, and those of your tools, and thinking critically about both is the most important skill a person can have.

It makes them think how things can be better.


Ah, I see ... I think we're in agreement.


Probably, it's really as simple as challenging your assumptions, and striving to be better, or make better things. Hell - it's what drives most entrepreneurs.


By "something" do you mean Ruby itself, or the fact that most Ruby implemenations are slow? If it was the former, then I think you're responding to the wrong statement. The statement was about "5 things you dislike about the tools and languages you use". So it wasn't about disliking Ruby itself, but rather things about Ruby.

If you were indeed saying that you don't care enough about the fact that "most implementations of Ruby are relatively slow." to raise that fact to the level of "dislike", well, I guess I find that hard to believe. I mean, sure, it generally won't matter. But even if it only matters a small portion of the time, what is there to "like" about implementations of a language being slow? Wouldn't you always dislike that fact, even when it didn't particularly matter in most cases?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: