Do you have any actual real-life anecdotes or something to back this up?
I have had people tell me this and read about it in several places over the years. One that I found in via Google also gives some information - here, the key line is:
It applies both to debugging issues in client code that manifest themselves as collector misbehavior, and to debugging the collector itself.
Emphasis added. I would also point out that the garbage collector itself can cause race conditions to occur differently when you do run software as you have no control over when the GC runs - thereby, the very fact that you have a GC causes code to run differently every time you run, or even every time you go into a function as the GC may or may not have run recently wrt that code In this respect, even for a single threaded program, GCs add the complexity of a multi-threaded programming. That is simply the nature of a GC as you have no guarantee that it will run exactly the same time in exactly the same way between any two runs of the program. (E.g. the GC may run earlier in one instance than the other, thus offsetting every GC run after that even if all other runs occurred identically between the two instances.)
As to some of the remarks that this may be a result of a more exuberant lifestyle : Bullshit.
Then tell me:
How much do you spend on computers each year? New laptop? New desktop? Upgrade memory, hard drive, processor, etc?
Do you have a cell phone? Get a new one? Do you text, surf the web, download ringtones, trade photos with people or use any other data service on it?
How much do you pay for Internet access? Own a domain? Run your own server on a static? Pay a hosting site?
Get a new car lately? Leasing a car?
Get a HDTV? Cable or Satellite TV? Paying for PPV? Got out to the movies? Rent movies? Get a new entertainment system, or upgrade a component to your entertainment system? Go to a sporting event?
Drink alcoholic beverages a lot - at the bar? at home? Smoke cigars, cigarettes? Chew tobacco?
Go out to eat? How about daily lunches during the work week?
What services do you purchase?
Use the credit on your credit card? Or do you only buy things that you have cash to pay for when the bill comes?
What kind of neighborhood are you living in? Could you find someplace cheaper to live?
The list goes on and on. In the end it comes down to - what are you paying for completely up front and what are you are paying for every month (e.g. monthly billed services), and whether or not you can avoid any of them. For example, if you have a static IP you could probably lower your cost of living by letting it go and paying for a cheaper Internet service where you get a dynamically assigned IP - unless of course you are running a business that requires in, in which case what can you do to turn that cost into a 100% business cost that could be written off by the business? If you get Cable or Satellite TV, then you could save by dropping those.
It may not seem like much, but monthly, re-incurring costs no matter how small are a financial death by a thousand cuts as it all adds up. Unfortunately, our culture today encourages spending in that manner. So what could you do to lower your cost of living? There's probably a number of services you subscribe to and pay for monthly that you don't really need (e.g. cable TV), or things you do on a regular basis that could be done more cheaply (e.g. going out to eat, versus cooking it yourself at home; buying pizza or making it yourself from scratch).
My wife & I have been working on this for a while. Sometimes I think she's a bit too strict, and sometimes she thinks I am too. For instance, my policy with our grocery shopping is "if it isn't on the list, we can't get it" - the list is made before we leave for the store. Sometimes we deviate a little (which isn't good), but we do a pretty good job.
In one financial book I have read - don't have the title at the moment - the author did a bit of a study - wrt at least his daily expenses he paid for everything in cash, and perhaps by check otherwise. He observed a 33% reduction in spending as a result. I've heard similar from other sources too. Didn't really change his life style other than changing how he paid for things - it resulted in a bigger change in lifestyle as he was more reluctant to pay for something when seeing the greens live his wallet, thus he ended up saving more.
Cost of living can almost always be reduced - unless you are paying the smallest amounts required to survive - but then, you wouldn't have a computer, you wouldn't have Internet access, you wouldn't have a phone (land or cell), you would be driving a cheap car if you drove at all, and you would be living in or near the slums.
If one of the costs go up, fine - do your business somewhere else that is cheaper, or drop it all together? (e.g. Rent goes up, move. Cell phone service costs go up, drop it or move to another provider that is cheaper.) You have a choice about your lifestyle whether you realize it or not, and you can reduce your costs when you decide to.
It's your responsibility to realise that if you signed up for 40hours a week working hours then that's how many hours you should do. If you're not getting paid why on Earth would you work, this has always been a mystery to me.
Sadly a lot of managers tell people that they have to do overtime if they expect to be promoted; and sadly, even if a manager doesn't say that, there are a lot of people that think that. In either case, a lot of people do overtime in the auspice of getting a promotion and thus move up the ladder.
Personally, I like coding, and I am in no hurry to move up the ladder. Given my personality, it'll happen soon enough any way regardless of what I want - so I'm not going to make it happen faster, and instead enjoy my time coding while I can.
Companies have always towed the "your a professional" line when expecting overtime from employees
My contract states 80 hours every two weeks, and unless the manager signs a special form, overtime is not paid - but also not required by the contract. The company will work like a hawk to make sure I get at least 80 hours in over that two week period. I see no reason why I should be giving them much more than 80 hours a week on average. (Sure, 82 hours is okay...but I'm not going to be working 90 or 100 hours cycles without overtime pay.)
My wife, on the other hand, has a contract that is requires 40 hours a week - though pay periods are only twice a month on specific dates of the month - but also has a certain number of hours (200 hours) of overtime built-in; her contract also guarantees overtime pay if she has move overtime than the contract states (e.g. 201 hours) through the entire year. She also has two seasons in the year of expected overtime, so if they keep her busy, it could be very easy for her to do so.
Point being - the company will keep you to your contract and make sure you fulfill your end of it, so you should keep the company to their contract as well and ensure they keep their end of it. You did agree to the contract, and they don't have the right to change the conditions of the contract without changing the contract, changes which you must also agree to. Additionally, anything that is illegal is not contractually binding.
As far as how a law of such a nature passing might affect contracts - it cannot affect an existing contract without your consent as well. If your contract denies you overtime pay, and the law require they pay you overtime pay, then they have to pay you overtime regardless of the contract as they would otherwise be breaking the law. It will, however, affect new contracts - such as when you change jobs, but even there they cannot break the law; and I doubt a lot of people would accept a pay cut on account of the law change; so, it will basically be to the workers benefits. Companies would also have a problem if they tried to lower wages or lay-off/fire people on account of the change in law.
As always, IANAL, this is just my interpretation and understanding - however accurate or inaccurate it may be. So consult one for good legal advice if you need a real, legal answer.
In some cases using a garbage collecting language can be cheaper than several months of testing.
Not really. It is far cheaper to resolve something during initial implementation than during testing; but it is cheaper to resolve it during testing than after it has been released to production or clients.
There is no substitute for testing, and only dumb program managers cut themselves short on testing. And - FYI - GC makes debugging memory issues a lot harder as you have an inconsistently timed mechanism claiming memory from you. However good the GC may be - the timing differences it can cause can make a huge difference in being able to resolve something easily or not - in fact, whenever you have something that causes timing differences, the difficulty of debugging is magnitudes higher. So, even with a GC you will need to be doing months of testing.
FYI - Open Source Software can get by with shorter testing periods because the testing is spread out among thousands of people. Where as a proprietary firm, like Microsoft - with notably takes a couple months to release a patch due to testing, cannot as they have to do their all of the testing themselves.
Bad software gets out for several reasons - (1) developers don't do the engineering they should have, and (2) management crunches the schedule and doesn't let the developers do the engineering they should have or the testing that should have been done. Obviously, managers do need to manage the time line of a project, and projects need to get out. But you can't short change yourself either. I'd much rather a manager scale back a project to meet the time line than short change the engineering and testing; of course, you can't scale back too much either so this is really where the trade offs come and must be managed between the management and the developers. (Developers need to show the financial and business reasons to management for why to keep something, and should design/plan around being able to expand new features - or delayed features - in in order to help management make the deadlines. It's a two way street.)
The set of all programs that are non-terminating (like an OS) is a subset of the set of all programs. So no, not every program is like an OS. It also does not follow that a program must manage every byte of memory, because OS's deal with resources at a coarser granularity (pages mostly).
Even the OS eventually terminates. I'd still put forth my paradigm works.
Programs really do need to manage their resources
I do not contest the statement that resources must be properly accounted for in any system (as improper accounting is the source of many security vulnerabilities), but I do contest the statement that this accounting must be manual.
Accounting is a part of management. However, management goes further in that it assumes responsibility for allocating and de-allocating resources. Even if that is simply telling the GC that an item is no longer needed so the GC doesn't have to waste as much time with determining that the item can be freed for other uses.
I still propose that no matter how complete the AMM may be, you still need a hybrid AMM/MMM such that the programmer can tell the AMM when something is no longer needed. The AMM may go further and help absolve conflicts between multi-threads, and such - and that is fine. However, the programmer still should have a way to tell it when it is done - perhaps as the programmer I want to release memory half way through a function instead of waiting for the pointer to go out of scope when the function exits.
It is only impossible to entirely eliminate it if the lower levels don't manage their memory properly either.
This implies a stack-based memory hierarchy, in which case automatic region-inference could allocate and deallocate this memory for you even more efficiently than you yourself could. That's a solved problem. Problem is, resource lifecycles are often not stack-based; fortunately, newer region inference techniques are getting good at tackling these issues as well, and I predict that within 5 years we'll have an acceptable automatic region inference technique that will outperform MMM.
No, it doesn't imply a stack-based hierarchy - but a mix of stack and heap which is what most programming languages have. Heap allocations are really what needs to be tracked, and there should be a way for a free() function to determine if a pointer is pointing to something on the stack or the heap. Currently, this is not very doable.
Then you would be wrong. We already know how to build secure software, such that the only attack vectors are social engineering. The problem is that people insist on using insecure languages, such as C/C++, which lead to easily exploitable vulnerabilities, such as buffer overflows. If you use a memory-safe language, you are already immune to buffer overflow attacks. If you then remove "access control lists" as the implicit access control and rely only on memory-safety, then you have now built a capability-secure platform, in which it is easy to reason about the causal effects of any given block of code, and thus, it is easy to design the program to follow the Principle Of Least Authority (POLA).
We know how to write software that is only as secure as the attack vectors that we are aware of. Claiming otherwise is foolishness. We can mitigate how software is affected by unknown attack vectors through Defensive Programming methodology, but even that can only truly protect against known vectors.
Additionally, reliance on a "memory-safe" language does not absolve you from buffer overflow attacks. Such reliance is foolishness - and is no better than security through obscurity. It also provides a fall sense of security. It may help to minimize such risk, but it does not absolve such risk - so please, stop fooling yourself.
Finally, when properly employed - C and C++ can be just as well secured as
There is not a single object in a single OO program that can possibly have the correct responsibility for freeing its memory
EXCEPT a garbage collector.
Dead wrong. It's all a matter of design. If you design a class to handle buffers and assign that class to the responsibility of handing out buffers to objects - which can then be passed around in accordance with the software design - and when done, be passed back to that class then that class can in fact know which buffers are in use and which are not. And in fact, if it has any that are not returned to it, that is a memory leak but a memory leak that can be handled - the buffers can be tracked. However, you have to do proper engineering of the software. You as a computer scientist may not like that, but the reality is that properly engineered software is in fact very solid - regardless of the language you use. But you have to do the work to get it there. If you're not willing to do the work, then don't complain when your application crashes and you can't figure out why.
And any app you wrote or anyone else ever did in C++ has memory leaks.
Hmm...there are quite a few C++ applications out there that do not have memory leaks. And yes - I have written C++ applications with no memory leaks - and provably so. But I have also gone through the work to design it to be so. It's not hard - just takes time, and is not something a code monkey can do. Sadly, this is not something taught in Computer Science - they just tell you go and do it, they don't really teach you how, and they completely leave out the engineering side of software programming. Most students are lucky to get a semester in an abbreviated software engineering course. However, software engineering is really what is required by industry to deliver good software.
Given this comment, I'm pretty sure the only garbage collected language you've used is Java, or perhaps a community language like Python. I assure you that garbage collection is quite efficient in serious languages when compared to manual memory management (see OCaml [debian.org]) if you actually read the GC literature on effective algorithms and not simply assume reference counting or other naive GC scheme is clearly optimal; more importantly, automatic memory management is much safer since there are no leaks.
Define a memory leak.
To most, a memory leak is simply when a pointer to memory is lost. This is something GC can theoretically solve. But is that truely a memory leak?
I propose that that is really the symptom of a memory leak, and that a memory leak is truly maintaining memory beyond when it is needed. This is something a GC cannot solve, as you may still have a valid pointer pointing to the memory still in scope even when the memory is no longer needed.
How does this differ? Consider a single function that allocates some memory, makes use of it, and then goes on to do something else that doesn't require the memory; the pointer to the memory is in scope throughout the entire life of the function. According to the "normal" view of a memory leak, there would be no memory leak in this function unless the memory was not freed before the end of the function - or a GC would clean it up shortly after the function leaves scope. However, according to my proposed definition, even if you waited until the end of the function and then cleaned up all your memory, it would still be a memory leak as you kept the memory around longer than you needed.
Now perhaps in a normal desktop environment the difference is not a big deal. However, it would be a big deal in an embedded or OS kernel environment, or any other environment where either performance or memory utilization needed to be maximized (e.g. a program that performed tasks that utilized gobs and gobs of memory and needed all the memory it could get).
This what I call "The Grand Misconception". C/C++ does not "force" you to manage resources at all. In fact, the complete lack of this forcing is the result of most bugs with C/C++ programs: leaks, buffer overflows, etc.
I wouldn't necessarily call it the "Grand Misconception". And if you read my other posts in this thread you would notice that my view does not adhere that as a misconception at all - rather, it takes that into account as being the mechanism by which the program is forced to do their resource management.
Honestly, OS's have to manage their resources - file systems, memory, processor time, and all kinds of stuff - and in reality, every program is in effect a small operating system dedicated to a single task, the task of what the program is trying to achieve, that is built on top of other operating systems - e.g. standing on the shoulders of giants. Programs really do need to manage their resources, which in most cases is just memory and UI resources, and sometimes involves files and devices too; often some of this can be left to the host operating system, however, anything that causes the program to fail forces the programmer to fix it - thus memory management is required for any program. GC's allow a programmer to be lazy by not doing this; languages like C and C++ - Pascal, Ada, and many others even - force programmers to manage their memory or risk crashing due to memory leaks (" normal" definition memory leaks).
Now may be you don't agree - that's fine. However, we should all strive to be better programmers, and learning how to manage our resources is one step along the way - a necessary step at that.
which are generally funtional, but where leaks and security holes are prevalent and likely impossible to entirely eliminate.
It is only impossible to entirely eliminate it if the lower levels do
Except that it can't. The programmer could be wrong or purposefully lying, and in fact still have a reference to this object. This, then, breaks type safety and might allow arbitrary code execution flaws...Yes it does. Not having any references to the object in any live object means that the memory it used may be reused after the next garbage collection cycle, which occurs automatically when free memory in the heap runs out.
Yes it can. Simply providing the programmer a way to remove that reference counter would do it. As it stands, languages like Java provide no functionality to do so. Whatever the method is, it must match the algorithm used by the GC to do the garbage collecting.
Additionally, the programmer can be wrong - that's the programmer's prerogative, and the system should detect and handle that appropriately - but the tool to do so is still necessary in order to deliver true performance applications. In fact, there is a whole methodology of programming that can handle that mistake - Defensive Programming.
And, to know, one of my issues with the C library is the lack of the ability to hand it a pointer and say "is this valid?" and " is this at least this size?" as that would go a long ways in Defensive Programming. The first question answers whether the pointer is valid - i.e. directly returned from a call to malloc() or from a buffer within one directly returned from a call to malloc() - and the second question answers the size of buffer and if there is enough space to so something. This could be easily tracked, though it would add a little overhead, and would be of great use in Defensive Programming technique.
There is always going to be some way that the programmer will be able to be wrong. However, that can only be countered by the programmer having the right tools to detect when that occurs and handle it appropriately. GC is not necessarily one of those tools.
You know everything you said would be true, IF our job was to squeeze the last bit of performance from a machine. But it's not. Our job is to enable the user. A programmer focusing on low level bit shifts, memory storage, string management, etc, takes his eyes off the truly "big picture" and that's the domain you are focusing on and the "business" problems there in.
Our users want results that provide them with real value, if performance is part of that value then so be it. Use the proper tools for the job.
Our job is to provide them with programs that work and function as expected and within a user-perceivable performance speck. Users have a perception of performance - and if that perception does not match what they want, then your program is in trouble, however hard that perception may be to achieve.
As another commentor points out, it is very true that performance does matter. Servers software must be very responsive and server admins care very much about the user perception of their server's performance, and the perceptive performance of the services they render.
However, while more tolerable on the user's desktop - it is still very important. User's don't like sitting around waiting for an application to become ready to use, or for an application to play catch up. That costs time, and for businesses that costs money. Simple things such as managing resources can often reduce that wait period to something more tolerable that isn't so costly but only when the programmer deploys such tactics and uses a language (GC'd or not) that allows them to do so.
Ever have a user complain that your program didn't respond fast enough? One good example for you - in one network I am on, there is no reverse-DNS lookups and some other network basics are not provided, this results in some programs not responding (both IE and FF) for up to 5 minutes if I accidentally type in a bad URL. This results in a user perceived performance issue with the application (my first thought, until I could show that the same problem did not exist on another network with the same machine) as the application locked up - user interface was not usable, and would not be repainted, etc. while the software waited. Now IE and FF could mitigate this by pushing that DNS lookup into a worker thread. While this is one example of an external issue affecting internals to a software program, the basis behind the issue - user perceived performance problem - extends quite far.
Few other examples - How often have you waited on MS Outlook to catch up with you? How often have to waited for MS Word to compete a task - that you didn't start - so that you could continue working on the document? How often have you worked on a document and had the computer stop responding to you while it finishes something else? How often have you upgraded Windows or Office to a newer version and end up having to upgrade the PC even though you didn't do anything different, and were not using any new features?
A Pentium 75 with 32 MB RAM should be sufficient to do basic email; however, try to do it with most programs these days and the system will feel like it was bogged down, even though you could do that and run Office, and more when it came out back around 1995.
Performance is a big thing, and the perception of performance is even bigger.
If you use a garbage collector, you're deciding that it's worth a small performance penalty and a memory footprint that's slightly higher than optimal, and in exchange having vastly fewer memory leaks than is otherwise likely.
Oh? A number of companies in recent years have been forced to switch programming efforts to Java due to only being able to get programmers that knew Java due to colleges & universities only training students in Java, or starting off students in Java, which then makes it harder for them to transfer to some other languages as some of the basics must be entirely retaught. (I've seen this; and I've heard complaints about it too.)
And then you sometimes have a manager or client saying "this will be done in Java" because its what they want for some reason. Then you as the programmer are forced to use Java and may be unable to change their minds despite the downside of not being able to manage your memory, when you normally would.
There are certainly reasons why people use things that go beyond the choice of choosing a GC. They may not have opted to for that higher memory footprint, or performance penalty, but were at the hands of someone else that didn't know any better and were unable to convince them otherwise.
Your other points are of very true, and often overlooked by the GC-supportive crowd and Java supporters.
Still, I'd rather work with a garbage collector than without. I can be clever and use those techniques to reduce the work that the collector has to do, but if I screw up -- and no matter how good I am, I will; and when I do, it's going to be damned hard to find -- the garbage collector will take care of that.
I wouldn't say its "damned hard to find". I've done it in the past by having a small stack tracer I could use and turn on and off. I would use for debugging, and turn it off (removed from the compiled code) for production. But all it did was tell me where my memory leaks were. Worked pretty well, and the program it was used in was very solid. The only leaks I couldn't remove were OS API based. Additionally, it was very easy and quick to locate leaks on account of it.
Actually, the big language culprits would be those with auto-garbage collection, etc. as they tend to have lazier programmers that don't "need" to manage their own resources,
People keep saying this. I wonder if it's true -- I haven't seen any evidence of it. I've seen lazy/stupid programmers in all kinds of languages. Wouldn't the same argument work just as well against memory protection, and preemptive multitasking, and compilers?
Perhaps it is because by having a GC, it encourages the programmer to ignore managing their resources - thus they become more lazy than they would have otherwise. There are certainly lazy/stupid programmers in all kinds of manners, but resource management shouldn't be one of them, and we shouldn't be putting "features" into languages to mitigate the failures of the lower eschelons of its programmers, especially if those "features" may increase they number of that lower eschelon.
A lot can be learned about programming by managing ones resources, and the programs will get better for it too.
and in some cases even prohibit the programmer from being able to manage their resources.
That's a problem with your specific GC, not a problem with GC. JWZ even ranted about this. You hear Java users complaining about memory, and Java programmers bitching about the GC, but you never hear Lisp programmers bitching about their GC. Any production Lisp GC gives the programmer far more control than Java's does. Hearing people rant against GC is like hearing Yugo owners rant that automobiles suck.
I'll give you that - and perhaps a good solution is to have the ability for the programmer do specify it even with the GC being there. However, at least for Java - there is nothing in the language itself that enables a Java programmer to even tell the GC that the memory block is available for de-allocation, the GC just has to guess and eat a lot of overhead to do it.
As for Lisp programmers, they are few and are usually Lisp programmers by choice. I know I certainly wouldn't punish myself with Lisp. (Yes, I've programmed in Lisp before.)
C/C++ and similar languages, on the other hand, force the programmers to manage their resources.
No, they don't. How would they? If I forget to free something and it goes out of scope, bang, memory leak. How am I forced to do anything about that by the language? (I've heard more than one story about somebody who learned Java, and then went back to writing C++, and wrote many lines of code before remembering that their C++, while correct, leaked left-and-right.)
You're forced to by the program not running for the required amount of time. If the program doesn't function, and crashes you'll have to track it down and fix it. You can make that easy on yourself, or hard on yourself depending on your approach; but having some algorithm follow you around and try to guess when you are no longer using a chunk of memory is not a solution - it's laziness.
To make it easy on yourself, you'd design the program to have entities that would be responsible for the memory - both for its allocation and de-allocation. I've done this. It works, and no GC is required either.
Moreover, I have written programs that stay up for a long time, and are good about their resources. And I'm done programs where I had to import legacy code that wasn't good and added such capabilities to them too so that they became good and solid - in the end, those programs were more solid than the OS, as the OS they were on was more likely to be rebooted before they would reach any kind of level that would be an issue.
I am not sure where you think C++ Programmers are more careful the Other Higher language programmers.
It's not that they are more careful - but to write a successful large program in C or C++, you have to manage your resources. If you don't - then the OS will kill the process as you will SEG Fault/etc. So, unless you are only writing small programs - like for a typical high school or college level class project - you have to manage your memory. (Even then, you have to to some degree.)
A lot of C++ Programmers are really not that good the only reason they use C++ because they had to take it part of their college requirements, thus being the only language they know.
The only reason a lot of folks use Java is because they learned it in college. Doesn't make them good programmers. Some vo-tech schools only teach.Net - VB before that - and the same thing resulted. This can be said about nearly any language. The trick is in the student that is able to learn multiple languages and take steps beyond that - otherwise, they'll never be a really good programmer. (I usually recommend people to learn at least three languages - a C family language, a Basic family language, and a Modulus family language - as well as some scripting languages. This puts them in different enough programming environments, with languages that are different enough from each other that it really does force some learning that goes above and beyond a single language.)
Problem with C++ is the fact programming memory is so intensive that most people will be willing to let it leak because of all the extra work it will take to clean it up.
You can say that about any language really. The problems might change a little bit, but the base problems are still there. Java programs end up as memory hogs because you can't manage your memory - it's left to the GC - and many programmers write in Java because it is all they learned in college; and regardless of whether or not they want to lower the memory by managing it, Java doesn't provide the tools to do so.
That may not be the case for all GC languages, but it is the case of what is perhaps the most prominent GC language - Java, which also has had the unfortunate aspect of being forced on a lot of companies because the programmers they could hire out of college didn't know any other language. (Sad reflection on the colleges and universities they came out of too - but that is also partly due to vo-tech colleges as well, where training is typically limited to the quick & dirty.)
The thing that usually gets me like comments like this parent it assumes a completely Academic Computer Science approach to all problems. While real life requires making trade offs and sacrificing performance is often a good trade off to make because most of the time it is unnoticeable, most computers spend most of their time idle anyways, and most application are idle waiting for inputs.
In no way was I assuming a quot;completely Academic Computer Science approach to all problems" - in fact, a lot of Academic Computer Science is strongly behind the GC languages and not teaching students how to manage resources.
What I am talking about is doing proper engineering of software - proper design, architecture, and implementation - such that the resources are managed in the program appropriately. It really is not a hard job to do, and when done - it can speed up implementation and debugging as it all works towards it in the end.
By doing the rag-tag job that Academic Computer Science pushes, debugging will be long and hellish, and will only add to cost over-run.
Additionally, I am primarily pushing management of resources in this thread, including memory. When it comes to performance, then yes - you need to run a profiler and optimize the program accordingly and not spend all your time on optimizing every line of code throughout the entire program.
Are you trying to argue that it's a bad thing that you can't leave dangling pointers in Java ?
No, I'm saying that it should be possible for the programmer to, at the very least, tell the GC that memory chunk X is no longer needed, so the GC knows 100% for sure that it can de-allocate that memory. Sure, it'd make the GC a bit more complex, but it would also help out with managing resources - for efficient programs, a programmer must be able to say "I don't need this memory any more, please take it back, and let me use it elsewhere, for other things, in the program". Java doesn't provide that.
Are there really any memory problems that cannot be cured by strict adherance to the rule of "allocate memory at the beginging of a routine, deallocate same amount at the end"?
This would be better states as: "allocate memory when needed and dellocate when no longer required" - memory allocations/dellocations do not always occur in the same routine, and this only gets worse in OO programming. However, garbage-collection does not resolve the issue either. The real answer is smart design and smart programming - and by smart programming I am not talking about garbage-collectors, etc. done for the programmer, I am talking about programmers programming smartly so that their programs manage their resources properly and efficiently.
Which brings my second point - even with your original version, this cannot always be done in some languages as some languages remove the ability to free resources. For example, so far as I am aware - and so far as I can tell - Java cannot free memory resources outside of the garbage collector. So much for a programmer being able to manage their resources properly - this is probably also one of the big reasons Java sucks at performance.
Perhaps the culprit is C++. Languages with auto-garbage-collection or are database-engine-based tend to clean up automatically or cache to disk more effectively.
Actually, the big language culprits would be those with auto-garbage collection, etc. as they tend to have lazier programmers that don't "need" to manage their own resources, and in some cases even prohibit the programmer from being able to manage their resources.
C/C++ and similar languages, on the other hand, force the programmers to manage their resources. In those cases, the programmers would likely be just not designing their programs well, or employing bad resource management. Yes, managing resources can be hard - one project I worked on had to go through several months of testing to get the resources properly managed, and even then some of the resources were still a little uncontrollable due to legacy code or Windows APIs, but overall the thing was pretty stable and any memory leaks were mostly due to Windows APIs.
In either case, I can't tell you how many times I have heard (especially from Java programmers) something along the lines of the following: "RAM is cheap", "processors are getting faster", "computers will be ready for this when we deliver it", "hardware is cheaper than programmers"
No offense, but to rely on hardware always being getting faster, or the cost of adding more RAM always being cheaper, etc. is a bad premise to rely on. Already with multi-core processors we are seeing slower processors being combined into a single processor get the equivalent processing power of a faster processor (e.g. two 1.8 Ghz cores rated equally to a single 3 Ghz core); thus the premise breaks down. Also, I want to be able to do more with the faster processors and additional RAM, rather than simply do the same job I could do yesterday only in "better" software.
The real answer is doing your job right, and using the right tool - which is not necessarily the easiest tool to use either. We also need to get back to writing applications that have good, if not great, performance with minimal resource requirements (e.g. RAM and processor). If we're not going this at the API/library level - at the very least - then the programs and library/APIs that rely on that API/library level will have worse performance no matter what they do. But in either case it doesn't get done unless the programmers do their job, and use tools that allow them to do it.
But it probably won't be cheaper. It's already very cheap.
But obviously it's not cheap enough for some people - like myself. I'm not interested in paying $50/month for cable TV, and I'm really not interested in paying $18/month for basic, local only service, though it is low enough that I do sometimes consider it - since I only get 2 OTA where I am. My choices from my local cat-TV provider:
Limited service - all local channels only, e.g. what should be OTA, and a couple others, total 24 channels - $17.16
Value service - e.g. standard Basic cable, total 79 channels - $56.20
Digital Service - e.g. Value, PPV, Music, some premium movie channels and a few others, total 180 channels - $74.15
HD Service - Basically, Digital + HD versions of some of the channels, not sure how many channels though - $80.56
Extra for other stuff - like HBO, Cinimax, Show Time, HD etc.
FYI - those prices do not include equipment, nor do they include HD channels. There are only about 5 or 6 spanish channels and in the Digital Service at that. Also, a DVR is $9.95/month; so a non-DVR box would be cheaper, likely $3 to $5 - I can't find any other price than the DVR price and am not going to call in just to find out for this post.
Now, granted - an a la carte would likely make each of those channels more expensive if you simply divided out the cost over the number of channels. However, different channels have different costs for them. EPSN might charge $24/month, while some random, unknown channel might charge $0.02/month. If an a la carte were to be truly offered, then the customer (not consumer!) would actually see these differences in price. So, whether or not it would be cheaper for the customer or not would be up to the customer as the customer could chose what channels to include, and thus directly affect their cost.
Sure, they may right now be getting ESPN for $0.72 (average price for the value package - $56.20/79) - or $0.42 if they are getting the 'Digital' package', and might have to pay $24 in a la carte pricing - that's why I said they could continue using their existing pricing - let the customer chose which pricing model they want.
(more on this below)
I know that if I was able to get an a la carte, then I certainly wouldn't be paying $56.20 for the service.
Also, realize - I don't want the other channels that I am not watching - even to the point of deprogramming them. And I don't necessarily want to support something financially (e.g. paying for) if I don't support it or want it. I'd like control of where my money goes and what my money supports. (E.g. I don't want to support MTV, VH-1, or the World Wide Shopping Channel (to name a few), but under the current system I wouldn't have a choice if I got cable TV).
Current prices: $23/month ($11 just to have the cable activeated in your house, includes channels 2-22 (broadcast channels + local edu/gov chnls, etc) + $9 equipment rental + $4 for the channels) New estimated prices: $21.60 ($11 access + $9 equipment + $1.60 channel)
Your price comparison is faulty as (a) my cable provider's limited and value services don't need extra equipment (e.g. no equipment rental), and (b) even when it does require equipment, the equipment is not included in the price.
So, if the customer choses a channel that requires the equipment, then they would have to get the equipment. If not, they won't have to. Either way, for comparisons sake, the equipment doesn't need to be factored into the price because it would be factored in the same way either way - if and only if you get service that requires the equipment, whether it is a package or (for a la carte style) a specific channel.
Still, to use your numbers - say I only want local (base price) plus 5 channels at $1.60 each - that would be $11 + $8, total $19, for a total of about 29 channels, yielding a cost of $0.65
Maybe what's actually needed is an accurate way to gauge what people are watching. Throw everything out there and bill for the channels that are actually watched. It might be a little more per channel, but it would definitely drive competition for better shows.
But then what would Conan O'Brien do those sketches where he surfs the channels for all the bad shows???
I guess what it all comes down to me is: It's a lot of fuss about something that isn't a big deal, and it's just as likely (if not more likely) to hurt the consumer as it is to help them, except in fringe cases.
I don't agree. I currently do not purchase cable TV (only cable Internet) because of the price. I don't consider the high cost to be worth it. However, there are a number of cable TV channels I would be interested in getting if the price were right - an a la carte would let me do that.
For example, I don't watch sports, so ESPN or any other sport channel would automatically be off - and when I have had cable TV in the past (since it was cheaper than simply having cable Internet) I deprogrammed ESPN and the likes so I wouldn't have to surf over them - however, channels like Cartoon Network, the Anime Channel, SCI-Fi, etc. would be of high interest to me.
Perhaps the real solution is a combination of choices. Have the current package set there offered as a "discount" package - e.g. for buying all together in bulk of these we'll give you a reduced price, kind of like volume pricing - or you can pay this low fee of $10/month for basic service (local channels) and then pay for each channel or set of channels for a small fee in addition to that. So, you may pay $.50 for the Anime Channel, or $1.25 for Anime, Cartoon Network, Nickelodeon as a "Cartoon" package, etc. If a content provider wanted to require all their channels be provided together - or none at all - (as some have claimed above Discovery Networks), then they would just be a like the "Cartoon" package and set the price for the package.
Let the customer have a choice.
This would not only increase their market penetration - as people like me might then become customers - but would also (a) allow the groups that would like to have the 400+ channels to have a "reasonable" price, and (b) allow the individuals (or small family homes - e.g. my wife & I) to also have what we would consider a "reasonable" price while getting only what we really want to get; and if we found the need to have a large chunk of channels, we could always switch over to the other pricing model.
For example, I could see this working as follows for most people:
Singles living on their own would get the a la carte - e.g. a single person being the only driver, so only their interests matter
Singles sharing an apartment/house/etc would get the big packages currently available - e.g. a few people with varying interests as equal primary drivers
Newly weds and young families (e.g. husband, wife, and a baby, or with kids below age 10) would get an a la carte - e.g. the primary TV driver is going to be the newly weds/parents, the kids won't really be able to say anything (too young).
The young family turns into a larger, older family (e.g. at least 2 kids above 10 in age, with several younger kids) and they move to the big package - e.g. parents will still be the primary TV driver, but the kids may want to watch somethings the parents won't, or have other interests so they become a good secondary driver.
Kids go off to college and then move out, mom & dad don't need the large set any more, so they go back to an a la carte - parents the primary driver again; perhaps going back to the big packages over the summer, and returning to a la carte when the kids are away.
Grand kids come along, grand parents have them over quite often, so the get the big package again - e.g. grand kids becoming an influential secondary driver for the grand parents
grandparents running low on finance, or kids move out of town, etc. (e.g. grand kids not over that much), go back to a la carte - e.g. grand parents are the only drivers
So yeah, I can see having both as a good thing - both for the customer and the companies - and peoples needs change over the years. Some families may never go to the packages,
Potentially, a system BIOS would be a good place to run a "phone home" program, except that it would require advanced components, like a TCP/IP stack, etc., to run properly, and it could still be easily wiped by replacing the firmware with boot media. Apple, for that matter, has an upper hand at such a tool since they "own" both the hardware and software. But either way, what you're attempting to do is no more possible than DRM (and Slashdotters know that DRM is nothing short of an attempt at perpetual motion).
Actually, it is possible with the Legacy System PC BIOS Replacements - EFI and its kin, as EFI is really a simplistic Hardware Abstraction Layer operating system that loads modules to do stuff. Technically, (and why I don't like EFI) EFI can be used to implement a system that would not load an untrusted (non-DRM'd) bootloader, which could in turn not load an untrusted OS, and so forth. There are some systems that are going towards this, but they are very few at the moment.
Because of its modularity and where it runs, it could theoretically have a module load that could (a) get GPS coordinates, and (b) send them on the network at boot before the OS loads. Of course, then you have to somehow build the GPS unit and antennae into your laptop...that is left as an exercise for the reader...but it could be doable. Unless built-in by the factory, the issue would be that the modules would be removable through power resets though.
use Mail::Sendmail; use Space::Earth::Networks::GPS;
$location = $Space::Earth::Networks::GPS::getCurrentCoordinates(); $subject = "your laptop"; $message = "Wish you were here - $location";
if ($message ne "") { %mail = ( To => 'You <you@somewhere.com>', From => 'your laptop <laptop@somewhere.com>', Subject => $subject, Message => $message );
sendmail(%mail) or die $Mail::Sendmail::error; }
(Not the actual code. Check out Perl-GPS and Garmin::GPS for actual code. Also, I'm pretty lame at Perl, so please forgive my syntatic mistakes should there be any, which is likely.)
...are they going to can McBride and get a CEO that will turn around the company, get them out of the mess they are in, and get them back to products? McBride has been bad for Caldera/SCOG since day one.
Question: Could Caldera/SCOG sue McBride for his inept leadership? And causing them to lose market due to his governance, deceptions, etc? He is liable for the company as an executive officer, especially as CEO.
I can sympathize with Mr. Barr; I remember when Linux natively ran on a 386SX with 16MB of RAM, and ran *well*. X? We don' need no steenkin' X! I think that, even if you stripped the current kernel to the bare bones, you'd have trouble running it in 16MB, it's been "spoiled" by too much cheap memory.
I concur with this post as I am running a version of Linux on a 486 Laptop with 4 MB of usable RAM. (There is really 8 MB but there's a hardware problem that drops it to 4 MB in reality. Linux still works wonderfully.) That same laptop also has a 300 MB hard drive. I didn't put X on it though as I had other plans.
...when I first signed up for my NYTimes account back in 1999 all the articles were free - or at least the same group they just made free. (Perhaps the ones that are not free now are so because they are not guaranteed to be on-line and someone has to type them in?) I was a little annoyed when they started charging access for anything older than 2 weeks - it made a good chunk of my inbox (where I stored my daily e-mails from them, that includes headlines, etc.) irrelevant.
Fortunately for me, they did this after I left college, as I used that portion of my inbox for a number of class assignments regarding current-events. When I needed to turn something in, I could search the my NYTimes folder for some articles and pull out stuff easily. Paying for the content on a per article basis would have made the work a lot harder, and I probably would not have used them as a local paper would have been a lot cheaper. (And keeping daily papers around in a dorm room would have been a nightmare.)
So, for that brief time of doing that they got a long time reader - and I do forward articles to friends & family. So they get a lot of advertising from me too. Now I can once again rely on providing URLs instead of having to provide the article when I forward articles.
Now if they - and the rest of the publications industry - would get their editors to do their job and start catching the grammar and spelling errors that are so prevalent, especially in the on-line editions. (Suffice it to say, due to some of the grammar and spelling errors, I hope they are only on the on-line version...though that is not likely.) It just doesn't reflect well on such a major publication.
DHCP doesn't give a network admin any more control over a network, either. That's just a silly statement. How does having a server doling out IP addresses make it any easier to control a network? It's not a like a device *must* be set to use DHCP. It's not difficult to figure out what IP address ranges a DHCP server is not doling out and use that, even on IPV4.
As others have said, DHCP does so much more.
I run DHCP on my home network to setup: DNS, WINS, Gateway, IP Address, NTP (Time), and other services. I also use it to record MAC addresses for security reasons, and to easily grab them so that I can configure static IPs and DNS names for specific systems without having to ask people for their specific MAC (unless they're coming in wireless...then they need to to get access anyway...).
Point is, it gives me an easy way to manage my network. And honestly, I was looking forward to playing around with IPv6 in the same manner on my home network (because I could, and wanted to experiment), but some things just aren't ready for it yet, and the lack of a DHCPv6 server (at the time) to manage the auto-configuring was an issue too.
Additionally, I have played with IPv6 with its auto-config, which at least under Windows 2003 is a joke as it is a half-baked implementation that is just plain broke. Half the time it works, and half the time it doesn't. And when it doesn't, it is seriously borked, and breaks everything else too. (And I was only running a set of 6 systems (4 servers, and 2 clients) in my test network.) It took a lot of time to get systems reconnected when things failed out due to IPv6 addressing not working. Haven't tried it much under Linux yet...but I would still have Windows clients to support, and VPN and other software that would need supported. (Software I don't control the version or support on...work does.)
Any how...DHCPv6 would have made supporting that test network a lot easier, and actually would have kept it functional. I cannot imagine what kind of problems admins will have trying to deploy IPv6 with auto-config on a larger network. (Imagine, your computer gets a new IPv6 address just because you rebooted...not make that your server and you could really screw up your network quickly.)
Then tell me:
The list goes on and on. In the end it comes down to - what are you paying for completely up front and what are you are paying for every month (e.g. monthly billed services), and whether or not you can avoid any of them. For example, if you have a static IP you could probably lower your cost of living by letting it go and paying for a cheaper Internet service where you get a dynamically assigned IP - unless of course you are running a business that requires in, in which case what can you do to turn that cost into a 100% business cost that could be written off by the business? If you get Cable or Satellite TV, then you could save by dropping those.
It may not seem like much, but monthly, re-incurring costs no matter how small are a financial death by a thousand cuts as it all adds up. Unfortunately, our culture today encourages spending in that manner. So what could you do to lower your cost of living? There's probably a number of services you subscribe to and pay for monthly that you don't really need (e.g. cable TV), or things you do on a regular basis that could be done more cheaply (e.g. going out to eat, versus cooking it yourself at home; buying pizza or making it yourself from scratch).
My wife & I have been working on this for a while. Sometimes I think she's a bit too strict, and sometimes she thinks I am too. For instance, my policy with our grocery shopping is "if it isn't on the list, we can't get it" - the list is made before we leave for the store. Sometimes we deviate a little (which isn't good), but we do a pretty good job.
In one financial book I have read - don't have the title at the moment - the author did a bit of a study - wrt at least his daily expenses he paid for everything in cash, and perhaps by check otherwise. He observed a 33% reduction in spending as a result. I've heard similar from other sources too. Didn't really change his life style other than changing how he paid for things - it resulted in a bigger change in lifestyle as he was more reluctant to pay for something when seeing the greens live his wallet, thus he ended up saving more.
Cost of living can almost always be reduced - unless you are paying the smallest amounts required to survive - but then, you wouldn't have a computer, you wouldn't have Internet access, you wouldn't have a phone (land or cell), you would be driving a cheap car if you drove at all, and you would be living in or near the slums.
If one of the costs go up, fine - do your business somewhere else that is cheaper, or drop it all together? (e.g. Rent goes up, move. Cell phone service costs go up, drop it or move to another provider that is cheaper.) You have a choice about your lifestyle whether you realize it or not, and you can reduce your costs when you decide to.
I
Personally, I like coding, and I am in no hurry to move up the ladder. Given my personality, it'll happen soon enough any way regardless of what I want - so I'm not going to make it happen faster, and instead enjoy my time coding while I can.
My wife, on the other hand, has a contract that is requires 40 hours a week - though pay periods are only twice a month on specific dates of the month - but also has a certain number of hours (200 hours) of overtime built-in; her contract also guarantees overtime pay if she has move overtime than the contract states (e.g. 201 hours) through the entire year. She also has two seasons in the year of expected overtime, so if they keep her busy, it could be very easy for her to do so.
Point being - the company will keep you to your contract and make sure you fulfill your end of it, so you should keep the company to their contract as well and ensure they keep their end of it. You did agree to the contract, and they don't have the right to change the conditions of the contract without changing the contract, changes which you must also agree to. Additionally, anything that is illegal is not contractually binding.
As far as how a law of such a nature passing might affect contracts - it cannot affect an existing contract without your consent as well. If your contract denies you overtime pay, and the law require they pay you overtime pay, then they have to pay you overtime regardless of the contract as they would otherwise be breaking the law. It will, however, affect new contracts - such as when you change jobs, but even there they cannot break the law; and I doubt a lot of people would accept a pay cut on account of the law change; so, it will basically be to the workers benefits. Companies would also have a problem if they tried to lower wages or lay-off/fire people on account of the change in law.
As always, IANAL, this is just my interpretation and understanding - however accurate or inaccurate it may be. So consult one for good legal advice if you need a real, legal answer.
There is no substitute for testing, and only dumb program managers cut themselves short on testing. And - FYI - GC makes debugging memory issues a lot harder as you have an inconsistently timed mechanism claiming memory from you. However good the GC may be - the timing differences it can cause can make a huge difference in being able to resolve something easily or not - in fact, whenever you have something that causes timing differences, the difficulty of debugging is magnitudes higher. So, even with a GC you will need to be doing months of testing.
FYI - Open Source Software can get by with shorter testing periods because the testing is spread out among thousands of people. Where as a proprietary firm, like Microsoft - with notably takes a couple months to release a patch due to testing, cannot as they have to do their all of the testing themselves.
Bad software gets out for several reasons - (1) developers don't do the engineering they should have, and (2) management crunches the schedule and doesn't let the developers do the engineering they should have or the testing that should have been done. Obviously, managers do need to manage the time line of a project, and projects need to get out. But you can't short change yourself either. I'd much rather a manager scale back a project to meet the time line than short change the engineering and testing; of course, you can't scale back too much either so this is really where the trade offs come and must be managed between the management and the developers. (Developers need to show the financial and business reasons to management for why to keep something, and should design/plan around being able to expand new features - or delayed features - in in order to help management make the deadlines. It's a two way street.)
Even the OS eventually terminates. I'd still put forth my paradigm works.
Accounting is a part of management. However, management goes further in that it assumes responsibility for allocating and de-allocating resources. Even if that is simply telling the GC that an item is no longer needed so the GC doesn't have to waste as much time with determining that the item can be freed for other uses.
I still propose that no matter how complete the AMM may be, you still need a hybrid AMM/MMM such that the programmer can tell the AMM when something is no longer needed. The AMM may go further and help absolve conflicts between multi-threads, and such - and that is fine. However, the programmer still should have a way to tell it when it is done - perhaps as the programmer I want to release memory half way through a function instead of waiting for the pointer to go out of scope when the function exits.
No, it doesn't imply a stack-based hierarchy - but a mix of stack and heap which is what most programming languages have. Heap allocations are really what needs to be tracked, and there should be a way for a free() function to determine if a pointer is pointing to something on the stack or the heap. Currently, this is not very doable.
We know how to write software that is only as secure as the attack vectors that we are aware of. Claiming otherwise is foolishness. We can mitigate how software is affected by unknown attack vectors through Defensive Programming methodology, but even that can only truly protect against known vectors.
Additionally, reliance on a "memory-safe" language does not absolve you from buffer overflow attacks. Such reliance is foolishness - and is no better than security through obscurity. It also provides a fall sense of security. It may help to minimize such risk, but it does not absolve such risk - so please, stop fooling yourself.
Finally, when properly employed - C and C++ can be just as well secured as
Define a memory leak.
To most, a memory leak is simply when a pointer to memory is lost. This is something GC can theoretically solve. But is that truely a memory leak?
I propose that that is really the symptom of a memory leak, and that a memory leak is truly maintaining memory beyond when it is needed. This is something a GC cannot solve, as you may still have a valid pointer pointing to the memory still in scope even when the memory is no longer needed.
How does this differ? Consider a single function that allocates some memory, makes use of it, and then goes on to do something else that doesn't require the memory; the pointer to the memory is in scope throughout the entire life of the function. According to the "normal" view of a memory leak, there would be no memory leak in this function unless the memory was not freed before the end of the function - or a GC would clean it up shortly after the function leaves scope. However, according to my proposed definition, even if you waited until the end of the function and then cleaned up all your memory, it would still be a memory leak as you kept the memory around longer than you needed.
Now perhaps in a normal desktop environment the difference is not a big deal. However, it would be a big deal in an embedded or OS kernel environment, or any other environment where either performance or memory utilization needed to be maximized (e.g. a program that performed tasks that utilized gobs and gobs of memory and needed all the memory it could get).
I wouldn't necessarily call it the "Grand Misconception". And if you read my other posts in this thread you would notice that my view does not adhere that as a misconception at all - rather, it takes that into account as being the mechanism by which the program is forced to do their resource management.
Honestly, OS's have to manage their resources - file systems, memory, processor time, and all kinds of stuff - and in reality, every program is in effect a small operating system dedicated to a single task, the task of what the program is trying to achieve, that is built on top of other operating systems - e.g. standing on the shoulders of giants. Programs really do need to manage their resources, which in most cases is just memory and UI resources, and sometimes involves files and devices too; often some of this can be left to the host operating system, however, anything that causes the program to fail forces the programmer to fix it - thus memory management is required for any program. GC's allow a programmer to be lazy by not doing this; languages like C and C++ - Pascal, Ada, and many others even - force programmers to manage their memory or risk crashing due to memory leaks (" normal" definition memory leaks).
Now may be you don't agree - that's fine. However, we should all strive to be better programmers, and learning how to manage our resources is one step along the way - a necessary step at that.
It is only impossible to entirely eliminate it if the lower levels do
Except that it can't. The programmer could be wrong or purposefully lying, and in fact still have a reference to this object. This, then, breaks type safety and might allow arbitrary code execution flaws...Yes it does. Not having any references to the object in any live object means that the memory it used may be reused after the next garbage collection cycle, which occurs automatically when free memory in the heap runs out. Yes it can. Simply providing the programmer a way to remove that reference counter would do it. As it stands, languages like Java provide no functionality to do so. Whatever the method is, it must match the algorithm used by the GC to do the garbage collecting.
Additionally, the programmer can be wrong - that's the programmer's prerogative, and the system should detect and handle that appropriately - but the tool to do so is still necessary in order to deliver true performance applications. In fact, there is a whole methodology of programming that can handle that mistake - Defensive Programming.
And, to know, one of my issues with the C library is the lack of the ability to hand it a pointer and say "is this valid?" and " is this at least this size?" as that would go a long ways in Defensive Programming. The first question answers whether the pointer is valid - i.e. directly returned from a call to malloc() or from a buffer within one directly returned from a call to malloc() - and the second question answers the size of buffer and if there is enough space to so something. This could be easily tracked, though it would add a little overhead, and would be of great use in Defensive Programming technique.
There is always going to be some way that the programmer will be able to be wrong. However, that can only be countered by the programmer having the right tools to detect when that occurs and handle it appropriately. GC is not necessarily one of those tools.
As another commentor points out, it is very true that performance does matter. Servers software must be very responsive and server admins care very much about the user perception of their server's performance, and the perceptive performance of the services they render.
However, while more tolerable on the user's desktop - it is still very important. User's don't like sitting around waiting for an application to become ready to use, or for an application to play catch up. That costs time, and for businesses that costs money. Simple things such as managing resources can often reduce that wait period to something more tolerable that isn't so costly but only when the programmer deploys such tactics and uses a language (GC'd or not) that allows them to do so.
Ever have a user complain that your program didn't respond fast enough? One good example for you - in one network I am on, there is no reverse-DNS lookups and some other network basics are not provided, this results in some programs not responding (both IE and FF) for up to 5 minutes if I accidentally type in a bad URL. This results in a user perceived performance issue with the application (my first thought, until I could show that the same problem did not exist on another network with the same machine) as the application locked up - user interface was not usable, and would not be repainted, etc. while the software waited. Now IE and FF could mitigate this by pushing that DNS lookup into a worker thread. While this is one example of an external issue affecting internals to a software program, the basis behind the issue - user perceived performance problem - extends quite far.
Few other examples - How often have you waited on MS Outlook to catch up with you? How often have to waited for MS Word to compete a task - that you didn't start - so that you could continue working on the document? How often have you worked on a document and had the computer stop responding to you while it finishes something else? How often have you upgraded Windows or Office to a newer version and end up having to upgrade the PC even though you didn't do anything different, and were not using any new features?
A Pentium 75 with 32 MB RAM should be sufficient to do basic email; however, try to do it with most programs these days and the system will feel like it was bogged down, even though you could do that and run Office, and more when it came out back around 1995.
Performance is a big thing, and the perception of performance is even bigger.
And then you sometimes have a manager or client saying "this will be done in Java" because its what they want for some reason. Then you as the programmer are forced to use Java and may be unable to change their minds despite the downside of not being able to manage your memory, when you normally would.
There are certainly reasons why people use things that go beyond the choice of choosing a GC. They may not have opted to for that higher memory footprint, or performance penalty, but were at the hands of someone else that didn't know any better and were unable to convince them otherwise.
Your other points are of very true, and often overlooked by the GC-supportive crowd and Java supporters. I wouldn't say its "damned hard to find". I've done it in the past by having a small stack tracer I could use and turn on and off. I would use for debugging, and turn it off (removed from the compiled code) for production. But all it did was tell me where my memory leaks were. Worked pretty well, and the program it was used in was very solid. The only leaks I couldn't remove were OS API based. Additionally, it was very easy and quick to locate leaks on account of it.
A lot can be learned about programming by managing ones resources, and the programs will get better for it too. I'll give you that - and perhaps a good solution is to have the ability for the programmer do specify it even with the GC being there. However, at least for Java - there is nothing in the language itself that enables a Java programmer to even tell the GC that the memory block is available for de-allocation, the GC just has to guess and eat a lot of overhead to do it.
As for Lisp programmers, they are few and are usually Lisp programmers by choice. I know I certainly wouldn't punish myself with Lisp. (Yes, I've programmed in Lisp before.) You're forced to by the program not running for the required amount of time. If the program doesn't function, and crashes you'll have to track it down and fix it. You can make that easy on yourself, or hard on yourself depending on your approach; but having some algorithm follow you around and try to guess when you are no longer using a chunk of memory is not a solution - it's laziness.
To make it easy on yourself, you'd design the program to have entities that would be responsible for the memory - both for its allocation and de-allocation. I've done this. It works, and no GC is required either.
Moreover, I have written programs that stay up for a long time, and are good about their resources. And I'm done programs where I had to import legacy code that wasn't good and added such capabilities to them too so that they became good and solid - in the end, those programs were more solid than the OS, as the OS they were on was more likely to be rebooted before they would reach any kind of level that would be an issue.
That may not be the case for all GC languages, but it is the case of what is perhaps the most prominent GC language - Java, which also has had the unfortunate aspect of being forced on a lot of companies because the programmers they could hire out of college didn't know any other language. (Sad reflection on the colleges and universities they came out of too - but that is also partly due to vo-tech colleges as well, where training is typically limited to the quick & dirty.) In no way was I assuming a quot;completely Academic Computer Science approach to all problems" - in fact, a lot of Academic Computer Science is strongly behind the GC languages and not teaching students how to manage resources.
What I am talking about is doing proper engineering of software - proper design, architecture, and implementation - such that the resources are managed in the program appropriately. It really is not a hard job to do, and when done - it can speed up implementation and debugging as it all works towards it in the end.
By doing the rag-tag job that Academic Computer Science pushes, debugging will be long and hellish, and will only add to cost over-run.
Additionally, I am primarily pushing management of resources in this thread, including memory. When it comes to performance, then yes - you need to run a profiler and optimize the program accordingly and not spend all your time on optimizing every line of code throughout the entire program.
Which brings my second point - even with your original version, this cannot always be done in some languages as some languages remove the ability to free resources. For example, so far as I am aware - and so far as I can tell - Java cannot free memory resources outside of the garbage collector. So much for a programmer being able to manage their resources properly - this is probably also one of the big reasons Java sucks at performance.
C/C++ and similar languages, on the other hand, force the programmers to manage their resources. In those cases, the programmers would likely be just not designing their programs well, or employing bad resource management. Yes, managing resources can be hard - one project I worked on had to go through several months of testing to get the resources properly managed, and even then some of the resources were still a little uncontrollable due to legacy code or Windows APIs, but overall the thing was pretty stable and any memory leaks were mostly due to Windows APIs.
In either case, I can't tell you how many times I have heard (especially from Java programmers) something along the lines of the following: "RAM is cheap", "processors are getting faster", "computers will be ready for this when we deliver it", "hardware is cheaper than programmers"
No offense, but to rely on hardware always being getting faster, or the cost of adding more RAM always being cheaper, etc. is a bad premise to rely on. Already with multi-core processors we are seeing slower processors being combined into a single processor get the equivalent processing power of a faster processor (e.g. two 1.8 Ghz cores rated equally to a single 3 Ghz core); thus the premise breaks down. Also, I want to be able to do more with the faster processors and additional RAM, rather than simply do the same job I could do yesterday only in "better" software.
The real answer is doing your job right, and using the right tool - which is not necessarily the easiest tool to use either. We also need to get back to writing applications that have good, if not great, performance with minimal resource requirements (e.g. RAM and processor). If we're not going this at the API/library level - at the very least - then the programs and library/APIs that rely on that API/library level will have worse performance no matter what they do. But in either case it doesn't get done unless the programmers do their job, and use tools that allow them to do it.
But obviously it's not cheap enough for some people - like myself. I'm not interested in paying $50/month for cable TV, and I'm really not interested in paying $18/month for basic, local only service, though it is low enough that I do sometimes consider it - since I only get 2 OTA where I am. My choices from my local cat-TV provider:
FYI - those prices do not include equipment, nor do they include HD channels. There are only about 5 or 6 spanish channels and in the Digital Service at that. Also, a DVR is $9.95/month; so a non-DVR box would be cheaper, likely $3 to $5 - I can't find any other price than the DVR price and am not going to call in just to find out for this post.
Now, granted - an a la carte would likely make each of those channels more expensive if you simply divided out the cost over the number of channels. However, different channels have different costs for them. EPSN might charge $24/month, while some random, unknown channel might charge $0.02/month. If an a la carte were to be truly offered, then the customer (not consumer!) would actually see these differences in price. So, whether or not it would be cheaper for the customer or not would be up to the customer as the customer could chose what channels to include, and thus directly affect their cost.
Sure, they may right now be getting ESPN for $0.72 (average price for the value package - $56.20/79) - or $0.42 if they are getting the 'Digital' package', and might have to pay $24 in a la carte pricing - that's why I said they could continue using their existing pricing - let the customer chose which pricing model they want.
(more on this below)
I know that if I was able to get an a la carte, then I certainly wouldn't be paying $56.20 for the service.
Also, realize - I don't want the other channels that I am not watching - even to the point of deprogramming them. And I don't necessarily want to support something financially (e.g. paying for) if I don't support it or want it. I'd like control of where my money goes and what my money supports. (E.g. I don't want to support MTV, VH-1, or the World Wide Shopping Channel (to name a few), but under the current system I wouldn't have a choice if I got cable TV).
Your price comparison is faulty as (a) my cable provider's limited and value services don't need extra equipment (e.g. no equipment rental), and (b) even when it does require equipment, the equipment is not included in the price.
So, if the customer choses a channel that requires the equipment, then they would have to get the equipment. If not, they won't have to. Either way, for comparisons sake, the equipment doesn't need to be factored into the price because it would be factored in the same way either way - if and only if you get service that requires the equipment, whether it is a package or (for a la carte style) a specific channel.
Still, to use your numbers - say I only want local (base price) plus 5 channels at $1.60 each - that would be $11 + $8, total $19, for a total of about 29 channels, yielding a cost of $0.65
I don't agree. I currently do not purchase cable TV (only cable Internet) because of the price. I don't consider the high cost to be worth it. However, there are a number of cable TV channels I would be interested in getting if the price were right - an a la carte would let me do that.
For example, I don't watch sports, so ESPN or any other sport channel would automatically be off - and when I have had cable TV in the past (since it was cheaper than simply having cable Internet) I deprogrammed ESPN and the likes so I wouldn't have to surf over them - however, channels like Cartoon Network, the Anime Channel, SCI-Fi, etc. would be of high interest to me.
Perhaps the real solution is a combination of choices. Have the current package set there offered as a "discount" package - e.g. for buying all together in bulk of these we'll give you a reduced price, kind of like volume pricing - or you can pay this low fee of $10/month for basic service (local channels) and then pay for each channel or set of channels for a small fee in addition to that. So, you may pay $.50 for the Anime Channel, or $1.25 for Anime, Cartoon Network, Nickelodeon as a "Cartoon" package, etc. If a content provider wanted to require all their channels be provided together - or none at all - (as some have claimed above Discovery Networks), then they would just be a like the "Cartoon" package and set the price for the package.
Let the customer have a choice.
This would not only increase their market penetration - as people like me might then become customers - but would also (a) allow the groups that would like to have the 400+ channels to have a "reasonable" price, and (b) allow the individuals (or small family homes - e.g. my wife & I) to also have what we would consider a "reasonable" price while getting only what we really want to get; and if we found the need to have a large chunk of channels, we could always switch over to the other pricing model.
For example, I could see this working as follows for most people:
So yeah, I can see having both as a good thing - both for the customer and the companies - and peoples needs change over the years. Some families may never go to the packages,
Because of its modularity and where it runs, it could theoretically have a module load that could (a) get GPS coordinates, and (b) send them on the network at boot before the OS loads. Of course, then you have to somehow build the GPS unit and antennae into your laptop...that is left as an exercise for the reader...but it could be doable. Unless built-in by the factory, the issue would be that the modules would be removable through power resets though.
...are they going to can McBride and get a CEO that will turn around the company, get them out of the mess they are in, and get them back to products? McBride has been bad for Caldera/SCOG since day one.
Question: Could Caldera/SCOG sue McBride for his inept leadership? And causing them to lose market due to his governance, deceptions, etc? He is liable for the company as an executive officer, especially as CEO.
...when I first signed up for my NYTimes account back in 1999 all the articles were free - or at least the same group they just made free. (Perhaps the ones that are not free now are so because they are not guaranteed to be on-line and someone has to type them in?) I was a little annoyed when they started charging access for anything older than 2 weeks - it made a good chunk of my inbox (where I stored my daily e-mails from them, that includes headlines, etc.) irrelevant.
Fortunately for me, they did this after I left college, as I used that portion of my inbox for a number of class assignments regarding current-events. When I needed to turn something in, I could search the my NYTimes folder for some articles and pull out stuff easily. Paying for the content on a per article basis would have made the work a lot harder, and I probably would not have used them as a local paper would have been a lot cheaper. (And keeping daily papers around in a dorm room would have been a nightmare.)
So, for that brief time of doing that they got a long time reader - and I do forward articles to friends & family. So they get a lot of advertising from me too. Now I can once again rely on providing URLs instead of having to provide the article when I forward articles.
Now if they - and the rest of the publications industry - would get their editors to do their job and start catching the grammar and spelling errors that are so prevalent, especially in the on-line editions. (Suffice it to say, due to some of the grammar and spelling errors, I hope they are only on the on-line version...though that is not likely.) It just doesn't reflect well on such a major publication.
I run DHCP on my home network to setup: DNS, WINS, Gateway, IP Address, NTP (Time), and other services. I also use it to record MAC addresses for security reasons, and to easily grab them so that I can configure static IPs and DNS names for specific systems without having to ask people for their specific MAC (unless they're coming in wireless...then they need to to get access anyway...).
Point is, it gives me an easy way to manage my network. And honestly, I was looking forward to playing around with IPv6 in the same manner on my home network (because I could, and wanted to experiment), but some things just aren't ready for it yet, and the lack of a DHCPv6 server (at the time) to manage the auto-configuring was an issue too.
Additionally, I have played with IPv6 with its auto-config, which at least under Windows 2003 is a joke as it is a half-baked implementation that is just plain broke. Half the time it works, and half the time it doesn't. And when it doesn't, it is seriously borked, and breaks everything else too. (And I was only running a set of 6 systems (4 servers, and 2 clients) in my test network.) It took a lot of time to get systems reconnected when things failed out due to IPv6 addressing not working. Haven't tried it much under Linux yet...but I would still have Windows clients to support, and VPN and other software that would need supported. (Software I don't control the version or support on...work does.)
Any how...DHCPv6 would have made supporting that test network a lot easier, and actually would have kept it functional. I cannot imagine what kind of problems admins will have trying to deploy IPv6 with auto-config on a larger network. (Imagine, your computer gets a new IPv6 address just because you rebooted...not make that your server and you could really screw up your network quickly.)