What are the advantages and disadvantages of metaprogramming? [closed] - ruby

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
As the title stated, what are the pros and cons of Ruby meta-programming?
So far I know the advantages of Ruby meta-programming give us quite flexible ways to write our code using code that writes code. But what are the disadvantages? Maintainability issues?
I feel that meta-programming helps to scale an app also.
Can anyone can give more details about this?

Almost everything I know about metaprogramming in Ruby comes from "Metaprogramming Ruby: Program Like the Ruby Pros". It's a great read, and I suggest it to everyone who want to understand metaprogramming.
I'd say the main advantage is to have incredibly flexible code, which can adapt swiftly to any changes one could imagine. Things like send, respond_to? or define_method really give you the possibility of writing beautiful code.
On the other hand, I'd say that the main disadvantage is to make code harder to read and harder to debug, since most of the times the code isn't there yet! It will be generated at runtime, so you can't actually read it when you debug it.

Related

How to improve coding skills? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I can't say I'm weak in programming but I can't come up with the logic faster. I can analyse others code and get to know the logic. But I can't do it on my own. How can I improve my programming skills?
Quite a broad question but from my own, 30yr experience I can tell you there is no way around starting to
analyze existing code,
modify some things (play with it until it feels like it's your own code)
see what the changes do
develop your own ideas on how to do things faster/better/more beautiful
implement your ideas
see if it works
go on to more complex tasks
read books (very important, because many things can't just be discovered by trial'n'error)
be very passionate and determined about what you want to become reality
if you want to learn faster, then write more code
One very important item. You should have fun with what you do is always the best guarantee for success
If you fail at these items then I'm afraid you will never succeed with programming. But then maybe it's like any other field of knowledge.
I experience the same difficulties during my learning journey, too. When I complete challenge tasks I create more complex tasks for myself to see what I can do. It takes me to the next levels of solving problems.
Practice, Practice, Practice!

Ruby on Rails marketability [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've been researching about Ruby on Rails and its marketability today. How does it compare to the other programming languages (like JAVA)? Would it be a really great time to learn it now? Will it be beneficial for me to learn this as my primary programming language?
I just wanted to know the highs and lows for this technology before I dive in and start learning.
Your opinions would be appreciated.
The name of the programming language is Ruby. Ruby on Rails is an awesome framework for fast, efficient building of web applications.
Ruby is an interpreted language in opposition to Java or C#, which are compiled.
With Ruby there's no need for type definition or type casting, no semicolons at the end of the line, no parentheses for method invocations, operators overload, getters/setters automatically available for all instance variables and many, many more. (copied from here)
I think that the learning curve with ruby is very steep.
But, after all, all the above is just an opinion ... my opinion. And you're question "Would it be a really great time to learn it now?" is answered by the pragmatic programmers: Learn a new programming language every year. So, why not starting learn Ruby now?

Style of writing conditional operators [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What is considered more appropriate style of writing conditional operators?
if(1){
puts("Hello")
}
or
if(1) puts("Hello")
Similar aspects of coding style are welcome too.
That's all depends on your preference, that's why we rarely see people code in the same style.. Moreover, it depends on which programming language you're using.. IMHO, the important thing in coding is code readability and comments, so when your BOSS asks other people to help or develop your code. He /she will spend the least amount of their time to understand your code..
If you ask specifically from your example above, I would prefer the first one.. Because in my OPINION, imagining the WHOLE code, that one will give better readability. HOWEVER, some people may argue that it will spend some of your time typing those brackets over and over..
As per the PSR standards any structure must always enclose the code in parentheses.
The body of each structure MUST be enclosed by braces. This standardizes how the structures look, and reduces the likelihood of introducing errors as new lines get added to the body.
from the official website
Please have a look under control structures section http://www.php-fig.org/psr/psr-2/

Functional programming style vs performance in Ruby [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I love functional programming and I love Ruby as well. If I can code an algorithm in a functional style rather than in a imperative style, I do it. I tend to do not update or reuse variables as much as possible, avoid using "bang!" methods and use "map", "reduce", and similar functions instead of "each" or danger loops, etc. Basically I try to follow the rules of this article.
The problem is that usually the functional solution is much slower that the imperative one. In this article there are clear and scary examples about that, being until 15-20 times slower in some cases. After reading it and doing some benchmarks I am afraid of keep using the functional style, at least in Ruby.
By the other hand I feel more comfortable writing code in functional style because it is smart and clean, it tends to less bugs, and I think is more "correct", specially nowadays that we can use concurrency and parallelism for better performance.
So I am very confused about which style to use in Ruby. Any wise recommendation will be appreciated.

Is it considered acceptable to have no comments in good Ruby code? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I reviewed some professional code written in Ruby and found no comments. The code was reasonably clear to read but not self-documenting. Should I expect professionally written Ruby code to have comments? Or, is there some Ruby doctrine that comments are not considered essential?
This issue isn't unique to Ruby.
Code comments should be kept to an absolute minimum, because they are usually not updated when the code changes, and become more misleading than helpful.
As you have already suggested, the best code is self-documenting and requires no comments.
Edit: to clarify, if you cannot reduce the code to remove the complexity, you must provide comments. This is rare in my experience, and usually only applies when external components don't behave as you might expect.
Matz, the creator of Ruby, states his philosophy here and there: "The source code is the documentation. It even states all the bugs correctly." And he probably means that for comments as well. I think many people who don't comment in Ruby source code are following his words. Whether for you to follow him is up to you.
I have also read some Ruby introductory websites saying that, whenever you feel the necessity to comment, that is an indication that you should split that routine as in individual method, and name it as you were to comment that part.

Resources