• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

JEE & me

 
Greenhorn
Posts: 2
Mac VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I would very much like to know what others think about this.
It's an issue that keeps tripping me up: no matter how hard I try, I can't seem to get along with JEE. I'm absolutely fine with Java itself - the language and the coding.
But every time that I'm confronted with frameworks, things being abstracted away and the like, the disconcert rises within me like boiling milk.

This is what I'm trying to figure out: should I accept this as an inevitable side-effect of how my brain is wired, or is there something that I have overlooked? Maybe a learning approach, a point of view that I missed until now?

I have thought about this a lot, because it seriously bothers me. I would love to either find a way to properly get my head around it - or know for once and for all that JEE and me simply aren't meant for one another, so that I can concentrate on finding a job without it. This is what I've been able to come up with until now.

- First, it's not that JEE is inherently too difficult or complex for me to understand. I studied technical physics at university level: I understand what a tensor is, and what quantum chromodynamics is about. I don't think that programming frameworks are essentially more difficult to understand than that.

- It's neither that I unconsciously dislike my job. I really like programming, at least as long as it's not JEE. I've been a programmer for 14 years: I've done a lot of C, C++ and PL/SQL programming. I know that I am good at that, and I definitely like doing it. It's fun, it brings me into a state of flow.

- It's not that I dislike Java. I've done quite a bit of Java coding. I especially like creating GUI's (first using Swing, now with JavaFX) and scientific applications.


I've thought about the following (overlapping) explanations:

- I think very much Bottom-up: I need to start with the technicalities, and then work my way up to abstractions.
The other way is Top-Down: starting with the high-level abstractions and later drilling down to the technical bits.
When I understand the technical details I can combine those elementary building blocks to larger concepts. I can then happily use those to create things with such as an application.
But that nitty-gritty technical understanding is a definite must-have: without it, abstractions don't make any sense to me.
I have the impression that most people think Top-Down. Hence, knowledge is more often than not presented in this fashion. I immediately recognise this when it happens: an abstraction is introduced (say, in a course) - without going into the details. This is also common in mathematics (as I learned in highschool): "just assume for now that ... is ... ". It always trips me up. My mind refuses to move on before the abstraction is properly understood.
It's maddening, because I cannot force it forward. The result is that I get stuck on the first new abstraction that's introduced; I'm frenetically trying to understand that while the rest of the class is moving forward in a carefree state of suspended understanding.
For most people, this understanding apparently comes afterwards (if at all). It does not bother them that it is not fully understood from the beginning: they can treat it as a black box.
The net result is that I neither understand that abstraction, nor whatever the course was supposed to teach me.

- working with JEE is, as an activity, something entirely different as programming in Java is.
The overall result is a bit as if I would have set out to become a painter and one day finding myself working in a marketing job, using stock images to create advertisements with.
Although you still use bits and chunks of Java code in JEE development, it seems to me that it comprises only a small part of it. A very small part.
Working on a JEE application consists largely of figuring out what framework is best in the given case; trying to understand those frameworks; installing, configuring and administering them; installing, configuring and administering application servers and making them to work with mentioned frameworks; setting up messaging services and message discovery services; deciding on a persistence framework and DB vendor and getting THOSE to work - etcetera.
The most obvious thing about all this is that whatever it is, programming it ain't.
Here my Top-Down handicap also comes into play: figuring out what has to be done, and where, and how, is a formidable task. Maybe this task is not necessarily intrinsically difficult. It's daunting because of its sheer vastness - such as in the number of pages that have to be read. And it doesn't make much sense because of how it is presented. On top of that, some people seem to enjoy making things appear more complex than they really are. They love to use interesting-sounding buzzwords that obfuscate more than they explain.
So:
* the way in which it is presented makes it difficult to understand ("here, read this 1000-page JXFL Unleashed ...")
* even if I can see that it is essentially a good idea (from the business POV) to use a framework instead of coding by hand in a given situation, I often feel bewildered *why* certain choices are made. Is it really a good thing to pile layers and layers of abstraction upon another? Sure, it offers an elegant solution. But it's also nearly impossible to truly understand what's happening "under the hood". What does that mean for future maintenance?
* maybe it's because of my troubled relationship with it, but I find working with JEE dreadfully boring (or maybe it's the other way around?). As I said, I really like programming. But I have never felt that working with JEE is programming - apart from the odd bits and pieces of method code that need to be overridden. Framework Administration would be a better word for it. You know what it feels like to me? As if JEE has taken the fun, creative bits out of my job and given me Framework Administration tasks in return.

