An Introduction to Metaprogramming

An Introduction to Metaprogramming 

In his article "An Introduction to Metaprogramming", master Ariel Ortiz explains the concept of metaprogramming, its several uses, and different ways to apply it depending the context of the problem to solve. 

As the prefix meta suggests, metaprogramming refers to the practice of writing code for a program that writes code for a program. Kind of confusing, but that's the essence of it. They are use to automatize code writing and agilizing software development, as they are faster than writing the code by hand. Most of them are found in Linux platforms, and are usually composed of compilers, interpreters, parser generators, assemblers and preprocessors.

After explaining this concepts, the author gives differents examples of metaprogramming by creating working code of C in Ruby, and viceversa, and proceeded to explain different elements that are very common in metaprogramming and easily implemented. First, he talks about eval, a function that is used in interpreting languages, like Lisp, Perl, Python, Ruby and JavaScript, where the programming language would evaluate the real values of the operation of a string. This is, you could declare an operation as a string and evaluate it to get the result:

eval("4 + 5")  ==>  returns 9 as result.

Another concept the author brings in are the quines, which is code that outputs its own text. The example seen in the lecture is the following:

f="f=%p;puts f%%f";puts f%f

Which prins itself when ran in the console.

To give an example of metaprogramming in the wild, we are given the accessors and initializers in Ruby. Instead of defining a variable, instancing it, and assigning its respective method to get its values or set them (Getters and setters), Ruby implements different accessors that internally create the getters and setters for the variables and initializers that substitute the code and writes in all what's needed for the object to be declared, reducing all the lines of code into 2 or 3 lines of code.

I think metaprogramming could be a good practice to simplify work when coding, but one must only implement it when it is a really complex code that requires it, or you could be complicating yourself too much. Plus one must be experienced with metaprogramming, as errors could lead to possible vulnerabilities to the code, like the probability of others making code injection or modifying values.

Comments

Post a Comment

Popular posts from this blog

War Games

War Games War Games is a sci-fi movie from 1983 that narrates the story of David Lightman, a teenager that trying to hack into what he thought was a videogame development company accessed instead into a top secret military base computer and initialized a "game" called Global Thermonuclear War, which ran a simulation of a nuclear war between the USSR and the USA, driving everybody mad as they thought the simulation was a real deal, and giving a head start to a potential World War 3. Even though it is considered a classic, I must admit I had never seen the movie, not even heard about it. I watched it without knowing a thing about the plot, and I enjoyed it more than I expected to be honest. However there are a lot of things that I found a little absurd and highly unlikely to occur in real life. The plot itself, for instance. Just to think that a kid by accident has the ability to enter a military base is something I found too fictional to my taste, even when we are talking...
Read more

Software Architecture

The power of good software architecture The importance behind a simple, yet efficient design. In the chapter 14 of his book "Code Craft", author and developer Peter GoodLiffe talks about the importance and influence of good software designing. I found it quite practical (and a little unconventional) how he describes the different styles of architecture in software through comparisons with pasta. I was so hungry yet intrigued while reading through the descriptions of each type and the different applications each have for different situations. I always find it overwhelming how easy it can seem to make a good base to develop software, and yet there are so many sources and lectures on how to get it right, as it is clearly underestimated how challenging it can result to make not only a functional software, but flexible, modular, esthetic, and reliable. And the most difficult thing of all is that there are NO right answers. There are NO instructions or guides on how to b...
Read more

Understanding the SOLID Principles

Understanding the SOLID Principles In a section on the book “Ace the Programming Interview: 160 Questions and Answers for Success”, Edward Guiness talks about a set of practices to have simple and efficient code: The SOLID Principles. The acronym stands for:  Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle The Single Responsibility Principle (SRP) states that each class should have one and exactly one responsibility. Only experience and practice will help you determine what one responsibility envolves, The Open/Closed Principle (OCP) says that each class should be open for extension, but closed for modification. When adding new behavior, we should leave the base class alone and instead create new inheriting classes, and avoid unexpected consequences for the original subclasses. The Liskov Substitution Principle (LSP) says that the less inheritance we h...
Read more