261–270 of 303 posts
I totally agree about refinements being a terrible idea. Brian Ford (of Rubinous) makes an excellent argument: http://www.youtube.com/watch?v=BagNfTbXn3w . What is the best way to let Ruby team know that refinements are a bad idea?
Get involved in the discussions on ruby-core.
I do wonder about the long term success of Ruby. Rails is easily the most visible project for Ruby. Rails is big, and all that code represents a high barrier to entry for any framework in a different language that wants to compete. However, a lot of people I talk to are moving to pure JS front-end + REST backend. In this world Rails doesn't deliver any particular value (in my opinion). Ruby also has utility for doing…
I find that the ruby community tends to be fairly vibrant, passionate and innovative. I think the language lends itself to a creative way of thinking, and that shows in the projects that are created in it.
Blocks are amazing, and really clean up code for what is a very common usage pattern. I'm semi-offended by python because of the lack of what I deem to be an elegant equivalent. Not as offended as I am by perl or java, but I used to like those languages too. I detest the python string interpolation syntax - #{} is so much nicer. And I suspect that for other people these choices matter too.
Why weren't things like Sinatra, Sass, Less, Jekyll, Metasploit and Rails invented on another language? Other languages would be adequate for the task as you put it. Github is arguably the biggest thing to happen to open source in recent years.
As far as JS front ends/Rails go, I think we could get there one day and there are tradeoffs but you have a few problems with the model you propose; 1) Javascript sucks as a language 2) Server side rendering is always going to give you more control 3) accessibility is easier if you have a server side fallback.
"Best Practice" has always switched between centralised and decentralised throughout the history of IT. With Rails you can do both.
Earlier quoted context omitted.
I'm a rubyist. I have nothing against python at all, but I have zero interest in learning it. Why? Simply because if I'm going to devote mental capacity to a new language I want it to be more different. Haskell is my current choice because as far as I can tell it is the opposite of Ruby in every way except the one that is my primary criteria for interest in a language: concision.
The more I think about it the more I believe concision is overrated and borderline dangerous. Shaving a few keystroke today very often means great troubles later. I used to like those hello world concision contests, but in fact who cares? Who writes a single hello world code? What we need is a language solving the real problems met in most codebase, and I'd say the biggest fish here is the dependencies mess.
The less bloated the core syntax is, the clearer your ideas are which makes your code easier to read. I'm not saying methods should be arithmetic symbols - I think short words with not much syntax around them makes for more readable code.
ruby tends to read like pseudo-code, which is a great way to express the code idea of your algorithm when you're thinking about it, and when you're reading it back later.
Earlier quoted context omitted.
Just as note: I don't really would call "len(o)" a "legacy call", as in "something it's here just for backward compatibility, but it's ugly and please don't use it". It's more "the good way to do it" :D len() is a perfect example of the duck typing and the "protocol-based" philosophy of python: its implementation it's something like def len(object): return object.__len__() as in "just return the result of invoking th…
Or, instead of having the convention that objects with a length implement __len__, you could have the convention where they just implement len and you could just call obj.len.
Yeah. You are right about the fact that a possible "convention" would be to call .len, not .__len__ but you are forgetting 20+ years of backward compatibility.
I don't know when len() was introduced, and I'm not sure it's initial implementation was a simple "return object.__len__()" (or an equivalent...). What I know is that an explicit len function helped to hide the eventually different implementation details, and allowed the developers of the containers go crazy with attributes.
Moreover, with a len(obj) function and a obj.len() "public" method, you have two ways to do it.
I do wonder about the long term success of Ruby. Rails is easily the most visible project for Ruby. Rails is big, and all that code represents a high barrier to entry for any framework in a different language that wants to compete. However, a lot of people I talk to are moving to pure JS front-end + REST backend. In this world Rails doesn't deliver any particular value (in my opinion). Ruby also has utility for doing…
> I just think it will slowly become less relevant. That's true for virtually anything. Do you think C/C++ or Java or JS will be mainstream 30 years from now. They will be in the same situation FORTRAN is today: important because of lots of legacy code, but not a viable choice when starting a new project. Of course some of them will never die. LISP comes to my mind. :-)
Earlier quoted context omitted.
You can compare the trivial differences all you want, but the truth is, they are real differences in the way you think about your code and programming. Indexing starting at 1 is not only irritating, it's mathematically difficult. Certain concepts actually can't be described (as easily) with array indices that start at 1. It's not a trivial argument. Similar with white space; having to write code which obeys white spa…
I would love to see an example of a large project in another language besides python, that uses frequent cases of non-pythonic indentation. Sure, there are certain edge cases when I wish I could represent something all in one line, or something similar, but they are so few and far between that I really cant see it as a major argument against not wanting to use python. I felt the same way about whitespace at one time,…
Python people constantly advocating white space indentation as some kind panacea to all programming problems programmers have ever faced is irritating to those people who know it is not and can never be.
Also look at what is happening in this thread. This thread is about Ruby, every time some thread on Ruby or Perl is started- You see Python trolls descending all over the thread to push their shiny tool down others throat. I mean this is happening for years now, may be even decades. There is also this quote...
"And what defines a 'python activist' anyway? Blowing up Perl installations worldwide?" - Ivan Van Laningham
http://mail.python.org/pipermail/python-announce-list/2005-J...
That is how notoriously Python people troll on other languages.
Trolling on other languages is a irritating thing, sooner or later people figure you have nothing to offer. Instead of doing this and trolling on other languages, may be the Python community should build about something awesome and let people decide if they should use on its merits.
Earlier quoted context omitted.
Python's whitespace-as-logic means that, for any given project, every editor used by every developer needs to have the same the same definition of what a "tab" is, because mixing tabs and spaces can introduce logic errors. You can reasonably argue that a project team should already have and enforce a coding style guide, so specifying a "tab" isn't a big deal. But what if you're part of two separate projects which dif…
This is a non-issue. Just follow PEP 8, which clearly suggests to "Use 4 spaces per indentation level." PEP 8 has been around for over a decade, so there's no excuse for not following its recommendations.
Earlier quoted context omitted.
I don't understand why you would want to implement HTTP caching in a language's runtime. Honestly, I don't even see where and how you could even do that.
You don't implement HTTP caching, except in very specific cases. You cache generated data where you need it. This is 1) Easy to add later, 2) Doesn't sacrifice the flexibility of being able to recompose that data on-demand, and 3) Doesn't require a bunch of complex front-end infrastructure to support.
Earlier quoted context omitted.
I would love to see an example of a large project in another language besides python, that uses frequent cases of non-pythonic indentation. Sure, there are certain edge cases when I wish I could represent something all in one line, or something similar, but they are so few and far between that I really cant see it as a major argument against not wanting to use python. I felt the same way about whitespace at one time,…
The problem is something like this. There is a cancer patient and he complains of head ache, the family members around give him a Paracetamol 500mg. The family members now also expect that Paracetamol just given will also cure him of cancer apart from curing his headache too. Python people constantly advocating white space indentation as some kind panacea to all programming problems programmers have ever faced is irr…
Also, stop putting your words into other people's mouth. Who here is advocating Python indentation as a cure-all? Point is, you can talk about Ruby all you want, but when you diss on Python indentation, you'd better back up your opinions with facts instead of substituting your opinion as facts.
The only valid reason to diss on Python indentation is if you find yourself constantly writing really long functions in multiple nested blocks. You'll have trouble seeing which block you are closing the further down you go.
Now we are done defending, I still haven't seen a valid argument against Python whitespace, or people who have the guts to say they just don't like it.
Earlier quoted context omitted.
The more I think about it the more I believe concision is overrated and borderline dangerous. Shaving a few keystroke today very often means great troubles later. I used to like those hello world concision contests, but in fact who cares? Who writes a single hello world code? What we need is a language solving the real problems met in most codebase, and I'd say the biggest fish here is the dependencies mess.
If you spend your day typing the same stuff for a simple program, or you need an IDE to be happy, that is a language failing in my opinion. The less bloated the core syntax is, the clearer your ideas are which makes your code easier to read. I'm not saying methods should be arithmetic symbols - I think short words with not much syntax around them makes for more readable code. ruby tends to read like pseudo-code, whic…
I often have discussions with colleagues about different coding idioms in Python, and I hear often "this one is better because it is less typing". I don't think this is very valid. If everything is equal, then sure, go for less typing. But using locals() instead of explicit arguments when calling a template rendering because "it is less typing" seems not strong enough an argument to me.