3 deleted 43 characters in body
source | link

Practical reasoning

OK, I know that code is data as well. What I don't understand is, why generate source code?

From this edit, I assume you are asking on a rather practical level, not theoretical Computer Science.

The classical reason for generating source code in static languages like Java was that languages like that simply did not really come with easy to use in-language tools to do very dynamic stuff. For example, back in the formative days of Java, it simply was not possible to easily create a class with a dynamic name (matching a table name from a DB) and dynamic methods (matching attributes from that table) with dynamic data types (matching the types of said attributes). Especially since Java puts a whole deal of importance, nay, guarantees, on being able to catch type errors at compile time.

So, in such a setting, a programmer can only create Java code and write a lot of lines of code manually. Often, the programmer will find that whenever a table changes, he has to go back and change the code to match; and if he forgets that, bad things happen. Hence, the programmer will get to the point where he writes some tools that do it for him. And hence the road starts to ever more intelligent code generation.

(Yes, you could generate the bytecode on the fly, but programming such a thing in Java would not be something a random programmer would do just inbetween writing a few lines of domain code.)

Compare this to languages that are very dynamic, for example Ruby, which I would consider the antithesis to Java in most respects (note that I am saying this without valuing either approach; they are simply different). Here it is 100% normal and standard to dynamically generate classes, methods etc. at runtime, and most importantly, the programmer can do it trivially right in the code, without going on a "meta" level. Yes, things like Ruby on Rails come with code generation, but we found in our work that we basically use that as a kind of advanced "tutorial mode" for new programmers, but after a while it gets superfluous (as there is so little code to write in that ecosystem that when you know what you are doing, writing it manually gets faster than cleaning up the generated code).

These are just two practical examples from the "real world". Then you have languages like LISP where the code is data, literally. On the other hand, in compiled languages (without a runtime engine like Java or Ruby), there is (or was, I have not kept up with modern C++ features...) simply no concept of having an "undefined"defining class or method handlernames at runtime. So there, so code generation the build process is a big spectrum herethe tool of choice for most things (other more C/C++ specific examples would be things like flex, yacc etc.).

Practical reasoning

OK, I know that code is data as well. What I don't understand is, why generate source code?

From this edit, I assume you are asking on a rather practical level, not theoretical Computer Science.

The classical reason for generating source code in static languages like Java was that languages like that simply did not really come with easy to use in-language tools to do very dynamic stuff. For example, back in the formative days of Java, it simply was not possible to easily create a class with a dynamic name (matching a table name from a DB) and dynamic methods (matching attributes from that table) with dynamic data types (matching the types of said attributes). Especially since Java puts a whole deal of importance, nay, guarantees, on being able to catch type errors at compile time.

So, in such a setting, a programmer can only create Java code and write a lot of lines of code manually. Often, the programmer will find that whenever a table changes, he has to go back and change the code to match; and if he forgets that, bad things happen. Hence, the programmer will get to the point where he writes some tools that do it for him. And hence the road starts to ever more intelligent code generation.

(Yes, you could generate the bytecode on the fly, but programming such a thing in Java would not be something a random programmer would do just inbetween writing a few lines of domain code.)

Compare this to languages that are very dynamic, for example Ruby, which I would consider the antithesis to Java in most respects (note that I am saying this without valuing either approach; they are simply different). Here it is 100% normal and standard to dynamically generate classes, methods etc. at runtime, and most importantly, the programmer can do it trivially right in the code, without going on a "meta" level. Yes, things like Ruby on Rails come with code generation, but we found in our work that we basically use that as a kind of advanced "tutorial mode" for new programmers, but after a while it gets superfluous (as there is so little code to write in that ecosystem that when you know what you are doing, writing it manually gets faster than cleaning up the generated code).

These are just two practical examples from the "real world". Then you have languages like LISP where the code is data, literally. On the other hand, in compiled languages (without a runtime engine like Java or Ruby), there is (or was, I have not kept up with modern C++ features...) simply no concept of having an "undefined" method handler at runtime. So there is a big spectrum here.

Practical reasoning

OK, I know that code is data as well. What I don't understand is, why generate source code?

From this edit, I assume you are asking on a rather practical level, not theoretical Computer Science.

The classical reason for generating source code in static languages like Java was that languages like that simply did not really come with easy to use in-language tools to do very dynamic stuff. For example, back in the formative days of Java, it simply was not possible to easily create a class with a dynamic name (matching a table name from a DB) and dynamic methods (matching attributes from that table) with dynamic data types (matching the types of said attributes). Especially since Java puts a whole deal of importance, nay, guarantees, on being able to catch type errors at compile time.