- I've been diagnosed with (inattentive) ADHD. As I've understood it, this makes my thought processes more associative than linear (compared to what's average). Another result is that this makes it more difficult to concentrate on things that are not directly engaging; on the other hand, I'm prone to hyperfocus on things that are engaging. I'm also a bit anti-authoritarian and allergic to what I perceive as peer (group) pressure. For instance: if my colleagues are all drooling over some snazzy new framework and it seems to me as if they are at least partly driven by "I don't want to appear like the odd one out" - chances are that I will dislike it for that reason alone.

- I'm a kinesthetic learner: my imagination works with spatial, tactile impressions as opposed to images or words.

- sometime ago I read a blog about "alteration mages" and "creation mages" in programming. I don't pretend to be a mage of any kind, but I definitely recognise myself in what was said about "creation mages". In short, it comes down to preferring "creating things myself" over "working with given solutions".


Maybe this post makes more sense on a psychology forum than a Java forum; but since it's also about Java I can always try. I'd be happy to know if there is anyone out there with a similar experience, because I've never met any.

PS - I'm aware that I have a particular opinion about JEE. Whether that's justified is quite another matter: it probably isn't, because so many apparently find it very useful.
But this is how I experience it and I want to figure out how to deal with it.



Thanks for reading this far!
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Luthien Dulk wrote:It's an issue that keeps tripping me up: no matter how hard I try, I can't seem to get along with JEE...


Wow. Quite a lot to take in there, but I'll have a stab at a few points.

First: You're not alone. I've been programming for 35 years, and I'm still happier when I can understand stuff from the ground up. I suspect that has a lot to do with the fact that when I started, almost ALL languages were procedural, so I had a lot of procedural theory drummed into me. If you're like me, I also suspect that you're far happier when you've written those low level methods too, because you know they're "right" (even when they're not ).

Second: To hear the hype, you might think that JEE is some universal panacaea. It's NOT...and a lot of programmers forget that. It's a framework that helps you to deal with large distributed systems in a way that allows you to forget (or at least postpone decisions) about a lot of the menial issues like concurrency, location, and (possibly most important) scalability. If you're writing a small desktop system, or even some medium-sized ones, it's a sledgehammer to crack a walnut.


The best analogy I can think of for abstraction like that (in fact, any type of abstraction) is driving a car:
1. In order to drive a car, you don't have to understand how the internal combustion engine works.
2. If every car had its own way of responding, learning how to drive would be awfully complicated.
So the abstraction is simple: You have either 2 or 3 pedals and a steering wheel; and they work the same way in every car that you get into. You'll also find the pedals in the same position whether you're driving on the left or the right, so your brain has less to remember and can concentrate on the business at hand, which is driving.

That said, if someone put you in the cockpit of a Formula one car, you'd probably want to run a lot of practise laps to familiarise yourself with the layout (not to mention the experience of 6G cornering).

On average, the human brain can handle 7 ± 2 things at once, so if you had to think about the order in which cylinders were firing, you'd be a lousy driver. Abstraction is a way of managing complexity.

In programming - especially Object-Oriented programming - the idea is the same:
If I want to use a HashMap, I DON'T need to know how it works - or whether it uses cuckoo hashing or Robin Hood hashing - what I DO need to know is what it does, and also why I would choose it over, say, a TreeMap, or a ConcurrentSkipListMap.

This is entirely at odds with the bottom-up approach, which is all about understanding how things work, and you do need to rewire your brain a bit to be able to deal with problems in terms of objects rather than procedures.


