2

I am now entering the world of java ee 6. And I am supposed to used different technologies like jsf, jpa, different kinds of beans and all that stuff.

I am learning using the netbeans IDE, which is, I should say, very efficient when it comes to getting the work done.

It is just that, I came from the old school servlet programming environment using scriptlets on them jsp pages where you get to write every line and every request parameter/attribute you have to set manually. which is somehow good because you get to understand you program THAT WELL.

but with this java ee 6, with the code generators from NETBEANS, I get to create controllers, jsf pages and entities without writing any code (taken aside the DB part though). I do understand the flow of the application but not to the degree that I can understand what the line does, how does it reached, what are the use of the variables and what does it do after. all the nitty gritty stuff.

to make it short, I am using generators without REALLY understanding the code that well (mostly on the new tags by jsf). I just want to ask if this is a bad path/practice or is it ok because we want PRODUCTIVITY?

Improve this question

3 Answers 3

Reset to default
6

The ability to abstract is one of the most powerful tools of the human brain. It allows it to handle complex systems as simple entities, provided the abstractions it works with are suitable.

This concept is very often applied to programming, because inevitably, we have to handle complex systems. Even Java as a language is already an abstraction of the JVM, which in turn is an abstraction of the actual machine you are running on. SQL is an abstraction of relational databases, which in turn are an abstraction of storage.

All this works well, because you think in terms of concepts in one abstraction layer, and this layer is separated from the layers below through an abstraction barrier. This is very well explained in SICP.

Based on this is the rather common approach of abstracting architecture and infrastructure. Libraries that do that are commonly referred to as frameworks (although nowadays everything is referred to as a framework).
One thing you will have to accept with frameworks is, that you must think within the abstraction layer they provide. How they work internally is none of your concern (assuming they work as specified) except for personal curiosity.

It is important to understand what a software component does, not how. In fact relying on the how is a good way of shooting yourself in the foot. Standing on the shoulders of giants is good.

Now to come back to code generators: Code generators are in a way an instrument of abstraction. You say: I want a controller for this and that, and zooooom it's there. You don't have to think about how it ties into the rest of the infrastructure, because all that is abstracted away. This is good.
However, I earlier mentioned the concept of abstraction barriers. An inherent problem of code generators is they provide no abstraction barrier. All the stuff they need, they do not hide it from you, but instead they throw it in your face. And you have code that consists of parts that you must change and parts that you mustn't change (as long as you want to stay in the same abstraction layer).

In some languages, Java being the canonical example, code generators are inevitable if you want to reach certain levels of abstraction. But as long as you have a clear understanding what the purpose of the code is that you generate and know which parts not to touch, you're on the safe side.

Improve this answer
4
  • 3
    I'll agree to a point - as soon as something like Spring or Hibernate does something you don't expect and you have no clue as to how they work? You're screwed :-)
    – Martijn Verburg
    Dec 10, 2011 at 20:18
  • VERY WELL SAID. i guess i just need to be more responsible with my code generators. thanks for the answer! appreciate it :D
    – chip
    Dec 11, 2011 at 0:03
  • @MartijnVerburg yes, I have encountered some situations when the stacktrace pukes out some cryptic messages, and until you get what the message is, you will feel SCREWED until you get to understand what the error message really means. thanks for (scaring) reminding me :D
    – chip
    Dec 11, 2011 at 0:08
  • A solution could be that the code generator generates interfaces and default implementations which throw exceptions when called. Your task would be to replace default implementations with customized classes. In the end you would have to add your own implementation classes and a factory class. That's a very localized change.
    – Giorgio
    Dec 11, 2011 at 12:56
6

In the book "The Pragmatic Programmer", there is a whole chapter dedictated to the problem you are mentioning. Their answer is clear: Don't use generated code you don't understand.

A probably more pragmatic (pun intended) approach is: If you have to use generated code you don't understand, for god's sake, don't touch it.

Improve this answer
2
  • hey, thanks for the suggestion. i will surely keep that in mind. :D
    – chip
    Dec 10, 2011 at 12:45
  • Thank you, thank you, thank you for saying this - it needs to be said more often!
    – Martijn Verburg
    Dec 10, 2011 at 20:16
0

I am now entering the world of assembly language, and I am supposed to used different technologies like text editors, linkers, assemblers.

I am learning using those, which is, I should say, very efficient when it comes to getting the work done.

It is just that, I came from the old school of programming where you get to enter every instruction on a front panel manually, which is somehow good because you get to understand you program THAT WELL.

But with this assembly language stuff, with the code generators from the assembler, I get to create program without touching any switches (taken aside the debugging part though). I do understand the flow of the application but not to the degree that I can understand what every bit does.

To make it short, I am using generators without REALLY understanding the code that well. I just want to ask if this is a bad path/practice or is it ok because we want PRODUCTIVITY?

Improve this answer
6
  • -1. Sarcastic and bad analogy, not an answer.
    – Fosco
    Dec 10, 2011 at 17:42
  • @Fosco Sarcastic, yes. Bad analogy? Why? It's exactly the same pattern that I've seen far too many times not to feel sarcastic about it. People used to one level of abstraction complaining that the introduction of an higher one is hiding the True Behaviour without remarking that what they take as the True Behaviour is just a level abstraction built over others. The only one I've never seen culprit of it are those making transistor models. They know very well they are building a level of abstraction over something mastered by nobody.
    – AProgrammer
    Dec 10, 2011 at 18:55
  • It is as common and as irritating as the other pattern, people used to a level of abstraction not wanting to use a lower one because it is too low without remarking that the question isn't "is it an higher or lower level of abstraction" but "is it the most appropriate one".
    – AProgrammer
    Dec 10, 2011 at 19:08
  • I get your point, but I still have a problem with the analogy and it's not a real answer. The switches on the front panel method no longer exists, so it's not a choice you can make... Some languages really do make things 'magic' and it's very difficult to give up control of the application flow and trust that your framework is going to put all the pieces together properly.
    – Fosco
    Dec 10, 2011 at 19:20
  • @Fosco, it always was difficult. I feel obligated to cite the story of Mel. And don't forget my second comment about the use of the right level of abstraction, it sometimes makes sense not to use the highest level available.
    – AProgrammer
    Dec 10, 2011 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.