Earlier quoted context omitted.
> Thoughts? I think most of the things you say sound like you haven't worked with either. Few people are moving to pure JS front-end. Some are, some write blogposts about it, but the majority of people isn't. Some are even moving back, a year or so ago there were a lot of blogposts about that kind of stuff. Rails offers a lot of interesting things in the M and C parts of the MVC pattern (Object persistence, REST endp…
FWIW, I only used examples with which I have personal experience. All new front-end projects we're doing are pure JS. I've used Jekyll in various commercial and non-commercial applications.
Ruby 2.0.0 Released
101–110 of 303 posts
Re: Ruby 2.0.0 Released
#102I 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…
rails may be the most visible ruby project out there (and indeed the "killer app" that got a lot of people and businesses into ruby), but it is by no means critical or even necessary for ruby's continuing success. check out puppet's userbase, for instance - there are some huge companies using it to manage their deployments. jruby could well become one of the go-to jvm automation solutions down the road; it's certainly doing everything right to get there.
but more than any of that, ruby is simply the most productive language i've encountered for performing quick one-off tasks and exploring algorithms. it has all the strengths of perl (another language that plays very well in this particular niche), and adds very natural support for both object-oriented and functional approaches. i've used lots of languages (everything from basic to haskell) and ruby is almost unique in that i have never felt like i was fighting with the language to put my ideas into code. i think of the way i'd like to say something, and sure enough, ruby supports it and more often than not makes it easy and natural.
Re: Ruby 2.0.0 Released
#103Overall, a good feature set. I only see some utility for keyword arguments, admittedly, but I tend to write very functional code, so maybe other people will get more mileage. Refinements, as I understand them, are a bad idea. I understand the motivation, but this is not the way to go about it. There's now a new scope all over the place (the set of refinements applied to any given class). This means that the behavior…
Agreed regarding refinements. I will personally stay away from them until some braver souls find best practices for them in long-term projects. Even then it will take some convincing. I have been awaiting Ruby keyword arguments for a very long time, but the first time I heard them brought up (relating to 2.0), the person explaining had some qualms with how they were implemented. For the life of me I cannot remember w…
There's a really in-depth article on them that also covers concerns about the implementation: http://blog.headius.com/2012/11/refining-ruby.html
Re: Ruby 2.0.0 Released
#104Earlier quoted context omitted.
Firstly (Disclaimer) I am a Rails developer, I choose to be one right now, until (if) I find that my efforts are better spent elsewhere. I agree with tferris to some extent. Those arguments are nonsensical to say the least. This might be a feeling, I am not one to shout random feeling-based percentages, but I feel that people, in general, not just HN, don't realise that you can just claim things in this way. 75%? Whe…
Well you should use a framework not because you are lazy but because there are a million other actually important things you should be doing than implementing state for HTTP for the billionth time.
Potato potato.
You are a 'glass-half-empty' interpreter of the word 'lazy'.
Easy syntax, DRY, etc. are things that are good because they limit you to waste time on trivial things, like you said. They stop you from reinventing the wheel.
I call that (positive) laziness. You can call it whatever you want of course. It still boils down to the same thing.
I have worked at places where programmers were willing to write thousands of lines of code, often copy-pasting big chunks and just replacing a few variable names. Needless to say, I didn't want to work there for very long. There is often no way to convince those kinds of programmers to stop and think about logic or technical design. They feel that they could just as easily write a few hundred lines again and again. Me, and my others, feel that you shouldn't repeat yourself in code and should limit your day-to-day efforts by writing reusable code, etc, etc. I don't need to tell you of course.
Re: Ruby 2.0.0 Released
#105I wonder, is asynchronous exception handling going to make exceptions useful in evented/fibered code? Because right now, the ability of your stack frame to unpredictable blow up is a complete nuisance.
Re: Ruby 2.0.0 Released
#106Does anyone here have a link to the new rubydocs for this?
Re: Ruby 2.0.0 Released
#107I 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…
RubyMotion is actually pretty cool. So far, the adoption of RubyMotion isn't too bad.
Re: Ruby 2.0.0 Released
#108I 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. :-)
>Of course some of them will never die. LISP comes to my mind. :-)
Or, to put it another way, LISP was never alive to begin with.
If Ruby/Python had a community and third party libraries the size of LISP we would consider them mostly irrelevant languages.
Re: Ruby 2.0.0 Released
#109Earlier quoted context omitted.
Totally agree about refinements. Hopefully the community pushes back enough on that experiment so it gets deprecated and removed. A better design approach to achieve this effect is wrapper objects (similar to jQuery and Underscore.js) where I can add functionality to existing objects. Ruby has everything we need for this already, and makes it quite easy to do.
Aren't refinements a "fixer feature", i.e. something 99% of developers should just ignore it until they really get into a problem with badly done monkeypatching, then use it to solve the problem and just move on? Why do people get so excited about them, both in a good and in a bad way? Just use them inside your library code and make sure people using your lib/framework can just pretend they don't exist, keep monkeypa…
Because they make efficient implementation of Ruby, which is already an utter nightmare, substantially harder.
Re: Ruby 2.0.0 Released
#110Overall, a good feature set. I only see some utility for keyword arguments, admittedly, but I tend to write very functional code, so maybe other people will get more mileage. Refinements, as I understand them, are a bad idea. I understand the motivation, but this is not the way to go about it. There's now a new scope all over the place (the set of refinements applied to any given class). This means that the behavior…
Agreed regarding refinements. I will personally stay away from them until some braver souls find best practices for them in long-term projects. Even then it will take some convincing. I have been awaiting Ruby keyword arguments for a very long time, but the first time I heard them brought up (relating to 2.0), the person explaining had some qualms with how they were implemented. For the life of me I cannot remember w…
The complaints I recall about Ruby keyword arguments were on Twitter:
https://twitter.com/brixen/status/281180931950264320
https://twitter.com/garybernhardt/status/281181122736582656.
Not sure if that's what you're thinking of.
@ch0wn: I'm pretty sure that chao- was talking about the implementation of keyword arguments, not refinements.