Here's a little two-part problem for you that may illustrate it better:
1. You have a crossing of two 2-lane roads that needs a new traffic light system. Assume that each lane in both roads has a sensor that registers when a car is approaching the light for its lane. It has already been determined that the lights for a particular road, once green, should remain green for at least 60 seconds, and that status checks only need to be done every second. Write a program that delivers a reasonable throughput of traffic in both directions.

2. The council now decides that it wants to add a left-turn (or right-turn if you live in the UK) lane that is also controlled by lights and sensors, and that these should remain green for at least 30 seconds.
(a) How would you do that?
(b) Knowing what you now know, how would you have changed your original design to make this addition easier?

Give it a bash and see what you come up with. You may surprise yourself.

Winston
 
Luthien Dulk
Greenhorn
Posts: 2
Mac VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Winston,

thanks for your reply!
Reading your comment, I wished that I had read something like that when I was first confronted with JEE because it explains the "why" very clearly.

However, the problem isn't so much that I don't understand the need for this "abstracted" approach in certain cases. Unfortunately, this awareness does not make it any easier to deal with. Though I can certainly learn things such as OO - I cannot change how I think and function; what my strong points are and my not-so-strong points. That's part of who I am.

Winston Gutkowski wrote:This is entirely at odds with the bottom-up approach, which is all about understanding how things work, and you do need to rewire your brain a bit to be able to deal with problems in terms of objects rather than procedures.



I did not find the switch from "procedural" to "object oriented" all that difficult to make. I admit that I still feel a bit inclined to think in procedural terms, but I can certainly think in OO terms. This is not the problem. I'll try to clarify it a bit more.
Last weekend I found a blog post titled "Whatever happened to programming?" by Mike Taylor which exactly describes what I'm trying to say.
(I first took some quotes from that post, but because I ended up quoting practically the whole thing I figured that the link would do just as well)

His point comes down to this: like me, he has the experience that the largest part of modern software development is an entirely different activity as it used to be. "It's not creative; it's not making".
He then quoted Donald Knuth from from Peter Siebel's book Coders at Work, who says largely the same thing: he's worried that the way programming goes these days isn't any fun, because "it's just plugging in magic incantations". You don't get the chance to do anything new. Nowadays, the reward is to see results coming after a load of boring work, but "the work didn't use to be boring".

Mike Taylor then talks about what he calls Phases 1 and 2 in development: Phase 1 being the initial, creative part where it all comes together and Phase 2 the consolidation, documenting, writing test cases etcetera. Phase 2 has always been part of development - that's not the problem. But today, practically everything is Phase 2.

In the follow-up post he answers some commentators of the original post, further working out his ideas.
For one thing, he argues that using libraries in itself is not the problem. I agree: it is great to have a set of existing (and well-documented!) functionality that we can call on whenever we need it. As he says: the problem arises when ALL we do is glue libraries together.
He then shifts towards Frameworks, defining the point where the "don't call us, we'll call you" principle kicks in as "not always, but often, marking the line where this stops being fun".

The Framework rant that follows goes into the supposed promises which Frameworks (usually) fail to fulfill. Now, as I said, this is not the gist of my point but I certainly recognise it. Here it is, slightly abbreviated:


Mike Taylor wrote:In my experience of programming with frameworks they do keep their promise of making things very quick and easy … so long as you do things in exactly the way the framework author intended.
The moment you go off-piste, everything goes Pete Tong, and what should be simple is suddenly not merely hard but often impossible. The framework goes out of its way to prevent you from doing what you intended. Strange side-effects hamper your efforts. The hook that you need to get the functionality you want isn’t there. Your attempt to work around it causes something else, apparently unrelated, to start misbehaving in subtle and unpredictable ways. Congratulations! You are now suffering from Framework Fever! Doctor Taylor prescribes a period of complete rest before building up your strength by working through the exercises in K&R.
(...)
You know the real problem with frameworks? They demo too well. Someone shows you their favourite framework and demonstrates how you can build 50% of your application in half an hour! Great! That other 50% can’t be hard, can it? But it turns out that what looked like 50% is actually 5%, and filling in the other 95% gets exponentially more difficult as you approach the 100% mark. Frameworks are great for building toys, and that fools us — again and again — into assuming they’re good for building products.



