I'm sure there will be a reward for the first compiler that can compile itself for a quantum computer from a quantum computer.
On a side note, I really don't think quantum computers will overrun the market much though. There really is no need for them in your average application. Where they will be popular is in add-on cards. It will do wonders I presume for mathematical applications such as: graphics(will OpenGL work?), encryption, perhaps even some kind of strange storage device or network device will make use of quantum shenanigans someday. Anyone with mork knowledge on the subject care to comment about the possible uses in the non-research world other than breaking encryption? I can't think of many cases where NP problems are even used in day to day tasks. Besides traveling salesmen or theives trying to optimize their theivery, what else is actually a practical use?
Ellison talks a lot of trash, why is this particular statement he made news worthy. He's by no means credible (he's on the same level as Balmer in the crazy scale). Does no one remember the Oracle challenges he used to issue periodically? He's worse than the WWF.
"Oracle is the most powerful database in existance. You want to take the Oracle challenge? Linux will decimate Windows. I will gouge you eyes out with a spoon."
So he didn't say the bit about the eyes, but it fits.
I dare you to write a program using only C# the language.
Aside from the fact that.Net isn't a standard (only C# is), I have a voice in the direction of Java. SUN created a group called the JCP (Java Community Process) that is the ISO and ECMA of Java.
When you can say that you have a word in an ISO or ECMA "standard", you let me know. They are no more standard than the JCP.
If.Net was a standard, and there were actually multiple implementations of this standard (to prove it is a standard that won't change just to break things), then I might be persuaded to have your optimism for.Net and MS.
Do you expect people to forget MS's track record? They gutted Java, and you pretend like they can't still do the same to.Net if anyone else implements it..Net was not built for portability. It was built only to work with other MS products. The ideas and principals that went into.Net assume that you'll be running on windows with windows widgets..Net is BS, and you're just on the bandwagon running off the edge of the cliff if you think any real server with real hardware will ever support.Net. IBM is your only hope of this, but they have deaply invested in Java. X86 is not everyone's solution. Some data centers need 64 way IBM systems to get the kind of performance they need. You get back to me when I can do that with.Net. In the meantime, I'll be enjoying the fact that the latest version of Java already up and running on real server hardware and real server operating systems.
Maybe Slashdot will stop flying the.Net banner until we see some real action in the arena other than political moves. I don't want to hear another word until Mono runs Microsoft's demo applications (like Donkey.Net:) ).
What you need is the LINK channel. They have a program called Mosaic that is news from around the world, about 4 times a day. They translate some, and some are broadcast in English. It's a great source for good news for those of you that haven't looked into getting it. I know some satelite providers carry it. DirecTV I think has it on channel 375 I am told.
I do a lot of parsing (recursive decent parsers usually) and have written compilers for stupid little languages. At this very moment, I'm writting a custom query language that takes a more generic query language that is easier to use and more robust and converting it into plain old SQL. It's not incredibly hard, and it has to be strongly typed (because you don't want people to compare integers to dates).
I'm not going to be the one to prove you wrong though. It will be a great day for computer science. I think IBM is more onto that trail than anyone at the moment. Although Intels generic language thing (I don't know what they call it... it made slashdot) shows some promise too. Basically,
I think you should take a step back and look at what C compilers do today. They preform miracles routinely on code. Back in the old days, if you told someone that C was faster than Assembler, you wouldn't find a job.
You can never overestimate what computers will do in a decade.
I've taken a look at a couple of those books at college. The books that I have seen didn't even cover the optimizations that C compilers do (other than trivial reordering).
Maybe if I get some time someday, I'll help out Kaffe, Parrot, or Python (at least experiment).
Yeah... and they are all good things for us developers I think.
NetBeans vs Eclipse has spurred both to work extremely hard to be the best. That means NetBeans is faster and Eclipse is more featureful than before.
Sun is working extremely hard on Swing and fixing old problems like the file chooser. SWT is getting more stable, more features, and prettier.
I don't think IBM wants to drive SUN out of business. It's just friendly competition I think. SUN won't loose any real assets directly by people using Eclipse. In fact, they stand to gain some more if more people get interested in Java (now that SWT gives some developers what they want). This means more companies licensing technology from SUN and more companies buying SUN's application server etc.
It's all good for everyone, but you are right in some respects about IBM. IBM wants Java:) Everyone does. Microsoft wanted it so bad they tried to hijack it, then they remade it under a different name to be what they would have hijacked Java into being (a windows only, secure, homogenous programming environment that requires as much Microsoft software as possible).
Why do you argue the futility that this is for you. The point is JIT-C exists already for Java. This compiles the code all the way down to machine code. Those optimizations you are saying are impossible are taking place in real time. They are looking at types and finding the appropriate function to call, and converting that function to machine code then injecting it into a running thread. The only problem at this point is that it has not matured enough. If you are saying JIT-C is the best it will ever be, you are dead wrong. At this very moment, common optimizations like ""+1 don't optimize to String.valueOf(1). Instead it creates a StringBuffer, adds the two as strings, then destroys the string buffer. Java is reaching the speed of C without taking these obvious optimizations. The memory consumption of Java isn't required by the task that it performs either The heap size doesn't need to be so large. The machine compiled code that the VM comes up with is discarded as soon as the VM is closed. It isn't even saved to the disk, yet Java seems to be doing a pretty good job.
How are you even trying to argue that I won't be able to see how and when a function is called?
If license_fees(@_) used @_ as strings, you could optimize for this situation like I said last time, keep an array of strings around too. If you have a function that must use the data as a string, you're going to have to do the same thing in C.
The more obfiscated you try to make this program, the more you are just argueing that the problem is obfiscated and you would have to do the same thing in C. The difference is, in a high level language, you may be able to figure out how best to store the data that the user gives you by profiling using a VM. Maybe one run I'll use a linked list for parameter passing, then foreach will be expanded to iterate the linked list. You can't tell me that a function may get called in any method that the computer can't know about it before hand.
The only thing you can argue your point on is dynamically generated code. The kind where a perl script writes another script or Lisp executes an array that it just built given user input. Languages like Perl and Java will get much faster as compiler technology (JITC) for those languages advance. I can see how a language like Lisp may be difficult considering it is considered OK to write a program that writes a program. If you wrote a C program to write a C program, I think you would be upset by the performance as well. These kinds of languages should be avoided for problems that don't warrent their use.
I can't believe I'm even argueing that compilers make more of a difference than language choice on speed anyhow. Just compare the different C compilers out there. The older compilers were horrendously slow compared to the new ones.
I don't have the resources of SUN or IBM or BEA at my disposal to develop anything as good as what they already have. I never argued that it was easy, only possible. If it were trivial, Java would already be faster than C. There are a lot of other things that people are more concerned about than speed (like security) to work on. It would be great if everyone had the resources to perfect every peice of software they work on, but they don't. They work on what they feel is more important. That's why security follows features in the C/C++ world. That's why I recommend people write software in HLLs whenever they can. Security is a must.
You can't use statistics or probabilities as proofs:)
I don't think you'll find anyone that will make a wager that there aren't an infinite amount of twin primes, but there is no definitive proof.
Basically, for all prime numbers less than the square root of the number between two primes, it's easy to see that it is possible that their multiples could add up to either be on this middle number or at least more than 3 or more away. Pretty much the theory is only going to show that numbers that are a multiple of 2 and 3 are possibly between 2 prime numbers. Pick any number not a multiple of 2 and 3 and a number on either side will either be divisible by 2 or 3. I would assume that a proof could be extended through this by saying that there would have to always be another multiple of a prime number that happens to land one away from a multiple of 2 and a multiple of 3 for every number 2^x*3^y (for all x,y where 2^x*3^y>Q and 2^x*3^y is prime there exists a number z such that z divides 2^x*3^y+1 or z divides 2^x*3^y-1).
This is a little trickier considering it has already been proven that there is no number > than some number I can't remember at the moment such that it is divisible by all prime numbers less than it's square root. (there are no numbers that have both factors > it's square root... easily proven:) )
With weird things like this going on with prime numbers it's hard to tell. Despite your obvious instincts that there should be a number x that happens to be a multiple of all prime numbers less than it's square root and still be large, it just isn't so.
Everytime you find something else about prime numbers, there is yet more questions about them. If this gets proven, the next logical step would be to prove that there are infinite number of prime numbers that are 2x apart from each other. If it gets disproven, we'll want to see exactly where it stops being true, and why. From there, we will only find more questions than answers:)
Me thinks Cmdr-Taco has never tried to solder wires onto surface mount components with carpel tunnel or a triple latte without a good iron, magnifing glass, camera and robotic arms.
It isn't easy... just hope those components are caps or resistors that aren't important. I would much rather use software than hardware... Now if only we could crack a key?
I don't remember claiming it was trivial, just it doesn't require any AI.
You're example is flawed in assuming that you don't know how it is going to be called. In fact, the compiler will know everywhere and everyhow it is called, or it's going to be a library (which could just be left in source format).
Lets say you call sum with @a=(2,"3",85,"4"+6); $b=sum(a);
If you are dumb enough to do this, you deserve the computer taking longer because you have to convert the strings to numbers.
The same goes for dynamically generated strings.
You would likely end up with
int a[]={2,3,85,10}; int b; b=sum(a);
just like you would expect. If you do something like $c=; a.push($c); b=sum(a);
since you have determined the type of the data in $a because it's called on a function that adds it's value to an int, you know a is an int array, so you would get something like:
(you would have a helper function that gets inlined in the code for a lot of things) c=perl_style_read(STDIN); a=perl_append( a,c); a_size++; b=sum(a,a_size);
perl_append: you can profile the code to see if LinkedLists, Arrays, DynamicArrays, Trees, etc are faster. This isn't magic, just complicated software (no AI involved).
Basically, it's only going to be slow if you use it like a maniac and assume that "4" + 5 is as fast as 4 + 5.
If you actually have to implement something as featurefull in C to recquire strings and ints to be converted by a function, then you'll end up with something just as slow.
Imagine you want to just grab numbers off the beginning of the line in that manner, then you print back out the full line, with a Total line. Doing that in C will take the same ammount of effort as Perl, only it would be easier to write in Perl.
At least you didn't choose Python or Lisp (yet harder) as examples (because they require the compiler to be accessible in order to work because they can rewrite themselves. This is where you have to use a VM to compile on demand, and keep that around so you won't have to compile it again.)
However, with VM's like Parrot, I think you'll see Perl storing it's machine level code (from JIT) so that it will pretty much be statically compiled by the end of the cycle.
You can bet there will be JIT-C showing up in more languages too. If you can write an interpretter for something, you can write JIT-C.
From looking at your example, I doubt you understand the power and knowledge that a compiler can get from "$total=0;" and return "$total;".
You can pretty much get the types for every variable there in that scenario. In fact, I think it's impossible for you to give an example of where the computer doesn't know the type desired by the user (the interpretter works just fine at guessing, so why can't a compiler?).
You would have to set the type of a variable at runtime, and then choose on strange circumstances which function to call. In this case, I doubt you will find a way to do this in less time than a compiler could as well.
Basically, I think what you are getting at is that a compiler will only work as good as the language. I'm just trying to say that the compiler will work as good as the code. Compiler technology will advance.
I like how you avoid the topic of Java because Java does have static compilers already. The only situation I think you'll come up with where performance may be an issue is in weakly typed languages where the programmer doesn't comprehend the performance issues. Although, you may find that an optimized compiler could try keeping several arrays around (one as strings, the other as ints) if it improved performance... that's likely what a C programmer would do if they needed both types of data and size wasn't a concern (-O3 optimizations that may result in larger programs that are faster).
I bet I could write some C code in obfiscated ways that the C compiler won't compile to efficient code either. If you write well behaved code in Perl, a compiler can get a lot of performance out of the code.
Actually I have used Java on embedded systems. Take a look at Lejos. It did pretty good considering there was no floating point when I implemented a neural net on a lego brick.
How could I use Java? because it's a language. Just the same as you can use C or C++ or even basic on embedded systems, you can use Java.
Phones and PDA's use Java as well. You're arguement is orthagonal to reality.
C is popular because language biggots don't want to learn another language. They tell each other it's ok to make insecure programs because security is a myth until they actually believe it. As much as the Sendmail people strive for security and are open source, it will take 10x as much work to make it secure as it would take to just redevelop the entire project in a sane language/system like Java, Python, Lisp or Perl.
Security Focus will be more than happy to point out the short comings of C/C++ in security. Every application Microsoft makes is insecure (mostly written in C) and most of the packages for Linux. This wouldn't even have been a debate if it hadn't been for the folks over at Security Focus pointing this out quite will for me!
With the number of people actually writing server-side java you'ld think they would have found a security problem if one had existed. There are great numbers of companies using Java on the server, and I can't think of one example of where security was an issue. MS's stupid little VM allowed people to open arbitrary files on client computers, but I don't ever remember argueing that Java couldn't be used to hack a system, just that a service running in Java has never been broken in to unlike the countless examples for C/C++.
I figure you have to be pretty dense to not see this arguement considering it's the entire topic of the debate. Examples have been given, and support has been shown that C/C++ is at the root of most exploits when Java would work fine.
You really have to be on crack to make the comment that Java isn't powerful enough to be run on most services. There are fast database servers written in Java. Some the fastest HTTP servers are written in Java. (Search slashdot history for that one.) You make these comments also in the face of companies prospering because they would rather spend money on hardware than development choosing Java. They get the security of Java, and the ease of development for a much lower TCO. Java is powerful enough to run any service you have on your computer short of X.
You can start by comparing the vulnerabilities in Tomcat and Jetty to Apache. There have been problems... some involving the kernel not droping privileges (also written in C). The more shielding you have between the world and insecure C programs on your computer, the better. (And despite your claims, they are pretty much all insecure in some way.)
Even if you manage to argue that Java is insecure, you'll only be argueing that I have to secure only one hole instead of a 10-20. (or two if you count Python or 3 if you count Perl)
See, where I disagree is that any language by any means is slower than another. It just requires a more complex compiler for abstract languages in order to more optimally perform the same task.
Any turring complete language will work for any task. It may be easier to code something in one language more than another, but this has nothing to do with speed.
I will agree with you that C is a glorified assembler, and therefore it requires much less of a complex compiler. But if I tell the computer to do a task, there is an optimal method of completing this task. Because I told it to in Java or C or C++ or even COBOL doesn't matter. You can argue that a compiler for Java will be a 2^n algorithm where n is the optimal number of instructions * log base 2 of instruction size, but you can not tell me that it's slower to actually execute.
Compiler technology for obscure languages like LISP and VM's like Python, Parrot, and Java will get better over time. As they get better, VM's theoretically will be faster than static compiled code if you ship binaries. If you ship source, then C can still benefit from the same knowledge of the target platform, and thus, they will theoretically be the same speed.
Languages, in their current form, do have their places. It's much easier to say some things in a functional language than a procedural language. In embedded system, since there are no compilers that can optimize timing and space requirements, assembler is still a preffered language. Again, it's only because there is no compiler for these systems that take into consideration their constraints.
My rebuttal to your arguement is: the most optimal machine code can be generated from any turring complete language. This means the only hinderance to performance is compiler technology.
There are some places you will never see a VM (where both memory and CPU are a concern... VM's are either compilers or interpreters... one eats memory, the other eats CPU). There can exist static compilers for Java or Python or any other language (Python and Lisp being the most difficult because of their dynamic nature).
The new version of eclipse (2.1) does a better job than 2.0.*. Or at least the latest stable RC builds are:)
Comparing jEdit to Eclipse is difficult though. jEdit has so many friggen plugins it's almost detrimental:) jEdit takes longer to load because of this. Eclipse has much better ANT integration in this release as well. So you can do XSLT on just the XML that changes with ANT. You'll have to rely on yet more plugins to Eclipse to get any language other than XML, ANT's xml, HTML, and other Java related file formats. I don't think it supports JSP out of the box, but I could be wrong.
CVS support is slightly better in this release as well.
The actual Java editor has reduced my keystrokes for symbols by a factor of 1.8 or so:) When you open anything {,(,",' it will automatically make the closing tag where you would expect as well as try to keep you on the right tabbing. All this is configurable by the default coding style settings under Windows->Preferences.
Eclipse is a wonderful IDE in it's own right, but I wouldn't through away a good editor as well. You may find yourself only using jEdit for things not supported by Eclipse, since Eclipse is the easiest to use between the two.
Basically, my suggestion to people in your class is give Eclipse a good few days of work. Let it manage your classes for a while. Once you have a lot of classes, you absolutely can't live without the refactoring support. You can tell Eclipse to rename a class, and every class it has control of that uses that class will be changed to use the new class name.
Eclipse is by far the best IDE I've seen in a long time. The Netbeans people are working hard to catch up. They are making leaps of progress on their performance issues. I think before long we'll have some competition in the Open Source Java editor market.
For those of you who don't know why SUN isn't working with the Eclipse people, it's because they are working with the NetBeans people. It's an Open Source editor that rivals with Eclipse. Eclipse is part of IBM's WebSphere product as well, so IBM has a very real reason to want their editor to be the best. If SUN helped out the Eclipse project, they would be playing favorites pretty much.
I thought I was the only person to think that way.
Honestly, *BSD is the reason TCP/IP works. They have a fast micro kernel (which a lot of Linux people say isn't possible). It's secure and free despite relatively low numbers of users and coders. BSD feels a hell of a lot snappier than Linux because it is a micro kernel (truely preemptable I suppose is the reason for this).
If BSDs had as much resources backing it as Linux, BSDs would be the defacto standard server. It would be wonderful if all the drivers from Linux were ported magically to the BSD kernels. I would run it as my desktop if it supported all my hardware.
Even if I was paid minimum wage to keep on top of these things, I could have a cluster of computers to handle the tasks that they serve for the same price. Nothing I do short of rewritting every service in another language will ever make my machines secure.
The "will be used" vs "can be used" arguement is somehow diminshed to me by the fact that it "is being used" in a poor manor in most cases. Security focus pointing this out is the root of the entire arguement. My root arguement was to show how Java can be fast, but is secure. If you argue that C/C++ should be used for services, you are argueing that services should be faster, and not neccisarily secure.
Only a language biggot would even bother argueing for C/C++ in these situations. There is no justification for the lack of security implementations in C/C++. There have been remote root exploits found in every popular package that ships with a computer. If you are trying to tell me that there are 25% of the developers that can write secure code in C/C++, I'm calling it BS. Perhaps Qmail is secure, but that's about 1 package in a thousand that opens a listening socket, which is.1%.
If you can quote some other software that is popular and hasn't been on security focus and is written in C/C++ and opens a socket, you let me know, and I'll start using it tomorrow. You'll be hard pressed to find anyone writting secure C programs. Harder pressed than I would be to find fast Java.
I was only making the arguement that speed of Java or Python is less than C only because of a lack of a good JIT compiler. C originally wasn't very fast either compared to assembly. About 5-10 years ago, it was ranked as being 2x slower than straight assembler. C has had a LONG time for people to write optimized compiler technology for. Java still hasn't had the ammount of time it will take for it to over-run C like C has assembler. I don't predict it occuring anytime soon. It's just theoretically possible. (Except floating point math because SUN wants this to be IEEE compliant. It's really the CPU makers fault that IEEE floating point is so slow, and thus is slow in Java.)
And from your post, linking this back on topic, do you really think that the speed trade-off that you get with current VM technology is worth the security (or time) trade-offs you make with lower level languages? Or do you have another means of ensuring that, as an administrator, your systems won't be comprimised and your data stolen? It scares me sometimes how little effort is put into making a system secure.
If you mean that compiler technology won't ever advance to the point that it will find the most optimum sequence of bytes to perform a task, then I'll agree with that. Just don't tell me you can either.
Even if you were some kind of crazed person that could do this, I'm willing to make significant wagers that no one will ever pay you to do so. It's unjustifiable expense.
Writing a program to perform this task for you would be the same as writing a better, magical compiler. If you put this compiler in Java's JIT, Java will be faster than C because of the reasons I have stated (inlining of system library calls, target of specific processor). If you ship only source code with C, and never a binary, then maybe you could achieve the same kind of speed.
You will never convince me that assembler is faster than C and you can still ship it to users. You can't possible do this without foresite into the processor's advanced features that only a compiler would have. Your app would have to target 386 or intel processors or athlon. You can't get the most possible performance out of both simultaneously. If you compile knowing what processor you have, you can take advantage of the unique features of that processor. In an ideal world, Java would JIT knowing this and optimize for a specific architecture. This isn't the case now, but it's not unrealistic to think that it will be one day. (It in the very least is possible... which is the statement I made.)
I don't hate Perl... in fact, it's part of my arguement. Perl could be faster than C in the future, and likely it will be safer.
But to defend Java, it's actually easier to call out to native methods in Java than in Perl. You load a system dependant DLL and start calling functions.
You can reuse code like that, but I don't recommend it. Everytime you call out to a native library with data generated partially from a user, you are taking some risks. Often times, there really is no reason to do so from Java considering just about anything there are native libraries for, there are Java libraries for. SSH2 is the only thing I can think of to the contrary, but there is SSH1 support from free third-party sources (Open source).
If you want to see facinating uses of Java calling native code, you should take a look at Eclipse and SWT more specifically.
If your suggesting that it requires just as much work to program in Java as C++, then I'ld just like to say I would rather have a half-done Java application than a half-done C++ application. If you don't take your time to optimize Java, it's just slow and ugly. If you don't take the time to properly develop C++ applications, then you have horrible security issues. I don't think you'll find many people that would even run a known buggy program. If someone wrote BIND and Sendmail in Java, I would be using it! (Insert any buggy package in the place of BIND and Sendmail.) I'ld rather my users had to wait than have downtime from rebuilding servers that were cracked and make everyone change their passwords on every system that they have. (Crackers install trojan ssh packages that store passwords often.)
I'm just saying I know which problems I'm able to sleep with at night. If a user calls me and tells me a system is slow, I'ld rather buy a second system than install a known security risk.
(I don't know how you meant your post since it's only one line... so I thought I would just clarify my position.)
Slashdot Mirror
I'm sure there will be a reward for the first compiler that can compile itself for a quantum computer from a quantum computer.
On a side note, I really don't think quantum computers will overrun the market much though. There really is no need for them in your average application. Where they will be popular is in add-on cards. It will do wonders I presume for mathematical applications such as: graphics(will OpenGL work?), encryption, perhaps even some kind of strange storage device or network device will make use of quantum shenanigans someday. Anyone with mork knowledge on the subject care to comment about the possible uses in the non-research world other than breaking encryption? I can't think of many cases where NP problems are even used in day to day tasks. Besides traveling salesmen or theives trying to optimize their theivery, what else is actually a practical use?
Ellison talks a lot of trash, why is this particular statement he made news worthy. He's by no means credible (he's on the same level as Balmer in the crazy scale). Does no one remember the Oracle challenges he used to issue periodically? He's worse than the WWF.
"Oracle is the most powerful database in existance. You want to take the Oracle challenge? Linux will decimate Windows. I will gouge you eyes out with a spoon."
So he didn't say the bit about the eyes, but it fits.
I dare you to write a program using only C# the language.
.Net isn't a standard (only C# is), I have a voice in the direction of Java. SUN created a group called the JCP (Java Community Process) that is the ISO and ECMA of Java.
.Net was a standard, and there were actually multiple implementations of this standard (to prove it is a standard that won't change just to break things), then I might be persuaded to have your optimism for .Net and MS.
.Net if anyone else implements it. .Net was not built for portability. It was built only to work with other MS products. The ideas and principals that went into .Net assume that you'll be running on windows with windows widgets. .Net is BS, and you're just on the bandwagon running off the edge of the cliff if you think any real server with real hardware will ever support .Net. IBM is your only hope of this, but they have deaply invested in Java. X86 is not everyone's solution. Some data centers need 64 way IBM systems to get the kind of performance they need. You get back to me when I can do that with .Net. In the meantime, I'll be enjoying the fact that the latest version of Java already up and running on real server hardware and real server operating systems.
.Net banner until we see some real action in the arena other than political moves. I don't want to hear another word until Mono runs Microsoft's demo applications (like Donkey.Net :) ).
Aside from the fact that
When you can say that you have a word in an ISO or ECMA "standard", you let me know. They are no more standard than the JCP.
If
Do you expect people to forget MS's track record? They gutted Java, and you pretend like they can't still do the same to
Maybe Slashdot will stop flying the
24K/s down (bandwidth up to 300K/s available)
:)
9K/s up (up to 16K/s available)
It fluctuates though... but appearantly my computer is having a hard time finding anyone to send it to
Make sure you have port 6881 forwarded to you (if this is your only download, it will only use that port).
If you don't people can't even connect to you to trade parts of the file with you, so you are going to get about half the connections that you could.
Also, huge torrents take a while to get off the ground.
And don't close it when it's done... leave it open for a few hours so everyone can get it from you for a while.
What you need is the LINK channel. They have a program called Mosaic that is news from around the world, about 4 times a day. They translate some, and some are broadcast in English. It's a great source for good news for those of you that haven't looked into getting it. I know some satelite providers carry it. DirecTV I think has it on channel 375 I am told.
hehe... ok :)
I do a lot of parsing (recursive decent parsers usually) and have written compilers for stupid little languages. At this very moment, I'm writting a custom query language that takes a more generic query language that is easier to use and more robust and converting it into plain old SQL. It's not incredibly hard, and it has to be strongly typed (because you don't want people to compare integers to dates).
I'm not going to be the one to prove you wrong though. It will be a great day for computer science. I think IBM is more onto that trail than anyone at the moment. Although Intels generic language thing (I don't know what they call it... it made slashdot) shows some promise too. Basically,
I think you should take a step back and look at what C compilers do today. They preform miracles routinely on code. Back in the old days, if you told someone that C was faster than Assembler, you wouldn't find a job.
You can never overestimate what computers will do in a decade.
I've taken a look at a couple of those books at college. The books that I have seen didn't even cover the optimizations that C compilers do (other than trivial reordering).
Maybe if I get some time someday, I'll help out Kaffe, Parrot, or Python (at least experiment).
Thanks for the recommendations though.
Yeah... and they are all good things for us developers I think.
:) Everyone does. Microsoft wanted it so bad they tried to hijack it, then they remade it under a different name to be what they would have hijacked Java into being (a windows only, secure, homogenous programming environment that requires as much Microsoft software as possible).
NetBeans vs Eclipse has spurred both to work extremely hard to be the best. That means NetBeans is faster and Eclipse is more featureful than before.
Sun is working extremely hard on Swing and fixing old problems like the file chooser. SWT is getting more stable, more features, and prettier.
I don't think IBM wants to drive SUN out of business. It's just friendly competition I think. SUN won't loose any real assets directly by people using Eclipse. In fact, they stand to gain some more if more people get interested in Java (now that SWT gives some developers what they want). This means more companies licensing technology from SUN and more companies buying SUN's application server etc.
It's all good for everyone, but you are right in some respects about IBM. IBM wants Java
Why do you argue the futility that this is for you. The point is JIT-C exists already for Java. This compiles the code all the way down to machine code. Those optimizations you are saying are impossible are taking place in real time. They are looking at types and finding the appropriate function to call, and converting that function to machine code then injecting it into a running thread. The only problem at this point is that it has not matured enough. If you are saying JIT-C is the best it will ever be, you are dead wrong. At this very moment, common optimizations like ""+1 don't optimize to String.valueOf(1). Instead it creates a StringBuffer, adds the two as strings, then destroys the string buffer. Java is reaching the speed of C without taking these obvious optimizations. The memory consumption of Java isn't required by the task that it performs either The heap size doesn't need to be so large. The machine compiled code that the VM comes up with is discarded as soon as the VM is closed. It isn't even saved to the disk, yet Java seems to be doing a pretty good job.
How are you even trying to argue that I won't be able to see how and when a function is called?
If license_fees(@_) used @_ as strings, you could optimize for this situation like I said last time, keep an array of strings around too. If you have a function that must use the data as a string, you're going to have to do the same thing in C.
The more obfiscated you try to make this program, the more you are just argueing that the problem is obfiscated and you would have to do the same thing in C. The difference is, in a high level language, you may be able to figure out how best to store the data that the user gives you by profiling using a VM. Maybe one run I'll use a linked list for parameter passing, then foreach will be expanded to iterate the linked list. You can't tell me that a function may get called in any method that the computer can't know about it before hand.
The only thing you can argue your point on is dynamically generated code. The kind where a perl script writes another script or Lisp executes an array that it just built given user input. Languages like Perl and Java will get much faster as compiler technology (JITC) for those languages advance. I can see how a language like Lisp may be difficult considering it is considered OK to write a program that writes a program. If you wrote a C program to write a C program, I think you would be upset by the performance as well. These kinds of languages should be avoided for problems that don't warrent their use.
I can't believe I'm even argueing that compilers make more of a difference than language choice on speed anyhow. Just compare the different C compilers out there. The older compilers were horrendously slow compared to the new ones.
I don't have the resources of SUN or IBM or BEA at my disposal to develop anything as good as what they already have. I never argued that it was easy, only possible. If it were trivial, Java would already be faster than C. There are a lot of other things that people are more concerned about than speed (like security) to work on. It would be great if everyone had the resources to perfect every peice of software they work on, but they don't. They work on what they feel is more important. That's why security follows features in the C/C++ world. That's why I recommend people write software in HLLs whenever they can. Security is a must.
for all x,y where 2^x*3^y>Q and 2^x*3^y is prime there exists a number z such that z divides 2^x*3^y+1 or z divides 2^x*3^y-1
should have been
for all x where 6x>Q there exists a number z such that z divides 6x+1 or z divides 6x-1
You can't use statistics or probabilities as proofs :)
:) )
:)
I don't think you'll find anyone that will make a wager that there aren't an infinite amount of twin primes, but there is no definitive proof.
Basically, for all prime numbers less than the square root of the number between two primes, it's easy to see that it is possible that their multiples could add up to either be on this middle number or at least more than 3 or more away. Pretty much the theory is only going to show that numbers that are a multiple of 2 and 3 are possibly between 2 prime numbers. Pick any number not a multiple of 2 and 3 and a number on either side will either be divisible by 2 or 3. I would assume that a proof could be extended through this by saying that there would have to always be another multiple of a prime number that happens to land one away from a multiple of 2 and a multiple of 3 for every number 2^x*3^y (for all x,y where 2^x*3^y>Q and 2^x*3^y is prime there exists a number z such that z divides 2^x*3^y+1 or z divides 2^x*3^y-1).
This is a little trickier considering it has already been proven that there is no number > than some number I can't remember at the moment such that it is divisible by all prime numbers less than it's square root. (there are no numbers that have both factors > it's square root... easily proven
With weird things like this going on with prime numbers it's hard to tell. Despite your obvious instincts that there should be a number x that happens to be a multiple of all prime numbers less than it's square root and still be large, it just isn't so.
Everytime you find something else about prime numbers, there is yet more questions about them. If this gets proven, the next logical step would be to prove that there are infinite number of prime numbers that are 2x apart from each other. If it gets disproven, we'll want to see exactly where it stops being true, and why. From there, we will only find more questions than answers
Me thinks Cmdr-Taco has never tried to solder wires onto surface mount components with carpel tunnel or a triple latte without a good iron, magnifing glass, camera and robotic arms.
It isn't easy... just hope those components are caps or resistors that aren't important. I would much rather use software than hardware... Now if only we could crack a key?
I don't remember claiming it was trivial, just it doesn't require any AI.
( a,c);
You're example is flawed in assuming that you don't know how it is going to be called. In fact, the compiler will know everywhere and everyhow it is called, or it's going to be a library (which could just be left in source format).
Lets say you call sum with
@a=(2,"3",85,"4"+6);
$b=sum(a);
If you are dumb enough to do this, you deserve the computer taking longer because you have to convert the strings to numbers.
The same goes for dynamically generated strings.
You would likely end up with
int a[]={2,3,85,10};
int b;
b=sum(a);
just like you would expect.
If you do something like
$c=;
a.push($c);
b=sum(a);
since you have determined the type of the data in $a because it's called on a function that adds it's value to an int, you know a is an int array, so you would get something like:
(you would have a helper function that gets inlined in the code for a lot of things)
c=perl_style_read(STDIN);
a=perl_append
a_size++;
b=sum(a,a_size);
perl_append: you can profile the code to see if LinkedLists, Arrays, DynamicArrays, Trees, etc are faster. This isn't magic, just complicated software (no AI involved).
Basically, it's only going to be slow if you use it like a maniac and assume that "4" + 5 is as fast as 4 + 5.
If you actually have to implement something as featurefull in C to recquire strings and ints to be converted by a function, then you'll end up with something just as slow.
Imagine you want to just grab numbers off the beginning of the line in that manner, then you print back out the full line, with a Total line. Doing that in C will take the same ammount of effort as Perl, only it would be easier to write in Perl.
At least you didn't choose Python or Lisp (yet harder) as examples (because they require the compiler to be accessible in order to work because they can rewrite themselves. This is where you have to use a VM to compile on demand, and keep that around so you won't have to compile it again.)
However, with VM's like Parrot, I think you'll see Perl storing it's machine level code (from JIT) so that it will pretty much be statically compiled by the end of the cycle.
You can bet there will be JIT-C showing up in more languages too. If you can write an interpretter for something, you can write JIT-C.
From looking at your example, I doubt you understand the power and knowledge that a compiler can get from "$total=0;" and return "$total;".
You can pretty much get the types for every variable there in that scenario. In fact, I think it's impossible for you to give an example of where the computer doesn't know the type desired by the user (the interpretter works just fine at guessing, so why can't a compiler?).
You would have to set the type of a variable at runtime, and then choose on strange circumstances which function to call. In this case, I doubt you will find a way to do this in less time than a compiler could as well.
Basically, I think what you are getting at is that a compiler will only work as good as the language. I'm just trying to say that the compiler will work as good as the code. Compiler technology will advance.
I like how you avoid the topic of Java because Java does have static compilers already. The only situation I think you'll come up with where performance may be an issue is in weakly typed languages where the programmer doesn't comprehend the performance issues. Although, you may find that an optimized compiler could try keeping several arrays around (one as strings, the other as ints) if it improved performance... that's likely what a C programmer would do if they needed both types of data and size wasn't a concern (-O3 optimizations that may result in larger programs that are faster).
I bet I could write some C code in obfiscated ways that the C compiler won't compile to efficient code either. If you write well behaved code in Perl, a compiler can get a lot of performance out of the code.
He must be using one of those original pentiums to calculate his numbers eh?
Actually I have used Java on embedded systems. Take a look at Lejos. It did pretty good considering there was no floating point when I implemented a neural net on a lego brick.
How could I use Java? because it's a language. Just the same as you can use C or C++ or even basic on embedded systems, you can use Java.
Phones and PDA's use Java as well. You're arguement is orthagonal to reality.
C is popular because language biggots don't want to learn another language. They tell each other it's ok to make insecure programs because security is a myth until they actually believe it. As much as the Sendmail people strive for security and are open source, it will take 10x as much work to make it secure as it would take to just redevelop the entire project in a sane language/system like Java, Python, Lisp or Perl.
Security Focus will be more than happy to point out the short comings of C/C++ in security. Every application Microsoft makes is insecure (mostly written in C) and most of the packages for Linux. This wouldn't even have been a debate if it hadn't been for the folks over at Security Focus pointing this out quite will for me!
With the number of people actually writing server-side java you'ld think they would have found a security problem if one had existed. There are great numbers of companies using Java on the server, and I can't think of one example of where security was an issue. MS's stupid little VM allowed people to open arbitrary files on client computers, but I don't ever remember argueing that Java couldn't be used to hack a system, just that a service running in Java has never been broken in to unlike the countless examples for C/C++.
I figure you have to be pretty dense to not see this arguement considering it's the entire topic of the debate. Examples have been given, and support has been shown that C/C++ is at the root of most exploits when Java would work fine.
You really have to be on crack to make the comment that Java isn't powerful enough to be run on most services. There are fast database servers written in Java. Some the fastest HTTP servers are written in Java. (Search slashdot history for that one.) You make these comments also in the face of companies prospering because they would rather spend money on hardware than development choosing Java. They get the security of Java, and the ease of development for a much lower TCO. Java is powerful enough to run any service you have on your computer short of X.
You can start by comparing the vulnerabilities in Tomcat and Jetty to Apache. There have been problems... some involving the kernel not droping privileges (also written in C). The more shielding you have between the world and insecure C programs on your computer, the better. (And despite your claims, they are pretty much all insecure in some way.)
Even if you manage to argue that Java is insecure, you'll only be argueing that I have to secure only one hole instead of a 10-20. (or two if you count Python or 3 if you count Perl)
See, where I disagree is that any language by any means is slower than another. It just requires a more complex compiler for abstract languages in order to more optimally perform the same task.
Any turring complete language will work for any task. It may be easier to code something in one language more than another, but this has nothing to do with speed.
I will agree with you that C is a glorified assembler, and therefore it requires much less of a complex compiler. But if I tell the computer to do a task, there is an optimal method of completing this task. Because I told it to in Java or C or C++ or even COBOL doesn't matter. You can argue that a compiler for Java will be a 2^n algorithm where n is the optimal number of instructions * log base 2 of instruction size, but you can not tell me that it's slower to actually execute.
Compiler technology for obscure languages like LISP and VM's like Python, Parrot, and Java will get better over time. As they get better, VM's theoretically will be faster than static compiled code if you ship binaries. If you ship source, then C can still benefit from the same knowledge of the target platform, and thus, they will theoretically be the same speed.
Languages, in their current form, do have their places. It's much easier to say some things in a functional language than a procedural language. In embedded system, since there are no compilers that can optimize timing and space requirements, assembler is still a preffered language. Again, it's only because there is no compiler for these systems that take into consideration their constraints.
My rebuttal to your arguement is: the most optimal machine code can be generated from any turring complete language. This means the only hinderance to performance is compiler technology.
There are some places you will never see a VM (where both memory and CPU are a concern... VM's are either compilers or interpreters... one eats memory, the other eats CPU). There can exist static compilers for Java or Python or any other language (Python and Lisp being the most difficult because of their dynamic nature).
I only see two things that you ask for that I'm not using Qmail for right now.
I hate setting up qmail, but it even has an easy to use web interface for configuring those things.
I haven't tried domain mirroring, but I'm sure you can do it with a simlink.
I don't know if anything else can do piped mail processing. If you ask me, I think that's a security risk in itself.
The new version of eclipse (2.1) does a better job than 2.0.*. Or at least the latest stable RC builds are :)
:) jEdit takes longer to load because of this. Eclipse has much better ANT integration in this release as well. So you can do XSLT on just the XML that changes with ANT. You'll have to rely on yet more plugins to Eclipse to get any language other than XML, ANT's xml, HTML, and other Java related file formats. I don't think it supports JSP out of the box, but I could be wrong.
:) When you open anything {,(,",' it will automatically make the closing tag where you would expect as well as try to keep you on the right tabbing. All this is configurable by the default coding style settings under Windows->Preferences.
Comparing jEdit to Eclipse is difficult though. jEdit has so many friggen plugins it's almost detrimental
CVS support is slightly better in this release as well.
The actual Java editor has reduced my keystrokes for symbols by a factor of 1.8 or so
Eclipse is a wonderful IDE in it's own right, but I wouldn't through away a good editor as well. You may find yourself only using jEdit for things not supported by Eclipse, since Eclipse is the easiest to use between the two.
Basically, my suggestion to people in your class is give Eclipse a good few days of work. Let it manage your classes for a while. Once you have a lot of classes, you absolutely can't live without the refactoring support. You can tell Eclipse to rename a class, and every class it has control of that uses that class will be changed to use the new class name.
Eclipse is by far the best IDE I've seen in a long time. The Netbeans people are working hard to catch up. They are making leaps of progress on their performance issues. I think before long we'll have some competition in the Open Source Java editor market.
For those of you who don't know why SUN isn't working with the Eclipse people, it's because they are working with the NetBeans people. It's an Open Source editor that rivals with Eclipse. Eclipse is part of IBM's WebSphere product as well, so IBM has a very real reason to want their editor to be the best. If SUN helped out the Eclipse project, they would be playing favorites pretty much.
I thought I was the only person to think that way.
Honestly, *BSD is the reason TCP/IP works. They have a fast micro kernel (which a lot of Linux people say isn't possible). It's secure and free despite relatively low numbers of users and coders. BSD feels a hell of a lot snappier than Linux because it is a micro kernel (truely preemptable I suppose is the reason for this).
If BSDs had as much resources backing it as Linux, BSDs would be the defacto standard server. It would be wonderful if all the drivers from Linux were ported magically to the BSD kernels. I would run it as my desktop if it supported all my hardware.
Even if I was paid minimum wage to keep on top of these things, I could have a cluster of computers to handle the tasks that they serve for the same price. Nothing I do short of rewritting every service in another language will ever make my machines secure.
.1%.
The "will be used" vs "can be used" arguement is somehow diminshed to me by the fact that it "is being used" in a poor manor in most cases. Security focus pointing this out is the root of the entire arguement. My root arguement was to show how Java can be fast, but is secure. If you argue that C/C++ should be used for services, you are argueing that services should be faster, and not neccisarily secure.
Only a language biggot would even bother argueing for C/C++ in these situations. There is no justification for the lack of security implementations in C/C++. There have been remote root exploits found in every popular package that ships with a computer. If you are trying to tell me that there are 25% of the developers that can write secure code in C/C++, I'm calling it BS. Perhaps Qmail is secure, but that's about 1 package in a thousand that opens a listening socket, which is
If you can quote some other software that is popular and hasn't been on security focus and is written in C/C++ and opens a socket, you let me know, and I'll start using it tomorrow. You'll be hard pressed to find anyone writting secure C programs. Harder pressed than I would be to find fast Java.
Great arguements, and I agree completely.
I was only making the arguement that speed of Java or Python is less than C only because of a lack of a good JIT compiler. C originally wasn't very fast either compared to assembly. About 5-10 years ago, it was ranked as being 2x slower than straight assembler. C has had a LONG time for people to write optimized compiler technology for. Java still hasn't had the ammount of time it will take for it to over-run C like C has assembler. I don't predict it occuring anytime soon. It's just theoretically possible. (Except floating point math because SUN wants this to be IEEE compliant. It's really the CPU makers fault that IEEE floating point is so slow, and thus is slow in Java.)
And from your post, linking this back on topic, do you really think that the speed trade-off that you get with current VM technology is worth the security (or time) trade-offs you make with lower level languages? Or do you have another means of ensuring that, as an administrator, your systems won't be comprimised and your data stolen? It scares me sometimes how little effort is put into making a system secure.
If you mean that compiler technology won't ever advance to the point that it will find the most optimum sequence of bytes to perform a task, then I'll agree with that. Just don't tell me you can either.
Even if you were some kind of crazed person that could do this, I'm willing to make significant wagers that no one will ever pay you to do so. It's unjustifiable expense.
Writing a program to perform this task for you would be the same as writing a better, magical compiler. If you put this compiler in Java's JIT, Java will be faster than C because of the reasons I have stated (inlining of system library calls, target of specific processor). If you ship only source code with C, and never a binary, then maybe you could achieve the same kind of speed.
You will never convince me that assembler is faster than C and you can still ship it to users. You can't possible do this without foresite into the processor's advanced features that only a compiler would have. Your app would have to target 386 or intel processors or athlon. You can't get the most possible performance out of both simultaneously. If you compile knowing what processor you have, you can take advantage of the unique features of that processor. In an ideal world, Java would JIT knowing this and optimize for a specific architecture. This isn't the case now, but it's not unrealistic to think that it will be one day. (It in the very least is possible... which is the statement I made.)
I don't hate Perl... in fact, it's part of my arguement. Perl could be faster than C in the future, and likely it will be safer.
But to defend Java, it's actually easier to call out to native methods in Java than in Perl. You load a system dependant DLL and start calling functions.
You can reuse code like that, but I don't recommend it. Everytime you call out to a native library with data generated partially from a user, you are taking some risks. Often times, there really is no reason to do so from Java considering just about anything there are native libraries for, there are Java libraries for. SSH2 is the only thing I can think of to the contrary, but there is SSH1 support from free third-party sources (Open source).
If you want to see facinating uses of Java calling native code, you should take a look at Eclipse and SWT more specifically.
If your suggesting that it requires just as much work to program in Java as C++, then I'ld just like to say I would rather have a half-done Java application than a half-done C++ application. If you don't take your time to optimize Java, it's just slow and ugly. If you don't take the time to properly develop C++ applications, then you have horrible security issues. I don't think you'll find many people that would even run a known buggy program. If someone wrote BIND and Sendmail in Java, I would be using it! (Insert any buggy package in the place of BIND and Sendmail.) I'ld rather my users had to wait than have downtime from rebuilding servers that were cracked and make everyone change their passwords on every system that they have. (Crackers install trojan ssh packages that store passwords often.)
I'm just saying I know which problems I'm able to sleep with at night. If a user calls me and tells me a system is slow, I'ld rather buy a second system than install a known security risk.
(I don't know how you meant your post since it's only one line... so I thought I would just clarify my position.)
People trying to device get-rich-quick schemes?
:)
Just sounds more realistic than they expected the game to be