Re: [Ilugc] Comparing programing languages [was: perl OO]
On Sun, 2011-12-04 at 21:05 +0530, Natarajan V wrote: > I think, this thread is slightly moving away from Linux and moving > towards programming skills and hiring. Should we tag it as [OT]? > > no - unless someone starts talking about vb. -- regards Kenneth Gonsalves ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] Comparing programing languages [was: perl OO]
I think, this thread is slightly moving away from Linux and moving towards programming skills and hiring. Should we tag it as [OT]? On Sun, Dec 4, 2011 at 10:42 AM, Suraj Kumar wrote: > Measuring one's language skills is of use only for gauging if the > candidate might be useful to fulfill, also, the short term needs (which, > usually, is to maintain/extend/fix an already developed solution). Agreed. > Measuring based on language skills is of only a cosmetic use from the point > of view of hiring a long-term asset for a company. +1 > Perl (or C, for that matter) doesn't lay out things on a plate. Perl > requires understanding of core OS concepts before one can build real world > applications for use in a production environment. I Agree, and agree to disagree as well :-) I agree that you need to get your OS fundamentals strong if you really need to code well in C/PERL. The disagreement is on the fact that when I want someone to be strong in Fundamentals, OS Concepts are NOT the only fundamentals. Linking back to your homepage - System Thinking is a good example of fundamentals. > PHP, Java, etc., OTOH, > makes it infinitely easy for anybody to program and build seemingly real > world applications, allowing all sorts of people to write all sorts of > things and still get away with it. In Java, it is the VM that externalizes > problems, as though, it is someone else's to handle. Again, Agreed and disagreed. I agree that Java, .NET and to some extent PHP, and others as well, do hide the OS implementations. This doesn't mean that I can write rubbish and expect the VM to take care of everything. A well experienced Java (or .NET) guy can guide you though how a memory leak could occur in a Java program, how to use a profiler to debug the memory leak, how threads get tangled causing deadlocks, etc... Sounds familiar? As I said earlier, we try to solve a different set of problems with different tools. We don't necessarily take care of freeing up the memory in Java, as we do in C. But, this doesn't mean that you can create anything you want. We still need to make sure that the Garbage Collector (GC) will be able to handle the memory on it's own, by coding correctly. A bad programmer will be the same across all languages. > I meant to say, thus, if you come across a perl programmer who has built > real world applications, chances are their fundamentals will be strong > (which, of course, you'd be testing in the interview). Their fundamentals > are strong because the language forced them to rethink their approach at > every juncture of their own skill development. The definition of what you mean by fundamentals makes a difference here. I would go down to "Systems Thinking" for example as a fundamental. OS Concepts, ... well an extremely added advantage? Unfortunately, *Nix and other "time shared" scheduling OSs are not the only one type lying around. > That said, likewise, one > also comes across a whole bunch of "perl scripting" people who have not > written anything more than 300 lines of relevant code... but then, again, > it is very easy to spot them. Spot on. Agreed +1 How come the candidates who come for interviews, never even realize this? >> IMHO, the problem isn't with Java/Perl, its a problem with your >> question paper / interview panel. > > Absolutely agree. But tell me, from your experience, do you have a perfect > interview panel who all ask relevant, core testing questions? :) pass :-) Actually, I have had identifying good panelists for myself. -- Natarajan ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] Comparing programing languages [was: perl OO]
On Sun, Dec 4, 2011 at 9:46 AM, Natarajan V wrote: > > From a hiring perspective, am not sure why people are obsessed with > the mastery over the syntax of the languages. This also creates a > problem, when you frame a question that is applicable for PERL and not > very applicable for Java. We have to understand that programmers are > not a single breed. Everyone specializes/has interests in particular > areas.You can't compare a OS programmer, with a Game developer, with > an enterprise application developer, with a mashup developer (What is > a Mash up?). Am sure the Mashup developer would have the least clue of > what it takes to sort objects in Java/ Perl. > Agreed to every thing you say. Not sure where I gave you the impression that perl, as a common ground for measuring language skills, is a good filter. Measuring one's language skills is of use only for gauging if the candidate might be useful to fulfill, also, the short term needs (which, usually, is to maintain/extend/fix an already developed solution). Measuring based on language skills is of only a cosmetic use from the point of view of hiring a long-term asset for a company. I didn't mean to say perl is "syntactically tough" or somesuch and hence its a good tool for interviews. Nope. I only meant to say this: Perl (or C, for that matter) doesn't lay out things on a plate. Perl requires understanding of core OS concepts before one can build real world applications for use in a production environment. PHP, Java, etc., OTOH, makes it infinitely easy for anybody to program and build seemingly real world applications, allowing all sorts of people to write all sorts of things and still get away with it. In Java, it is the VM that externalizes problems, as though, it is someone else's to handle. I meant to say, thus, if you come across a perl programmer who has built real world applications, chances are their fundamentals will be strong (which, of course, you'd be testing in the interview). Their fundamentals are strong because the language forced them to rethink their approach at every juncture of their own skill development. That said, likewise, one also comes across a whole bunch of "perl scripting" people who have not written anything more than 300 lines of relevant code... but then, again, it is very easy to spot them. > IMHO, the problem isn't with Java/Perl, its a problem with your > question paper / interview panel. As I said earlier, a language is > independent of analytical skills. Why not frame your questions in such > a way that they don't have to write programs, but provide you with > algorithms instead? > Absolutely agree. But tell me, from your experience, do you have a perfect interview panel who all ask relevant, core testing questions? :) -Suraj -- Career Gear - Industry Driven Talent Factory ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
Re: [Ilugc] Comparing programing languages [was: perl OO]
> On Sat, Dec 3, 2011 at 9:15 PM, Suraj Kumar wrote: > > On Sat, Dec 3, 2011 at 4:52 PM, Girish Venkatachalam < > > girishvenkatacha...@gmail.com> wrote: > I would partially agree with you that object oriented programming (the way > it is done in Java) makes it possible for anybody and everybody to "get > their job done" - I think, we are comparing Apples and Oranges here. (See below) > which is also bad from the point of view of building > teams and organizations I beg to disagree here. Perl, C++ and Java were created for different purposes/problem spaces. It would be better if we choose the right tools for the right purpose. PERL/ C++ / Java have inbuilt libraries and constructs for different purposes. So if in their solution space, they find that "A" is very repetitive, they build a library/construct for that. If PERL thinks "A" is not the problem, but "B" is, you get a different building block in PERL. So, when you use PERL/Java/C++ you should know what building blocks are available, and what aren't. Then fill the gaps with your brains. A house can be constructed using wood, clay, clay bricks, hollow block bricks, steel and glass, etc... The problem is same. The solution space is different. The problem that needs to be addressed by the developer differs. He will have a different set of problems to solve in each of the solution spaces. As I said in one of my previous mails, A language is just a language. Its your ideas that become programs. If I allow any North Indian Politician to contest in elections in Tamil Nadu, would s/he not talk a few words in Tamil? Frankly, its not very different in programming languages. Each language has its own nuances and abilities. A "good" programmer will try to utilize the tools to the best possible extent. //வல்லவனுக்கு புல்லும் ஆயுதம்// From a hiring perspective, am not sure why people are obsessed with the mastery over the syntax of the languages. This also creates a problem, when you frame a question that is applicable for PERL and not very applicable for Java. We have to understand that programmers are not a single breed. Everyone specializes/has interests in particular areas.You can't compare a OS programmer, with a Game developer, with an enterprise application developer, with a mashup developer (What is a Mash up?). Am sure the Mashup developer would have the least clue of what it takes to sort objects in Java/ Perl. > (very difficult to gauge one's programming / > analytical capabilities). Perl, that way, is a very useful tool for > filtering out and hiring the best. IMHO, the problem isn't with Java/Perl, its a problem with your question paper / interview panel. As I said earlier, a language is independent of analytical skills. Why not frame your questions in such a way that they don't have to write programs, but provide you with algorithms instead? >> But in perl it is nice and simple. Let me fix it for you, "But PERL is nice and simple " :-) -- Natarajan ___ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc