FYI: Allocating on the stack is usually more efficient in time and space than allocating memory on the heap. The speed difference in allocating a static 1K buffer and a dynamic, variable size buffer outweighs the size or flexibility issues while in the kernel.
If a kernel coder can't keep there messages under 1K, you've got worse problems than a rigid API. If you want type safety, you should be using C++ and compile-time type traits. If you want raw speed for an internal kernel API in C, you expect a tradeoff in the lack of bounds checking (which has a non-trivial overhead in large quantities).
And his reasons for resisting the kernel debugger were not so cavalier as "real men grok the code." His assertion was that a proper design should not allow random errors to occur. His assertion was that the debugger encouraged a quick hack/variable test instead of looking at the overall picture of whether or not the implementation was inherently flawed.
I'd agree with you if MS hadn't put in a handler for the escape key since Win95. Want all those annoying messages? Hit escape on boot. Don't want splash screen to ever appear? Delete the splash screen image.
Don't get your panties in a bunch over nothing. Even NT/2K has a way of watching the boot process. I'd just as soon that distributions shipped with the Linux Progress Page patch. If "real geeks" want to see the messages, since they are recompiling the kernel anyway (right? right!?!), they can just choose not to have the flashy screen.
Isn't choice wonderful?
The new user doesn't understand the messages going by. The new user doesn't care about the messages going by. The new user wants to check their email, browse the web, and write their reports. I think it's quite appropriate that the default should be sans informational messages. The technical user is more adept at changing the option, so leave it to the more adept user to change the option.
I'm seeing 14,850 bytes for an unstripped build with g++ and 4,194 for the stripped build.
Now let's perform a couple of very simple C++ optimizations: put the filename in the ofstream constructor and pass the character '1' instead of the character string "1".
#include <fstream>
int main () {
ofstream out( "/proc/sys/kernel/sysrq" );
out << '1';
return 0;
}
With these changes, I get 14,738 bytes for the unstripped build and 4,114 bytes for the stripped build.
Bigger than the C code by only ~800 bytes, and definitely not 354K or 71K.
On my Dell 4400 with 2G of RAM and 2 933MHz PIII and NetGear 2Gbit NICs
I achieve about 2500 SpecWeb99 connections, with both X15 and
TUX (actually X15 is sligtly faster, some 20 connections more...;)
Faster than TUX, I can see. 2-3 times faster than TUX 1.0, I could possibly swallow. 2-3 times the speed of TUX 2.0 is just plain wrong.
Moderators! Don't you even bother looking for the supporting data? The item about Cheetha being 100-1000 times faster should have tipped you off that this person pulled those numbers out of his ass! If the Cheetha server can do what it says -- I for one am skeptical given this guy's list of "facts" so far -- it most certainly isn't running on anything remotely resembling a Dell 4400.
Point number two: TUX and Apache do not compete. If TUX finds that it the file you requested does not exist or that you requested a URL that has been flagged as unserveable (dynamic content), it passes the request on to user-space for something like Apache to handle. Apache, in this case, knows nothing about the go-between and reacts as though it were the only web server on the system.
Moderators! Send this guy to the hole! Meta-moderators! Make sure that the people who modded this up get slapped!
Before people continue to fly off the handle about kernel bloat, kernel-space vs. user-space, et al, please take the time to read one of Ingo Molnar's comments on X-15 vs. TUX.
Apparently there is so little time spent in TUX-specific code (~2% of the total transaction), that other implementations, even user-space solutions, end up using a large portion of what we would consider TUX code. That shared codebase is known as the 2.4 kernel. The arguments thus far may have more to do with aesthetics than functionality or security.
If people are really worried about TUX which only handles static files by default and is fairly strict in the requests it will serve, what about NFS?
NFS has been in the kernel for a long time, does just everything that TUX does (network file distribution) and more, is far more complex, has had well known security problems, has had well known performance problems, and people are worried about hypothetical, *potential* problems in TUX!?!
The ideal debug/log system should take a single line to invoke, and not have additional overheads.
No, this is not the ideal. You are oversimplifying the truth. In large projects, it is desirable to keep logging abstracted from the problem at hand, allow output to varying targets (not just ever-growing logfiles), allow multiple log levels (DEBUG, INFO, WARNING, etc.), make output format easily configurable, AND it should be fast.
Log4J has all of these attributes and more. As for complexity, you have a single configuration file where you specify your log targets and invocation requires only n+1 statements. That last point means that you get a reference to your log output handler (the "+1") and put in your logging statements (the "n"). Have you even tried using it or are you just talking out of your ass?
With regards to speed,
On a 233 MHz ThinkPad running JDK 1.1.7B, it costs about 46 nanoseconds to determine if that statement should be logged or not. Actual logging is also quite fast, ranging from 79 microseconds using the SimpleLayout, 164 microseconds using the TTCCLayout and around a millisecond when printing exceptions.
With regards to size, the core library is 78K. The complete library (core + utility classes that you can mix and match to your needs) is 159K. Not all that much to add to a general library distribution. Is this going to make or break your hard drive capacity or is this simply an aesthetic gripe?
Sun is on a mission to create the Ultimate Set of APIs, and call it Java. The "community" is on a mission to get everything they don't want to do themselves shoved into an Ultimate Library.
So are you complaining that people want to reuse code or that they don't want to waste time reinventing the wheel (two sides of the same coin)?
And finally, your C++ anecdote is somewhat misleading. I think you're taking for granted that the standard C and C++ libraries are installed by default on many systems. If the JRE were installed by default and you were not including its size, your Java programs would be the smaller download/install. Is the Java standard library large? Yep. Does it do more than the C and C++ standard libraries? Yep. Should the C and C++ standard libraries do more? Yep.
Socket communication, GUI, distributed computing, threads, file I/O, component technology, database access, and on and on. Yes, it's a long list. The list is also there for C and C++, but on a far larger scale. Not only do your customers have to install the C/C++/Pascal/Fortran/Ada libraries for your particular task (CORBA implementations anyone?), but they must also install all of the library competitors that the other packages chose to use (database API implementations anyone?).
When I'm writing a program that is handling hundreds or thousands monetary transactions, I do not want to write my own database abstraction layer. It is not my core business. I do not want to write my own ORB. It is not my core business. I do not want to write my own logging infrastructure. It is not my core business. Other people have written these things and written them well. Unless there is a particular case where I think I can do it much better and actually find the time to do so (I haven't yet found a case like this in the Java standard library), there is absolutely NO reason for me to write it myself except maybe for educational purposes.
If you don't like Java, then don't use it. If you want to take advantage of what Java provides, don't be so quick to look a gift horse in the mouth. You begin to sound like Microsoft when they say that Open Source is bad, but turn around and use some BSD code. Java is not perfect but neither is your chosen saviour, C++. Use the right tool for the job instead of trying to band a square peg into a round hole.
Not if you use jikes (IBM) or use tools.jar by itself (which is what Tomcat does to process JSPs). This issue was talked about a couple of years ago (when JSPs were first announced) and the solution was a relaxation of the distribution terms for some of the basic compilation tools.
Yes, you will still need the JRE, but isn't that similar to saying that you will need the C++ runtime library to run dynamically linked C++ programs? Or the standard C library? The only difference is that you are used to the last two being installed for you. The JRE comes on many install disks nowadays. It just isn't installed by default.
rpm -Uvh or apt-get or tar xzvf or./install.sh.
Or you could play with the new java tools coming out of Cygnus and the GCC project which allows native compilation. Then it really is just a matter of installing the program and a shared library. Hardly unreasonable.
Port scanning is like looking at a house from across the street. The equivalent of "crawling around someone's house rattling doorknobs, windows, mailboxes, air ducts, rooftop hatches, basement doors, garage doors, electric panel doors, gas valves, water valves, sewer vent lines, outdoor outlets, chimney openings, stove vents" is sending known exploit code to the port in order to see if you can get unauthorized access. It's not even like looking in the windows. A port scan tells you nothing more about a computer than seeing that a window on the second floor has been left open.
The first could be used in the sense of "casing the joint," but it could also be a case of looking at the architecture of the houses on the block without the owners' permission. It may make some people uncomfortable, but it's hardly illegal. A port scan is the closest thing to a look-but-don't -touch on the Net today.
If port scanning is found to be illegal, would a bare ping to see if a site is up and running be made illegal in the future as well? Beware the slippery-slope. We need to make sure that there is a difference in law between commiting a crime and having the potential to commit a crime.
If a script kiddie starts trying known exploits against your box, THAT should be seen as a crime. They are totally trying the vents to see if it's loose so that they can gain access. This is a clear, distinct, and unambiguous step beyond a port scan.
Yup, it's the problem that Microsoft tries to solve with COM and Mozilla with XPCOM. You run into packaging issues with each class as a separate library not to mention scaling issues with so many dynamic library loads. This is why (XP)COM uses GUIDs (Globally Unique IDs). But we are agreed that Java does it cleaner.
Python is a great platform too. After reading through all of the discussions on this topic, I would recommend Python to that VB coder.
Nice to know. Disclaimer: I haven't used PHP at all. But then, if you have a functional source size limit of 50k lines -- if your OO code doesn't scale -- then what's the point in using OO in PHP for the job? One of the principle reasons for using OOP is for the management of large programming projects. If the code is that small, you might as well use a procedural model.
I would also wonder about the speed of your example. Isn't that the equivalent of multiple eval statements and require multiple passes through the source to run?
Note: I know a company that has a huge amount of OO Perl as its software backbone. I realize that it can be done, but I liken it to using a screwdriver to drive a nail through a two-by-four.
I suppose you could always just produce a.java file, compile it, load it and run it, but that's hardly comparabile, speed and ease wise.
Funny, I thought that's what JSP does for servlets and XSP does for Cocoon generators. More than speedy enough and more than one group is doing it so it can't be all that impossible to implement. Admittedly the ASF and Sun are industry leaders, but then so are the developers of PHP, Perl and Python.
C++ or C is good for GUIs? Ummm... Which toolkit? Oh *that's* right! There are twenty billion of them and no cohesive patterns among them. Java's GUI toolkits (AWT and Swing) have their shortcomings, but at least they're consistent and encourage others to write consistent APIs when extending the built-in toolkits.
I disagree. Starting with Python or Perl is far less frustrating for a relative beginner. The majority of people who start with C stop programming or go into Visual Basic remission. Just because pointers are easy for you and I now doesn't mean they are easy for beginners. Better to learn good programming habits and clean algorithms than fight with malloc and dangling pointers.
Once they master a scripting language and need more speed or specialization, C or C++ will be the next step. Algorithm differences beat language differences 90% of the time. Except for large-scale processing tasks, language speed differences only amount to a few seconds. Programming time is much more than a few seconds with C vs. a scripting language. Hardware is cheap. People are expensive.
Use C is the task fits C's solution set. Otherwise use Java, Perl, Python or whatever happens to fit your problem best.
mindstrm is correct that learning a language is dulled by the use of an IDE. However use an IDE if getting problems done quickly is more important to you than becoming a better coder. I'd recommend learning a language, but to each their own.
As long as that C or C++ isn't learned with Visual Studio. While VS *can* do reasonably standards-compliant code, it is too easy to use a MS-specific API and assume that it is C or C++. Considering that MS has effectively stopped development for Java, it's less of an issue.
<rant>To all those folks who use the term C/C++ as though they were parts of the same animal, please stop. Sure, you can compile (pre-C99) C code in a C++ compiler, but then you're coding in C and not C++. C has only slightly more in common with C++ as C has with Java. C++ is more than a couple of new keywords for C.</rant>
Note: This is not an attack on James Foster, just a general rant.
Java is not more powerful than C. Given sufficient (a lot of) effort, C can do what Java does and a lot that Java cannot. They are different tools for different jobs. Kernel code in Java anyone? Yuck.
As for Java being more dynamic than C++, it depends where you want the dynamism. Java is more dynamic at runtime. C++ is more dynamic at compile-time. No argument about Java being simpler than C++ though.
Less dynamic than Perl or PHP? What are the Perl or PHP equivalents of the Java idiom
Class newClass = Class.forName( "some.java.class.name" );
Interface if = (Interface)newClass.newInstance();
Perl people, please don't answer with some ridiculous 30 line hack using "require" or "use."
And what about distributed computing (RMI and CORBA)? Thread handling (possible in Perl, but not pretty)? JavaBeans? EJBs? I think you mean that Java is a more strict environment, not that it is less dynamic.
Personally, I am of the camp that believes that simpler languages should be used for learning. I learned Pascal and C first, but I think I would have been better served starting with Perl or Python. Very little is gained from frustrating people out of the profession when you should be teaching them basic (no pun intended) programming skills.
Moot point anyway in that this person is starting from a VB background, but programming idioms are more important than syntactic sugar. And IDEs usually hide a good portion of the language behind RAD tools anyway.
I recently bought 512MB PC133 SDRAM for $150 (two 256MB DIMMS) from a local retail shop. I know of few programmers that can't spare $150 for a half gig of RAM.;) Prices vary according to area (I live in Santa Cruz, CA, US) but even if it's double where you live, 256MB for $150 is still not that bad.
I say use whatever IDE the heart desires. Computer parts are cheaper than your time waiting for it process your source, forms, etc. And considering the fragility of Forte, for example, more memory helps (re)start times.
You're thinking of the Honda Insight. The Insight makes the trade of lower horsepower in exchange for 70MPG.
The gas engine *alone* on the Prius is 70hp @4,500rpm. The electric motor is 44hp @1,040rpm-5,600rpm. Gas engine + electric motor on the Prius is 114hp equivalent max.
Unlike the Insight, the Prius uses *both* for moving the car. I can accelerate quite well up steep hills. Have you ever test-driven one? Contrary to your thoughts about a car that you obviously don't own, the Prius is no slouch. In fact, most people who have gone for a ride in my car refer to it as the future of cars in general. Aside from it being exceptionally quiet, they are astounded to learn that it is a hybrid vehicle.
In addition, except for very short trips for which you should be walking or riding a bike anyway, diesels such as the Peugot 206 are more polluting. The Peugot 206 also does not pass California emmisions standards whereas the Prius exceeds them enough to qualify as a SULEV (Super Ultra-Low Emmisions Vehicle). As such, I can drive in the carpool lanes without a passenger (you get the sticker at the local CHP office).
Hell, don't take my word for it. Get it from the horse's mouth and stop spreading FUD.
Catalytic converters are indeed basically useless (and even counter-productive) for very short distances, but standard diesel fuel has higher nitrogen oxide emmisions due to the high sulpher content in fossil fuel diesel. The excess sulpher makes filtering the output (what a catalytic converter does for an unleaded fuel vehicle) for NOx harder.
Biodiesel lacks sulpher so making an emmisions filter for it is much easier. That and it's a renewable resource.
I must say that I agree with one of the other posts today; It's time for a hybrid diesel/electric vehicle. Just as long as it's biodiesel.
"Recycled" cooking oil? I think you're talking about biodiesel. The last I heard, there was no recycling going on. They grow crops (such as the soybean) for the explicit purpose of making it. The only recycling going on is being done by Mother Earth.
It is cool though. Most people are using blends (part biodiesel, part standard diesel) because the fossil fuel is currently cheaper. Not by much, but more than enough to cut into trucking profits. Luckily, standard diesel and biodiesel mix well so the infrastructure can gradually get up to speed.
Slashdot Mirror
How about the error in IE 5.x that you get when you try to programmatically add an option to an empty dropdown box:
Internal Error
A modal dialog box that, when you hit OK, the browser closes. Thank god they didn't put any unecessary messages in there.
FYI: Allocating on the stack is usually more efficient in time and space than allocating memory on the heap. The speed difference in allocating a static 1K buffer and a dynamic, variable size buffer outweighs the size or flexibility issues while in the kernel.
If a kernel coder can't keep there messages under 1K, you've got worse problems than a rigid API. If you want type safety, you should be using C++ and compile-time type traits. If you want raw speed for an internal kernel API in C, you expect a tradeoff in the lack of bounds checking (which has a non-trivial overhead in large quantities).
And his reasons for resisting the kernel debugger were not so cavalier as "real men grok the code." His assertion was that a proper design should not allow random errors to occur. His assertion was that the debugger encouraged a quick hack/variable test instead of looking at the overall picture of whether or not the implementation was inherently flawed.
I'd agree with you if MS hadn't put in a handler for the escape key since Win95. Want all those annoying messages? Hit escape on boot. Don't want splash screen to ever appear? Delete the splash screen image.
Don't get your panties in a bunch over nothing. Even NT/2K has a way of watching the boot process. I'd just as soon that distributions shipped with the Linux Progress Page patch. If "real geeks" want to see the messages, since they are recompiling the kernel anyway (right? right!?!), they can just choose not to have the flashy screen.
Isn't choice wonderful?
The new user doesn't understand the messages going by. The new user doesn't care about the messages going by. The new user wants to check their email, browse the web, and write their reports. I think it's quite appropriate that the default should be sans informational messages. The technical user is more adept at changing the option, so leave it to the more adept user to change the option.
Now let's perform a couple of very simple C++ optimizations: put the filename in the ofstream constructor and pass the character '1' instead of the character string "1".
With these changes, I get 14,738 bytes for the unstripped build and 4,114 bytes for the stripped build.
Bigger than the C code by only ~800 bytes, and definitely not 354K or 71K.
FYI: I am on a relatively stock RedHat 7.1.
How does it get 900 miles per tank when it gets 45-55MPG and has a 11.9 gallon tank?
I love my Prius, but I still get closer to 500 miles per tank.
Faster than TUX, I can see. 2-3 times faster than TUX 1.0, I could possibly swallow. 2-3 times the speed of TUX 2.0 is just plain wrong.
Moderators! Don't you even bother looking for the supporting data? The item about Cheetha being 100-1000 times faster should have tipped you off that this person pulled those numbers out of his ass! If the Cheetha server can do what it says -- I for one am skeptical given this guy's list of "facts" so far -- it most certainly isn't running on anything remotely resembling a Dell 4400.
Point number two: TUX and Apache do not compete. If TUX finds that it the file you requested does not exist or that you requested a URL that has been flagged as unserveable (dynamic content), it passes the request on to user-space for something like Apache to handle. Apache, in this case, knows nothing about the go-between and reacts as though it were the only web server on the system.
Moderators! Send this guy to the hole! Meta-moderators! Make sure that the people who modded this up get slapped!
Before people continue to fly off the handle about kernel bloat, kernel-space vs. user-space, et al, please take the time to read one of Ingo Molnar's comments on X-15 vs. TUX.
n el /0104.3/0814.html
http://www.uwsg.indiana.edu/hypermail/linux/ker
Apparently there is so little time spent in TUX-specific code (~2% of the total transaction), that other implementations, even user-space solutions, end up using a large portion of what we would consider TUX code. That shared codebase is known as the 2.4 kernel. The arguments thus far may have more to do with aesthetics than functionality or security.
If people are really worried about TUX which only handles static files by default and is fairly strict in the requests it will serve, what about NFS?
NFS has been in the kernel for a long time, does just everything that TUX does (network file distribution) and more, is far more complex, has had well known security problems, has had well known performance problems, and people are worried about hypothetical, *potential* problems in TUX!?!
Would that be a stoned OS? Just provide pot and wait for the computer to decide to start processing...
No, this is not the ideal. You are oversimplifying the truth. In large projects, it is desirable to keep logging abstracted from the problem at hand, allow output to varying targets (not just ever-growing logfiles), allow multiple log levels (DEBUG, INFO, WARNING, etc.), make output format easily configurable, AND it should be fast.
Log4J has all of these attributes and more. As for complexity, you have a single configuration file where you specify your log targets and invocation requires only n+1 statements. That last point means that you get a reference to your log output handler (the "+1") and put in your logging statements (the "n"). Have you even tried using it or are you just talking out of your ass?
With regards to speed,
With regards to size, the core library is 78K. The complete library (core + utility classes that you can mix and match to your needs) is 159K. Not all that much to add to a general library distribution. Is this going to make or break your hard drive capacity or is this simply an aesthetic gripe?
So are you complaining that people want to reuse code or that they don't want to waste time reinventing the wheel (two sides of the same coin)?
And finally, your C++ anecdote is somewhat misleading. I think you're taking for granted that the standard C and C++ libraries are installed by default on many systems. If the JRE were installed by default and you were not including its size, your Java programs would be the smaller download/install. Is the Java standard library large? Yep. Does it do more than the C and C++ standard libraries? Yep. Should the C and C++ standard libraries do more? Yep.
Socket communication, GUI, distributed computing, threads, file I/O, component technology, database access, and on and on. Yes, it's a long list. The list is also there for C and C++, but on a far larger scale. Not only do your customers have to install the C/C++/Pascal/Fortran/Ada libraries for your particular task (CORBA implementations anyone?), but they must also install all of the library competitors that the other packages chose to use (database API implementations anyone?).
When I'm writing a program that is handling hundreds or thousands monetary transactions, I do not want to write my own database abstraction layer. It is not my core business. I do not want to write my own ORB. It is not my core business. I do not want to write my own logging infrastructure. It is not my core business. Other people have written these things and written them well. Unless there is a particular case where I think I can do it much better and actually find the time to do so (I haven't yet found a case like this in the Java standard library), there is absolutely NO reason for me to write it myself except maybe for educational purposes.
If you don't like Java, then don't use it. If you want to take advantage of what Java provides, don't be so quick to look a gift horse in the mouth. You begin to sound like Microsoft when they say that Open Source is bad, but turn around and use some BSD code. Java is not perfect but neither is your chosen saviour, C++. Use the right tool for the job instead of trying to band a square peg into a round hole.
Not if you use jikes (IBM) or use tools.jar by itself (which is what Tomcat does to process JSPs). This issue was talked about a couple of years ago (when JSPs were first announced) and the solution was a relaxation of the distribution terms for some of the basic compilation tools.
./install.sh.
Yes, you will still need the JRE, but isn't that similar to saying that you will need the C++ runtime library to run dynamically linked C++ programs? Or the standard C library? The only difference is that you are used to the last two being installed for you. The JRE comes on many install disks nowadays. It just isn't installed by default.
rpm -Uvh or apt-get or tar xzvf or
Or you could play with the new java tools coming out of Cygnus and the GCC project which allows native compilation. Then it really is just a matter of installing the program and a shared library. Hardly unreasonable.
Port scanning is like looking at a house from across the street. The equivalent of "crawling around someone's house rattling doorknobs, windows, mailboxes, air ducts, rooftop hatches, basement doors, garage doors, electric panel doors, gas valves, water valves, sewer vent lines, outdoor outlets, chimney openings, stove vents" is sending known exploit code to the port in order to see if you can get unauthorized access. It's not even like looking in the windows. A port scan tells you nothing more about a computer than seeing that a window on the second floor has been left open.
The first could be used in the sense of "casing the joint," but it could also be a case of looking at the architecture of the houses on the block without the owners' permission. It may make some people uncomfortable, but it's hardly illegal. A port scan is the closest thing to a look-but-don't -touch on the Net today.
If port scanning is found to be illegal, would a bare ping to see if a site is up and running be made illegal in the future as well? Beware the slippery-slope. We need to make sure that there is a difference in law between commiting a crime and having the potential to commit a crime.
If a script kiddie starts trying known exploits against your box, THAT should be seen as a crime. They are totally trying the vents to see if it's loose so that they can gain access. This is a clear, distinct, and unambiguous step beyond a port scan.
Yup, it's the problem that Microsoft tries to solve with COM and Mozilla with XPCOM. You run into packaging issues with each class as a separate library not to mention scaling issues with so many dynamic library loads. This is why (XP)COM uses GUIDs (Globally Unique IDs). But we are agreed that Java does it cleaner.
Python is a great platform too. After reading through all of the discussions on this topic, I would recommend Python to that VB coder.
Nice to know. Disclaimer: I haven't used PHP at all. But then, if you have a functional source size limit of 50k lines -- if your OO code doesn't scale -- then what's the point in using OO in PHP for the job? One of the principle reasons for using OOP is for the management of large programming projects. If the code is that small, you might as well use a procedural model.
I would also wonder about the speed of your example. Isn't that the equivalent of multiple eval statements and require multiple passes through the source to run?
Note: I know a company that has a huge amount of OO Perl as its software backbone. I realize that it can be done, but I liken it to using a screwdriver to drive a nail through a two-by-four.
Funny, I thought that's what JSP does for servlets and XSP does for Cocoon generators. More than speedy enough and more than one group is doing it so it can't be all that impossible to implement. Admittedly the ASF and Sun are industry leaders, but then so are the developers of PHP, Perl and Python.
Beginners need to work too. ;-)
C++ or C is good for GUIs? Ummm... Which toolkit? Oh *that's* right! There are twenty billion of them and no cohesive patterns among them. Java's GUI toolkits (AWT and Swing) have their shortcomings, but at least they're consistent and encourage others to write consistent APIs when extending the built-in toolkits.
I disagree. Starting with Python or Perl is far less frustrating for a relative beginner. The majority of people who start with C stop programming or go into Visual Basic remission. Just because pointers are easy for you and I now doesn't mean they are easy for beginners. Better to learn good programming habits and clean algorithms than fight with malloc and dangling pointers.
Once they master a scripting language and need more speed or specialization, C or C++ will be the next step. Algorithm differences beat language differences 90% of the time. Except for large-scale processing tasks, language speed differences only amount to a few seconds. Programming time is much more than a few seconds with C vs. a scripting language. Hardware is cheap. People are expensive.
Use C is the task fits C's solution set. Otherwise use Java, Perl, Python or whatever happens to fit your problem best.
mindstrm is correct that learning a language is dulled by the use of an IDE. However use an IDE if getting problems done quickly is more important to you than becoming a better coder. I'd recommend learning a language, but to each their own.
As long as that C or C++ isn't learned with Visual Studio. While VS *can* do reasonably standards-compliant code, it is too easy to use a MS-specific API and assume that it is C or C++. Considering that MS has effectively stopped development for Java, it's less of an issue.
<rant>To all those folks who use the term C/C++ as though they were parts of the same animal, please stop. Sure, you can compile (pre-C99) C code in a C++ compiler, but then you're coding in C and not C++. C has only slightly more in common with C++ as C has with Java. C++ is more than a couple of new keywords for C.</rant>
Note: This is not an attack on James Foster, just a general rant.
Java is not more powerful than C. Given sufficient (a lot of) effort, C can do what Java does and a lot that Java cannot. They are different tools for different jobs. Kernel code in Java anyone? Yuck.
As for Java being more dynamic than C++, it depends where you want the dynamism. Java is more dynamic at runtime. C++ is more dynamic at compile-time. No argument about Java being simpler than C++ though.
Less dynamic than Perl or PHP? What are the Perl or PHP equivalents of the Java idiom
Perl people, please don't answer with some ridiculous 30 line hack using "require" or "use."
And what about distributed computing (RMI and CORBA)? Thread handling (possible in Perl, but not pretty)? JavaBeans? EJBs? I think you mean that Java is a more strict environment, not that it is less dynamic.
Personally, I am of the camp that believes that simpler languages should be used for learning. I learned Pascal and C first, but I think I would have been better served starting with Perl or Python. Very little is gained from frustrating people out of the profession when you should be teaching them basic (no pun intended) programming skills.
Moot point anyway in that this person is starting from a VB background, but programming idioms are more important than syntactic sugar. And IDEs usually hide a good portion of the language behind RAD tools anyway.
I recently bought 512MB PC133 SDRAM for $150 (two 256MB DIMMS) from a local retail shop. I know of few programmers that can't spare $150 for a half gig of RAM. ;) Prices vary according to area (I live in Santa Cruz, CA, US) but even if it's double where you live, 256MB for $150 is still not that bad.
I say use whatever IDE the heart desires. Computer parts are cheaper than your time waiting for it process your source, forms, etc. And considering the fragility of Forte, for example, more memory helps (re)start times.
I stand corrected.
Très cool!
You're thinking of the Honda Insight. The Insight makes the trade of lower horsepower in exchange for 70MPG.
The gas engine *alone* on the Prius is 70hp @4,500rpm. The electric motor is 44hp @1,040rpm-5,600rpm. Gas engine + electric motor on the Prius is 114hp equivalent max.
Unlike the Insight, the Prius uses *both* for moving the car. I can accelerate quite well up steep hills. Have you ever test-driven one? Contrary to your thoughts about a car that you obviously don't own, the Prius is no slouch. In fact, most people who have gone for a ride in my car refer to it as the future of cars in general. Aside from it being exceptionally quiet, they are astounded to learn that it is a hybrid vehicle.
In addition, except for very short trips for which you should be walking or riding a bike anyway, diesels such as the Peugot 206 are more polluting. The Peugot 206 also does not pass California emmisions standards whereas the Prius exceeds them enough to qualify as a SULEV (Super Ultra-Low Emmisions Vehicle). As such, I can drive in the carpool lanes without a passenger (you get the sticker at the local CHP office).
Hell, don't take my word for it. Get it from the horse's mouth and stop spreading FUD.
Catalytic converters are indeed basically useless (and even counter-productive) for very short distances, but standard diesel fuel has higher nitrogen oxide emmisions due to the high sulpher content in fossil fuel diesel. The excess sulpher makes filtering the output (what a catalytic converter does for an unleaded fuel vehicle) for NOx harder.
Biodiesel lacks sulpher so making an emmisions filter for it is much easier. That and it's a renewable resource.
I must say that I agree with one of the other posts today; It's time for a hybrid diesel/electric vehicle. Just as long as it's biodiesel.
"Recycled" cooking oil? I think you're talking about biodiesel. The last I heard, there was no recycling going on. They grow crops (such as the soybean) for the explicit purpose of making it. The only recycling going on is being done by Mother Earth.
It is cool though. Most people are using blends (part biodiesel, part standard diesel) because the fossil fuel is currently cheaper. Not by much, but more than enough to cut into trucking profits. Luckily, standard diesel and biodiesel mix well so the infrastructure can gradually get up to speed.