I'm aware that my topic may be rather ill-defined. Mike Taylor also seems to shift from "libraries" to "frameworks" - and I use the term JEE a lot, because that's where in my experience the trouble always occurs.
But it seems that the root cause of my uneasiness and frustration comes from a shift in my job from "mostly creative programming" to "mostly administering frameworks". Apart from how well those Frameworks actually perform; apart from any considerations about the desirability of building and using large distributed systems based on Frameworks - I have noticed time and again that this calls for another sort of person.

I'm unhappy and frustrated because what I consider to be my best skills are almost never used.
Instead, there is ample call on skills that I don't have: the ability to absorb large amounts of high level information without understanding it technically. I'm supposed to work with things created by others - while I would rather have done that myself. It's not the sort of thing that I am good at, and it is all the more frustrating because I am continuously getting the message that what I am good at is not needed.

Should I get out of Java programming, or is there still a place somewhere where I can do what I'm good at?


Winston Gutkowski wrote:
The best analogy I can think of for abstraction like that (in fact, any type of abstraction) is driving a car:
1. In order to drive a car, you don't have to understand how the internal combustion engine works.
(...)



Funny you should give this example, because I have, even as a seven-year-old girl, always wanted to know how things work. Because I was also quite smart, I figured out how the television and radio and cars worked. By asking my parents - I even had a big notebook in which my father wrote down (and drew) all he explained to me, or, if they didn't know, I went to the library and read until I knew.
I have oftentimes wondered how people can work with things that they don't have any idea about how they work: I was, for instance, much surprised that not one of my 50 colleagues in my first IT job had ever taken a computer apart (and put it back together again). They neither knew nor cared - and indeed as you say: they could nevertheless do their work. But I'm different. I want to know how things work, because otherwise all that I do is nothing but voodoo. Magic incantations. Which is precisely the phrase that Donald Knuth uses "it's just plugging in magic incantations".
There's nothing wrong with magic incantations as such - but surely not in something so inherently logical and rational as software development!


Winston Gutkowski wrote:
2. If every car had its own way of responding, learning how to drive would be awfully complicated.
So the abstraction is simple: You have either 2 or 3 pedals and a steering wheel; and they work the same way in every car that you get into. You'll also find the pedals in the same position whether you're driving on the left or the right, so your brain has less to remember and can concentrate on the business at hand, which is driving.
That said, if someone put you in the cockpit of a Formula one car, you'd probably want to run a lot of practise laps to familiarise yourself with the layout (not to mention the experience of 6G cornering).



Interesting point - but I think it only applies as long as you restrict yourself to one framework only, so that you are very familiar with it. In this case the argument would also apply to using a sufficiently high-level language: you don't need to know the exact instruction sets of different processors because they are abstracted (far) away behind the core elements of the language.
In practice however, the complexity of the abstraction layer far surpasses the complexity of whatever it encapsulates. And that's just one framework - but there are many! A typical JEE framework does not so much simplify the underlying language features - but it clusters them in pre-configured chunks. Because there are so many possible ways of assembling and configuring these chunks, the framework specs are hugely complex. Much more so than the language.