So, in such a setting, a programmer can only create Java code and write a lot of lines of code manually. Often, the programmer will find that whenever a table changes, he has to go back and change the code to match; and if he forgets that, bad things happen. Hence, the programmer will get to the point where he writes some tools that do it for him. And hence the road starts to ever more intelligent code generation.

(Yes, you could generate the bytecode on the fly, but programming such a thing in Java would not be something a random programmer would do just inbetween writing a few lines of domain code.)

Compare this to languages that are very dynamic, for example Ruby, which I would consider the antithesis to Java in most respects (note that I am saying this without valuing either approach; they are simply different). Here it is 100% normal and standard to dynamically generate classes, methods etc. at runtime, and most importantly, the programmer can do it trivially right in the code, without going on a "meta" level. Yes, things like Ruby on Rails come with code generation, but we found in our work that we basically use that as a kind of advanced "tutorial mode" for new programmers, but after a while it gets superfluous (as there is so little code to write in that ecosystem that when you know what you are doing, writing it manually gets faster than cleaning up the generated code).

These are just two practical examples from the "real world". Then you have languages like LISP where the code is data, literally. On the other hand, in compiled languages (without a runtime engine like Java or Ruby), there is (or was, I have not kept up with modern C++ features...) simply no concept of defining class or method names at runtime, so code generation the build process is the tool of choice for most things (other more C/C++ specific examples would be things like flex, yacc etc.).

2 deleted 73 characters in body
source | link

Practical reasonreasoning

OK, I know that code is data as well. What I don't understand is, why generate source code? Why not make it into a function which can accept parameters and act on them?

From this edit, I assume you are asking on a rather practical level, not theoretical Computer Science.

So. The classical reason for generating source code in static languages like Java was that languages like that simply did not really come with easy to use in-language tools to do very dynamic stuff. For example, back in the formative days of Java, it simply was not possible to easily create a class with a dynamic name (matching a table name from a DB) and dynamic methods (matching attributes from that table) with dynamic data types (matching the types of said attributes). Especially since Java puts a whole deal of importance, nay, guarantees, on being able to catch type errors at compile time.

So, in such a setting, a programmer can only create Java code and write a lot of lines of code manually. Often, the programmer will find that whenever a table changes, he has to go back and change the code to match; and if he forgets that, bad things happen. Hence, the programmer will get to the point where he writes some tools that do it for him. And hence the road starts to ever more intelligent code generation.

(Yes, you could generate the bytecode on the fly, but programming such a thing in Java would not be something a random programmer would do just inbetween writing a few lines of domain code.)

Compare this to languages that are very dynamic, for example Ruby, which I would consider the antithesis to Java in most respects (note that I am saying this without valuing either approach; they are simply different). Here it is 100% normal and standard to dynamically generate classes, methods etc. at runtime, and most importantly, the programmer can do it trivially right in the code, without going on a "meta" level. Yes, things like Ruby on Rails come with code generation, but we found in our work that we basically use that as a kind of advanced "tutorial mode" for new programmers, but after a while it gets superfluous (as there is so little code to write in that ecosystem that when you know what you are doing, writing it manually gets faster than cleaning up the generated code).

These are just two practical examples from the "real world". Then you have languages like LISP where the code is data, literally. On the other hand, in compiled languages (without a runtime engine like Java or Ruby), there is (or was, I have not kept up with modern C++ features...) simply no concept of having an "undefined" method handler at runtime. So there is a big spectrum here.

Practical reason

OK, I know that code is data as well. What I don't understand is, why generate source code? Why not make it into a function which can accept parameters and act on them?

From this edit, I assume you are asking on a rather practical level, not theoretical Computer Science.

So. The classical reason for generating source code in static languages like Java was that languages like that simply did not really come with easy to use in-language tools to do very dynamic stuff. For example, back in the formative days of Java, it simply was not possible to easily create a class with a dynamic name (matching a table name from a DB) and dynamic methods (matching attributes from that table) with dynamic data types (matching the types of said attributes). Especially since Java puts a whole deal of importance, nay, guarantees, on being able to catch type errors at compile time.

So, in such a setting, a programmer can only create Java code and write a lot of lines of code manually. Often, the programmer will find that whenever a table changes, he has to go back and change the code to match; and if he forgets that, bad things happen. Hence, the programmer will get to the point where he writes some tools that do it for him. And hence the road starts to ever more intelligent code generation.

(Yes, you could generate the bytecode on the fly, but programming such a thing in Java would not be something a random programmer would do just inbetween writing a few lines of domain code.)

