On Thursday 20 April 2006 16:48, L505 wrote: > Yeah, I'll hire an electrical engineer with no prior programming > experience.. that's going to work.
Actually - yes, it is. Most of our staff here comes from electrical and even mechanical engineering. And some of them are good. The worst people are those with prior "programming" (I'd like to call it hacking) experience from their university days. What makes it worse: Because of their university degrees and "language knowledge" they even get paid better than the other guys. Not including me, of course, slaves don't get paid. > If he knows English and math, surely he'll figure out Pascal in a few > days. Learning all the ins and outs of Pascal takes several years, Yes. But as nobody *is* perfect, why would you expect someone to be right from the start? > not a few days. Especially since languages are always improving and > are not static. That's nonsense. An ISO-Standardization cycle takes 10 years. Oh. Sorry. Of course you are refering to languages where you discover a new feature from time to time despite 15 years of experience with that language? > Am I going to hire someone with no Pascal language skills and pay him > an hourly wage to learn Pascal, on my behalf? No. Yes. That'd do. > Business would probably go broke. No. Businesses go down because they don't hire capable people, but always try hire "experienced". Where the hell did you want to get someone with 10 to 15 years of Java-experience in 1997? And I've seen such ads. > So you are going to hire someone with Java skills and waste your > salary having the guy learn Pascal for 6 months, and even after 6 > months he won't be an expert? I would need experts on software design, people who know how to spell real-time, embedded. So most of the candidates would be proficient in C and maybe some assembly language (although those people are mostly dead already). So the probability that the people I'd like to hire simply don't exist is very high. Coding is about 10%, so if the lion's share (as testing is) goes well, I can spend another 100% on that coding part (which makes it 20% in total, and for the first project only) and still spent 80% in the expensive parts of the software. Doesn't sound too bad to me. > You are going to pay the guy an hourly wage to learn Pascal, Yes. Or any other language he needs. Hell, that is what companies are doing all the day when they have/need/want to change their target language for whatever reasons. > when he should have done that on his own time > first and become an expert before applying at the job? Became an expert? You won't find those anymore. They're retired. > Sure Pascal and C and Ada are close languages, but please if I'm > creating desktop software don't give me a Perl expert or a PHP expert > who knows only Perl and PHP. And again your focusing on language skills. > I would hire a PHP/Perl programmer who has interest in Pascal if I > was doing web programming for FPC though. Lots of common knowledge > between http there that is needed. Since when do have PHP-programmers any knowlegde of HTTP? At *best* they know HTML not some but those are the good ones. ;-> > But he must have interest in the > Pascal language and can't be a Perl/PHP zealot who believes Perl/PHP > are the answer to every question. Agreed. Somebody who doesn't respond to reasoning is surely not able to create good software. He makes a good project manager, though. > Particular languages are not just expressions - they are built for > different purposes. They have different types of how to express things. Some things can't be expressed, some are easier, some are harder to express. Yet, those are just expressions. > Try shipping a desktop GUI software application done in Perl. Some is running here. And we're doing web applications with Python. > Ever seen one? Yes, more than once. Small applications, admittable, but Perl is not a language you want to write large projects in it. Neither is C. Yet it is done. Some of the results can be seen on Bugtraq. > I've found having knowledge about C really helps, Usually it hurts the software design issue. It is really hard to explain experienced C-programmers, why types should not all be pointers and ints. You're better off with people who learned a real assembly language. > But I'm sure someone would have eventually come up with a > pchar/shortstring combination like ansistrings at some point, even if > C was not created. "Ada.Unbounded_String" for instance. > > And hell, I practically learned Java in a couple of days. > > I always laugh at this. You learned it. You learned what? > You learned the basic Java grammar. I learned basic Java patterns. How tasking is done and how restricted it is. The fucked up numeric system. The practically non-existent type system. The screwed modularization system they call package. That finalizer code may never be called. Such things. I think that's a bit more than the basic Java grammar. I even read the whole fucking JLS. > You don't know a thing about java though. I know enough to create serious workable results. And I know where to look for if I think, this or that class probably already exists. > You just know the grammar. You don't know 1000 libraries that > sun has created. Of course not. /Nobody/ knows, sometimes even Sun can't remember. The same was with Free Pascal. I knew Pascal for over 10 years when I started porting our application to Free Pascal, but I did not know *anything* about SysUtils, DateUtils, Classes, ... So you're saying I haven't learnt Pascal yet, because I did not know the packages that come with Free Pascal by heart? Are you at least realizing that you are talking nonsense here? > You haven't studied each and every one. And you > cannot possibly apply for a Java job if your friend bob there HAS > studied 1000 Java libraries. You don't have a chance. Well, the company paid that we learned it. Nobody applied. We were already there. Probably they should just have fired us and get new people right away from the street. > Language skills are important, because some languages are designed > for only one purpose. Your focus is still wrong. > The type of language you use tells a lot about yourself. Alright: I am using Pascal, Ada, C, Assembly, Java, VHDL, Perl, Python, C++, ordered by (current) importance. I also have been using Modula, Smalltalk and Prolog in the past. So - what kind of guy am I? > If you use C you probably build a lot of desktop software > or command line utilities. Wrong. Device-driver. > If you use Perl you probably build a lot of shell scripts. Wrong. A specialized drawing application. > If you use Perl and C and Pascal, you probably know > a lot about shell scripts, Well, I know how to get along. But I am by no means an expert in that. But there's an electronics engineer here who knows that. He's a shell-wizard, so to say. > desktop software, No. Definitely not. Especially not when we're talking about user interfaces. As a "child of the command-line" I am terrible in designing those. And I won't be any good at it ever. > and OS Api's. I still remember the DOS-API, does that count? Anything else is described in man-pages or on MSDN and I look it up when I need it. > Since the languages you use tell a lot about you, you can in fact pick > a person out of a crowd by looking at what languages he uses. Some, if not most, of the languages above are just in the uses list, because I *have* to use them on the job for historical or whatever reasons, not because I *wanted* to do it and not even because the language fitted the task. So just looking at the uses list might give you quite a skewed view on that person. > You would then look at his existing code and > see: has he made hodgepodge messes of code, or has he modularized > everything in neat manner? It's not about neatness, it's about sense, but yes. That is some factor. > I've seen PHP programmers who know how to program websites, but they > don't know a thing about desktop software. Well, so we are doing applications based on Browser-Interfaces. Does that define as desktop software or as website? > They know http and they > know HTML, but they haven't a clue about OS Api's. If you need it, look it up. That's a basic skill, I'd expect: RTFM. > build desktop software. Until then, I would not hire a pure PHP/Perl > programmer if he only knew that language. I never would hire people because they "know some language". :-) > Because he knew a language > geared toward web programming, not desktop software. So that means you are thinking his abilities are crippled when trying to create desktop software, just because he didn't do it yet? I think that's different. > desktop software shop. He may be able to learn the basics of Pascal > and the basics of some Pascal libraries in a few months, but why in > the world would I pay him, on my behalf, and hourly wage, to learn > Pascal? Because he's motivated, good and worth it. Unless of course you are planning to fire him again in three months when the project is "finished". Maybe all you have is a life-cycle problem. The software I am doing here has it's earliest copyrights dated back to 1989 and is in the field since about 1992. So it would be magnitudes more expensive to fire people who learned the system (which took me about six months and surely not because of the language) and replace them by fresh young starters who know $LANGUAGE, than to just pay some money to teach the old people how to handle $LANGUAGE. Or maybe you just try to hire coders instead of software engineers. Regards, Vinzent. _______________________________________________ fpc-other maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-other
