7 ms·

>Dealing with Duplicated Code Anyone notice the duplicate topic under Tutorials and Talks "Offline Processing in PHP with Advanced Queuing," just gave me a lit

>Dealing with Duplicated Code Anyone notice the duplicate topic under Tutorials and Talks "Offline Processing in PHP with Advanced Queuing," just gave me a little chuckle when one of the articles is dealing with duplicated code. Aside from this, I LOVE PHP. A prospective employer was asking if I would be open to learning RoR. Anyone who is experienced on Rails, could you let me know if it's a similar structure as PHP (which I'm great at)? Thanks.

inovica 13y ago
You spotted the deliberate mistake - erm. Whoops. Thanks for pointing that out!
nkozyra 13y ago
As Rails is a framework and not a language, it has a much more specified "structure." Syntactically, the languages are not all that similar. It's probably closer to Python. As much as people abhor PHP in programming communities (and I get that sentiment), I find RoR to be a far, far worse platform to build upon.
- jiggy2011 13y ago
  What do you find worse about RoR? Compared to whichever PHP framework.
  - fooyc 13y ago
    Ugly monkey patching everywhere, open classes, insecure by default (e.g. mass assignment), global states, model classes easily too much tied to a single controler, active record pattern, ...
    - rbanffy 13y ago
      It's interesting. Much of what I think is beautiful about Ruby (and Python, and Objective C, and Smalltalk) is what people who like PHP consider ugly. I, myself, and it's a matter of taste, find PHP (and most of the code written with it) ugly. There is no objective measurement for ugliness.
      - prollyignored 13y ago
        There you go https://github.com/runekaagaard/snowscript https://github.com/runekaagaard/snowscript PHP is a kludge. You'd be surprised to know that world is made of kludges with a few elegant hacks thrown in and not the other way round. Performance hacks are always kludges. Can you live without them ? Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ? What makes that time well spent ? Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ?
        jiggy2011 13y ago
        Well, everyone has their own definition of "elegant syntax" which makes objectivity difficult. I guess the best tools are ones which help you produce output quickly whilst being conductive to elegance and readability, Ruby's terse syntax and features like blocks are an attempt at this. It also depends on how big your project will get and how long it will need to be maintained for. There are plenty of projects I have seen where chunks of extremely bad code have been pumped out to create a 1.0 with a giant list of features. Of course such code becomes increasingly costly to maintain or modify without breaking. In many cases they would have been better off cutting features from the 1.0 (most features are unused anyway) and concentrating on quality.
        rbanffy 13y ago
        > You'd be surprised to know that world is made of kludges No. I wouldn't. I'm an electrical engineer by training. > Performance hacks are always kludges. Not always. Sometimes they bring out some inner beauty in the code that was previously hidden. But, again, sometimes they don't. > Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ? It depends on your priorities. If you were a poet, would you be more worried about making good poetry or selling more books? > Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ? Again, it depends on what is your output and how you relate with the fact that the thing generating that output is a horrible mess.
  - nkozyra 13y ago
    Here I'll admit that my exposure to PHP frameworks is minimal. My primary issues are the rigidity of RoR, the ample amount of security issues and the general slowness of Ruby in some very key areas (which tends to cascade down even more with a framework).
- kbenson 13y ago
  Syntactically, the languages are not all that similar. It's probably closer to Python. My impression was that Ruby is much closer to Perl than Python.
  - nkozyra 13y ago
    Don't really see that. PHP was basically written as a C-style interpreted language with $vars. It ended up so much like Perl that there's a decent amount of Perl and PHP you can cross-paste without error.