Compare this to languages that are very dynamic, for example Ruby, which I would consider the antithesis to Java in most respects (note that I am saying this without valuing either approach; they are simply different). Here it is 100% normal and standard to dynamically generate classes, methods etc. at runtime, and most importantly, the programmer can do it trivially right in the code, without going on a "meta" level. Yes, things like Ruby on Rails come with code generation, but we found in our work that we basically use that as a kind of advanced "tutorial mode" for new programmers, but after a while it gets superfluous (as there is so little code to write in that ecosystem that when you know what you are doing, writing it manually gets faster than cleaning up the generated code).

These are just two practical examples from the "real world". Then you have languages like LISP where the code is data, literally. On the other hand, in compiled languages (without a runtime engine like Java or Ruby), there is (or was, I have not kept up with modern C++ features...) simply no concept of having an "undefined" method handler at runtime. So there is a big spectrum here.

Practical reasoning

OK, I know that code is data as well. What I don't understand is, why generate source code?

From this edit, I assume you are asking on a rather practical level, not theoretical Computer Science.

The classical reason for generating source code in static languages like Java was that languages like that simply did not really come with easy to use in-language tools to do very dynamic stuff. For example, back in the formative days of Java, it simply was not possible to easily create a class with a dynamic name (matching a table name from a DB) and dynamic methods (matching attributes from that table) with dynamic data types (matching the types of said attributes). Especially since Java puts a whole deal of importance, nay, guarantees, on being able to catch type errors at compile time.

So, in such a setting, a programmer can only create Java code and write a lot of lines of code manually. Often, the programmer will find that whenever a table changes, he has to go back and change the code to match; and if he forgets that, bad things happen. Hence, the programmer will get to the point where he writes some tools that do it for him. And hence the road starts to ever more intelligent code generation.

(Yes, you could generate the bytecode on the fly, but programming such a thing in Java would not be something a random programmer would do just inbetween writing a few lines of domain code.)

Compare this to languages that are very dynamic, for example Ruby, which I would consider the antithesis to Java in most respects (note that I am saying this without valuing either approach; they are simply different). Here it is 100% normal and standard to dynamically generate classes, methods etc. at runtime, and most importantly, the programmer can do it trivially right in the code, without going on a "meta" level. Yes, things like Ruby on Rails come with code generation, but we found in our work that we basically use that as a kind of advanced "tutorial mode" for new programmers, but after a while it gets superfluous (as there is so little code to write in that ecosystem that when you know what you are doing, writing it manually gets faster than cleaning up the generated code).

These are just two practical examples from the "real world". Then you have languages like LISP where the code is data, literally. On the other hand, in compiled languages (without a runtime engine like Java or Ruby), there is (or was, I have not kept up with modern C++ features...) simply no concept of having an "undefined" method handler at runtime. So there is a big spectrum here.

1
source | link

Practical reason

OK, I know that code is data as well. What I don't understand is, why generate source code? Why not make it into a function which can accept parameters and act on them?

From this edit, I assume you are asking on a rather practical level, not theoretical Computer Science.

So. The classical reason for generating source code in static languages like Java was that languages like that simply did not really come with easy to use in-language tools to do very dynamic stuff. For example, back in the formative days of Java, it simply was not possible to easily create a class with a dynamic name (matching a table name from a DB) and dynamic methods (matching attributes from that table) with dynamic data types (matching the types of said attributes). Especially since Java puts a whole deal of importance, nay, guarantees, on being able to catch type errors at compile time.

So, in such a setting, a programmer can only create Java code and write a lot of lines of code manually. Often, the programmer will find that whenever a table changes, he has to go back and change the code to match; and if he forgets that, bad things happen. Hence, the programmer will get to the point where he writes some tools that do it for him. And hence the road starts to ever more intelligent code generation.

(Yes, you could generate the bytecode on the fly, but programming such a thing in Java would not be something a random programmer would do just inbetween writing a few lines of domain code.)

Compare this to languages that are very dynamic, for example Ruby, which I would consider the antithesis to Java in most respects (note that I am saying this without valuing either approach; they are simply different). Here it is 100% normal and standard to dynamically generate classes, methods etc. at runtime, and most importantly, the programmer can do it trivially right in the code, without going on a "meta" level. Yes, things like Ruby on Rails come with code generation, but we found in our work that we basically use that as a kind of advanced "tutorial mode" for new programmers, but after a while it gets superfluous (as there is so little code to write in that ecosystem that when you know what you are doing, writing it manually gets faster than cleaning up the generated code).

These are just two practical examples from the "real world". Then you have languages like LISP where the code is data, literally. On the other hand, in compiled languages (without a runtime engine like Java or Ruby), there is (or was, I have not kept up with modern C++ features...) simply no concept of having an "undefined" method handler at runtime. So there is a big spectrum here.