After reading many of these posts, I think were getting a bit confused here. In part, the original poster is a bit confused, or at least imprecise in his wording.
When coding a module or piece of program for use in a wider system, such as a library or module, black box thinking is a good thing. In this context, a black box means something that does not expose its internals, and provides an abstraction to the user/programmer.
The STL or the standard c library is a black box. TCPIP and the sockets API is a black box. the java standard class library is a black box. If you were required to know all the interal details of all these systems to be able to use them, you wouldnt get very far.
Abstractions, which is what we are talkign about when we use the term black box as above, are absolutely required to write decent software. You simply cant reliably keep that many details inplay at once and expect to get it to work right.
As useful as the above black box libraries are, it is very possible to create a library that is unusable. Making the user of the library know all the impelentation details from inside is one way to do this, but the other is to use the wrong abstractions, make the wrong assuptions about usage, etc.
In short, what the original poster and many others are complaining about when they say they dont like black boxes is that they are using bad or incompatible boxes!
Having to fight with a library that makes assuptions that are invalid, provides the wrong level of abstraction, or is not implemented very well is not an indictment of black boxes, but of black boxes that suck. The fact that their internals are hidden is not the problem. the fact that their interface to these internals sucks is the problem.
So dont confuse the problems of using bad black boxes with a fundamental problem with black boxes. A bad impelemtation doesnt mean the concept is bad. A poorly designed system well may provide a black box that no one can use, or at least not in all situations. but making that box white, and exposing all its internals, isnt the solution. designing the module to work right is.
Further, one persons perfect abstraction is anothers miserable pile of junk. Just because the black box doesnt provide the interface you need/want doesnt mean it sucks, it could just mean your using the wrong tool for the job. Complaining about how hard threads make it to hammer in a screw doesnt make much sense. Use a nail.
do you know why people dont build buildings and let them fall down, and then do it again, and fix a few things they saw, and then try again, and again, and again? Its because its time consuming and expensive. And we've been building things that fell down and learning from them for centuries.
Know why that doesnt happen as much with software? Because for most of the cases, its cheaper to just build the thing and test it in isolation and watch it fall down a million times than it is to try to engineer it the way a 747 is. I cant keep making planes and watching the crash, get a clean copy out of a drawer, and make a few fixes to it. That would be insanely expensive. But I can do that 100 times a day on a piece of software, for a whole hell of a lot chaper than I can engineer it.
This crap about 'software being immature' is nonsense. No, its not like structural engineering. It doesnt have to be. Creating software is different than creating buildings, and using the models we have for building real things doesnt nescessarily apply to building virutal things. the economics are all backwards. Software doesnt need to grow up into one of the other engineering disciplines. it needs to figure out what it is, and grow up into its own entity. Not a baby Electrical engineering, and not a 2nd gen mechanical engineering.
Software deals with the virtual. Its influnced by completly different forces, economics, and as a result, it will never be exactly like one of the other engineering disciplines. It will be something else completely.
trying to force it into a engineering or factory floor model is doing both a disservice.
You know what I've seen with engineering and related stuff is this.
I started work where I currently am with a bunch of other people from my school, many of which are still here. What I've seen is that most of these guys are still working with the same skill set they joined the company with, and havent gotten better or more well rounded or better read or skilled because they stopped studying the day they graduated.
So for these guys, they have a problem. The new guys come out of school, cheaper and better than they are, for one simple reason. These 'old' guys have been sitting on their rear ends the entire time they have been here, and not gotten one bit better at what they do.
So they are looking for management positions and other jobs where they wont be in competition with the new guys, because they don't really care about being able to program well. They have gotten comforatble, can spend their time with their families, kids, hobbies, and put no effort in to learning new stuff.
Because these positions, the management and leadership roles are not driven by the knowledge and understanding of their participiants, but who they know, and their social skills.
If any of these guys had put just a few hours a week into studying their area of interest, and just a few hours a week working with the new technologies, reading journals, books, etc, these new guys wouldn't stand a chance against them.
Instead they spend every spare momemnt watching football, basketball, or NASCAR, and then they have the nerve to complain about the new guys knowing more than them. What the heck did they expect? that the world would stand still and give them a free ride because they made it through college?
In most other engineering areas, other than software, this also happens, but much slower. In software, all it takes if 5 years of not learning anything to be completely obsolete. Of course they loose their jobs after awhile, they got expensive, and dont provide anything of value for that money that cant be gotten from a cheaper person.
If they had spent their time better and had kept studying after they graduated, they would be head and sholders above new graduates, and the company would not think it made sense to get rid of them quite as easily.
It's hard, and most likely not possible, to get oss software to be usable. And for a very good reason.
Much of the very important things in oss are very good solutions to very complicated problems. apache, linux, gcc, etc. Ive only ever seen one way to make a complex thing simple and that is to make lots of assumptions about how the program will be used, and to take away options.
Take IIS and compare it with Apache. Its easier to set up, and simpler to configure, but its damned near impossible to get it to do some of the things apache will do. Why is this? because iis is designed to be easier to use. Many of the parameters that apache exposes could have been exposed to iis, but that would have been complicated. So to fix the problem, we make some assumptions about how it will be used, and don't let the user change things.
This is true of other things, like MS Access. Database's can be very complicated. Access Db's are usually not. Why? many assumptions are made about how you are going to use it. If you try to put a datamodel behind an access app that doesnt corespond to the one ms had in mind, you will be writing lots of code to make it work. Its possible, but its a bitch. They have made assumptions, and taken away control, but that is in fact what made it easy to use.
The people that write OSS are, as we almost all agree, usually writing something for them, but in any decent sized project, there are lots of developers involved. So we have a piece of software that is trying to scratch the itch of many different developers. This HAS to make it complicated. Everyone wants something different added to it. The only way to make it work for everyone who is working on it is to make it complicated, to not hide the complication, and not make assumptions about how its used.
And as soon as you realize that to make the program what everyone wants is to make it complicated, you can not make it easy to use. Its just not possible.
I spend all day writing sofware, side by side with EE's and ME's and others designing and building control systems and other machines, and have been doing so for the last 10 years.
The thing is, they screw up their designs just as often as I do, they build things that don't work well the first time just as often as I do, and they release stuff that doesnt do what the customer wants just as often as I do. And the outside companies we work with are worse.
It's a complete falacy that more mature engineering disciplines are able to some how make things that work all the time, right up front. I heard this in school long ago, and with out any experience I took it as true. After just a few years of working with hardware engineers, I found it was complete crap.
The crux of the issue is this. Building hardware is complicated. Building software is complicated. Building anything with a couple of hundred thousands parts in it is very hard. To do it right takes talented and motivated people, lots of time, and lots of money. Things need to be well organized, well planned, and well executed.
I've seen a few people on this story post that many traditionally engineered things that people hold up as being examples of how to do it right, such as bridges, are much simpler than software. That is very true. Most circuts that our EE's build here, lets say they had 50000 things in them. thats quite a lot. but look at the things. the things that make up a circut are all very simple. one input, one output, performs a very simple operation. Its actually alot less complicated that a big piece of software. Write a program with 50000 addition, subtraction, and boolean logic statements in it, and you'll find youve got a very simple program. Take a look at an assembly dump for a simple hello world program, and your find that many thigns.
Invariably, when someone says that engineering works with less complicated things than software, someone always trots out a 747 or a space shuttle by way of a counter example. Its true, these things are well engineered, work right, and are insanely complicated.
They also took many (10-12?) years to go from idea to working tool, and took billions of dollars to make. Find me a software consumer willing to sit around for more than a year, and I'll be excited. Find me someone that doesnt think 600K for piece of software is insanly expensive and I'll be just as excited. The space shuttle software is often taken as an example of what could be done with good software enginnering, but they dont realize that the documentation budget for the space shuttle software is larger than many software companies entire revenue stream. The space shuttle's software teams customers are people that understand that if the software isnt done right, people and billions of dollars worth of stuff will be destroyed. You know what that means, they have the staff, budget, and time to do things right.
You cant compare things like the space shuttle to a 6mo project to make data entry program. Dont even bother. And dont think that the problems you have in a 6mo data entry project can in any way be solved by tools designed and proven to work on the space shuttle.
People have come to expect good software very quickly and for cheap. That comes with some problems, and its very hard to combat those problems. The programmers are often very poorly trained, the budget is tight, and the software is a moving target. I have yet to see a program I started to work on not change substantiatly from the time I started till the end. Spending 2 mo at the beginning designing things to the level of a 747 is stupid, because by the time the item gets out the door, it will have changed from a plane to a boat. that 2 mo was wasted.
Yea, but its an interpreted document, and the interpretations were selected by councils, popes, etc.
When/who wrote it is less important than the uses it was put to, and the interpretations it inspired, and that was done by the church.
A complete record of all their changes of opinion, selective enforcement of canon law, and their political intrigues would make for very interesting reading.
Theres probably 2000 years of history in that library, all of it important, and all of it affecting the modern church. There's much more in there than just early copies of the New Testament gospels, and while important, the gospels are not the only thing that influenced, informed, and motivated the early church and early Europe.
Europe and the rest of the western hemisphere by extension owe their existence to the church, and as such, their history is really the history of the west. Keeping it locked up in the basement of the Vatican is not where this should be.
Lets be honest here. Using comments as a crutch to prevent you from having to figure out what what the program does is destined to fail.
Comments are not compiled. They do not affect the outcome of the program. If you want to know what the code does, even in the presence of comments, you have to look at the code. Comments can be out of date, misleading, and just plain wrong.
There is no substitute for just reading the code, and learning to understand what it means.
Even in a beautifully commented piece of code, you will still have to go back to the code, to confirm what its doing.
Just try to remember. Comments arent compiled. They are not the code. If you want to know what the code does, you have to read the damned code.
That being said, the comments that are most likely to have an impact on others is comments not about the code, but about intentions. Its pretty easy to convert your intentions in to code, but alot harder to convert your code back in to what you were trying to do.
The code tells me what you did, but not why. And comments that talk about why you are doing something, and why you chose this path, are less likely to be wrong, missleading, or out of sync.
If you know what you are doing, you can look at uncommented code and figure out what its doing, but not why. Why is whats important.
Coding is a kind of compression. It takes the verbose ideas that you and your team have been tossing around for a while, and convertes them in to something quite sparse for the compiler. If I look at your code, I might be able to reconstruct your ideas and intentions, but its not likely. Thats what I need added to the code.
So, if your Bill Gates, and onthe stand trying to tell the judge your company isnt an abusive monopoly, would you think its a good idea to start shaking down schools for money? Is that a good way to make your point?
What is OOP? Its a way of abstracting a problem in to something simpler that is easier to work with.
What is mathematics? Its a way of abstracting a problem into something simpler that is easier to work with.
Rather than work with the actual quantities of things in question, we can abstract them to numbers. Rather than work with actual processes and physical things, we can work with mathematical representations of these things, equations and procedures.
This is very similar to what oop does. Rather than work with piles of unabstracted data, we work with abstracted data in the form of objects.
But if the problem you are trying to solve has already been abstracted after years of work in to a nice set of equations and processes, whats the benefit to abstracting it further? The math is already an abstraction, and a good one at that.
So in this type of problem, the most natural abstraction is already there, the math, and can be used directly in a non oop way. adding an unnatural layer of abstration overtop of that one will likely just make things more work.
Thats not to say that the overall structure of the program cant be improved by the abstraction and orginization that OOP can bring to the table, but the actual calculations, the math, is already a huge level of abstraction over the real entity anyway. Why add more to it?
for (i = 0; i array_size; i++)
free(array[i]);
free(array);
does, I dont want you messing with my software.
dont say what you do, say why you do it, and why you didnt do something else. That I cant get from the code. what it does, is quite clear in most cases. if not, rewrite it so it is.
It can also happen because what you read is nonsense. Its not safe to assume everyone knows everyting about software development, and that you are reading the wisdom of the sages. Its possible that the code your working on is full of years of wisdom. But Its also possible that its full of years of nasty hacks done as quickly as possible. Its possible that after years of this, you cant fix it any more, cause every thing you do will break N unknown parts of the code.
Its possible that it was written by people that didnt know what they were doing. Its possible that the 'changes' you are to make would in effect make it a different application.
Its possible that the wisdom you are seeing, these bug fixes, would all have been unnescessary if the design or core implementation were different.
So dont, please, make the blanket statement that old code is good. It is quite lilkely, as likely that its good, that its complete crap, and needs redone to have any chance of getting it to do what its going to need in the future.
You cant just keep fixing something. Your clients wanted an airplane. They couldnt afford one. they bought a car. Theve been paying you for years to slowly graft propellers and wings to the car. Now, they realize they really need a boat. But, being cheap, and following this guys idea, they dont want to just redoit, they want you do tie pontoons to the car.
Never did anyone ever ask if you could actually convert a car to an airplane, or the result to a boat. What you end up with is a car that cant turn, a plane that cant fly, and a boat that will sink faster than a brick.
Fix bugs, sure, add a few features, sure. but when what you want to do ceases to be possible with the base yove got, youve got to leave it behind.
Also, this model of never rewrite, assumes that you always have the best people working on it, and that they all know everything, and that the world of software development never changes. Sure, I could fix the code that the inexperienced co-op down the hall wrote, and make it do something else, but I know much more than him, know better tools, better designs, better implemetataion strategies. So I could either spend a week fixing this crap, or I could just redoit with the right design, the right tools, and the right implementation, and not only be done sooner, but have a much better product.
As another poster said, there is often good information in a piece of code thats been worked on for years. There are also crumbs of attempts in the past that went no where. And stuff that doesnt work, but you dont know it, cause its never been used until you made that last little fix. It can also be full of dumb ideas, bad implementations, and simple old ideas that dont work anymore.
So, if your a wank that doesnt know anything, and your given code written by someone that knows what they are doing, read it. youll learn something. If in stead, your a good programer, and given something written by someone with exactly 3 hours of experience programming, it may be much easier to just rewrite it, rather than try to fix it.
or even if not easier, much better, and in the long run, more supportable. much small, tight, well thought out unix code is still being run, because it was done well first, with out regards to getting it out the door. Old dos and win31 code that was pounded out the door as quick as possible was thrown away years ago.
I spent all morning decompiling and reading through this thing, to see what it does. the wave file that it attaches to the email is actually an executable, named readme.exe, that contains the package. Its rather nasty. It also messes around with windows resources, and explicitly looks for winzip. Its rather big, so I havent gotten the entire thing understood just yet, but from all Ive tracked out of it so far, it messes with nt lanmanager security settings, explorere settings, and mail settings, as well as mangeling certain files.
And I wasnt kidding about it messing around with resource bundles on the end of windows executables. I havent figured out what its attacheing there, but something is definitely doing it.
And earlier posts were right about the attacking of codered rooted boxes. it also gets other misconfigured iis setups that allow access to cmd some how.
Whats nasty is that since it can come in over email, it got behind the corporate firewall this morning. and since inside most people hadnt bothered to keep their iis servers pathched and secured. So even though we were safe from code red, this one got in and starting mangeling servers.
Think of it this way. We can produce software with out management help. They can't produce software with out us. This means that while they may have the responsiblity and authority over a project, they have no power.
You can take this two ways. You can recognize that you are responsible for something you have no control over, and you can do everything in your power to help those that do have control over it complete their task.
The second way is to find some other way to regain control over those that will be doing the work.
Ive seen several innovative ways to do this. One is the basic use of fear. If you make people think that they can be fired at any moment, then they will do what ever is nescessary to stay around.
Obviously, this has less of an effect when you are in a booming IT economy and the fired can find a new job before they get escorted out.
One other way is through guilt. Do it for the team kind of crap. Making you feel that it is somehow your fault that you cant meet ridiculous deadlines, etc.
Obviously, this has its limites to. to be a good developer usually requires some smarts, and its not long before you realize that this is a bunch of crap. You refuse to take blame for things that arent your problem.
I've seen the company I work for refuse to hire someone that was very confident. Those that are confident are less likely to be pushed around by management. You cant use fear or guilt on someone that is both good at what they do, smart, and knows it. They know that its not their fault sales sold something that was undoable. They know they can do the work, and they know you cant.
Which leads me to my point. Lots of young and foreign workers are more likely to be less confident in their abilities, less confident of their position, and easier to manipulate.
If your ability to stay in this country is predicated on your not pissing of your boss (if you quit or are fired, you often have to restart the visa process, etc...), you are more likely than not to do what your told. If you are just out of school, and think your lack of experience will keep you from other jobs, you will be more likely to do what you are told. The young workers also dont know anybetter. they dont know that its unacceptable to be asked to work 80 hrs. And the young are very fresh out of a very authority driven world of teachers, parents, and administrators. It takes a while to realize that authority doesnt nescessarily mean anything.
So, as a result, Its easier for management to bully young guys out of school and foreign workers. One group is bullyable for only a short time, untill they get some experience, and some credentials, and some skills, and realizes that they have a lot more power than they think they do.
Foreign workers are much better in this regard, as they can be bullied for much longer.
So it doesnt come as a big surprise to me that companies would want to glut the market with cheap, easily controlable work force.
Also, how many of us have heard in software engineering that it is bad to have super hero programmers that do it all. We're told its much better to have a bunch of mediocre programmers. There is obviously some truth to the idea that having one programmer is riskier than many, and having several spreads out the risk, but it also spreads out the control. if 10 people have all the control in the company, then it is easier for each one of them as individuals to think that they aren't that important. if none of them think they have control of the company, they are easier to control. but with just one guy, its a lot harder to control him, becuase unless he's really dumb, he knows he had everone by the short hairs.
What makes you think there are 25K linux boxes in there? StarOffice runs on Solaris, and I know they have lots of Sun boxes floating around. And more than a few Windows machines.
Women were considered sex objects well before tv. And people were being conditioned to be violent well before video games.
I cant argue that its not possible that kids are being conditioned towards violence in this country, but lets be careful about what we say is doing it.
Seems unlikely that recent additions to the american culture (tv and video games) are the cause of problems that have plagued this country for centuries.
Do you have 35 million dollars and 200 people to work on the single product that your company has been working on for the last 20 years? Do you have a customer that knows exactly what it wants, in extereme detail? Do you have the problem domain so absolutely understood that you can describe exactly what you want before you even begin to write the program? Does the rest of your company understand that the software is not an addon to the system but a very fundamental and important piece, a piece that rightfully occupies a place of importance equal to the rest of the system. Does your schedule get driven by quality, not contracted deadlines?
What, you dont have that much money? Nor that many people? You mean you have several products? And some are new things that neither you nor anyone else has ever done? You are asked to solve non-trivial unique problems that need interesting solutions developed by you, not a team of experts with PhD's. You mean that you havent been doing the same thing with the same people for 20 years? Your customers dont know what they want? Your customers and management dont let your experience with the problem domain drive schedules, but instead, insist that things be done when they say, not you? Your software is not considered the most important part of the system?
Well, I'm sorry for you. It must suck living in the real world.
this kind of elitest stance will do absolutely no good for linux, open source, or any of the stuff that we seem to hold so dear here on slashdot.
The customer is not just a dumb lump that needs to get out of your way. they are what makes your software viable. with out them, your just a lone hacker hiding in your room, writing stuff noone will ever use.
Telling them they just shouldnt use that stuff that wont work with the newest linux glibc is not the answer. providing ways for vendors to provide glibc neutral software is. Having oracle for linux was one of the biggest wins linux has had in a long time, makinng it seem almost viable to the business world.
It is possible to avoid dll hell, (or.so hell, in this case), but it takes work, and forethought. hacking together a library just wont do it. unfortunately, the clibrary was written a long time ago, and there is almost no chance of getting it rewritten using better opaque types, and hiding its internal implementation.
But that is the only way to make this problem go away.
I have read more than one post here that says the problem is that you cant write code in C that doesnt encourage tight coupling between application and library.
well it just aint so. opaque types are very easy to produce in C. With these, you can link your applicaion dynamically with its library, and replace the library when ever you want, with no effect at all (as long as the interfaces and semantics of the library is the same). You can add fields, to your hearts content, with almost no penalty, if you pay attention to what your doing, and think things through.
the problem is that the glibc library wasnt written this way, and its way to ugly. it exposes internal structures, which is a very bad thing to do, as we all know. (think objects...)
C++ isnt the only language you can hide implementation details in though.
Just do a google search on opaque types. its possible, and easy, to do in C.
When I first started using Java, my first response was 'great, slow c++'. I know it has some thing that c++ doesnt, but the common ones, such as a nice stdlib of classes and garbage collection, are all available under c++ with a little work.
I figured, if I was going to pay for the overhead of an interpreted lang that was so slow, I better get something more out of it than what java gives you.
So when I started working with Python, and other very high level languages, I was much happier. Sure they are slow, but they do so much for you. Strings, tupels, lists, passing class definitions around as parameters, dynamically constructing your code and relationships, etc... The list goes on and on in these other languages.
The way I see it, for what we pay for java (in tearms of runtime speed, etc) better be offset by what we get, and at least in the beginning, that was nothing.
Dont get me wrong, reflection is a nice thing you cant replicate too well in c++, though you can in other languages. And as the years have gone by, more and more packages and class libraries have been made for java, making it more and more useful.
But lets remember something guys. The tools need to fit your problem. Java isnt the end all, neither is python, c++, ML, or lisp. Each have domains where they work better than the other. Knowing one language is a sure way to commit professional suicide. Would a master cabinet maker get anywhere if all he/she knew how to use was a hammer? of course not. To be a master at your craft, you need to know the tools, the problems, the media, and have lots of tools to choose from.
Not everyone is writing servlets to drive web sites, or just talking to a db. Some people need the speed given by other languages, or the access to the bear metal, or the high level abstractions provided by others.
Trying to point out that your language of choice is the best thing ever to me shows only that you work in a limited domain and dont realize that other languages may suit other people and other problems better.
Slashdot Mirror
Even the books are few and far between now. Used to be one or two new ones every month, now its more like 1 every 4-6 months.
After reading many of these posts, I think were getting a bit confused here. In part, the original poster is a bit confused, or at least imprecise in his wording.
When coding a module or piece of program for use in a wider system, such as a library or module, black box thinking is a good thing. In this context, a black box means something that does not expose its internals, and provides an abstraction to the user/programmer.
The STL or the standard c library is a black box. TCPIP and the sockets API is a black box. the java standard class library is a black box. If you were required to know all the interal details of all these systems to be able to use them, you wouldnt get very far.
Abstractions, which is what we are talkign about when we use the term black box as above, are absolutely required to write decent software. You simply cant reliably keep that many details inplay at once and expect to get it to work right.
As useful as the above black box libraries are, it is very possible to create a library that is unusable. Making the user of the library know all the impelentation details from inside is one way to do this, but the other is to use the wrong abstractions, make the wrong assuptions about usage, etc.
In short, what the original poster and many others are complaining about when they say they dont like black boxes is that they are using bad or incompatible boxes!
Having to fight with a library that makes assuptions that are invalid, provides the wrong level of abstraction, or is not implemented very well is not an indictment of black boxes, but of black boxes that suck. The fact that their internals are hidden is not the problem. the fact that their interface to these internals sucks is the problem.
So dont confuse the problems of using bad black boxes with a fundamental problem with black boxes. A bad impelemtation doesnt mean the concept is bad. A poorly designed system well may provide a black box that no one can use, or at least not in all situations. but making that box white, and exposing all its internals, isnt the solution. designing the module to work right is.
Further, one persons perfect abstraction is anothers miserable pile of junk. Just because the black box doesnt provide the interface you need/want doesnt mean it sucks, it could just mean your using the wrong tool for the job. Complaining about how hard threads make it to hammer in a screw doesnt make much sense. Use a nail.
do you know why people dont build buildings and let them fall down, and then do it again, and fix a few things they saw, and then try again, and again, and again? Its because its time consuming and expensive. And we've been building things that fell down and learning from them for centuries.
Know why that doesnt happen as much with software? Because for most of the cases, its cheaper to just build the thing and test it in isolation and watch it fall down a million times than it is to try to engineer it the way a 747 is. I cant keep making planes and watching the crash, get a clean copy out of a drawer, and make a few fixes to it. That would be insanely expensive. But I can do that 100 times a day on a piece of software, for a whole hell of a lot chaper than I can engineer it.
This crap about 'software being immature' is nonsense. No, its not like structural engineering. It doesnt have to be. Creating software is different than creating buildings, and using the models we have for building real things doesnt nescessarily apply to building virutal things. the economics are all backwards. Software doesnt need to grow up into one of the other engineering disciplines. it needs to figure out what it is, and grow up into its own entity. Not a baby Electrical engineering, and not a 2nd gen mechanical engineering.
Software deals with the virtual. Its influnced by completly different forces, economics, and as a result, it will never be exactly like one of the other engineering disciplines. It will be something else completely.
trying to force it into a engineering or factory floor model is doing both a disservice.
You know what I've seen with engineering and related stuff is this.
I started work where I currently am with a bunch of other people from my school, many of which are still here. What I've seen is that most of these guys are still working with the same skill set they joined the company with, and havent gotten better or more well rounded or better read or skilled because they stopped studying the day they graduated.
So for these guys, they have a problem. The new guys come out of school, cheaper and better than they are, for one simple reason. These 'old' guys have been sitting on their rear ends the entire time they have been here, and not gotten one bit better at what they do.
So they are looking for management positions and other jobs where they wont be in competition with the new guys, because they don't really care about being able to program well. They have gotten comforatble, can spend their time with their families, kids, hobbies, and put no effort in to learning new stuff.
Because these positions, the management and leadership roles are not driven by the knowledge and understanding of their participiants, but who they know, and their social skills.
If any of these guys had put just a few hours a week into studying their area of interest, and just a few hours a week working with the new technologies, reading journals, books, etc, these new guys wouldn't stand a chance against them.
Instead they spend every spare momemnt watching football, basketball, or NASCAR, and then they have the nerve to complain about the new guys knowing more than them. What the heck did they expect? that the world would stand still and give them a free ride because they made it through college?
In most other engineering areas, other than software, this also happens, but much slower. In software, all it takes if 5 years of not learning anything to be completely obsolete. Of course they loose their jobs after awhile, they got expensive, and dont provide anything of value for that money that cant be gotten from a cheaper person.
If they had spent their time better and had kept studying after they graduated, they would be head and sholders above new graduates, and the company would not think it made sense to get rid of them quite as easily.
-glo
It's hard, and most likely not possible, to get oss software to be usable. And for a very good reason.
Much of the very important things in oss are very good solutions to very complicated problems. apache, linux, gcc, etc. Ive only ever seen one way to make a complex thing simple and that is to make lots of assumptions about how the program will be used, and to take away options.
Take IIS and compare it with Apache. Its easier to set up, and simpler to configure, but its damned near impossible to get it to do some of the things apache will do. Why is this? because iis is designed to be easier to use. Many of the parameters that apache exposes could have been exposed to iis, but that would have been complicated. So to fix the problem, we make some assumptions about how it will be used, and don't let the user change things.
This is true of other things, like MS Access. Database's can be very complicated. Access Db's are usually not. Why? many assumptions are made about how you are going to use it. If you try to put a datamodel behind an access app that doesnt corespond to the one ms had in mind, you will be writing lots of code to make it work. Its possible, but its a bitch. They have made assumptions, and taken away control, but that is in fact what made it easy to use.
The people that write OSS are, as we almost all agree, usually writing something for them, but in any decent sized project, there are lots of developers involved. So we have a piece of software that is trying to scratch the itch of many different developers. This HAS to make it complicated. Everyone wants something different added to it. The only way to make it work for everyone who is working on it is to make it complicated, to not hide the complication, and not make assumptions about how its used.
And as soon as you realize that to make the program what everyone wants is to make it complicated, you can not make it easy to use. Its just not possible.
The thing is, they screw up their designs just as often as I do, they build things that don't work well the first time just as often as I do, and they release stuff that doesnt do what the customer wants just as often as I do. And the outside companies we work with are worse.
It's a complete falacy that more mature engineering disciplines are able to some how make things that work all the time, right up front. I heard this in school long ago, and with out any experience I took it as true. After just a few years of working with hardware engineers, I found it was complete crap.
The crux of the issue is this. Building hardware is complicated. Building software is complicated. Building anything with a couple of hundred thousands parts in it is very hard. To do it right takes talented and motivated people, lots of time, and lots of money. Things need to be well organized, well planned, and well executed.
I've seen a few people on this story post that many traditionally engineered things that people hold up as being examples of how to do it right, such as bridges, are much simpler than software. That is very true. Most circuts that our EE's build here, lets say they had 50000 things in them. thats quite a lot. but look at the things. the things that make up a circut are all very simple. one input, one output, performs a very simple operation. Its actually alot less complicated that a big piece of software. Write a program with 50000 addition, subtraction, and boolean logic statements in it, and you'll find youve got a very simple program. Take a look at an assembly dump for a simple hello world program, and your find that many thigns.
Invariably, when someone says that engineering works with less complicated things than software, someone always trots out a 747 or a space shuttle by way of a counter example. Its true, these things are well engineered, work right, and are insanely complicated.
They also took many (10-12?) years to go from idea to working tool, and took billions of dollars to make. Find me a software consumer willing to sit around for more than a year, and I'll be excited. Find me someone that doesnt think 600K for piece of software is insanly expensive and I'll be just as excited. The space shuttle software is often taken as an example of what could be done with good software enginnering, but they dont realize that the documentation budget for the space shuttle software is larger than many software companies entire revenue stream. The space shuttle's software teams customers are people that understand that if the software isnt done right, people and billions of dollars worth of stuff will be destroyed. You know what that means, they have the staff, budget, and time to do things right.
You cant compare things like the space shuttle to a 6mo project to make data entry program. Dont even bother. And dont think that the problems you have in a 6mo data entry project can in any way be solved by tools designed and proven to work on the space shuttle.
People have come to expect good software very quickly and for cheap. That comes with some problems, and its very hard to combat those problems. The programmers are often very poorly trained, the budget is tight, and the software is a moving target. I have yet to see a program I started to work on not change substantiatly from the time I started till the end. Spending 2 mo at the beginning designing things to the level of a 747 is stupid, because by the time the item gets out the door, it will have changed from a plane to a boat. that 2 mo was wasted.
Yea, but its an interpreted document, and the interpretations were selected by councils, popes, etc.
When/who wrote it is less important than the uses it was put to, and the interpretations it inspired, and that was done by the church.
A complete record of all their changes of opinion, selective enforcement of canon law, and their political intrigues would make for very interesting reading.
Theres probably 2000 years of history in that library, all of it important, and all of it affecting the modern church. There's much more in there than just early copies of the New Testament gospels, and while important, the gospels are not the only thing that influenced, informed, and motivated the early church and early Europe.
Europe and the rest of the western hemisphere by extension owe their existence to the church, and as such, their history is really the history of the west. Keeping it locked up in the basement of the Vatican is not where this should be.
have any of you ever been to japan? the idea of privacy is silly. they never had any, what would they be giving away exactly?
Lets be honest here. Using comments as a crutch to prevent you from having to figure out what what the program does is destined to fail.
Comments are not compiled. They do not affect the outcome of the program. If you want to know what the code does, even in the presence of comments, you have to look at the code. Comments can be out of date, misleading, and just plain wrong.
There is no substitute for just reading the code, and learning to understand what it means.
Even in a beautifully commented piece of code, you will still have to go back to the code, to confirm what its doing.
Just try to remember. Comments arent compiled. They are not the code. If you want to know what the code does, you have to read the damned code.
That being said, the comments that are most likely to have an impact on others is comments not about the code, but about intentions. Its pretty easy to convert your intentions in to code, but alot harder to convert your code back in to what you were trying to do.
The code tells me what you did, but not why. And comments that talk about why you are doing something, and why you chose this path, are less likely to be wrong, missleading, or out of sync.
If you know what you are doing, you can look at uncommented code and figure out what its doing, but not why. Why is whats important.
Coding is a kind of compression. It takes the verbose ideas that you and your team have been tossing around for a while, and convertes them in to something quite sparse for the compiler. If I look at your code, I might be able to reconstruct your ideas and intentions, but its not likely. Thats what I need added to the code.
-
So, if your Bill Gates, and onthe stand trying to tell the judge your company isnt an abusive monopoly, would you think its a good idea to start shaking down schools for money? Is that a good way to make your point?
the users wont see it that way, they will simply wonder why their new browser is broken and wont view their favorite sites.
Am i the only one here that went to school and had a bunch of dumb xterminal machines to work on, all slaved off a few servers in the back room?
Pretty close to the definition of a thin client, if im not mistaken. An old technology to be sure, but it works, is proven, and doesnt cost that much.
Every thing old is new again. Go from thin client to desktop back to thin clients agian.
What is OOP? Its a way of abstracting a problem in to something simpler that is easier to work with.
What is mathematics? Its a way of abstracting a problem into something simpler that is easier to work with.
Rather than work with the actual quantities of things in question, we can abstract them to numbers. Rather than work with actual processes and physical things, we can work with mathematical representations of these things, equations and procedures.
This is very similar to what oop does. Rather than work with piles of unabstracted data, we work with abstracted data in the form of objects.
But if the problem you are trying to solve has already been abstracted after years of work in to a nice set of equations and processes, whats the benefit to abstracting it further? The math is already an abstraction, and a good one at that.
So in this type of problem, the most natural abstraction is already there, the math, and can be used directly in a non oop way. adding an unnatural layer of abstration overtop of that one will likely just make things more work.
Thats not to say that the overall structure of the program cant be improved by the abstraction and orginization that OOP can bring to the table, but the actual calculations, the math, is already a huge level of abstraction over the real entity anyway. Why add more to it?
if you need comments to know what:
for (i = 0; i array_size; i++)
free(array[i]);
free(array);
does, I dont want you messing with my software.
dont say what you do, say why you do it, and why you didnt do something else. That I cant get from the code. what it does, is quite clear in most cases. if not, rewrite it so it is.
It can also happen because what you read is nonsense. Its not safe to assume everyone knows everyting about software development, and that you are reading the wisdom of the sages. Its possible that the code your working on is full of years of wisdom. But Its also possible that its full of years of nasty hacks done as quickly as possible. Its possible that after years of this, you cant fix it any more, cause every thing you do will break N unknown parts of the code.
Its possible that it was written by people that didnt know what they were doing. Its possible that the 'changes' you are to make would in effect make it a different application.
Its possible that the wisdom you are seeing, these bug fixes, would all have been unnescessary if the design or core implementation were different.
So dont, please, make the blanket statement that old code is good. It is quite lilkely, as likely that its good, that its complete crap, and needs redone to have any chance of getting it to do what its going to need in the future.
You cant just keep fixing something. Your clients wanted an airplane. They couldnt afford one. they bought a car. Theve been paying you for years to slowly graft propellers and wings to the car. Now, they realize they really need a boat. But, being cheap, and following this guys idea, they dont want to just redoit, they want you do tie pontoons to the car.
Never did anyone ever ask if you could actually convert a car to an airplane, or the result to a boat. What you end up with is a car that cant turn, a plane that cant fly, and a boat that will sink faster than a brick.
Fix bugs, sure, add a few features, sure. but when what you want to do ceases to be possible with the base yove got, youve got to leave it behind.
Also, this model of never rewrite, assumes that you always have the best people working on it, and that they all know everything, and that the world of software development never changes. Sure, I could fix the code that the inexperienced co-op down the hall wrote, and make it do something else, but I know much more than him, know better tools, better designs, better implemetataion strategies. So I could either spend a week fixing this crap, or I could just redoit with the right design, the right tools, and the right implementation, and not only be done sooner, but have a much better product.
As another poster said, there is often good information in a piece of code thats been worked on for years. There are also crumbs of attempts in the past that went no where. And stuff that doesnt work, but you dont know it, cause its never been used until you made that last little fix. It can also be full of dumb ideas, bad implementations, and simple old ideas that dont work anymore.
So, if your a wank that doesnt know anything, and your given code written by someone that knows what they are doing, read it. youll learn something. If in stead, your a good programer, and given something written by someone with exactly 3 hours of experience programming, it may be much easier to just rewrite it, rather than try to fix it.
or even if not easier, much better, and in the long run, more supportable. much small, tight, well thought out unix code is still being run, because it was done well first, with out regards to getting it out the door. Old dos and win31 code that was pounded out the door as quick as possible was thrown away years ago.
-sbos
-glo
comments wont improve a bad design, inexperienced design or poor implementation. Nor make crap smell better.
Rewriting might.
I spent all morning decompiling and reading through this thing, to see what it does. the wave file that it attaches to the email is actually an executable, named readme.exe, that contains the package. Its rather nasty. It also messes around with windows resources, and explicitly looks for winzip. Its rather big, so I havent gotten the entire thing understood just yet, but from all Ive tracked out of it so far, it messes with nt lanmanager security settings, explorere settings, and mail settings, as well as mangeling certain files.
And I wasnt kidding about it messing around with resource bundles on the end of windows executables. I havent figured out what its attacheing there, but something is definitely doing it.
And earlier posts were right about the attacking of codered rooted boxes. it also gets other misconfigured iis setups that allow access to cmd some how.
Whats nasty is that since it can come in over email, it got behind the corporate firewall this morning. and since inside most people hadnt bothered to keep their iis servers pathched and secured. So even though we were safe from code red, this one got in and starting mangeling servers.
Think of it this way. We can produce software with out management help. They can't produce software with out us. This means that while they may have the responsiblity and authority over a project, they have no power.
You can take this two ways. You can recognize that you are responsible for something you have no control over, and you can do everything in your power to help those that do have control over it complete their task.
The second way is to find some other way to regain control over those that will be doing the work.
Ive seen several innovative ways to do this. One is the basic use of fear. If you make people think that they can be fired at any moment, then they will do what ever is nescessary to stay around.
Obviously, this has less of an effect when you are in a booming IT economy and the fired can find a new job before they get escorted out.
One other way is through guilt. Do it for the team kind of crap. Making you feel that it is somehow your fault that you cant meet ridiculous deadlines, etc.
Obviously, this has its limites to. to be a good developer usually requires some smarts, and its not long before you realize that this is a bunch of crap. You refuse to take blame for things that arent your problem.
I've seen the company I work for refuse to hire someone that was very confident. Those that are confident are less likely to be pushed around by management. You cant use fear or guilt on someone that is both good at what they do, smart, and knows it. They know that its not their fault sales sold something that was undoable. They know they can do the work, and they know you cant.
Which leads me to my point. Lots of young and foreign workers are more likely to be less confident in their abilities, less confident of their position, and easier to manipulate.
If your ability to stay in this country is predicated on your not pissing of your boss (if you quit or are fired, you often have to restart the visa process, etc...), you are more likely than not to do what your told. If you are just out of school, and think your lack of experience will keep you from other jobs, you will be more likely to do what you are told. The young workers also dont know anybetter. they dont know that its unacceptable to be asked to work 80 hrs. And the young are very fresh out of a very authority driven world of teachers, parents, and administrators. It takes a while to realize that authority doesnt nescessarily mean anything.
So, as a result, Its easier for management to bully young guys out of school and foreign workers. One group is bullyable for only a short time, untill they get some experience, and some credentials, and some skills, and realizes that they have a lot more power than they think they do.
Foreign workers are much better in this regard, as they can be bullied for much longer.
So it doesnt come as a big surprise to me that companies would want to glut the market with cheap, easily controlable work force.
Also, how many of us have heard in software engineering that it is bad to have super hero programmers that do it all. We're told its much better to have a bunch of mediocre programmers. There is obviously some truth to the idea that having one programmer is riskier than many, and having several spreads out the risk, but it also spreads out the control. if 10 people have all the control in the company, then it is easier for each one of them as individuals to think that they aren't that important. if none of them think they have control of the company, they are easier to control. but with just one guy, its a lot harder to control him, becuase unless he's really dumb, he knows he had everone by the short hairs.
What makes you think there are 25K linux boxes in there? StarOffice runs on Solaris, and I know they have lots of Sun boxes floating around. And more than a few Windows machines.
sun != linux.
Women were considered sex objects well before tv. And people were being conditioned to be violent well before video games.
I cant argue that its not possible that kids are being conditioned towards violence in this country, but lets be careful about what we say is doing it.
Seems unlikely that recent additions to the american culture (tv and video games) are the cause of problems that have plagued this country for centuries.
-sbos
Do you have 35 million dollars and 200 people to work on the single product that your company has been working on for the last 20 years? Do you have a customer that knows exactly what it wants, in extereme detail? Do you have the problem domain so absolutely understood that you can describe exactly what you want before you even begin to write the program? Does the rest of your company understand that the software is not an addon to the system but a very fundamental and important piece, a piece that rightfully occupies a place of importance equal to the rest of the system. Does your schedule get driven by quality, not contracted deadlines?
What, you dont have that much money? Nor that many people? You mean you have several products? And some are new things that neither you nor anyone else has ever done? You are asked to solve non-trivial unique problems that need interesting solutions developed by you, not a team of experts with PhD's. You mean that you havent been doing the same thing with the same people for 20 years? Your customers dont know what they want? Your customers and management dont let your experience with the problem domain drive schedules, but instead, insist that things be done when they say, not you? Your software is not considered the most important part of the system?
Well, I'm sorry for you. It must suck living in the real world.
this kind of elitest stance will do absolutely no good for linux, open source, or any of the stuff that we seem to hold so dear here on slashdot.
.so hell, in this case), but it takes work, and forethought. hacking together a library just wont do it. unfortunately, the clibrary was written a long time ago, and there is almost no chance of getting it rewritten using better opaque types, and hiding its internal implementation.
The customer is not just a dumb lump that needs to get out of your way. they are what makes your software viable. with out them, your just a lone hacker hiding in your room, writing stuff noone will ever use.
Telling them they just shouldnt use that stuff that wont work with the newest linux glibc is not the answer. providing ways for vendors to provide glibc neutral software is. Having oracle for linux was one of the biggest wins linux has had in a long time, makinng it seem almost viable to the business world.
It is possible to avoid dll hell, (or
But that is the only way to make this problem go away.
I have read more than one post here that says the problem is that you cant write code in C that doesnt encourage tight coupling between application and library.
well it just aint so. opaque types are very easy to produce in C. With these, you can link your applicaion dynamically with its library, and replace the library when ever you want, with no effect at all (as long as the interfaces and semantics of the library is the same). You can add fields, to your hearts content, with almost no penalty, if you pay attention to what your doing, and think things through.
the problem is that the glibc library wasnt written this way, and its way to ugly. it exposes internal structures, which is a very bad thing to do, as we all know. (think objects...)
C++ isnt the only language you can hide implementation details in though.
Just do a google search on opaque types. its possible, and easy, to do in C.
When I first started using Java, my first response was 'great, slow c++'. I know it has some thing that c++ doesnt, but the common ones, such as a nice stdlib of classes and garbage collection, are all available under c++ with a little work.
I figured, if I was going to pay for the overhead of an interpreted lang that was so slow, I better get something more out of it than what java gives you.
So when I started working with Python, and other very high level languages, I was much happier. Sure they are slow, but they do so much for you. Strings, tupels, lists, passing class definitions around as parameters, dynamically constructing your code and relationships, etc... The list goes on and on in these other languages.
The way I see it, for what we pay for java (in tearms of runtime speed, etc) better be offset by what we get, and at least in the beginning, that was nothing.
Dont get me wrong, reflection is a nice thing you cant replicate too well in c++, though you can in other languages. And as the years have gone by, more and more packages and class libraries have been made for java, making it more and more useful.
But lets remember something guys. The tools need to fit your problem. Java isnt the end all, neither is python, c++, ML, or lisp. Each have domains where they work better than the other. Knowing one language is a sure way to commit professional suicide. Would a master cabinet maker get anywhere if all he/she knew how to use was a hammer? of course not. To be a master at your craft, you need to know the tools, the problems, the media, and have lots of tools to choose from.
Not everyone is writing servlets to drive web sites, or just talking to a db. Some people need the speed given by other languages, or the access to the bear metal, or the high level abstractions provided by others.
Trying to point out that your language of choice is the best thing ever to me shows only that you work in a limited domain and dont realize that other languages may suit other people and other problems better.