I have not found it particularly portable. You end up having to learn the VM, instead of the real machine. Each VM behaves a little different. It's strategies are different, it's bugs.
I know a lot of C++ programs that are portable. There are a lot of good paradigms to follow if you want to make portable code in C++ (or any compiled language).
EXCEPT: in a situation where you want binary compatibility. You want to deliver the code in a binary package to processors with incompatible machine code. Like a distributed processing situation on heterogeneous harware. With Java you can pass that code around regardless of the CPU type knowing it will run (assuming you use the right VMs). However, with everybody always reminding me how much faster computers are getting, I'm thinking you could get this with ANSI C++, compiled on the fly. Why not?
the C++ compiler really is as good as most people at assembly, but VMs are only promised to be as efficient as compiled languages.
the CLI and GUI interfaces actually introduce a new paradigm for a program that itself makes the program capable of some new ability. Slow imperative languages offer little that you cannot obtain with fast imperative languages.
Also, I write in slow languages all the time. I'm not a speed freak. I'm just tired of the argument that faster machines mean slower software is a non-issue. That's no argument at all. Slower is slower, bloated is bloated, it counts against you. If you want to say it's only one set of factors... of course I agree, but be specific about the other factor you're trying to obtain.
You can't call it a general purpose solution; with baggage like that you have to justify it. I'm not buying the more rapid development argument either for any scripting language. Any speed gained in creation is lost in debugging. Other speedups are just familiarity with the correct libraries. To get better productivity you have to leave imperative languages, because that's where the real woes in developmental struggles are. imnsho, of course.
PS: I'm not saying I intend to leave the imperative languages, but it's clear that CASE addicted people begging to be let out from underneath the hood clearly need development models of their own (indoubtably built using imperative languages). I'm fond of citing Zope at the moment, which has an interesting mix, going from Products you simply drop in and use (changing art, or title type parameters), a template language, and then a relatively a smooth transition to the underlying python, allowing full access to an OO language.
By the way, this is a good example of why you would use a VM based language, use of this in Zope allows all the levels to exist in the same namespace (e.g. python code fragments in template language expressions).
Just because we have more CPU power do you think that justifies wasting this power? I guess that Java is for people that already have computers more powerful than they can handle? Personally, I'd rather even give my cycles to SETI@HOME than give them to some VM.
And Java is still slow. Or Swing, or whichever excuse... perhaps it's slow because my VM is optimizing my code behind the scenes.
You've lowered your standards for performance, that's the whole story. Your reason is neither good nor bad nor compelling to someone that still values performance.
These Java processes take 15 meg and up on solaris, at least. They half the power of my machine, they half it's value. I need two machines instead of one. Is that good? Why the hell should I care if they run just as well as old applications on old machines? Why in the hell would I be happy about that... you think I'm nostalgic or something?
no the Amiga was better. If it had survived it would have faster chips too.
It had real multitasking as modern systems but on top of that was a distributed system... sound and graphics were handled by their own chips that could be given their own programs to run, so for example you could program the graphics chip to switch resolutions midscreen (the OS used this to allow you to pull down one desktop to reveal the desktop behind it of a different color depth and resolution.
Oh yeah, and it came with Emacs.
I suppose you know all this, but I speak to inform the youngins.
what you can complain about is a lack of a public safety structure able to guarentee health care and other necessities inbetween employment, at least, in the US.
Re:worse then vibration
on
Ant Farm PC
·
· Score: 1
nothing is more realistic than things rendered by your own imagination. Having an immersive world is only more realistic for people with less imagination than it takes to get hooked on MUDs. They're probably still hooked on MUDs.
all I know is that I had a connection object problem connecting to a DB from java. I had a connection reference, it worked, I created the next reference (e.g. new Connection) and started my next DB connection. When the first connection object was destroyed, it interrupted my second connection. According to java syntax these were totally different connections, but in reality the connections were pooled and the proxy object called something to screw with the second proxy (to the same underlying connection, evidently). Setting the connection reference to null cured the ill as evidently the GC cleaned up sooner. This was Sun's JVM on solaris, with apache and an evidently buggy sybase JDBC.jar.
I'm totally open to other interpretations of the events as the black hole, I mean "box", of the VM makes deep investigation all but impossible/pointless.
I hadn't thought about that because of the enormity of following every pointer! But as you say, this can be done more cheaply, concievably, if it doesn't happen very often.
don't you use reference counting to mark things for deletion.
In reference counting you don't have to delete or free the memory when the count goes to 0. I agree with you, you "collect" those later. In some cases, you don't have to collect, you just give the memory to someone else.
> Incrementing the ref count is generally more than one instruction because you have to get its address first. You also have memory taken up by the ref counts, increased register and cache pressure for the increments, etc. And when you decrement it, you have to test for zero. I think ref counting would work well if you had a lot of short-lived local objects, but not so well if you had a lot of long-lived objects passed as method parameters.
the question would be how can you do any less than that and achieve the same result? optimal is related to functionality. And especially, how could you have less in a garbage collection situation.
>GCs don't maintain ref counts, btw.
the one's I've worked with do. How could any not? you have to know if there are references left before you collect unused memory, yes? btw, the garbage collecting systems I have used have always been for the situation where you are making a lot of allocations and deallocations, so you create a separate heap (one block of new/malloced memory) from which you give out pieces. You still reference count in order to know what memory you can erase and give to another requestor. You don't actually HAVE to garbage collect if all the blocks are the same size, you can just give out slots that are free without every freeing them. Maybe you don't want to call this scheme GC? But in another more general case many sizes of short lived objects need to work in this scheme then you will actually garbage collect so that you can defrag memory from time to time.
>I've heard that GC can work pretty well with C++, but you can't guarantee that there won't be memory leaks because you have to assume that a declared int might really be a pointer. It would be great with a type-safe variant of C++, though.
but you can't even guarantee that in a GC system because it's possible to keep references to memory you don't need. I've seem Java programs that grow and grow and grow that don't need to, that's still a memory leak in my book. Personally, I am not looking for a language to guarantee so much as enable.
There are two answers to memory correctness in C/C++:
(1) remember to free what you malloc, delete what you new.
(2) don't use pointers and arrange to manage memory entirly by scope, and in constructors/destructors (where it's relatively easy to apply rule (1).
you need to specify the criteria. I can think of cases where it's suboptimal for the sun to shine, but it's pretty contrived and special case.
I especially predict that in managing memory that is shared by different client modules you will at LEAST have to reference count. If you need more, then you reference counting alone is not sufficient. If you do not need more, it is sufficient, and it is optimal.
I can think of times you would not want to reference count, but it's not because there is any more optimal solution to tracking references! (more like you don't want to share memory or you know you are not going to free the relevant memory anyway)
what's so slow about it? it it incrementing an int? That does take a whole instruction.
Or is it having to call the for the pointer?
Circular references are a design problem -- guess what, Java won't help you if you have a circular reference either!
btw, garbage collectors always reference count, so you should mention what you want MORE than reference counting when advocating memory voodoo... I'm sorry, I mean "automatic garbage collection".
a few Bjarne quotes:
* The best garbage collecting language that I know of is C++ with a garbage collector. * If you have problems with memory management in C++, I think it is to a large extent your own fault; because either you have a problem for which the traditional C++ solutions work - in which case you use them - or you have a problem which needs a garbage collector - in which case you should use one.
instead of stomping a reference with a new object reference, you set it to "null" first. Worked for me when I had a problem with the GC deleting a connection object that was pooled below the surface (my code just was creating a new connection, but it was reused... to get the GC to delete the proxy connection object before I created a separate one, I set it to null, as many of the java faithful recommended.
I really think handling memory takes a lot of thought but is the most rewarding... just like thinking about data structure in the first place. Of course you think a lot about how it's arraned. Or, don't, you can have fat safe classes in C++ too.
>In many cases, where an object can be referred to by arbitrarily many pointers in arbitrarily many locations, the programmer essentially has to manually implement their own garbage collection mechanism (most commonly through reference counting). This is often sub-optimal.
you are correct with regard to your ideas but it works like this:
the software engineers start before the machine it will run on is actually available. They have to guess. They want to put a lot in their software, so (until recently) that meant they were limited by the machines resources, and when the company helps direct them to be aggressive in what they try, the end result is that the machine is not ready for the tasks they put it too, and they did not write optimal code in terms of resource usage.
>The big question in the computing world is how not to become a dog on some manufacturer's leash. Woof, woof, where do you want me to go today, Bill, Steve, or Scott?
exactly.
I think that's the real beauty of unix/linux, both were in the hands of their user, software engineers and system deployers. It's not quite what RMS is talking about, I don't think, but he's facilitated it with a license that retains their power better than the public domain did before. Then the other beauty is just being implimented over and over which is good for any technology, however flawed it might be.
>My biggest reason for liking JAVA is that it forces people to stop writing bad C code. Which is exactly what it was designed to do.
this is what I dislike about it. I don't like languages built to force me away from a bad habit, it means I've been forced into (someone else's idea of) the perfect habit. I have yet to find the perfect habit.
The real solution for bad C/C++ code (I slipped C++ in there on purpose) is to learn what you are doing. If you can't learn the ins and outs of procedural logic than don't create an imperitive language, you still have the the real pitfalls still present, and create a new paradigm altogether at a higher language, like Zope.
There are good problems that VMs address, but they are niche areas (dynamically distributed code that can benefit by using heterogenous networds, and certain idioms like self modifying code... somehow I don't think the joy of self modifying code is what Java is about, but then, I'm told again and again how Java will be as fast as C++ when the JVM's dynamically recompile and optimize code as it runs... loluck), and not general purpose areas.
What you fail to understand is the real world doesn't matter. There is a special case in which that might not be true and someone might code the JVM that executes the special case, so the horrors you speak of are superfluous!
Also, I'm glad that C++ is open ended, it incorporated some of the ideas of OOP without becoming slave to them. It gave useful syntax for putting function pointers in structures which you can use in a very C like way. I'm glad it didn't force a whole rigid paradigm down.
Also, while I totally accept the idea that programs that wait a lot for human input (and all your other points, which are quite reasonable), I don't like the general argument that CPU time is cheap enough to waste. And I deal with people writing server applications that spend 0 time waiting for human input in Java.
Just to prove I'm not a low level cave dwelling device driver writer with no appreciation of high level solutions... I'm falling in love with Zope for quick intranet tool development.
In fact, at the risk of rambling, this is what I want... if someone wants to improve on languages like C/C++, use a different paradigm for the next higher level, something different. Creating Virtual Machines to run Imperative Languages is not the way to go, imo, except for niche products (like a Macro Language for a Word Processor, or scripting language for an extensible web server), the real problem with Imperative languages when considering general purpose development (which many think Java is ready for) for people is logic, not just memory manipulation or this or that, but logic in general, it's complicated, it gets convoluted by nature as it grows. Create systems which do not require imperitive demands. The quest for the perfect VM based language really strikes me as software engineers telling hardware engineers how hardware should work, but still sticking with the imperative methodologies they fear are the cause of our terrible track record as an industry when it comes to quality and lack of predictable development schedules.
>A portable assembler that thinks it's an object system...
sounds like great praise!!!
physics is confusing, we still teach it to undergraduates.
Depends on your learning style. Personally, put me in a cloud of chaos and let the shifting forms resolve themselves.
But why C/C++ is a good learning language is because you are supposed to be learning about how computers work. As you point out, C/C++ is something like a portable assembler, this allows you to learn to think like the machine. Is it really better to learn how to think like a Virtual Machine (i.e. the machine software engineers would make if they were not too busy making software so they made it anyway)?
If the way computing machines work is confusing, well fsck, that's why you'll be around here four years child! And in fact, it's not that confusing. Confusing is being taught that computers behave like a virtual machine.
Give kids the cream niceness of high level safe scripting and interpreted languages when they have a framework to know what it's cost them. Then, they will still make that decision, but they won't try to code Corel Office in Java 1.
oh yeah, none of the people in the suburbs ever lived in the city to know for themselves how freaking great it is to walk around with tumble trash gently blowing downs the concrete slave ways.
In the suburbs you have to leave the house to do something. In the city is all right there for you, right? who's self centered.
I do hate the suburbs, but not for the reasons you state, and your confidence that urban living is better (which you imply, if I can tell) is totally off mark.
Frankly, the city could be the best place to live, but you'd all have to move underground.
seriously, life in the US today is already like a utopia, say, compared with living in the middle ages. Consider... ancient cities were huge, millions of people like today... shitting in gutters! I think we have even further to go.
Utopia is not impossible unless by utopia you mean "impossibly great". The "great but possible" world has a lot to offer. Cities designed without cars might be one way. And who says we have to convert the whole world. After all, there are 6 Billion people, to make a little city with a million people is nothing, just a tiny little experiment. How would you get people to move there? hmmm, I'd say, "offer jobs".
they would not have to release their modifications. You only have to do that if you sell or distribute your system. So if they sold or gave their system to ESA it would have to come with the code.
Slashdot Mirror
I have not found it particularly portable. You end up having to learn the VM, instead of the real machine. Each VM behaves a little different. It's strategies are different, it's bugs.
I know a lot of C++ programs that are portable. There are a lot of good paradigms to follow if you want to make portable code in C++ (or any compiled language).
EXCEPT: in a situation where you want binary compatibility. You want to deliver the code in a binary package to processors with incompatible machine code. Like a distributed processing situation on heterogeneous harware. With Java you can pass that code around regardless of the CPU type knowing it will run (assuming you use the right VMs). However, with everybody always reminding me how much faster computers are getting, I'm thinking you could get this with ANSI C++, compiled on the fly. Why not?
the differences:
the C++ compiler really is as good as most people at assembly, but VMs are only promised to be as efficient as compiled languages.
the CLI and GUI interfaces actually introduce a new paradigm for a program that itself makes the program capable of some new ability. Slow imperative languages offer little that you cannot obtain with fast imperative languages.
Also, I write in slow languages all the time. I'm not a speed freak. I'm just tired of the argument that faster machines mean slower software is a non-issue. That's no argument at all. Slower is slower, bloated is bloated, it counts against you. If you want to say it's only one set of factors... of course I agree, but be specific about the other factor you're trying to obtain.
You can't call it a general purpose solution; with baggage like that you have to justify it. I'm not buying the more rapid development argument either for any scripting language. Any speed gained in creation is lost in debugging. Other speedups are just familiarity with the correct libraries. To get better productivity you have to leave imperative languages, because that's where the real woes in developmental struggles are. imnsho, of course.
PS: I'm not saying I intend to leave the imperative languages, but it's clear that CASE addicted people begging to be let out from underneath the hood clearly need development models of their own (indoubtably built using imperative languages). I'm fond of citing Zope at the moment, which has an interesting mix, going from Products you simply drop in and use (changing art, or title type parameters), a template language, and then a relatively a smooth transition to the underlying python, allowing full access to an OO language.
By the way, this is a good example of why you would use a VM based language, use of this in Zope allows all the levels to exist in the same namespace (e.g. python code fragments in template language expressions).
I find this line of reasoning a bit pathetic.
Just because we have more CPU power do you think that justifies wasting this power? I guess that Java is for people that already have computers more powerful than they can handle? Personally, I'd rather even give my cycles to SETI@HOME than give them to some VM.
And Java is still slow. Or Swing, or whichever excuse... perhaps it's slow because my VM is optimizing my code behind the scenes.
You've lowered your standards for performance, that's the whole story. Your reason is neither good nor bad nor compelling to someone that still values performance.
These Java processes take 15 meg and up on solaris, at least. They half the power of my machine, they half it's value. I need two machines instead of one. Is that good? Why the hell should I care if they run just as well as old applications on old machines? Why in the hell would I be happy about that... you think I'm nostalgic or something?
no the Amiga was better. If it had survived it would have faster chips too.
It had real multitasking as modern systems but on top of that was a distributed system... sound and graphics were handled by their own chips that could be given their own programs to run, so for example you could program the graphics chip to switch resolutions midscreen (the OS used this to allow you to pull down one desktop to reveal the desktop behind it of a different color depth and resolution.
Oh yeah, and it came with Emacs.
I suppose you know all this, but I speak to inform the youngins.
companies have to grow and shrink.
what you can complain about is a lack of a public safety structure able to guarentee health care and other necessities inbetween employment, at least, in the US.
People for the Ethical Treatment of Ants?
regarding text and realism:
nothing is more realistic than things rendered by your own imagination. Having an immersive world is only more realistic for people with less imagination than it takes to get hooked on MUDs. They're probably still hooked on MUDs.
all I know is that I had a connection object problem connecting to a DB from java. I had a connection reference, it worked, I created the next reference (e.g. new Connection) and started my next DB connection. When the first connection object was destroyed, it interrupted my second connection. According to java syntax these were totally different connections, but in reality the connections were pooled and the proxy object called something to screw with the second proxy (to the same underlying connection, evidently). Setting the connection reference to null cured the ill as evidently the GC cleaned up sooner. This was Sun's JVM on solaris, with apache and an evidently buggy sybase JDBC .jar.
I'm totally open to other interpretations of the events as the black hole, I mean "box", of the VM makes deep investigation all but impossible/pointless.
thanks for the explanation.
I hadn't thought about that because of the enormity of following every pointer! But as you say, this can be done more cheaply, concievably, if it doesn't happen very often.
don't you use reference counting to mark things for deletion.
In reference counting you don't have to delete or free the memory when the count goes to 0. I agree with you, you "collect" those later. In some cases, you don't have to collect, you just give the memory to someone else.
> Incrementing the ref count is generally more than one instruction because you have to get its address first. You also have memory taken up by the ref counts, increased register and cache pressure for the increments, etc. And when you decrement it, you have to test for zero. I think ref counting would work well if you had a lot of short-lived local objects, but not so well if you had a lot of long-lived objects passed as method parameters.
the question would be how can you do any less than that and achieve the same result? optimal is related to functionality. And especially, how could you have less in a garbage collection situation.
>GCs don't maintain ref counts, btw.
the one's I've worked with do. How could any not? you have to know if there are references left before you collect unused memory, yes? btw, the garbage collecting systems I have used have always been for the situation where you are making a lot of allocations and deallocations, so you create a separate heap (one block of new/malloced memory) from which you give out pieces. You still reference count in order to know what memory you can erase and give to another requestor. You don't actually HAVE to garbage collect if all the blocks are the same size, you can just give out slots that are free without every freeing them. Maybe you don't want to call this scheme GC? But in another more general case many sizes of short lived objects need to work in this scheme then you will actually garbage collect so that you can defrag memory from time to time.
>I've heard that GC can work pretty well with C++, but you can't guarantee that there won't be memory leaks because you have to assume that a declared int might really be a pointer. It would be great with a type-safe variant of C++, though.
but you can't even guarantee that in a GC system because it's possible to keep references to memory you don't need. I've seem Java programs that grow and grow and grow that don't need to, that's still a memory leak in my book. Personally, I am not looking for a language to guarantee so much as enable.
There are two answers to memory correctness in C/C++:
(1) remember to free what you malloc, delete what you new.
(2) don't use pointers and arrange to manage memory entirly by scope, and in constructors/destructors (where it's relatively easy to apply rule (1).
you need to specify the criteria. I can think of cases where it's suboptimal for the sun to shine, but it's pretty contrived and special case.
I especially predict that in managing memory that is shared by different client modules you will at LEAST have to reference count. If you need more, then you reference counting alone is not sufficient. If you do not need more, it is sufficient, and it is optimal.
I can think of times you would not want to reference count, but it's not because there is any more optimal solution to tracking references! (more like you don't want to share memory or you know you are not going to free the relevant memory anyway)
what's so slow about it? it it incrementing an int? That does take a whole instruction.
Or is it having to call the for the pointer?
Circular references are a design problem -- guess what, Java won't help you if you have a circular reference either!
btw, garbage collectors always reference count, so you should mention what you want MORE than reference counting when advocating memory voodoo... I'm sorry, I mean "automatic garbage collection".
a few Bjarne quotes:
* The best garbage collecting language that I know of is C++ with a garbage collector.
* If you have problems with memory management in C++, I think it is to a large extent your own fault; because either you have a problem for which the traditional C++ solutions work - in which case you use them - or you have a problem which needs a garbage collector - in which case you should use one.
giving hints:
instead of stomping a reference with a new object reference, you set it to "null" first. Worked for me when I had a problem with the GC deleting a connection object that was pooled below the surface (my code just was creating a new connection, but it was reused... to get the GC to delete the proxy connection object before I created a separate one, I set it to null, as many of the java faithful recommended.
I really think handling memory takes a lot of thought but is the most rewarding... just like thinking about data structure in the first place. Of course you think a lot about how it's arraned. Or, don't, you can have fat safe classes in C++ too.
>In many cases, where an object can be referred to by arbitrarily many pointers in arbitrarily many locations, the programmer essentially has to manually implement their own garbage collection mechanism (most commonly through reference counting). This is often sub-optimal.
no, it's optimal.
you are correct with regard to your ideas but it works like this:
the software engineers start before the machine it will run on is actually available. They have to guess. They want to put a lot in their software, so (until recently) that meant they were limited by the machines resources, and when the company helps direct them to be aggressive in what they try, the end result is that the machine is not ready for the tasks they put it too, and they did not write optimal code in terms of resource usage.
i think.
>The big question in the computing world is how not to become a dog on some manufacturer's leash. Woof, woof, where do you want me to go today, Bill, Steve, or Scott?
exactly.
I think that's the real beauty of unix/linux, both were in the hands of their user, software engineers and system deployers. It's not quite what RMS is talking about, I don't think, but he's facilitated it with a license that retains their power better than the public domain did before. Then the other beauty is just being implimented over and over which is good for any technology, however flawed it might be.
>My biggest reason for liking JAVA is that it forces people to stop writing bad C code. Which is exactly what it was designed to do.
this is what I dislike about it. I don't like languages built to force me away from a bad habit, it means I've been forced into (someone else's idea of) the perfect habit. I have yet to find the perfect habit.
The real solution for bad C/C++ code (I slipped C++ in there on purpose) is to learn what you are doing. If you can't learn the ins and outs of procedural logic than don't create an imperitive language, you still have the the real pitfalls still present, and create a new paradigm altogether at a higher language, like Zope.
There are good problems that VMs address, but they are niche areas (dynamically distributed code that can benefit by using heterogenous networds, and certain idioms like self modifying code... somehow I don't think the joy of self modifying code is what Java is about, but then, I'm told again and again how Java will be as fast as C++ when the JVM's dynamically recompile and optimize code as it runs... loluck), and not general purpose areas.
What you fail to understand is the real world doesn't matter. There is a special case in which that might not be true and someone might code the JVM that executes the special case, so the horrors you speak of are superfluous!
good points. Dang it, I like the extra legs.
Also, I'm glad that C++ is open ended, it incorporated some of the ideas of OOP without becoming slave to them. It gave useful syntax for putting function pointers in structures which you can use in a very C like way. I'm glad it didn't force a whole rigid paradigm down.
Also, while I totally accept the idea that programs that wait a lot for human input (and all your other points, which are quite reasonable), I don't like the general argument that CPU time is cheap enough to waste. And I deal with people writing server applications that spend 0 time waiting for human input in Java.
Just to prove I'm not a low level cave dwelling device driver writer with no appreciation of high level solutions... I'm falling in love with Zope for quick intranet tool development.
In fact, at the risk of rambling, this is what I want... if someone wants to improve on languages like C/C++, use a different paradigm for the next higher level, something different. Creating Virtual Machines to run Imperative Languages is not the way to go, imo, except for niche products (like a Macro Language for a Word Processor, or scripting language for an extensible web server), the real problem with Imperative languages when considering general purpose development (which many think Java is ready for) for people is logic, not just memory manipulation or this or that, but logic in general, it's complicated, it gets convoluted by nature as it grows. Create systems which do not require imperitive demands. The quest for the perfect VM based language really strikes me as software engineers telling hardware engineers how hardware should work, but still sticking with the imperative methodologies they fear are the cause of our terrible track record as an industry when it comes to quality and lack of predictable development schedules.
>A portable assembler that thinks it's an object system...
sounds like great praise!!!
physics is confusing, we still teach it to undergraduates.
Depends on your learning style. Personally, put me in a cloud of chaos and let the shifting forms resolve themselves.
But why C/C++ is a good learning language is because you are supposed to be learning about how computers work. As you point out, C/C++ is something like a portable assembler, this allows you to learn to think like the machine. Is it really better to learn how to think like a Virtual Machine (i.e. the machine software engineers would make if they were not too busy making software so they made it anyway)?
If the way computing machines work is confusing, well fsck, that's why you'll be around here four years child! And in fact, it's not that confusing. Confusing is being taught that computers behave like a virtual machine.
Give kids the cream niceness of high level safe scripting and interpreted languages when they have a framework to know what it's cost them. Then, they will still make that decision, but they won't try to code Corel Office in Java 1.
oh yeah, none of the people in the suburbs ever lived in the city to know for themselves how freaking great it is to walk around with tumble trash gently blowing downs the concrete slave ways.
In the suburbs you have to leave the house to do something. In the city is all right there for you, right? who's self centered.
I do hate the suburbs, but not for the reasons you state, and your confidence that urban living is better (which you imply, if I can tell) is totally off mark.
Frankly, the city could be the best place to live, but you'd all have to move underground.
... back to the drawing board ...
seriously, life in the US today is already like a utopia, say, compared with living in the middle ages. Consider... ancient cities were huge, millions of people like today... shitting in gutters! I think we have even further to go.
Utopia is not impossible unless by utopia you mean "impossibly great". The "great but possible" world has a lot to offer. Cities designed without cars might be one way. And who says we have to convert the whole world. After all, there are 6 Billion people, to make a little city with a million people is nothing, just a tiny little experiment. How would you get people to move there? hmmm, I'd say, "offer jobs".
they would not have to release their modifications. You only have to do that if you sell or distribute your system. So if they sold or gave their system to ESA it would have to come with the code.
all a part of the re-evaluation of values. It'll wear off.