To think of an analogy that would demonstrate my point: take washing. The basic language would translate to a handful of basic elements: adding water, draining, spinning, adding soap, etcetera. The controls of such a very simple machine would be easy to understand and I would not find it very difficult to figure out a workflow that would result in clean laundry.
Now, someone thinks that this is all too much hassle: too procedural, too much error-prone, whatnot. So they develop an abstraction layer: the LaundryButler. The demo that comes with it involves setting a row of switches for laundry colour, shape, amount, location and exact fiber composition. Among others. And then the magic happens: the LaundryButler takes your laundry and processes it fully automatic.
Of course, when you really start using the thing, you need to go through the LaundryButler Unleashed volume (1200 pages) that came with it in order to get it working for your specific household situation. The control panel resembles that of a Boeing-747.
The essence: while this LaundryButler may indeed work very well in a given situation, it requires a completely different sort of skill to get the damn thing working.
But that is only the beginning, because as these things go, LaundryButler is actively developed and you get an update every year, requiring you to change the whole configuration. And on top of that, there isn't just the LaundryButler - your mother has a WashRobot (c); the neighbours to the left have a Wash-O-Matic and the neighbours to the right a Spic-and-Spantastic (c). They are all completely different in the way they operate - knowing one does not help you to understand another - rather the contrary.
It makes you wonder if it's worth all the hassle in the end, if you wouldn't have been better off with the simple low-level washing machine.


Winston Gutkowski wrote:On average, the human brain can handle 7 ± 2 things at once, so if you had to think about the order in which cylinders were firing, you'd be a lousy driver. Abstraction is a way of managing complexity.


Understanding how the internal combustion engine works is not the same thing as needing to be aware of the order in which the cylinders fire.
Still, I agree with "Abstraction is a way of managing complexity". But I'm afraid that it's not that straightforward. It's rather that Abstraction replaces one kind of complexity with another kind. Instead of the low-level complexity of the programming language, you get the high-level complexity of the framework. As Mike Taylor also says: "Frameworks demo too well". In the ideal situation, a framework does indeed work wonderfully well. But it is also my own experience that as soon as you try to use it in a real-world scenario, things can get very hairy, very quickly. And then the problem arises that it is never straightforward to find out how to make the framework do what you (or the customer) wanted - while, using the programming language it would have been trivial.

I have imagined a sort of visual representation of how this works. Imagine the whole field of possible programming situations as a rectangle. The vertical axis represents depth - the intrinsic richness or complexity; the horizontal axis represents width - the multitude, the amount of elements, the extent. In this view, a (3G) programming language is a narrow, high (deep) rectangle. It doesn't have many elements (narrow), but they can be combined in many subtle ways (depth). Applying a framework somehow translates depth into width: by creating a manifold of combinations of language elements. The intrinsic complexity is shallow, because you cannot combine Framework elements in the same way as language elements. Framework elements are not atomic like Language elements, but complex entities of their own. They are more or less given and can only be configured.
In both ways - programming language or framework - it is in essence possible to address all possible programming situations. The difference is that the cognitive labour required to arrive on a given point is very different. Using the programming language, one has to construct a pathway to access it. Using a framework, one has to look up the nearest solution, and tweak it until it fits.


Well, I hope it makes some sense
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Luthien Dulk wrote:Well, I hope it makes some sense


Some; and I do agree that sometimes working on a large distributed project can make you feel more like a configurator than a programmer, but maybe it's a natural course of events. Vancouver has a rapid transit system that has been running very nicely for more than 20 years with no drivers. Also, it should be added, with no accidents.

I've always thought that if we (programmers) are doing our jobs properly, eventually we will program ourselves into oblivion. In many cases (for example, modern JIT compilers) programs can already write better code than us and, if that's the case, I reckon we should just let them get on with the job. However, we're a long way from a thinking machine yet, so there's still a fair bit of scope for creativity; just maybe not in the "nuts and bolts" stuff any more.

Strangely enough, it took me about 8 years of working with C++ and Java before I had my "moment of clarity", but it truly was a 'Eureka' moment, (and you don't get too many of those in your life). And ever since, the business of thinking in abstractions has come a lot easier.

Have you had a look at the problem I described? Do you understand what makes it so difficult to solve simply in procedural terms?
I suspect that the more problems you can find like it, the more you may begin to see that there are many orders of problems that can't be solved by the "how" paradigm; you need to look at "what". I think perhaps that my work in databases and modelling probably helped me out a bit there, because they are almost entirely concerned with "what" rather than "how".

I've actually written a short essay about my OO "epiphany" and how it came about. If you're interested, let me know and I'll send it to you.

Winston
 
Lasagna is spaghetti flvored cake. Just like this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic