At my company we are looking for all ranges of skill level and on the past few months we have yet to find someone that I think deserves the title of programmer let alone engineer. And this is coming from a self taught software engineer, so it's not like I'm looking for endless experience or any degree. Most programmers don't even understand the basics of how a computer works, or the major syntax of the languages they supposedly program in.
If you really want to find a "qualified" firmware engineer then then I suggest posting a link. I would also suggest not writing off everyone with less than 10 years of experience and a Masters Degree.
That being said, I believe you when you say you are having a hard time finding programmers of any sort as I have been interviewing candidates for months, for all levels of experience, and have yet to find even a single person worth extending an offer too.
Obviously, they're too used to their 2 income lifestyle to realize that $12/hr. means scraping by in poverty level conditions if that's your sole source of income.
Go live at real poverty levels for a while before you try and claim that $12 an hour is the poverty level anywhere outside of silicon valley.
The official poverty line in the United States affects nearly 40 million residents. To be in that 40 million strong group you have to make less than 10.5k per year as an individual with no dependents. $12/hr full time equates to aproximately 24k, more than double the official poverty level and just about enough to keep a family of 5 above the poverty line.
I'm not saying that $12 a hour is a great wage and it doesn't suck that most of what you should be earning is in the hands of less than a million US residents. What I am saying is that anyone make even $10 an our with out any dependents hasn't a clue what it means to be poor. Heck if you have the time and resources to post on slashdot then you most likely can't even fathom the realities of being in poverty (myself included).
I am anti-libertarian economics, but that doesn't mean I'm going to sit around a bitch about my lot in life when right now wealth is still there for anyone interested in actually working for it (assuming you are willing to trample on a few people to get there).
I'm guessing you actually know very little about this game. This "game" is actually the most complex physics engine ever released for a video game console. Between the complexity of the highly parallel processing physics engine, and the in depth intelligent level creation (not just through pre designed fixed size tiles on the screen) you end up with a game that the Wii couldn't handle even if the resolution of the graphics was drop to that of the 8 bit era.
You are correct that the game premiss is suitable for the Wii audiance, and that the wii controls may be useful if they were anything close to accurate, but the game itself is not suitable for the actual Wii hardware.
Not to mention the release of Life with Playstation and the Beta's of Home, it's starting to look like Sony's online community is about to take a pretty huge jump in quality and content.
Stop trying to bring facts into this debate. It's for more interesting to watch people that have no clue what they are talking about, and either never had to stand on their own, or never been a member of a union, argue over a topic they know little about.
Seriously I wish I had mod points and hadn't already posted in this thread. This is the first comment I have seen on either side with any actual facts in it.
Let's note that American Honda builds all their cars using non-union labor, and we know how Honda is doing. Honda is also one of the best companies to work for.
Good point, but probably not the one you meant to make.
you have to realize that there is no union because Honda is a good company to work for and not vice versa.
Yes in theory we as employees can chose to only work for the good companies and their for put the bad companies out of business, but to do this and have it work you have to do it in an organized fashion. And how many people do you know are able to live a year or more without a job while we wait for the better companies to grow large enough to support us all? I'm sure your answer is few if any. With shared resources, as supplied by a union this is a much more surmountable obstacle.
I'm still not seeing the issue. A String object is a String object. If you can't remember if you that the object you are working with is a number of not then use the NaN function to make that determination first. This same thing would happen in any other language with an overloaded + operator.
I'm just saying that JS gives you the tools necessary to not make these mistakes if you are every dealing with unknown object types and using primitive operations (not a problem if you use method calls as you are safe as long as the object supports the method being called, which is also easy to check).
I don't see how you can claim it's a "huge hindrance" - you sound like something of a cowboy programmer to be honest.
That's kind of funny. My teams always complain that I am to structure and process oriented. I would say it's my application of engineering practices that allows me to be able to safely work with dynamic and duck typed languages.
And yes it is true the more popular languages are strong static typed, but that does not mean it is the best way. And I have been doing mostly Java development professional for the past few years so I am very familiar with strong static typing and the libraries available for such languages. The majority of those library use object interrogation or even proxying to deal with the limitations of Strong static typing (Java's even includes an entire API to circumvent the limitations of strong static typing in it's Relection API). Even the majority of the design OO design patterns are design specifically to deal with these limitations.
Defining and declaring your types up front may seem inconvenient but it means your codebase can scale, more bugs are found ahead of time, future programmers can more easily comprehend your code and compilers can optimize your code much more easily.
In JS you declare and define your types up front, so I'm not sure what you are getting at. Yes, it is possible to extend your type once it is created, but that neither means that you have to or that this should cause any reduction in maintainability. You have the option to use JS without ever once adding functionality to an object once it is created. Learn JSs object model and how to create constructors and you will understand more about how easy this is.
I rarely run into a bug that would be caught by a compiler, either in dynamic, static, weak or string typed languages. Bugs that can be caught by compilers are trivial in nature. You are better off having a good suite of test cases to catch bugs.
Optimizations on run time parsed languages are actually much easier than compile time languages. This is why Java now uses a Just in time Compiler, and that this has caused great improvements in performance. Plus there are multiple native/byte code compilers for JS, so it's not beyond reason that dynamic and duck typed languages can be compiled.
If there was some kind of efficient, statically typed language available for use in web browsers making it run fast wouldn't be a research problem, and we could replace the unintuitive CSS box model with something that actually worked for web apps. The reason you can't do this today is that JavaScript is just too damn slow to do real time GUI reflow, so you have to let the web browser do it in C++, so you're stuck with CSS.
The performance issued in browser application development have nothing to do with JS performance, it has to do with the browser implementation, and more importantly the DOM. This is why things such as XUL were devised. They provide a more application oriented object model and greater performance. It's also possible for JS to access native libraries, which is the only way to gain good performance in any language (even Java, C# and other byte code languages have an interface for accessing native code and utilize it highly in their core APIs).
Just do a little more research into JS, and understand the core features of the language. You will see that bad and inefficient JS code has nothing to do with the language.
I think you are very confused. In JavaScript a Number is a Number and a String is a String. The fact that you are trying to add 1 + "1" doesn't mean there is anything wrong with JS. Objects are only treated as Strings when a string is required, or it does not meet the criteria for any of the other applicable objects. Read the specification sometime. There is a hierarchy for auto casts for every operations.
If the operation is over loaded to work with Strings or Numbers the operation will treat all the objects in the operations as numbers if they are all numbers, otherwise it has to treat them all as strings, as every object can be treated as a string. It's actually far more detailed than that, but I'm not going to rewrite the spec in a slashdot comment.
Just try and remember that 1 == "1" but 1 !== "1".
The primary flaws in javascript are its lack of namespaces, true OO, and, most of all, its lack of types and type safety.
The primary flaws in javascript are developers that do not understand the fundamentals of the JS language (and I don't mean to be attacking anyone particular, this is just a really common problem).
JS is 100% Object Oriented. Just because it contains Functions as first class objects and Closures does not mean it is not Object Oriented. Everything in JS is and object, everything. There are no classes because it's a prototypical system not a classical system. The fact that all things are objects and that JS contains closures means that Namespacing does exist, if you have some specific reason to use, just by creating an object to represent the name space and keep all namespace protected objects in that objects scope.
Also JS is completely type safe. You can not cast an object to a type that it is not (something you can do in none type safe languages like C). What you meant to say is Strongly Static typed, which is found in only a few languages and is a huge hinderance in those languages. Duck Typing, as implemented in JS and few other languages, is far more flexible and just as robust as you still can't screw with memory arbitrarily.
The only thing I would give you is that it would be interesting if JS variables could be typed (as the objects already are). This would allow the runtime environment to determine type conflicts and for an IDE to be able to have additional autocompletion options. But sadly this would just lead to other problems just as difficult.
So, just to be clear: you're advocating breaking up your software into otherwise-unnecessarily fine-grained methods, because it's less intrusive than just adding logging statements? Sounds more like a recipe for spaghetti code.
Actually what I am suggesting is that breaking up your code in this fashion actually leads to cleaner, more readily reusable code, that just happens to be perfect for allowing the necessary level of logging. I suggest that the same rule applies to commenting. If you find the need to for an inline comment than you code is more complicated than it needs to be and should be broken up into smaller components.
Well segmented code need not be spaghetti code. Spaghetti code is a reference for difficult to follow control structures and has nothing to do with segmentation.
I have one simple rule when it comes to code: If it is not required for honoring the contract of the procedure or directly influencing the required logic, do not put it in the code. This goes for configurations as metadata (like java's asinine annotations), premature optimizations (result caching), insignificant commenting (any inline commenting), as well as logging.
I just wanted to second the "as little as...possible" sentiment and take it one step further. DO NOT add any logging to your application code. If it is not essential to the logic it should not be in the code.
That being said, you can add what ever logging you want as long as you do it outside the application code, such as through AOP (if you don't know what that is then google is your new best friend).
Logging through external means has a number of benefits. First you application code is relieved from unnecessary clutter. Second the logging can be added or removed as fit for the environment with no need for any runtime checking, which is perfect for turning of all logging in production environments. And lastly it enforces good coding practices as it makes sure people break up code in a way that makes external logging possible, which is how code should be written anyway.
The majority of all logging, dare I say all useful logging, is easy to summarize.
Starting Process... with the following conditions...
Starting Process... with the following conditions...
This is perfect for function/method interception since it comes down to something more specific.
Executing Function... with the following arguments... (with one of those arguments being the state of the object the function is attached to in Object Oriented Programming)
Function... returned the following...
So simply add the first logging to an interceptor that operates before the functions you want to log, and the second after the function.
If you find yourself needing detail inside the function then you need to break the function up into sub routines, so you can use this generic logging on the sub routines instead, or as well as.
You really can't hold parents responsible for their children doing stupid things...
I used to think these exact same things, before I was an adult and before I was a parent. Now that I am both, in that order I might add, I disagree. Children doing stupid things is entirely the responsibility of the parents.
It's very easy to teach a child how to act responsibly and not post lies on social networking sites. There is also the concept that parents should know what there children are doing, I happen to know what mine is doing at all times. This doesn't mean stopping them from doing anything, just being prepared to stop them from doing something stupid.
On the other hand I don't really see an issue with a child posting a fictional story on a blog, it's just not a big deal and there is no reason to sue a paper for printing it.
Maybe you were joking, but this is exactly the attitude that keeps the 'interchangeable code monkey' approach to software development and personnel development alive and well in the software development career field. Go on - keep laughing...while they offshore your job.
It amazes me that developers don't want to be taken more seriously. When they do - they end up becoming architects without much impact on the new batch of developers coming in -- little if any mentoring or lessons-learned. Many of the people who become 'developers' have not a clue about computer architecture - and end up learning from the 'school of hard knocks' - when they do something a CS grad would recognize is the wrong thing from a mile off. (hint: RAM is limited, CPU Cycles are finite over a given time frame, and virtualization is ubiquitous and the key to every important advancement in system capabilities (microcode, machine code, system code, application code, higher level abstractions)).
No wonder software development is so screwed up - and we only have ourselves to blame.
The problem is that we are hiring scientists or developers to do an engineers job. It's called software engineering for a reason. You don't hire scientists to design engines, or electrical circuits, or even cities. For those tasks you use engineers, mechanical, electrical and civil respectively.
I'd be happy to find you a few dozen self-taught developers that would run circles around your average, or even above average Computer Scientist, including on detailed hardware knowledge. I have personally never met a Computer Scientist that knew the slightest about the computers they work on, that's the realm of the computer engineer (and yes I can build a 64 bit look ahead adder from knowledge in my head without reference). But if you need to have someone repeat to you the SHA hash algorithm, or,I'll even give them credit here, you need someone to design a new algorithm, which is rare if ever, then you should get a computer scientist.
Just remember science is knowledge and study, where as engineering is practical application and construction.
I'm not sure where quality comes into this. The language doesn't affect quality of programming, at least for good programmers. It's not hard at all to learn a new programming language, but it can be very hard to shoehorn a solution into an inappropriate language. A developer shouldn't get to decide the language, but the project manager should with feedback from the devs.
Quality comes in because no person can be as proficient with every language as they could be with one. You either spend you time learning the basics of all languages, or in the ins and outs of one. Sure a good engineer can pick up any language and write in it, but they won't do it nearly as well or as quickly as they would in the language they have been using for the past 5 years. This is a basic fact and it applies to all industries. You don't take your Toyota to the Chevy dealer and expect them to be able to do the work nearly as efficiently. Sure any mechanic should be able to fix your car eventually, but at a pretty substantial cost in time and resources.
So why don't we write device drivers in Java? C and Java are like C and Java, inappropriate analogies aren't helping anyone.
This is for the same reason the ICs are not built with Craftsman or Snap-on Tools.
Sure you can't use a single set of tools for every task, but in reality very few companies write drives and web apps, and if you do the team is so large that you are not going to be moving people around that much. So if all you company or team does is one type of software, say drivers or business applications, then you can standardize on a single language and be far more efficient.
Only the good ones are interchangeable. If the process is in place so that the engineers involved do not need esoteric subject matter knowledge then any decent developer should be able to work on any project at any time. Yes there is some over head in task switching, but it's a lot better than saying "we can't do that today because bob is on vacation" or "we have to keep bob even though he normally shows up to work drunk."
...and all languages are not interchangeable.
For most business applications there are many interchangeable languages. Sure if you are building hardware drivers you are not going to be able to do so in Java, and JavaScript was not designed for enterprise applications (though I assure you can can be used to do so). But if all you do is build the same type of products or systems then using a single language or small set of language with defined uses certainly simplifies the search for talent and the ability to migrate teammates between projects.
Sure, and while they're at it, let's give all the mechanics just one size of wrench and screwdriver.
I am so sick of this analogy, as it's completely inaccurate. Programming languages, at least full featured languages, are a whole set of tools, not a single tool. Comparing Java to C is more like comparing Craftsman to Snap-on, different brands of tools but they can both be used to do the same thing. If you can give you mechanics a single tool that can be used in all their tasks, like a sonic screwdriver, then do it. If the language isn't full featured, or cover all your needs, then don't use it.
And conversely, each project team should be free to evaluate the best tools to get each job done.
This is exactly what you need to do if you want to guarantee that you have to continue with the team you have or hiring nothing but experienced senior developers. Keep the number of tools simple and you can have a small number of leads and many interns to do the same amount of work with a much higher over all quality and considerably less cost.
If anyone thinks that limiting a computer scientist's choice of tools is a good idea, you should kick that manager to the curb.
If anyone thinks that hiring computer scientist's to do anything other than research and theory is a good idea, you should kick that manager to the curb.
I don't think you can count The Dalai Lama as he was born with a title of nobility. Yes it turns out the he is a good leader, or so it would appear, but he didn't have to earn it.
You also can't count King Bhumibol Adulyadej for similar reasons. Not to mention that fact that pretty much any leader will look good when their critics are subject to up to 15 years in prison.
And as for Obama, all I can do is laugh. There is only one american politician that I can think of that didn't rise to power by stepping on people on the way up and it's not Obama.
In most major metropolitan areas there is more traffic than can be safely supported by the available lanes. Restricting one of those lanes for passing only would cause further congestion. And no the left lane is not always for passing only.
But what the GP was saying here is that the traveling faster than the speed limit is breaking the law and causing unsafe driving conditions. So if you need to exceed the speed limit to pass the person you probably should be worried about passing them.
"patents are stupid --> all of IP is stupid --> abolishing IP by itself would immediately bring about world peace"
certainly didn't make my common sense tingle... You just didn't carry the equation out completely.
"Patents are stupid --> Intelectual property is stupid --> private ownership of property is stupid -->abolishing all private ownership of property would immediately bring about world peace"
I mean what can you fight over if you can't own or control anything.
And I'm only partially joking.
Patents and IP are not necessary, but they are necessary in a capitalist system.
All you need for either is a very basic understanding of how it works. Obviously written by someone that either does not play the drums or does not Rock Band.
Being someone that does both(all be it I haven't drummed in a number of years), I have to say the RB drums are a lot closer to reality then the guitar. RB drums are very good practice for coordination, limb independence and speed. To complete RB drums on the expert level requires a lot of practice, including knowing the basic rudiments. Sure it doesn't make you a professional drummer, but would get you through your high school jazz band.
When Activision is screwing their customers by denying cross compatibility the moderators refuse to put the article up, even though it was voted all the way up on the firehose.
When someone has some wild speculation about a new game being released by Activision it goes right to the front page!
Slashdot Mirror
Anyway, the point is, there are kids who'll use something like that to skate by while doing even less work.
We call them "Executives."
At my company we are looking for all ranges of skill level and on the past few months we have yet to find someone that I think deserves the title of programmer let alone engineer. And this is coming from a self taught software engineer, so it's not like I'm looking for endless experience or any degree. Most programmers don't even understand the basics of how a computer works, or the major syntax of the languages they supposedly program in.
If you really want to find a "qualified" firmware engineer then then I suggest posting a link. I would also suggest not writing off everyone with less than 10 years of experience and a Masters Degree.
That being said, I believe you when you say you are having a hard time finding programmers of any sort as I have been interviewing candidates for months, for all levels of experience, and have yet to find even a single person worth extending an offer too.
Obviously, they're too used to their 2 income lifestyle to realize that $12/hr. means scraping by in poverty level conditions if that's your sole source of income.
Go live at real poverty levels for a while before you try and claim that $12 an hour is the poverty level anywhere outside of silicon valley.
The official poverty line in the United States affects nearly 40 million residents. To be in that 40 million strong group you have to make less than 10.5k per year as an individual with no dependents. $12/hr full time equates to aproximately 24k, more than double the official poverty level and just about enough to keep a family of 5 above the poverty line.
I'm not saying that $12 a hour is a great wage and it doesn't suck that most of what you should be earning is in the hands of less than a million US residents. What I am saying is that anyone make even $10 an our with out any dependents hasn't a clue what it means to be poor. Heck if you have the time and resources to post on slashdot then you most likely can't even fathom the realities of being in poverty (myself included).
I am anti-libertarian economics, but that doesn't mean I'm going to sit around a bitch about my lot in life when right now wealth is still there for anyone interested in actually working for it (assuming you are willing to trample on a few people to get there).
This game sounds absolutely perfect for the Wii.
I'm guessing you actually know very little about this game. This "game" is actually the most complex physics engine ever released for a video game console. Between the complexity of the highly parallel processing physics engine, and the in depth intelligent level creation (not just through pre designed fixed size tiles on the screen) you end up with a game that the Wii couldn't handle even if the resolution of the graphics was drop to that of the 8 bit era.
You are correct that the game premiss is suitable for the Wii audiance, and that the wii controls may be useful if they were anything close to accurate, but the game itself is not suitable for the actual Wii hardware.
Not to mention the release of Life with Playstation and the Beta's of Home, it's starting to look like Sony's online community is about to take a pretty huge jump in quality and content.
Stop trying to bring facts into this debate. It's for more interesting to watch people that have no clue what they are talking about, and either never had to stand on their own, or never been a member of a union, argue over a topic they know little about.
Seriously I wish I had mod points and hadn't already posted in this thread. This is the first comment I have seen on either side with any actual facts in it.
Let's note that American Honda builds all their cars using non-union labor, and we know how Honda is doing. Honda is also one of the best companies to work for.
Good point, but probably not the one you meant to make.
you have to realize that there is no union because Honda is a good company to work for and not vice versa.
Yes in theory we as employees can chose to only work for the good companies and their for put the bad companies out of business, but to do this and have it work you have to do it in an organized fashion. And how many people do you know are able to live a year or more without a job while we wait for the better companies to grow large enough to support us all? I'm sure your answer is few if any. With shared resources, as supplied by a union this is a much more surmountable obstacle.
I'm still not seeing the issue. A String object is a String object. If you can't remember if you that the object you are working with is a number of not then use the NaN function to make that determination first. This same thing would happen in any other language with an overloaded + operator.
I'm just saying that JS gives you the tools necessary to not make these mistakes if you are every dealing with unknown object types and using primitive operations (not a problem if you use method calls as you are safe as long as the object supports the method being called, which is also easy to check).
I don't see how you can claim it's a "huge hindrance" - you sound like something of a cowboy programmer to be honest.
That's kind of funny. My teams always complain that I am to structure and process oriented. I would say it's my application of engineering practices that allows me to be able to safely work with dynamic and duck typed languages.
And yes it is true the more popular languages are strong static typed, but that does not mean it is the best way. And I have been doing mostly Java development professional for the past few years so I am very familiar with strong static typing and the libraries available for such languages. The majority of those library use object interrogation or even proxying to deal with the limitations of Strong static typing (Java's even includes an entire API to circumvent the limitations of strong static typing in it's Relection API). Even the majority of the design OO design patterns are design specifically to deal with these limitations.
Defining and declaring your types up front may seem inconvenient but it means your codebase can scale, more bugs are found ahead of time, future programmers can more easily comprehend your code and compilers can optimize your code much more easily.
In JS you declare and define your types up front, so I'm not sure what you are getting at. Yes, it is possible to extend your type once it is created, but that neither means that you have to or that this should cause any reduction in maintainability. You have the option to use JS without ever once adding functionality to an object once it is created. Learn JSs object model and how to create constructors and you will understand more about how easy this is.
I rarely run into a bug that would be caught by a compiler, either in dynamic, static, weak or string typed languages. Bugs that can be caught by compilers are trivial in nature. You are better off having a good suite of test cases to catch bugs.
Optimizations on run time parsed languages are actually much easier than compile time languages. This is why Java now uses a Just in time Compiler, and that this has caused great improvements in performance. Plus there are multiple native/byte code compilers for JS, so it's not beyond reason that dynamic and duck typed languages can be compiled.
If there was some kind of efficient, statically typed language available for use in web browsers making it run fast wouldn't be a research problem, and we could replace the unintuitive CSS box model with something that actually worked for web apps. The reason you can't do this today is that JavaScript is just too damn slow to do real time GUI reflow, so you have to let the web browser do it in C++, so you're stuck with CSS.
The performance issued in browser application development have nothing to do with JS performance, it has to do with the browser implementation, and more importantly the DOM. This is why things such as XUL were devised. They provide a more application oriented object model and greater performance. It's also possible for JS to access native libraries, which is the only way to gain good performance in any language (even Java, C# and other byte code languages have an interface for accessing native code and utilize it highly in their core APIs).
Just do a little more research into JS, and understand the core features of the language. You will see that bad and inefficient JS code has nothing to do with the language.
I think you are very confused. In JavaScript a Number is a Number and a String is a String. The fact that you are trying to add 1 + "1" doesn't mean there is anything wrong with JS. Objects are only treated as Strings when a string is required, or it does not meet the criteria for any of the other applicable objects. Read the specification sometime. There is a hierarchy for auto casts for every operations.
If the operation is over loaded to work with Strings or Numbers the operation will treat all the objects in the operations as numbers if they are all numbers, otherwise it has to treat them all as strings, as every object can be treated as a string. It's actually far more detailed than that, but I'm not going to rewrite the spec in a slashdot comment.
Just try and remember that 1 == "1" but 1 !== "1".
The primary flaws in javascript are its lack of namespaces, true OO, and, most of all, its lack of types and type safety.
The primary flaws in javascript are developers that do not understand the fundamentals of the JS language (and I don't mean to be attacking anyone particular, this is just a really common problem).
JS is 100% Object Oriented. Just because it contains Functions as first class objects and Closures does not mean it is not Object Oriented. Everything in JS is and object, everything. There are no classes because it's a prototypical system not a classical system. The fact that all things are objects and that JS contains closures means that Namespacing does exist, if you have some specific reason to use, just by creating an object to represent the name space and keep all namespace protected objects in that objects scope.
Also JS is completely type safe. You can not cast an object to a type that it is not (something you can do in none type safe languages like C). What you meant to say is Strongly Static typed, which is found in only a few languages and is a huge hinderance in those languages. Duck Typing, as implemented in JS and few other languages, is far more flexible and just as robust as you still can't screw with memory arbitrarily.
The only thing I would give you is that it would be interesting if JS variables could be typed (as the objects already are). This would allow the runtime environment to determine type conflicts and for an IDE to be able to have additional autocompletion options. But sadly this would just lead to other problems just as difficult.
So, just to be clear: you're advocating breaking up your software into otherwise-unnecessarily fine-grained methods, because it's less intrusive than just adding logging statements? Sounds more like a recipe for spaghetti code.
Actually what I am suggesting is that breaking up your code in this fashion actually leads to cleaner, more readily reusable code, that just happens to be perfect for allowing the necessary level of logging. I suggest that the same rule applies to commenting. If you find the need to for an inline comment than you code is more complicated than it needs to be and should be broken up into smaller components.
Well segmented code need not be spaghetti code. Spaghetti code is a reference for difficult to follow control structures and has nothing to do with segmentation.
I have one simple rule when it comes to code: If it is not required for honoring the contract of the procedure or directly influencing the required logic, do not put it in the code. This goes for configurations as metadata (like java's asinine annotations), premature optimizations (result caching), insignificant commenting (any inline commenting), as well as logging.
That being said, you can add what ever logging you want as long as you do it outside the application code, such as through AOP (if you don't know what that is then google is your new best friend).
Logging through external means has a number of benefits. First you application code is relieved from unnecessary clutter. Second the logging can be added or removed as fit for the environment with no need for any runtime checking, which is perfect for turning of all logging in production environments. And lastly it enforces good coding practices as it makes sure people break up code in a way that makes external logging possible, which is how code should be written anyway.
The majority of all logging, dare I say all useful logging, is easy to summarize.
This is perfect for function/method interception since it comes down to something more specific.
So simply add the first logging to an interceptor that operates before the functions you want to log, and the second after the function.
If you find yourself needing detail inside the function then you need to break the function up into sub routines, so you can use this generic logging on the sub routines instead, or as well as.
I wish I had mod points because this is the clearest form of using braces in code, but very few people use this form.
I didn't believe this until I started using it, and now I can't stand looking at any other code.
You really can't hold parents responsible for their children doing stupid things...
I used to think these exact same things, before I was an adult and before I was a parent. Now that I am both, in that order I might add, I disagree. Children doing stupid things is entirely the responsibility of the parents.
It's very easy to teach a child how to act responsibly and not post lies on social networking sites. There is also the concept that parents should know what there children are doing, I happen to know what mine is doing at all times. This doesn't mean stopping them from doing anything, just being prepared to stop them from doing something stupid.
On the other hand I don't really see an issue with a child posting a fictional story on a blog, it's just not a big deal and there is no reason to sue a paper for printing it.
Maybe you were joking, but this is exactly the attitude that keeps the 'interchangeable code monkey' approach to software development and personnel development alive and well in the software development career field. Go on - keep laughing...while they offshore your job.
It amazes me that developers don't want to be taken more seriously. When they do - they end up becoming architects without much impact on the new batch of developers coming in -- little if any mentoring or lessons-learned. Many of the people who become 'developers' have not a clue about computer architecture - and end up learning from the 'school of hard knocks' - when they do something a CS grad would recognize is the wrong thing from a mile off. (hint: RAM is limited, CPU Cycles are finite over a given time frame, and virtualization is ubiquitous and the key to every important advancement in system capabilities (microcode, machine code, system code, application code, higher level abstractions)).
No wonder software development is so screwed up - and we only have ourselves to blame.
The problem is that we are hiring scientists or developers to do an engineers job. It's called software engineering for a reason. You don't hire scientists to design engines, or electrical circuits, or even cities. For those tasks you use engineers, mechanical, electrical and civil respectively.
,I'll even give them credit here, you need someone to design a new algorithm, which is rare if ever, then you should get a computer scientist.
I'd be happy to find you a few dozen self-taught developers that would run circles around your average, or even above average Computer Scientist, including on detailed hardware knowledge. I have personally never met a Computer Scientist that knew the slightest about the computers they work on, that's the realm of the computer engineer (and yes I can build a 64 bit look ahead adder from knowledge in my head without reference). But if you need to have someone repeat to you the SHA hash algorithm, or
Just remember science is knowledge and study, where as engineering is practical application and construction.
I'm not sure where quality comes into this. The language doesn't affect quality of programming, at least for good programmers. It's not hard at all to learn a new programming language, but it can be very hard to shoehorn a solution into an inappropriate language. A developer shouldn't get to decide the language, but the project manager should with feedback from the devs.
Quality comes in because no person can be as proficient with every language as they could be with one. You either spend you time learning the basics of all languages, or in the ins and outs of one. Sure a good engineer can pick up any language and write in it, but they won't do it nearly as well or as quickly as they would in the language they have been using for the past 5 years. This is a basic fact and it applies to all industries. You don't take your Toyota to the Chevy dealer and expect them to be able to do the work nearly as efficiently. Sure any mechanic should be able to fix your car eventually, but at a pretty substantial cost in time and resources.
So why don't we write device drivers in Java? C and Java are like C and Java, inappropriate analogies aren't helping anyone.
This is for the same reason the ICs are not built with Craftsman or Snap-on Tools.
Sure you can't use a single set of tools for every task, but in reality very few companies write drives and web apps, and if you do the team is so large that you are not going to be moving people around that much. So if all you company or team does is one type of software, say drivers or business applications, then you can standardize on a single language and be far more efficient.
Programmers are not interchangeable...
Only the good ones are interchangeable. If the process is in place so that the engineers involved do not need esoteric subject matter knowledge then any decent developer should be able to work on any project at any time. Yes there is some over head in task switching, but it's a lot better than saying "we can't do that today because bob is on vacation" or "we have to keep bob even though he normally shows up to work drunk."
...and all languages are not interchangeable.
For most business applications there are many interchangeable languages. Sure if you are building hardware drivers you are not going to be able to do so in Java, and JavaScript was not designed for enterprise applications (though I assure you can can be used to do so). But if all you do is build the same type of products or systems then using a single language or small set of language with defined uses certainly simplifies the search for talent and the ability to migrate teammates between projects.
Sure, and while they're at it, let's give all the mechanics just one size of wrench and screwdriver.
I am so sick of this analogy, as it's completely inaccurate. Programming languages, at least full featured languages, are a whole set of tools, not a single tool. Comparing Java to C is more like comparing Craftsman to Snap-on, different brands of tools but they can both be used to do the same thing. If you can give you mechanics a single tool that can be used in all their tasks, like a sonic screwdriver, then do it. If the language isn't full featured, or cover all your needs, then don't use it.
And conversely, each project team should be free to evaluate the best tools to get each job done.
This is exactly what you need to do if you want to guarantee that you have to continue with the team you have or hiring nothing but experienced senior developers. Keep the number of tools simple and you can have a small number of leads and many interns to do the same amount of work with a much higher over all quality and considerably less cost.
If anyone thinks that limiting a computer scientist's choice of tools is a good idea, you should kick that manager to the curb.
If anyone thinks that hiring computer scientist's to do anything other than research and theory is a good idea, you should kick that manager to the curb.
I don't think you can count The Dalai Lama as he was born with a title of nobility. Yes it turns out the he is a good leader, or so it would appear, but he didn't have to earn it.
You also can't count King Bhumibol Adulyadej for similar reasons. Not to mention that fact that pretty much any leader will look good when their critics are subject to up to 15 years in prison.
And as for Obama, all I can do is laugh. There is only one american politician that I can think of that didn't rise to power by stepping on people on the way up and it's not Obama.
In most major metropolitan areas there is more traffic than can be safely supported by the available lanes. Restricting one of those lanes for passing only would cause further congestion. And no the left lane is not always for passing only.
But what the GP was saying here is that the traveling faster than the speed limit is breaking the law and causing unsafe driving conditions. So if you need to exceed the speed limit to pass the person you probably should be worried about passing them.
"Patents are stupid --> Intelectual property is stupid --> private ownership of property is stupid -->abolishing all private ownership of property would immediately bring about world peace"
I mean what can you fight over if you can't own or control anything.
And I'm only partially joking.
Patents and IP are not necessary, but they are necessary in a capitalist system.
Being someone that does both(all be it I haven't drummed in a number of years), I have to say the RB drums are a lot closer to reality then the guitar. RB drums are very good practice for coordination, limb independence and speed. To complete RB drums on the expert level requires a lot of practice, including knowing the basic rudiments. Sure it doesn't make you a professional drummer, but would get you through your high school jazz band.
Just saying to not knock it until you try it.
Good job Slashdot.
When Activision is screwing their customers by denying cross compatibility the moderators refuse to put the article up, even though it was voted all the way up on the firehose.
When someone has some wild speculation about a new game being released by Activision it goes right to the front page!