Last week I got to take interviews to hire senior java developers with
around 5 years of experience. But after the interview process is over I
felt like the frameworks makes developers life easier but at the same time making them dumb.
Everyone puts almost all the new frameworks on their resume claiming they have "Strong, working experience on Spring, Hibernate, Web Services etc".
Here is how the interviews went on.
Me: You have used Spring in your latest project. What are the advantages of using Spring?
Interviewee: We can configure beans in XML and it will take care of instantiating them and give it to us.
Me: If Spring is only for creating objects why is it required at all? I can directly instantiate the dependencies using "new". Why should I configure the class names in XML and get the object from Spring?
Interviewee: If tomorrow we wish to create another implementation of our interface, we can create the new implementation and update the XML configuration to use new impl. We don't need to change Java class and compile them.
Me: But you are writing a new Java class, so obviously you need to compile the project.
Regarding XML change, 99% of the times your XML will be packaged in war or ear file.
So you will run ANT script and create the war with all the new changes. Then your point of "if it is XML I don't need to compile" is not a valid point.
Interviewee: Hmmm, but the Dependency Injection design pattern suggests to follow this way.
Me: OK. I am done with the interview. Our HR will get back to you. :-)
Interview with another guy:
Me: Can you explain about your latest project and what technologies have you used?
Interviewee: It is some XYZ System and we are using Spring, Hibernate, REST WebServices.
Me: Ok. Can you explain something about RESTful architecture?
Interviewee: We can develop RESTful application by using @RequestMapping(value="/url", method="POST"). And also we can use PUT, DELETE methods.
Me: That OK, but what is the concept of RESTful architecture?
Interviewee: That's what I am explaining. If you use @RequestMapping(value="/url", method="POST") you can develop RESTful application.
Me: Ok, How good are you in Hibernate?
Interviewee: I am using Hibernate for the last 2 years. I am very good at using Hibernate.
Me: What are the advantages of using Hibernate over JDBC?
Interviewee: By using Hibernate, we don't need to write anything to interact with the database, Hibernate will take care of it.
Me: How Hibernate comes to know about your project requirements?
Interviewee: If we use Hibernate, it will take care of saving, updating and fetching data from the database.
Me: Uffffffuuuuu... OK.. In your free time do you read any technology related blogs?
Interviewee: Yeah, why not. That how I learn Hibernate in-depth.
Me : Very Good, nice talking to you. Our HR will get back to you. :-)
Interview process went on like this...
I strongly believe frameworks will increase developer productivity. But the developers should try to understand how the framework is doing the stuff. You need not learn all the internal working mechanisms of frameworks. If you are really good at Servlets and JSP then it is very easy to understand any Java Web framework like Struts, SpringMVC etc.If you aren't good at the basics then obviously for every other question reply would be.. "framework's annotation/xml will execute this"
I strongly recommend the people who want to start their career as a Java developer to work on Core Java, Servlets, JSP for sometime.Then only one can understand the frameworks in proper way.
Reference: Are frameworks making developers dumb? from our JCG partner Siva at the "My Experiments on Technology" blog.
Everyone puts almost all the new frameworks on their resume claiming they have "Strong, working experience on Spring, Hibernate, Web Services etc".
Here is how the interviews went on.
Me: You have used Spring in your latest project. What are the advantages of using Spring?
Interviewee: We can configure beans in XML and it will take care of instantiating them and give it to us.
Me: If Spring is only for creating objects why is it required at all? I can directly instantiate the dependencies using "new". Why should I configure the class names in XML and get the object from Spring?
Interviewee: If tomorrow we wish to create another implementation of our interface, we can create the new implementation and update the XML configuration to use new impl. We don't need to change Java class and compile them.
Me: But you are writing a new Java class, so obviously you need to compile the project.
Regarding XML change, 99% of the times your XML will be packaged in war or ear file.
So you will run ANT script and create the war with all the new changes. Then your point of "if it is XML I don't need to compile" is not a valid point.
Interviewee: Hmmm, but the Dependency Injection design pattern suggests to follow this way.
Me: OK. I am done with the interview. Our HR will get back to you. :-)
Interview with another guy:
Me: Can you explain about your latest project and what technologies have you used?
Interviewee: It is some XYZ System and we are using Spring, Hibernate, REST WebServices.
Me: Ok. Can you explain something about RESTful architecture?
Interviewee: We can develop RESTful application by using @RequestMapping(value="/url", method="POST"). And also we can use PUT, DELETE methods.
Me: That OK, but what is the concept of RESTful architecture?
Interviewee: That's what I am explaining. If you use @RequestMapping(value="/url", method="POST") you can develop RESTful application.
Me: Ok, How good are you in Hibernate?
Interviewee: I am using Hibernate for the last 2 years. I am very good at using Hibernate.
Me: What are the advantages of using Hibernate over JDBC?
Interviewee: By using Hibernate, we don't need to write anything to interact with the database, Hibernate will take care of it.
Me: How Hibernate comes to know about your project requirements?
Interviewee: If we use Hibernate, it will take care of saving, updating and fetching data from the database.
Me: Uffffffuuuuu... OK.. In your free time do you read any technology related blogs?
Interviewee: Yeah, why not. That how I learn Hibernate in-depth.
Me : Very Good, nice talking to you. Our HR will get back to you. :-)
Interview process went on like this...
I strongly believe frameworks will increase developer productivity. But the developers should try to understand how the framework is doing the stuff. You need not learn all the internal working mechanisms of frameworks. If you are really good at Servlets and JSP then it is very easy to understand any Java Web framework like Struts, SpringMVC etc.If you aren't good at the basics then obviously for every other question reply would be.. "framework's annotation/xml will execute this"
I strongly recommend the people who want to start their career as a Java developer to work on Core Java, Servlets, JSP for sometime.Then only one can understand the frameworks in proper way.
Reference: Are frameworks making developers dumb? from our JCG partner Siva at the "My Experiments on Technology" blog.
Related Articles :
Recently I helped a friend to solve some problems in his project and he told me that the architect says that is an expert in Spring and Hibernate but he didn't know anything about DI and ORM. For example the architect instructs the developers to inject DAO using @Autowired directly to JSF Managed Beans(BTW he never configured an ELResolver for JSF) and he never realise that the "Spring Beans" were nothing but a simple instance created by JSF
ReplyDelete"But the developers should try to understand how the framework is doing the stuff."
ReplyDeleteExcept that's not what you're asking for.
Your questions were *actually* about design patterns (eg, dependency injection) and other high-level concepts (eg, the REST web service architecture, ORM plus/minuses).
And guess what? There have *always* been developers who don't understand software design and architecture (hell, many developers don't understand the basics of object oriented software development). This is hardly new, and "frameworks" aren't making that situation better or worse.
It's certainly good to understand how a framework gets its job done - but the glory of a framework if that if you follow the recipes you don't *have* to understand it completely to get serviceable results.
ReplyDeleteI see a somewhat different issue in your experience: in order to use patterns/tools/frameworks safely, you have to know your own limits so you know when to go get more help ... and it sounds like perhaps some of the folks you're interviewing aren't able to make that critical judgement. If they don't have that self-awareness (and the integrity to own up to their limits) then they can be dangerous to have in the workplace.
it is not the frameworks which is making them dumb.
ReplyDelete--Gautam
"In your free time do you read any technology related blogs?"
ReplyDeleteThis question really irritates me and any interviewer asking needs to take a reality check. You are digging for geeks and they have a strong tendency to harm projects, because they tend not to be well rounded and almost invariably have poor communication. By all means test candidates on their ability to do the job (technical ability is fundamental for developers but by no means the only fundamental skill required to be productive). Your second example just shows you that reading computing blogs has no direct connection to technical ability.
Also you are confusing not understanding principles of a given framework, rather than an issue with frameworks this is more to do with the quality of candidates you are attracting and selecting for interview.
Frameworks aren't making developers dumb. They are allowing dumb developers to be able to achieve things. Without the frameworks the dumb developers would have given up long ago, but these days they can get quite a long way without knowing what they're doing...
ReplyDeleteI can't agree more, its not just about framework its basic lack of initial knowledge, I've been facing very similar interviews lately and they're really pegging us. We always opt for quality intakes but trust me its real hard to find, so we went off to a very different strategy entirely, now what we do is hire the people with talent and good initial programming skills and pass them through training process to get used to the things they missed at university level CS courses.
ReplyDeleteHere we go it'll be nice read for you similar interview stories:
http://me-bleeding.blogspot.com/2011/03/hilarious-interviews.html
We call this thinking 'Power comes from an outlet'-philosophy.
ReplyDeleteI strongly recommend the people who want to start their career as a java developer to beware of java. In computer science we breed idiots.
That has one simple reason: They have to be cheap. Remember why java exist. Why core java is more dangerous than c++.
Because it's cheap to learn. You become productive much faster than in c++.
But you stay dumb. You will never solve real problems with multiple inheritance easily because you cannot phrase or even think such a solution. You cannot think const correctness, no c++-references, no raii, only pointers and no guarantee when or even if an object will be destructed.
But with java you are very productive after a short time.
I have worked a java developer in a very, very big project. And since then i am absolutely with you: java and its framework will result in a huge amount of dumb developers and a small group of experts.
I was better paid than the rest of the java developers. They told me "c++ developer know what they doing.", that's why I got the job.
There I learned that you are very productive at the beginning but java becomes unbelievable expensive if your project grows. Then you try to compensate with additional tools, but there is no tool to compensate const-correctness.
Exceptions everywhere. More exceptions than regular algorithms. We got something that I called Exception-Ping-Pong. You can imagine what happens. Not my fault, but I had to debug it and it was very hard to debug.
If you want to become a good developer beware of java.
Graham, I agree somewhat. There are programmers who could be a lot better if it wasn't for frameworks. They forget the basic concepts of Computer Science altogether, even if they have they knew it at one time or had the competency to understand it, but don't, simply because Frameworks let them solved of the problems.
ReplyDeleteIn my opinion, these Frameworks are great if you're trying to create a line-of-business applications, particularly for a targted customer installation. They are almost useless for mass-market products or enviornments where the core competency is to push the limits beyond what any framework can give you. I would be surprised if Google and Amazon are using Hibernate or Spring for their critical infrastructure.
I half agree with your general premis, but I don't agree with your line of questioning.
ReplyDelete"Enterprise" engineers that learn frameworks but don't know why the frameworks were built in the first place clearly missing some of the story. Though, it doesn't mean they can't create value in well defined tasks using that framework. They just won't be the high level thinkers you might want creating your architecture.
You are clearly looking for someone that has a deep understanding of the underlying design principles and the reasons why these design principles have been materialized into frameworks. Unfortunately, your candidates probably haven't had to deal with refactoring from junk to such patterns, and thus have not felt the pain that the framework developers were trying to remedy.
Your line of questioning may have been terse for the sake fo the blog entry, but if it was not, I think you were being overly vague with your questioning. Ask the right question, and you might get the right answer. I'm not saying that you should lead the engineer into the right answer, but you should be a little more blunt in your approach. Keep in mind, that person may be quite nervous. They may have more going upstairs than you give them credit.
If you are looking for framework engineers, some rockstars per say, then they should understand your questioning well enough to be able to elaborate upon the frameworks and the reasons they have created.
Are you not pretentious yourself ?
ReplyDeleteThey are not perfect developers but you are not a perfect manager neither.
There are plenty of less-capable developers, irrespective of frameworks. The reason you're seeing more people come across your desk that appear dumb is the modern method of instruction (and, fair enough, the historical method as well) is rote memorization as opposed to rational analysis. This is compounded by labor found in Asia and the Middle East entering the picture due to cost, where it quickly becomes apparent their entire method of learning is 'memorize, regurgitate.' The work ethic is also vastly different, as being self-motivated and seeking out more work is oftentimes regarded as a societal ill as it may potentially offend your superiors' authority. It's as true a culture clash as any I've ever seen.
ReplyDeleteAll in all, it has less to do with frameworks and more to do with that fact that most people aren't capable of being developers, but we continuously need an increasing number of them, so naturally the quality of the pool degrades. The problem is further compounded by the fact that people who aren't capable end up in hiring positions and maintain their positions by hiring even less capable individuals.
I frequently have this discussion with people: the biggest problem our world faces intellectually is we're too focused on the word "how" and completely unconcerned with the word "why". It's endemic, pandemic and unfortunately, it's probably always going to be that way as it's also human nature.
Xin is right. From a C++ developer's perspective, it's Java itself, and other "high level," garbage-collected languages like C# which are "making developers dumb," because they don't have to understand/deal with low-level memory allocation. And from an Assembly-level perspective, it's C and C++ dumbing things down so that you don't really know what the machine is doing. And there are some who think we should go back to making CS majors take electrical engineering, so that they understand what's actually happening in the circuitry of the computer. This all reminds me a bit of how each generation thinks that music kids are listening to these days is just loud noise.
ReplyDeleteI agree with you on this. Though lets see things on the bright side, we can use frameworks to learn different technologies, techniques, etc. I tend to learn with frameworks first before working on the language itself (example: I don't really understand AJAX until I have used jQuery.Ajax()). Its like abstracting the implementations so that we can better understand the uses of technologies.
ReplyDeleteBut to much reliance on frameworks really make one developer dumb. very dumb...
Frameworks needs to be "Black Box", if developers needs to know about how is implemented, that is a Framework issue.
ReplyDeleteFirst, I am not a Java developer.
ReplyDeleteNow that is out of the way, here's my two cents on the subject since this seems to be commonplace in every language.
Developers: Stop distributing your frameworks allowing "n00bs" who don't have the slightest inclination for critical thinking, to take over a geeks job simply because they are more pleasant to be around.
n00bs: Stop using frameworks to do your grind and to make everyone think "look how smart he/she is". You are not capable of critical thinking until you start coding at a higher level (interpretation).
Employers: Stop hiring people because they know XYZ framework and can formulate business logic. Framework developers (not all, but most), generally take much longer to complete a large assignment, and the end result is very sloppy, resource intense, and insecure code.
Those who create the Frameworks, know what they are doing as they basically take the core features and make them more abstract. This adds one or more additional layers to the original language and thereby interpretation, is much slower than coding direct. In a lot of cases, a real coder would not use a framework because of two reasons:
1. It is only slightly faster to code using a framework.
2. A good coder generally has already developed much lighter versions of any complex libraries which are in a re-usable format.
3. A good coder understands that for every layer of abstract code, the penalties are performance, and loss of control over the underlying structure.
Generally this means that the more abstract the code base is, the less control the developer has which is not dissimilar to driving a train off the tracks without knowing how to drive a train.
Also, if a framework is doing something wrong (backwards to industry standard), such as Zend and their PDF library (0,0) co'ords are the bottom right --- can anyone guess whats wrong with this picture ? --- then the developer inherently writes all of their code screwed up and backwards and poof, if/when the framework "fixes" the problem, everything needs to be re-written (perhaps in this case a PDF reporting system with specific layout requirements).
So this is my vote to keep all languages High level, toss the frameworks and the horrible abstractions that come with it, and that should definitely weed the crop a bit more to real developers who actually write real code, not Powerpoint "programming".
(Correction)
ReplyDelete"In a lot of cases, a real coder would not use a framework because of two reasons:"
Should be:
"In a lot of cases, a real coder would not use a framework because of three reasons:"
Thought of the third reason as I was typing and forgot to edit before posting. -- der.
I find that some have become overly reliant on frameworks, and I see no real point in including jQuery on every page in a website when it is only needed on one page and only saves 2 lines of code.
ReplyDeleteThen I get looked at like I'm the idiot for questioning the usage.
@DanKorn
ReplyDelete"High Level" means closer to real machine language. But I do understand this common misnomer as people tend to think the more abstract the language, the "higher" it is, when in fact, the more layers there are between actual machine interpretation and code is "lower".
Example:
Assembler Language (ASM -- original), is a very High Level language requiring a high level understanding of memory addressing and hardware registers.
Java is a very low level language having many layers of "other" languages it depends on before reaching the CPU. From my little understand of Java, in more recent years (and under specific environments), this language has moved slightly closer to machine level, but all-in-all, is still a very "Low Level" language.
Abstractions on a low level language can be a catastrophe like a ticking time bomb -- or more like a bomb that already exploded, but in a stasis field ready to collapse at any given time.
@Mad Myche -- I do understand where you are coming from. jQuery is one of those things where really, you are already working with a language so abstract, that it doesn't really matter anymore if you abstract further for simplicity. Including jQuery from the CDN for example, can have no real harmful effect since the component is generally already loaded in the users cache, so hooking into it, to write the "on document load" event and to process some simple inline scripts based on element id's / names, really doesn't make much difference. It does save the developer some time, and the developer still needs to know at minimum CSS selectors. HTML itself is a low level language.
It's not a technical issue, it's a business issue.
ReplyDeleteFrameworks don't make programmers dumb, neither do high level languages. The problem is that the world has a shortage of highly skilled programmers (always has as long as I can remember), so the business world has created high level languages and frameworks to try to make use of less-skilled programmers. Now some may try to remind me that high-level languages and frameworks can increase productivity, and that is true - but it is a two-edged sword. In the hands of skilled programmers high-level languages and frameworks can increase productivity, but they also limit flexibility (what you can and can't do from the code). In an ideal world we'd all be highly skilled programmers writing everything in assembly language and C (like it pretty much used to be back in the '80s) - but remember the "golden rule", those who have the gold make the rules - and in this case those with the gold are the business-types who don't have the patience to wait for a highly skilled programmer to become available - so they press into service those who only know how to program at a high-level and use frameworks. Bottom line - it's a business issue, not a technical one.
Frameworks are what they are, useful and efficient, but one glove does not fit all.
ReplyDeleteI'm sure every generation of developers believes the next generation is dumb. Assembly programmers probably said the same thing about C programmers. "Well, yes, you are incrementing a variable, but do you know the inner-workings of how that is done?" Who cares? The purpose of engineering is to make things easier for people. If someone develops a technology that takes monotonous tasks out of the process, that is something to celebrate, not a means to gauge someone's lack of intelligence.
ReplyDelete@Xin: I love your "Power comes from an outlet"-philosophy: you're completely correct.
ReplyDeleteThing is, there just aren't that many programmers out there (real ones, I mean). These days, in college, programmers aren't taught assembly language, or other low-level stuff that one really must know in order to understand how the high-level stuff works. It's essential to do so, especially if you're going to end up using something like Java (which is a horrible language anyway, especially from a real programmer's perspective... so inefficient...) otherwise how are you ever going to be able to write anything even remotely efficient?
This reminds me of an interview I conducted once: it was for a FoxPro job (LOL) and the interviewee was sitting there telling me how great he was at FoxPro. So I said, "Do you know any languages other than FoxPro?" to which he replied, "Why should I learn anything else when I can do it in FoxPro?"... so I said, "Have you ever written an operating system in FoxPro? How about a device driver?" He sat there and looked at me for a while, then got up and left.
Some other posters on this thread are correct, also: it's not that the frameworks are making the programmers dumb: it's that dumb people can now get into programming because there are frameworks.... but don't expect them to develop anything useful as a result. Reminds me of the first instances of VB: all of a sudden, programmers could produce a plethora of forms and controls and pretty looking things instantly... these things didn't actually do anything, but they looked GREAT!
Interesting article and comments. Just one note from me: there are *no* senior developers with five years of experience. If there's one thing that drives me it's people thinking that 3 or 5 years experience makes you "senior", and that barely more than that makes you an "architect".
ReplyDeleteIf software development were a profession you'd have to have 20 years minimum under your belt before even daring to mumble the word "senior".
Having worked for many years in commercial off-the-shelf Java development we looked in envy at those who could use Hibernate Spring and so on. We simply couldn't because their deployability was so restricted when changing a live running web server was not an option. How many sites have you seen advising you to upgrade this or that jar in the servers classpath and just ignore what other business critical web project is trashed when you do..
ReplyDeleteWell, we were SO WRONG to envy what's actually there when you find it!
I may be an old fool but I'm pretty good at solving problems and for the life of me I just can't see where these damn frameworks actually make anything any easier, either for the clever or the dumb!
For example... Is it easier to create a bunch of POJOs, then do it AGAIN in XML, then find that in order to get at one field in one Pojo, the framework ends up loading thousands of records and using thousands of SQL selects to do it!
(yes I do know about lazy loading, thank you very much... but guess what, there's another damn framework waiting round the corner to send that value across to a Flash client using Blaze/DS or something and that forces all the lazy loads to be dragged in...) and then there's yet another framework to make the stuff written for one framework use another protocol, and just don't get me started on the crap4j logging!)
OK, so you can do it reasonably with Hibernate and not write any SQL... but wait... Why did you write the POJO in the first place? Did you actually want Java objects on the server or did you just write it because you needed a pojo to send to some other framework to send to your client? And is that client in Java...? (No... thought not.)
SO why the hell didnt you just write a sql select statement, fancy as you like, and then use a small-but-dumb function to stream the resultset over to your client where it can create it's own objects in whatever language it likes! No need for POJOs, no need for XML, no need for mahoosive framework... and oh, while I'm at it... don't use XML or JSON if you know anything about signal to noise ratios!
Anything else... you bet! But as I said, I'm just an old fool and it's way past my bed time... nurse ... Nurse!
Interviewer: How you will implement linked list in Java?
ReplyDeleteInterviewee: Just like that...
Interviewer: What????
Interviewee: Just like that use ArrayList... what else.
I can go on and blame the language or the framework but the real problem is with the individual. Apparently, the above dialog is a real one.
Year: 2030
Interviewee: By dragging and dropping two nodes on a HTML5 canvas... Linked List can be implemented.
Or just use java voice recognition programming tool and say " create linked list " in 2030
DeleteThe problem starts with Java itself. As a language, it's much easier to learn than say, C++. That's nice, but it also means the less trained get their opportunity to become a software engineer. They are a lot cheaper to hire and that's the main reason Java has won so much ground. There's nothing wrong with the language, but there's so much that helps mediocre programmers to write mediocre software. Frameworks add to that. Of course it's not the Frameworks, nor the language that makes people dumb. These people probably were dumb already...
ReplyDeletePlease don't be all forlorn. After all, there are still some developers out there writing frameworks.
ReplyDeleteIndeed develoepers should understand how their frameworks operate under the hood. It's called not "programming by coincidence".
ReplyDeleteWell said..I have seen the same thing while taking the interviews. Most of the peoples with fairly high experience does not have the basics clear.
ReplyDeleteI disagree that the frameworks are making the programmers dumb! With or without these frameworks these candidates would response in the same way. It's not about the technology X or language Y or framework Z. It's about the fundamentals - the core principles of OOP, software architectures, clean code and software engineering in general.
ReplyDeleteHow do you define a senior developer? N years experience with X, Y, Z frameworks and such? Wrong! You should try to seek for the best software engineering generalists, not some narrow specialists.
"senior developers with 5 years of experience" sounds near impossible.
ReplyDeleteHad a college once with just one year of experience after completing his computer science degree who showed very good skills in assessing characterictics such as scalability, security and robustness of various frameworks, understood the design patterns they supported and knew when apply them and when to avoid them -- but he is only one of approx 100 developers I have worked with through the time.
I have had other colleges with 10+ years of experience who in my mind had a naive understanding of frameworks and who will readily cause a project to fail by choosing a framework that can never meet the scalability or security requirements for that project.
..but still if years of experience is any indication then I'd go for someone with at least 10+ years when interviewing for a "senior". On top of that I would look for a computer science degree, experience with programming from an early age, if he is a generalist or a specialist, the type of projects he has worked on and the companies he has worked for, his ability to communicate design.
I think it depends on if you are looking for a developer with broad but shallow knowledge vs deep but narrow.
ReplyDeleteIn my last two roles It has been more useful to have have a basic knowledge about a lot of stuff, with at least enough understanding to know what to search the web for when an issue arrises.
Having a deep and narrow knowledgebase is fine, but you can't always apply your specialist subject experties to problems you encounter.
I think frameworks help get a much broader (but sometimes shallow) understanding of developmenmt practices.
D.
The following is from our reader Thomas who wanted to share his opinion but was facing some technical problems:
ReplyDelete"Computer Programming has, for the most part, never been an engineering discipline much less a science. As long ago as the 50s and 60s, there were COBOL and RPG programmers who had no idea how the code they were writing actually worked, how efficient it was, what the tradeoffs of their decisions were. You just wrote some code and if it compiled and if you knew enough JCL to get it to run, you were a “programmer”.
The common tasks back then were to add a new field to a printed report or to combine data from two databases (before SQL). Then it became to add a new field and a checkbox to a screen. Just know some tricks, do some "magic" and make it work. "How" doesn't matter. This was the life of a commercial “programmer” then, and it still is now.
As someone mentioned, VB was a way for these same coders (I hesitate to call them "programmers") to move to the PC world, with no clue how to properly structure a program or how things actually worked. Create a form, add field, add a checkbox. The result was a lot of hard-to-maintain, hard-to-extend, inefficient crap programs, but they worked. All you needed to know were the right tricks, and the "magic" would happen.
Now along comes HTML and JavaScript. Now not only don't you need to know how things work, you don't even have to get the syntax right! With everyone singing the praises of these "efficient" loosely typed languages, who cares how things actually work!
I've skipped over things like Delphi and Pascal. Those were languages you used if you actually cared about writing efficient code. C++ was a huge step backwards. All of a sudden you had a jumble of low level and high level concepts, where the programmer had to control things like memory management (rather than the OS making global choices for you), and you could crash the system (or another unrelated program) if you got your address pointers wrong. As long as you were the only program running, all went fairly well. But suddenly people who thought they knew what they were doing "because they were C++ programmers" had no idea what code was actually being generated by the optimizing compiler, or what the operating system was actually doing behind their backs to handle things like interrupts for character oriented IO. Even today: Do you actually know what happens if your code causes a cache flush? Or how expensive it is to shift to another thread or task? Or even what precision is being used in your “double” calculations (sometimes up to 80 bits worth on Intel processors, sometimes 64)? Thought not.
So along comes Java and C#, where you don't know what's being interpreted and what has been compiled or when, or how the runtime interacts with the underlying OS. The things that were being asked about in this post are the tip of an iceberg of not knowing (and not caring) how things actually work.
As for frameworks, in the Windows world, have you ever tried to find out how Entity Framework or WCF or WPF actually work? I've gone to programming code camps where, when questioned, instructors have actually said "Don't worry about it. Just do XYZ and it'll work." Sometimes extremely inefficiently and with subtle “gotcha’s”, and with longer-term ramifications that you might not expect, but the "magic" will happen if you perform the right tricks.
That’s "Computer Science" education today, as well as yesterday. This is a craft, like pottery, and most people get paid for churning out pots -- sometimes pretty pots, sometimes pots that will stack neatly, sometimes just pots that don’t leak too badly -- not for knowing the chemistry and physics of clay or how to build a kiln."
-- Thomas
@dak
ReplyDeleteno Asembler is not a fracking high level language - do you have any flipping idea what you are taking about.
well, recently exactly opposite happens with me. I was rejected just because I don't know hibernate, though I told them I knew ORM and JDBC.
ReplyDeleteSecond incident was, interviewer ask me some classes name and methods in them from Struts, no question on servlet, MVC.
Life is difficult in some part of the world!
@Maurice, you are correct.
ReplyDeleteHigh-level refers to the level of abstraction from the computers instruction set. High-level languages are built to be more programmer friendly than the low-level languages.
Machine Code is the lowest you can get, and needs no interpretation to run on a CPU. It (generally) appears as straight hex code. The programmer needs to know the exact command for the chipset in its raw format
Assembly Language is a second layer of low-level. There are simple near-english commands present which make it easier, however; the programmer still needs to be aware of the system architecture.
Once you get to the high level languages, the compiler takes care of the system architecture. The compiler will take care of the changes that need to be done depending if you are going to deploy to a 16, 32, or 64 bit machine without significant code changes.
Sometimes you need a code writer and to know how use some frameworks and the language structures and some others tecnical skills are enough.
ReplyDeleteSometimes you need a analist or a programmer and in this case you need to hardly check if the candidate is what you looking for.
The problem is because you don't have qualified professional enough for the demand nowadays some unqualified workers are hired like programmer, analist and even architect.
It's not a framework problem - at least it's not just a framework problem. It's a professesional problem in my opnion.
I think our focus is on How ? rather then Why ?
ReplyDeleteI think it all boils down to what requirements you have. When C was introduced the assembly people shouted it was slower than pure assembly. C people said among other things it was now much easier to port their programs to other processor architectures. Over the years C compilers got better and the slower argument was kind of invalidated.
ReplyDeleteMore important than language are algorithms and datastructures, you can screw this up in any language. Lets take for example finding an item in a list in Java. There is no need to know the exact implementation of List.contains(Object o) if you want to find an item. But if you want have acceptable performance in a big list it might be
important to know your essentially performing a linear search. Knowing this you might better
be sorting your list and use Collections.binarySearch(List l). As for frameworks it depends on the framework in question. How many dependencies does it introduce, how much overhead does it impose, how much boiler plate is necessary before you get acutual businness value. The frameworks that suck the most in my opinion are the ones with the 'Microsoft Word' syndrome, trying do everything for everyone.
Well sir your post has the truth in it,but the invention of these frameworks was so that even dumb guys could program aint that right i mean if you are seriously considering say a web development project and the requirements is to deliver it you ask your programmers to deliver it successfully courtesy frameworks but if you have the situation where you need to develop a new product or for that matter any R&D work at that moment you will go to guys who have actually made these frameworks or those who have analyzed and are in real grasp of things.It totally depends on your project requirements and then you have people according to that.
ReplyDelete