symfoniq 13y ago
I've done both PHP and Ruby/Rails professionally. They are quite different. I earned a living with PHP first, but I prefer to use Rails (or Sinatra) for most projects these days. Even though PHP and Ruby (and therefore Rails) have little in common, I think you can still learn the Rails fundamentals quickly. Check out Michael Hartl's excellent Rails Tutorial. Also, Ryan Bates' Railscasts are a fantastic resource.
- quackerhacker 13y ago
  Thanks symfoniq. I started with PHP also, and picked it up fairly quickly. I'd learned Ruby regardless, just to work with this dev team and it never hurts to know another language. I really wanted to hear experience from someone who went from php to ruby (since that's what I'd be doing). Php .net is so well doc'd with an example for almost every function/feature that it made it EXTREMELY easy to pick up. Does Ruby have something similar (really hope it's not -> ruby-lang.org, reminds me of w3), not too keen to Michael Hartl's just cause I'd have to buy it.
  - aggronn 13y ago
    it is ruby-doc. What don't you like about it specifically? Its very concise, consistent, and thorough, which is what I always thought was ideal for these.
  - brandoncordell 13y ago
    Michael Hartl's book is free to read online... I much prefer Ruby's documentation to PHP's. Especially when it comes to 3rd party code, I don't have one gem in my current Rails project that isn't very nicely documented. Compare that to the PHP I work on during the day and almost all the 3rd party libs have no documentation.
    - pacmon 13y ago
      Perhaps I am misinterpreting your statement, but it almost sounds like you blame PHP for the lack of documentation of those libraries. Really you should be blaming the authors of the libraries for poorly documenting them, or the developer who chose those libraries, for choosing ones with poor documentation.
vec 13y ago
Speaking as someone who made this exact jump a couple years back, here's the big differences I remember. * The languages are very different, syntactically. Ruby's blocks and enumerators really don't have an analog in PHP, and they'll take some getting used to. There's also some pretty deep philosophical differences in what the two languages mean by "class". That said, they sit at about the same abstraction layer, so line by line the complexity and flow shouldn't be that big of a jump. * Rails is more like, say, Zend Framework than raw PHP. It enforces an MVC layout on your code and does what looks at first like a lot of magic to figure out which template files correspond to which pages. When you're starting out the rails scaffold generators are your friend. * Ruby's standard library has a lot less in it than PHPs, so no XML parser or SQL client out of the box. Gems, and bundler in particular, makes it much easier to add third party code, though. You'll spend a lot more time bikeshedding over which third-party library to use, but the competition generally leads to more pleasant APIs in the long run. * Ruby convention is to have more files and less code per file. A lot of your template files will only end up being three or four lines long. It's honestly easier in the long run, but get an editor that supports that workflow (multiple tabs, fuzzy file open, find-in-project, etc). * RoR is almost completely independent of Apache for configuration. You get to move all the logic that was in .htaccess into ruby code in your app somewhere, and you get much more freedom over defining what you want your URLs to look like. You'll need to familiarize yourself with a concept called reverse proxying to figure out how this works in production, though. * Not strictly ruby, but the rails asset pipeline is magic. Once you get used to it you'll never want to do frontend coding without it.
- quackerhacker 13y ago
  Seeing as I have no choice to learning Ruby if I become apart of this dev team, this is great to know. One of the greatest strengths that I absolutely utilize all the time in PHP is the libraries (curl, gd2, xml parsing, mysql, ect)...I couldn't imagine doing effective programming without it now. Oh well, another challenge, another achievement. Thanks Vec!
  - tmzt 13y ago
    Ruby has bindings for most of those libraries (or classes of libraries, like XML parsers.) I think CURL is handled in a more abstract way in Rails, but I haven't really gotten to work with Http clients in Rails yet.
intendedeffect 13y ago
I learned PHP years ago, never got past the "futzing around making a basic CMS" stage with RoR (I currently do most of my work in C# and ObjC). I'm sure I'll be politely corrected in this view, but the piles of add-on gems and scripting utilities that characterize Rails-in-practice meant that Rails struck me as kind of a moving target. Coming from PHP where basically nothing happens unless you make it happen (for better and very often for worse), I found Rails confusing once you got beyond easy Active Record calls and into using gems. There are tons of add-ons that do useful things, but they do a lot of their work behind the scenes assuming adherence to certain conventions—which, I know, is a strength as well as a weakness, I get it. But that increases the difficulty of jumping past the stage of following a tutorial and just installing one persons collection of gems, scripts and other helpers.
tmzt 13y ago
It really depends on how you write PHP. If you write Object Oriented PHP and use a framework with strong OOP principals you probably will have no problem learning Rails. If you've used MVC before, and you understand the role of a Model, View, Controller, data bindings, ORM, etc. then you should have no problem learning Rails. If all you know is PHP and it's control structures, and you expect your file to be interpreted every time you visit a URL, then you will probably have more difficultly learning Rails. It would be helpful to know what you love about PHP.

inovica 13y ago

You spotted the deliberate mistake - erm. Whoops. Thanks for pointing that out!

nkozyra 13y ago

As Rails is a framework and not a language, it has a much more specified "structure." Syntactically, the languages are not all that similar. It's probably closer to Python. As much as people abhor PHP in programming communities (and I get that sentiment), I find RoR to be a far, far worse platform to build upon.

jiggy2011 13y ago
What do you find worse about RoR? Compared to whichever PHP framework.
- fooyc 13y ago
  Ugly monkey patching everywhere, open classes, insecure by default (e.g. mass assignment), global states, model classes easily too much tied to a single controler, active record pattern, ...
  - rbanffy 13y ago
    It's interesting. Much of what I think is beautiful about Ruby (and Python, and Objective C, and Smalltalk) is what people who like PHP consider ugly. I, myself, and it's a matter of taste, find PHP (and most of the code written with it) ugly. There is no objective measurement for ugliness.
    - prollyignored 13y ago
      There you go https://github.com/runekaagaard/snowscript https://github.com/runekaagaard/snowscript PHP is a kludge. You'd be surprised to know that world is made of kludges with a few elegant hacks thrown in and not the other way round. Performance hacks are always kludges. Can you live without them ? Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ? What makes that time well spent ? Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ?
      - jiggy2011 13y ago
        Well, everyone has their own definition of "elegant syntax" which makes objectivity difficult. I guess the best tools are ones which help you produce output quickly whilst being conductive to elegance and readability, Ruby's terse syntax and features like blocks are an attempt at this. It also depends on how big your project will get and how long it will need to be maintained for. There are plenty of projects I have seen where chunks of extremely bad code have been pumped out to create a 1.0 with a giant list of features. Of course such code becomes increasingly costly to maintain or modify without breaking. In many cases they would have been better off cutting features from the 1.0 (most features are unused anyway) and concentrating on quality.
      - rbanffy 13y ago
        > You'd be surprised to know that world is made of kludges No. I wouldn't. I'm an electrical engineer by training. > Performance hacks are always kludges. Not always. Sometimes they bring out some inner beauty in the code that was previously hidden. But, again, sometimes they don't. > Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ? It depends on your priorities. If you were a poet, would you be more worried about making good poetry or selling more books? > Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ? Again, it depends on what is your output and how you relate with the fact that the thing generating that output is a horrible mess.
- nkozyra 13y ago
  Here I'll admit that my exposure to PHP frameworks is minimal. My primary issues are the rigidity of RoR, the ample amount of security issues and the general slowness of Ruby in some very key areas (which tends to cascade down even more with a framework).
kbenson 13y ago
Syntactically, the languages are not all that similar. It's probably closer to Python. My impression was that Ruby is much closer to Perl than Python.
- nkozyra 13y ago
  Don't really see that. PHP was basically written as a C-style interpreted language with $vars. It ended up so much like Perl that there's a decent amount of Perl and PHP you can cross-paste without error.

symfoniq 13y ago

I've done both PHP and Ruby/Rails professionally. They are quite different. I earned a living with PHP first, but I prefer to use Rails (or Sinatra) for most projects these days. Even though PHP and Ruby (and therefore Rails) have little in common, I think you can still learn the Rails fundamentals quickly. Check out Michael Hartl's excellent Rails Tutorial. Also, Ryan Bates' Railscasts are a fantastic resource.

quackerhacker 13y ago
Thanks symfoniq. I started with PHP also, and picked it up fairly quickly. I'd learned Ruby regardless, just to work with this dev team and it never hurts to know another language. I really wanted to hear experience from someone who went from php to ruby (since that's what I'd be doing). Php .net is so well doc'd with an example for almost every function/feature that it made it EXTREMELY easy to pick up. Does Ruby have something similar (really hope it's not -> ruby-lang.org, reminds me of w3), not too keen to Michael Hartl's just cause I'd have to buy it.
- aggronn 13y ago
  it is ruby-doc. What don't you like about it specifically? Its very concise, consistent, and thorough, which is what I always thought was ideal for these.
- brandoncordell 13y ago
  Michael Hartl's book is free to read online... I much prefer Ruby's documentation to PHP's. Especially when it comes to 3rd party code, I don't have one gem in my current Rails project that isn't very nicely documented. Compare that to the PHP I work on during the day and almost all the 3rd party libs have no documentation.
  - pacmon 13y ago
    Perhaps I am misinterpreting your statement, but it almost sounds like you blame PHP for the lack of documentation of those libraries. Really you should be blaming the authors of the libraries for poorly documenting them, or the developer who chose those libraries, for choosing ones with poor documentation.

vec 13y ago

Speaking as someone who made this exact jump a couple years back, here's the big differences I remember. * The languages are very different, syntactically. Ruby's blocks and enumerators really don't have an analog in PHP, and they'll take some getting used to. There's also some pretty deep philosophical differences in what the two languages mean by "class". That said, they sit at about the same abstraction layer, so line by line the complexity and flow shouldn't be that big of a jump. * Rails is more like, say, Zend Framework than raw PHP. It enforces an MVC layout on your code and does what looks at first like a lot of magic to figure out which template files correspond to which pages. When you're starting out the rails scaffold generators are your friend. * Ruby's standard library has a lot less in it than PHPs, so no XML parser or SQL client out of the box. Gems, and bundler in particular, makes it much easier to add third party code, though. You'll spend a lot more time bikeshedding over which third-party library to use, but the competition generally leads to more pleasant APIs in the long run. * Ruby convention is to have more files and less code per file. A lot of your template files will only end up being three or four lines long. It's honestly easier in the long run, but get an editor that supports that workflow (multiple tabs, fuzzy file open, find-in-project, etc). * RoR is almost completely independent of Apache for configuration. You get to move all the logic that was in .htaccess into ruby code in your app somewhere, and you get much more freedom over defining what you want your URLs to look like. You'll need to familiarize yourself with a concept called reverse proxying to figure out how this works in production, though. * Not strictly ruby, but the rails asset pipeline is magic. Once you get used to it you'll never want to do frontend coding without it.

quackerhacker 13y ago
Seeing as I have no choice to learning Ruby if I become apart of this dev team, this is great to know. One of the greatest strengths that I absolutely utilize all the time in PHP is the libraries (curl, gd2, xml parsing, mysql, ect)...I couldn't imagine doing effective programming without it now. Oh well, another challenge, another achievement. Thanks Vec!
- tmzt 13y ago
  Ruby has bindings for most of those libraries (or classes of libraries, like XML parsers.) I think CURL is handled in a more abstract way in Rails, but I haven't really gotten to work with Http clients in Rails yet.

intendedeffect 13y ago

I learned PHP years ago, never got past the "futzing around making a basic CMS" stage with RoR (I currently do most of my work in C# and ObjC). I'm sure I'll be politely corrected in this view, but the piles of add-on gems and scripting utilities that characterize Rails-in-practice meant that Rails struck me as kind of a moving target. Coming from PHP where basically nothing happens unless you make it happen (for better and very often for worse), I found Rails confusing once you got beyond easy Active Record calls and into using gems. There are tons of add-ons that do useful things, but they do a lot of their work behind the scenes assuming adherence to certain conventions—which, I know, is a strength as well as a weakness, I get it. But that increases the difficulty of jumping past the stage of following a tutorial and just installing one persons collection of gems, scripts and other helpers.

tmzt 13y ago

It really depends on how you write PHP. If you write Object Oriented PHP and use a framework with strong OOP principals you probably will have no problem learning Rails. If you've used MVC before, and you understand the role of a Model, View, Controller, data bindings, ORM, etc. then you should have no problem learning Rails. If all you know is PHP and it's control structures, and you expect your file to be interpreted every time you visit a URL, then you will probably have more difficultly learning Rails. It would be helpful to know what you love about PHP.