Slashdot Mirror
The End of Native Code?
psycln asks: "An average PC nowadays holds enough power to run complex software programmed in an interpreted language which is handled by runtime virtual machines, or just-in-time compiled. Particular to Windows programmers, the announcement of MS-Windows Vista's system requirements means that future Windows boxes will laugh at the memory/processor requirements of current interpreted/JIT compiled languages (e.g. .NET, Java , Python, and others). Regardless of the negligible performance hit compared to native code, major software houses, as well as a lot of open-source developers, prefer native code for major projects even though interpreted languages are easier to port cross-platform, often have a shorter development time, and are just as powerful as languages that generate native code. What does the Slashdot community think of the current state of interpreted/JIT compiled languages? Is it time to jump in the boat of interpreted/JIT compiled languages? Do programmers feel that they are losing - an arguably needed low-level - control when they do interpreted languages? What would we be losing besides more gray hair?"
When your web-based-datastore gets 50,000 inserts per second, hovers between 15 and 20 billion rows and endures a sustained query rate of 43,000 queries per hour, tell me which part of it you want to coded in PHP.
As the overhead of interpreted languages gets smaller (through faster systems, JIT, and other optimizations), its inevitable that eventualy we'll all be using one (unless you are one of the few people who have to program the virtual machines, the JIT compilers, etc).
And this is a good thing, because it means more independance from certain CPU architectures.
Someday, you will be able to use any OS on any CPU and any Application on any OS. This is one step in that direction.
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
(a) 'loosing': oh jesus christ
(b) the obvious answer is that native vs interpreted is basically simply the balance of developer cost versus cost of end-user resources (ram, cpu, users time). Interpreted code is getting faster every day, no matter what "OMG JAVA IS SO SLOW DUDE" geniuses on the interweb tell you, but there'll always be problem spaces where a 5% speedup pays huge dividends.
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
Outside of introspection and like technologies there is no reason why code cannot be compiled natively. Linux users are aware of compiling java code natively, microsoft is working on a native c# compiler, so why is it that everyone else things it's still okay to compile to byte code or scripts. It's not; end of story. I do not like when every new processor that comes out is stomped on by new programs requiring more resources to do the same job. How many java programmers use runtime reflection or introspection? How many programs is it actually needed? If you're not using that, then you should compile natively. Just because Vista is wasting precious resources on it's silly aero glass, etc, doesn't make it right for everyone else too. What happens when someone tries writing a kernel in an interpreted language? Stage 3 bootloaders'll throw us into a JIT environment now. I could just imagine the efficiency there. Native languages are the way to go and we're in for big problems if they don't stay around.
Yeah... people keep saying that. Okay, lets take the benchmark I hear about most: http://kano.net/javabench/ "The Java is Faster than C++ and C++ Sucks Unbiased Benchmark". Unbiased my foot. "I was sick of hearing people say Java was slow" is not a good way to start an unbiased benchmark. Lets have a few more problems:
Y'know, I think there's a reason for that...
Y'know, a couple of decades ago I was running non-native applications on a 7Mhz system with 1MB RAM (my old A500). They were fast, but not quite as fast as native. I'm now using a system in the region of 500 times faster, in terms of raw CPU, and with 2,048 times more memory. And y'know what, non-native stuff is fast, but not quite as fast as native. Something about code expanding to fill the available CPU cycles, methinks...
Now find me one CPU that can do a decent simulation of the physics of continuous media. Why isn't there any game where you ride a surfboard realistically? Why do meteorologists use the most powerful number crunching systems in the world to be wrong in 50% of the cases when predicting weather a week ahead?
And what about artificial intelligence and neural networks? Find me a CPU that can do a decent OCR, or speech recognition. What about parsing natural language? Why can't I search in Google by abstract concepts, instead of isolated words?
No matter how powerful CPUs are, they are still ridiculously inadequate for a large range of real world problems. When you go beyond textbook examples, one still needs to squeeze every bit of performance that only optimized compilers can get.
Don't you hate that answer?
Yes, we are seeing more development in non-native code but, it gets it's power from the underlying libraries and core code that is native. The line between them gets fuzzy when you toss in JIT and scripting to native code compilers. It really depends on the problem area. If I'm just parsing apart a bunch of log files to make reports Perl or Python would be the best. Web apps seem to benefit from the safety net of non native code but I'm sure there are exceptions.
OTOH there are plenty of apps that need all the speed and memory the machine can provide. My current job involves real time financial data delivery. Writing that in Python or Java would (probably) not work out too well. OS code that works directly with hardware will probably stay in assembler or C. Fast low level stuff is what allows the slower high level stuff to be useful.
Either way you still need to know what you're doing because in the end both native code and interpreted code run as opcodes on a CPU and use hardware resources. You need to mind memory use in Java just like C. Just in different ways. You've need to watch what you do in inner loops in both Python and C++. Linear lookups can cause scaling problems in Perl, Java, Python or C/C++.
It all depends on how fast you want to get from problem to solution, how much hardware you can throw at it, how complicated the problem is, how much time you have and many other factors.
Languages are tools, not a religion. The broader your knowledge the more tools you have at your disposal. Pick the best one for the job at hand.
The obscure we see eventually. The completely obvious, it seems, takes longer. - Edward R. Murrow
Ok, assuming the post isn't flamebait... This issue keeps coming up. A good programmer should understand that the language choice depends on the task at hand.
If you're making a pretty GUI, you may want to use an easy-to-use and portable language and may not care about performance as much. If you're creating a high-performance backend, or doing some realtime processing, an interpreted language is practially useless.
Before deciding which paradigm is superior, you must narrow down the question to a type of task. Since the variety of tasks we use software for does not seem to be shrinking, it seems that this issue will not be resolved decisively anytime soon.
> It's starting [to] annoy me as much as people [who] can't tell they're from there from their.
... and you lot complain about China.
I'm not from there. I'm sorry if it annoys you, but, really, I'm not.
(You should probably put some quotes in there somewhere).
It's usually USians who get these things wrong, of course. Those I've talked to really don't seem to care much and explain it away as "evolution of the language".
I guess there's an argument there somewhere, but I look to history and find 'reports' of 'people' (iirc, Webster) deliberately changing the language - not out of ignorance, but just to piss off the English. It worked - and is still working.
Just another example of 'Embrace and extend' - part of the US culture (is that an oxymoron?). The USA is the 'Microsoft' of the English language - copy it, then change it so that it doesn't work properly with the original version.
If I had the opportunity to change the language, I would make more obvious changes, like remove silent letters.
Wow - you actually used 'correctly' correctly! Awesome! Obviously, you're not an Apple user, else you'd spell it different.
BTW, for anyone who's interested, it's not "British English", it's just "English". The Scotts, Welsh and Irish each have their own language - some even use them.
I'm a Software Engineering Consultant who works in the avionics industry. While the enterprise application market may be moving that way, avionics certainly is not. I program about 80% C code, 15% C++ (helper apps), and 5% Assembly Code. The cost involved in certifying any sort or interpreter or JIT compiler is not worth it to anyone doing saftey critical RTOS work. Any speed in application development would be offset by several orders of magnitude in the effort to make that language available to the embedded platform through a certification process which would likely take a large team of developers several years. And maybe by then the cost of the hardware will have dropped enough to support it. Right now the product I work on has 512kB of Flash and 1MB of RAM, and it runs on a ultra low power 20MHz processor.
But for all you folks working in the application sphere, I'm sure things are heading that way as portability becomes a larger issue between OS's and architectures as the market moves away from a Windows based x86 monoculture. But for those of us working on products that include hardware, extra cycles aren't in the budget since they drive up the per unit cost.
You seem very self-impressed. Fifteen years ago, before you were senile, I'm sure your benchmarks were of reasonable conclusions. Your C skills must have never been much to flaunt if they were compiling to a result 200 times slower than the "bare metal". I'm hoping for your sake that was exaggeration, but somehow I doubt it. The harsh reality is that working years of brilliant minds have pushed forward to develop compilers capable of pushing out code that would put your best work to shame. Optimizations you likely haven't thought of are regular passes in modern compilation.
JIT techniques, much like compiler optimizations, are developing day by day. Efficient caching techniques and dynamic recompilation and optimization are paving the way to an era of practical programming where an interpreted programming language can present comparable speeds to match against its compiled predecessors.
Like an old man harping about the "good ol' days", you are simply blinded by your years of experience and afraid of change. You cry "naivete" with respect to those who even suggest that there may be performance merits to interpreted languages while showing very little real-world modern figures or statistics. Naive! Naive! Naive!
Friend, blindly disregarding established JIT theory or advances in interpreted programming language performance sounds fairly naive to me.
Interpreted & JIT languages are "within a constant factor" of native code's speed, and CS students are taught that such things don't matter. ;-)
And for many types of apps, they really don't. Ten times slower than instantaneous, is instantaneous.
But people use computers for lots of things, and believe it or not, some of those things are still CPU-bound, and take so much work that humans can perceive the delay. Your word-processor is 99% idle so surely it doesn't need to be native, but you know that somewhere on this planet, a poor shmuck is staring at an hourglass icon, waiting for a macro to finish. The real question is: who cares? Is that guy's time worth more, or is the programmer's time worth more?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I was right with you until you started gushing about the beauty of assembly. You might be able to write a single, heavily-used subroutine in assembler, and make a thing of beauty out of it. But the moment you try to do something truly ambitious, you abso-friggin-loutely need layers of abstraction. CPU cycles are one thing you don't have an unlimited amount of. Brain cycles are another.
You want the truthiness? You can't handle the truthiness!
Firstly, the compiler doesn't spit out C. It spits out machine language, the same thing your assembler spits out.
In this day and age, the compiler is probably smarter than you are. It can be told which processor your executable is targetting and use its instruction set as appropriate. This is particularly important for x86 chips, as there have been a number of SIMD extensions added to the instruction set in the last 15 years.
15 years ago, 3D graphics on a computer was unheard of. Now, they are ubiquitous. Programming 3D graphics is theoretically possible with assembler, but it is a much better idea to use something like C and an API like OpenGL.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
One of the oldest analogies in computing is comparing algorithms to cooking recipes. We even have books like "Numerical Recipes" and "Perl Cookbook".
Well, to me, interpreted languages are like frozen dinners. They will do if you come home late at night and are too hurried and hungry to cook a proper meal. But C is like a fully equipped kitchen. It takes *much* more skill to cook a proper meal than to heat a frozen dinner in a microwave oven, but the results are incomparably better, not to mention the pleasure you get from doing it the right way.
... and only a compiler can write code to use SIMD extensions? You forget history - that originally, it was people abusing the fpu (in assembler) to have it process multiple chunks of data with one instruction that gave rise to SIMD extensions, formalizing what was already going on. We're seeing the same thing again, with people using the gpu on graphics cards to process non-video data.
Software will always expand to fill available resources with useless secondary gimmicks. I mean, look at Vista and its requirements. You would hope that when purchasing a PC that the available resources you are paying for will be used by applications you use. Instead, looks like the OS will be eating most of that up. It is the operating system's job to facilitate applicatons' access to resources, not to squander them on mostly useless (although arguably pretty) features.
Therefore, Lisp can't be used to create an operating system!
Heh, I love it when kiddies try to do logic. Learn some history, damnit!"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
So, the question is what is more important? Time to code or Time to run?
If you have a one-off task, and your developer costs money, you want quick-to-develop.
If you are going to run the program a bijillion times (a lot), you quick-to-run at whatever developer cost.
I've coded C++, Java, and .NET services that all did what they needed to do (long running data collection applications).
There is more than one way to skin a cat, and the end result all tastes good with enough hot sauce.
This issue is a bit more complicated than you think.
The problem isn't native-code vs interpretive code. It's that our native code languages are terribly flawed.
Programming backed itself into a corner with C and C++. They're useful languages, but they're not safe. Now this has nothing to do with performance; you can have safety in a hard-compiled language. Ada, the Modula family, and the Pascal/Delphi family did it. The problem is that, because of some bad design decisions in C (the equivalence of arrays and pointers being the big one), you have to lie to the language to get anything done. This makes safety hopeless. The basic problem of C is that you have to obsess on "who owns what" for memory allocation purposes, and the language gives you no help with this. The language doesn't even adequately address "how big is this". With those two design defects, we're doomed to have memory safety problems. Which we do.
C++ at first seemed like an improvement, but as it turned out, C++ adds hiding to C without improving safety. Note that this seems to be unique to C++; no prior language did that, and no language since has taken that route. Attempts have been made to work around the problem within the structure of C++, but with limited success. The "auto_ptr" debacle and the endless problems of trying to make sound reference-counted allocation work reliably indicate the fundamental limitations of the language. You just can't fix those problems in C++ without breaking backwards compatibility. (See my postings in comp.std.c++ over the last decade for more details on this.)
Java was invented mostly to get around the memory safety problems of C and C++. The fact that Java is usually semi-interpretive has nothing to do with the language design; that's a consequence of Sun's original focus on applets. There are native-code compilers for Java; GCC contains one. There are competitive advantages of locking the user into a giant environment (J2EE in the Java world, .NET in the Microsoft world), which is part of why we're seeing so much of that. But it's not a language design issue.
Microsoft came up with C# as their answer to Java, and most of the same issues as with Java apply.
What's so embarassing about all this is that it's quite fixable. The solutions were known twenty years ago. If you have a language where the language knows how big everything is, and the subscript checks are hoisted out of loops at compile time, you get safety with high performance. There were Pascal compilers that got this right in the 1980s.
On the allocation front, you can use either garbage collection or reference counting to automate that process. Java and C# are garbage-collected; Perl and Python are reference-counted, and in practice, programmers in those languages seldom have to think about memory allocation issues. Allocation overhead can also be hoisted out of loops. Java compilers are starting to do this, allocating temporary variables on the stack. Reference count updates can be optimized similarly. There's nothing to prevent using these techniques in a native-code compiler.
And that's how we got to where we are today, with buffer overflows, zombies, and blue screens of death, papered over with a layer of inefficient interpreters. Fortunately the hardware people have held up their end and made it possible to live with this, but we on the software side should have the understanding and grace to be embarassed by it.
A lot of folks use languages like PDL, IDL, MatLab, Octave, or even NumPy to do array processing, and tout the fact that for large arrays those languages run "essentially as fast as C". But that's bullshit. All those languages vectorize their operations in exactly the wrong order - if you have a hundred million datapoints and you want to do six operations on each one, each of those vectorized languages will dutifully swap each of your hundred million datapoints out of RAM into the processor, multiply it by seven (or whatever), and push it back out to RAM before pulling them all back in to add six to each one. What you really want is to vectorize in pipeline order, doing all the operations you plan to on each data point once and for all so that you can take advantage of your processor's nice, fast cache. Nobody has (to my knowledge) figured out a way to do that, that is robust enough for an interactive/JIT language, so just writing it in "C" and getting the loops nested in the right order can speed you up by a factor of more than 10 on a modern AMD or Intel CPU.
Why is it that as soon as processors get more powerful, memory becomes cheaper and hard disks get bigger, the next operating systems and applications suddenly need a lot more of it; but still present you with essentially the exact same thing?
Programs written in interpreted languages need higher systems specs to run at the speeds we are used to. Sure, the modern systems can handle it no problem; but shouldn't faster computers mean faster programs and response times? Instead we get the same or only slightly faster results because we program them in slower ways because it's easier and faster for us to do it that way. Maybe we're all just getting lazy.
And with operating systems, I mean Vista in particular: by the system requirements you can tell it's a resource hog. I was horrified by the system requirements of XP when it was released, and after I upgraded and started using it I asked myself: 'What was the big deal? How is this better than 2000 besides a shinier interface?' What about Vista requires the system specs it asks for? The even shinier interface?
One guess where 99% of the ccycles arae in that
I'll take a guess! And it's even the one you want me to guess. The db2 instance. That's the fucking *point*. The fast C code that's executing has already been written.. some of it is in the python interpreter, some it is in the ksh and php interpreters, most of it is in the db2 interpreter. Very fast algorithms doing what they do best: optimized, super fast loops operating on static types.
That is WHY python and other interpreted languages achieve the speed they achieve.. because what they do is allow you to glue together C code written by other people. And, because the Python code is much simpler, you can understand the interactions between the fast code more easily, and see where your code fails to perform well. It's always because you're putting loops together inefficiently and making poor design choices, not because of the speed of the interpreter--and now that your code is short enough for you to see that, you can fix it.
Your application logic doesn't need to be super fast. It needs to be super agile, so you can refactor and accommodate changing requirements and make smart decisions about which pieces you are going to use and how you are going to use them together.
C won't die, at least, not for a long, long time*, and that doesn't bother me, a hardcore Python programmer, in the least. Somebody has to do the dirty job of writing those fast loops. Meanwhile I'll be here zipping through the application implementation.
*It will eventually be replaced by Pyrex, of course.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
I think the parent has this almost completely backwards.
As the complexity of enviornments increases (many cores, multi-chip packages etc) it's going to be harder to compile a program to binary that can take advantage of the resources on all the systems it will run upon. It may work really well on one configuration, and may run on many, but it won't make the most of the resources in many cases.
VMs have access to information about the runtime environment and can dynamically compile byte codes to binary to take the best advantage of the available resources - some can even re-compile on the fly to tighten up performance based on feedback from the environment. From a developers POV a program can run on many platforms, and can run as well on all of them.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
I'm sick of cliched sensationalist articles with the sensationalist titles, how about you?
.NET this is pretty easy: "unsafe" sections and "managed" sections can originate in the same project and even the same source code, so you can optimize those critical 10% of your code where 90% of the time is spent (you prolly know the cliche), and use managed to take benefits of the advancements in the platform.
As always this is a non-existant problem hyped up by people that don't have a clue.
First, the performance hit of managed code is not "negligible". For tasks that rely on raw math power it can be significant, like 3D engines, data processing and so on.
But if you're doing, say, a rich client, your code will most likely just call existing multimedia, communication and input API-s. Then managed code's performance hit is next to nothing since most of the time is spent processing the commands from the API-s, not your own code anyway.
Thing is: can we drop the raw power of native code and go all managed: hell no. And we never will. While plenty of consumer applications have good performance on managed code, there will always be a class of professional software where 20% better performance means potentially tens of hundred of dollars saved for a middle-sized company.
But the big miss in the article is that managed and non-managed code can coexist. In
So wait, we were talking about end of what again?
The point is, if you're going to be waiting 50ms for disk access, why bother shaving 2ms of processing time by running in a native compiled language? Nobody will ever notice.
.net land though maybe its better there.
what they will notice is when the gc decides it needs to scan a memory area that has been swapped out crowding out any other IO on the system.
Average performance only matters for a few time consuming tasks (and they do still exist), what matters far more in end user apps is any apparent hangs, if a button takes 100ms to get a response i probablly won't notice unless i'm gaming. if a button takes 10ms 99% of the time and 1 second the rest then i damn well will notice despite the better average performance, app startup time is also a killer in terms of percived perfomance (and languages like java are terrible for this especilly the first run on boot).
And you may find the more modern and high-level design of the interpreted language's library allows you to write faster performing IO code more easily than the simple & low level libraries that are supplied with most compiled languages, at which point you may get better results for the same programming effort for using that language.
java.io really sucks for some types of apps as it basically forces you to have one thread per socket and the new java.nio isn't really any higher level than bsd sockets. I don't know what the situation is like over in
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
No sorry, the English spoken in England is called 'English'. It is the language of the English.
Americans speak an American version of English, hence 'American English'. And so on.
If your native code is running as slow as interpreted, I would really recommend getting that looked at. It would seem that people are losing the ability to write clean code since the crutch of interpreted languages is hiding so much of the finer grains of computer science.
First of all, when experienced programmers write big systems in interpreted languages, you can rest assured that they know what they are doing and are doing the benchmarks to make sure they aren't losing performance where they need it. If they need special, high-performance algorithms or libraries, they will figure out the minimal set of C/C++ primitives they need and make them a native code library inside the scripting language.
And whether code is "clean" really has nothing to do with the language. People can write clean Perl code and unclean C code.
Finally, "the finer grains of computer science" are absolutely and positively not concerned with the kind of low-level mess that C exposes.
I'm currently working on learning SDL in C/C++ for exactly that reason.
Good, so you are in a very early stage of your development as a programmer. As you mature, you'll figure out how to get the job done without wasting all your time on C/C++ programming.
In general, when experienced programmers use languages like Python or Ruby with native code plug-ins, or when they use languages like Java or C#, they produce code with better performance and fewer bugs than straight C/C++, simply because they end up having more time implementing good data structures and focussing their efforts where it counts.
There are several reasons.
.NET have already far surpassed Java desktop usage on their respective platforms (and Mono makes both sets of APIs cross-platform if you want).
.NET is a better platform for developing Windows apps anyway.
(1) Java's market presence for UI applications has been decreasing: applets have largely disappeared, and the JRE is preinstalled on fewer and fewer desktops.
(2) Even on OS X, where Java is pre-installed and exceptionally well supported and integrated, there are few applications written in Java, and even fewer written in Java using Swing.
(3) Java's UI classes don't integrate well with native desktops, and it is impossible with them to write a cross-platform UI that conforms to every target platform's conventions.
(4) Within the span of just a couple of years, Mono and
(5) Sun's licensing and compatibility requirements have made Java unattractive for Linux desktop distributions, and it seems doubtful that that will change (it looks like Sun may open source their implementation, but the specs will probably remain restrictive).
(6) As far as cross-platform GUIs go, the most widely used tools are wxWidgets, Qt, Tcl/Tk, and Gtk, plus their various language bindings (even Eclipse uses its own toolkit, not Swing).
But at some point Java/Swing programs will have accumulated enough performance and features that they are good enough for what people want to do, and they have the added advantage of not being tied to Windows.
And that attitude is why Java/Swing isn't succeeding. As a Linux and Mac user, I don't want cross-platform scraps thrown to me, I want high-quality applications that integrate well with my desktop. And given that people are creating those based on Gnome, KDE, ObjC-Cocoa, and Mono, I have no incentive for using Java applications. Of course, Windows users don't have any interest in third-rate Java replacements for their native apps either, and
Even better, the Gnome, KDE, and Mono apps even run on Windows, so that even Java's cross-platform aspects are uninteresting.
SUN seems to be in this Java business for the long haul,
Well, that's another problem: I think many people are unconvinced that Sun is in anything for the long haul; the company has serious problems.
- Any decent C++ programmer will always put the OS-specific code in an abstraction layer. C++ has many ways of allowing this, ranging from macro's to templates and everything in between. These features even enable portability without sacrificing speed, since the choice of function happens at compile-time. So this so-called portability issue just doesn't hold.
- For a lot of applications, optimal performance simply is the only way to get the job done. JIT Languages often have high-level objects providing functionality that takes lineair time where one would expect constant time performance. Building these objects yourself int a JIT language simply isn't going to make things run any faster, since the atomic components have to much overhead to be good candidates for such low-level operations. C++'s STL templates on the other hand have well-defined operation times. By the way, these lineair/constant time issues won't just go away as computers get faster.
- With JIT-languages, you have no control over the underlying virtual machine on which the program will be running if it's a program that will be downloaded by many people and run on a client machine. If that VM has a security flaw, then your program will have one too. With precompiled programs, you can choose your compiler and have full control over security. You can even decide to link statically to minimize the number of external dependencies that could be a security threat. He who controls (or manufactures for that matter) the VM also controls your program. God knows who's out there wanting your program to be less performant than theirs. And how will you ever find out?
And finally, just take a look at topcoder.com to see what programming language is used most by the people occupying the top 10 highest ranks. It's not a JIT language, but C++. That alone says a LOT to me.
Am I biased? I've written in both C++ and C#. While I even enjoyed writing in C#, I never felt the power as I felt while writing in C++. True, for every downside there's an upside to the JIT languages, but IMHO, the cons of the JITs just don't weigh up to their pros.
Native code will and should always be around.
And what if there's nothing behind the door until it is being opened?
I had a pentium 2 233 with 64 megs of ram and a 6 gig harddrive. I primarily used my computer to run windows, ms office, diablo, IE and Netscape, winamp, and an antivirus program. Today I have a brand new computer and do almost the same thing. I run a "better" version of windows and office, I have a "better" video game or two, I run a newer improved IE and Firefox, still have winamp but its "better" than the v2 I had, and I have antivirus from the same company. The only thing new is a divx player. So how come with 10 times the processing power and 8 times the memory and 50 times the harddrive space its not really all that much faster and in some ways it slower. Could it be how things are coded these days. No that can't be. Newer is better.
There is a philosophical reason to go to a high-level for all this. If you observe evolution in all its forms it always goes from low-level stuff to high-level stuff (from tools making to society behavior, with countless examples in all fields like business, economics, etc). In our brains, it just make sense for us to always think in ever-higher levels, because if we had to keep track of all the previous details we'd spend more time dealing with details than with the goals of what we're trying to accomplish.
Note that this is nothing new in software engineering. Most software a few decades ago was written in low-level code, even assembly language. If you did a survey then about the ratio of low-level to high-level coding, and compare it to a survey today, you'd realize that we do not even ponder about where things are going, as there is plenty of evidence today to tell us that going higher-level is the path the software industry is taking.
Native coding will become more and more of a niche, first to do Operating Systems, Drivers, Kernels and such. But eventually I can see even a fully-operational OS being written in a high-level language. In a sense that's what's happing today when you combine all the Web Services and tools we find today on the Web.
So, it's just a matter of time before everyone codes in high-level languages, and even today's high-level languages will seem low-level by what we're going to replace them in the future.
[i]It's "USians" to avoid using "Americans" to refer to 300 million people when there are legitimately over a billion people who can claim the name "American." [/i]
Wouldn't that logic make the Scottish and the Welsh "British"?
Just then the floating disembodied head of Colonel Sanders started yelling Everything You Know Is Wrong!-Weird Al
The level of control you need as a programmer is related to the work that you are doing. If you are writing an O/S, low level network app, embedded system app, etc, then you'd better have the control afforded by non-managed code. If you are just writing web-based business logic programs then higher level languages are a better fit. Overall though, as they move languages to fit the lowest common denominator those of us that were forced to learn the lower languages will find their value increased. Not to mention that those understand the more diffcult programming concepts encompassed by managing memory or multithreading are going to better grasp other languages and complex concepts (if you don't believe me, study compliers and see how related all programming language concepts are).
Now who else thinks the first 100 comments on this thread are what make slashdot a venting forum for offtopic issues?
- Kal`Goblez
Well it's time for another opportunity for Java to take off on the client side. I think it might have a chance should a couple of things happen.
First, Sun needs to open source Java. There are tons of bugs in Swing and that section of the code could benefit the most from the open source community in my opinion. Sun has been negligent of Swing off and on in favor of more profitable ventures on the server or on mobile phone specific stuff. If, instead of voting on your highest priority bug on sun's dev site, people were actually able to *fix* bugs...If, it were set up so that new features could be added fairly quickly, Sun could see Swing swing into action. If they don't open source Java or have too much bureaucratic work involved, then Swing might just be left as a hobbyist prototype-like portion of Java.
Second, I wonder if SWT will catch on. Eclipse is doing some very good work with 3.2 and the synchronized release of several projects in Callisto (http://www.eclipse.org/callisto). They are making it easier to do SWT client-side apps. If they execute well and developers pick up on this, Java could also make it big on the desktop.
I think both have to occur for Java to really take off on the client side though. We'll see.
But, of course, then you are distorting the meaning of the statement. The original statement, as written, means "there is not a single ticket tracker written in Zope that is comparable to Eventum." When you change the language like you have, it now can be taken to mean "any ticket tracker written in Zope will not be as good as Eventum" -- which might be true, but is not what the parent was trying to say. The correct way to rephrase it would be:
And, as usual, the real lesson is that if you're going to be a self-righteous pedant, you should at least know what the fuck you're talking about, or else leave the English language to the professionals.
If I had to have a programmer code a not-so-trivial application for me, then...
I wouldn't trust him to do it properly if he had no experience with low-level languages, because it is my opinion that a good coder must understand what happens between his code and the hardware aswell as he should have some knowledge about optimization and mission-critical algorithms*.
I wouldn't pay him if he had no experience with high-level languages, because he'll end up using too much time coding and optimizing instead of planning and designing the application structure, management, etc.
Of course, if I needed a non-mission-critical GUI-app to be coded within a short timeframe, I certainly wouldn't ask for a programmer with years of C-experience, but still the additional knowledge wouldn't hurt.
Once again, The-right-tool-for-the-right-job (tm) is the way to go.
Replacing most of the native code with interpreted one? Nah. You wouldn't want your database software/search engine/OS/compilers (calm down, just kidding) coded in a high-level language, would you?
IMO, low-level won't die, since there will always be need for mission-critical programs... and there's still something the high-level code needs to run on.
*Yes, these are necessary. How many search- and sort-algorithms do you know and know how to code? How many modern applications can do without? How many of those algorithms can be, of course after some optimization, executed in C (or Assembler if you really need those cycles...) much faster than in any high-level language?