Derivative systems - no big deal. I've worked in telco, supply chain management and finance fields - they are all the same except for the fact that the derivatives-related managers wave more money around, yell louder and have the biggest hissy fits. (And you talk of programmer prima donnas.)
Who do you think writes the very software frameworks that allow your B coder drones to plug away on day after day? Gee, I dunno, could it be... the A coders? You've likely inherited a successful software infrastructure from a buckaroo that came before you and you are merely milking and taking credit for it. And in spite of the great software you inherited it probably takes you six months to roll out the most minor feature and you think it's a huge victory for mankind.
Thank you for keeping the world running. I really appreciate that.
I contend that RMS not allowing a vote on C++ usage (or people not voting for fear of annoying RMS) is just the same as C++ being voted down. GCC is a great compiler designed by brilliant people. This is not in dispute. Mere mortals like me just wish its learning curve was not quite as steep.
For a person who disagrees with what I wrote, you understand where I'm coming from. Yes, technically there was no vote on C++ - you're right. In the end the result is the same - GCC ain't gonna use C++ any time soon. Not having a vote is much worse than voting it down, in my opinion. The GCC project is very bureaucratic.
On the other point you mentioned, too bad there is not a complete toy language for GCC for people to cut their teeth on. The GCC learning curve is pretty steep. I just can't help but think how much better a compiler it would be if coding for it would be easier.
I agree that C++ template meta-programming is a resource pig at compile time but it produces very quick and tight code for runtime. I think it was the Spirit example Pascal or HTML grammar that took 500 Megs to 1 Gig to compile on GCC but in the end it produced a 250K.o object file. Ideally, you only need to compile that file just once;-).
If you are looking for a C++ only parser consider Spirit. It is a C++ lex/yacc equivalent where you do not need a preprocessor program of any kind - you write in 100% C++ only.
But be warned - you need a gigabyte of memory and a lot of time to compile when you are dealing with large grammars as Spirit does all its magic with C++ templates and extensive operator overloading.
The casual Slashdot reader may roll his/her eyes when they see yet another Virtual Machine - but this project is much more than that. It's a complete compiler infrastructure project that will one day surpass GCC. Why? Because it's around ten times easier to understand and written in a modern language (C++) rather than C. An expert C++ programmer could start contributing code to LLVM in under a month; whereas an equivalent learning curve for GCC is at least a year. Writing new compiler passes or complete language front ends for LLVM is very straight-forward, for example. The LLVM AST has the advantage of having strong typechecking and not arcane tree macros as in GCC. LLVM is not burdened with the legal or philosophical wranglings of GCC where they do NOT WANT their compiler to be the backend of a commercial compiler and try their damnedest to obscure and change the programming API from release to release. The GCC "Toy" example language has not worked in many releases for this very reason. GCC recently voted down using C++ in their core code. Perhaps LLVM at the very least will drag GCC into the modern age due to competition.
The VM part of LLVM is just icing on the cake.
(And yes, I am aware that LLVM uses GCC 3.4's C and C++ front-end code. That's a good thing for the short term. Perhaps longer term they will develop their own front-ends.)
The very nature of stock trading is that no money is created, it's only moved.
Not quite. Transaction fees are the friction in this system. Buying and selling stocks is not a zero sum game. The brokers and exchanges always come out ahead.
The python challenge scripts were available for only 6 months, but you had a full year to write a python bytecode interpreter. Anyway, Leo almost got the scripts working, to his credit.
The Parrot team had ONE YEAR to complete the Pie-thon task - the challenge was made at OSCON 2003 for crying out loud! Meanwhile in less time than that the IronPython guy wrote a complete (and fast) Python to CLR translator by HIMSELF. Sorry, but the Parrot team's "dog ate my laptop" excuses don't hold water.
- Copy the Linux system header files to the Cygwin box. - Build a GCC Linux-target cross compiler hosted on Cygwin. - Run the distcc daemon on Cygwin making sure that it finds the Linux cross compiler binaries (gcc/g++) in the path first (use a script to launch the daemon). - Point the Linux box to the Cygwin box via DISTCC_HOSTS and go.
Some notes: - using -g (debug) distcc builds can lead to bizarre behavior because the source file path is embedded in the.o file. Try to get all your boxes to use the same directory structure. - compiler versions must be IDENTICAL on all boxes if you intend to use C++. Don't trust your system's default g++ compiler - who knows what crazy patches it has - build one from scratch using the same GCC sources on ALL machines. C is more leniant - you can get away with vastly different versions of GCC if you only use C.
The RAM transfer speeds are so poor that it takes around a second to snap a picture with many of these 5 Megapixel cameras - by that time you can easily miss the shot.
Malloc is still ridiculously expensive compared compared to what a generational GC can do. A malloc is dozens to hundreds of instructions, while in many cases (eg: when you're following the typical functional-language allocation patterns), a generational GC can alloc in just a few instructions. And while the GC phase itself is hardly speedy, the amortized cost of the GC is much lower than the non-amortized cost of doing all those free()'s individually.
What a bunch of complete nonsense. Please put up some numbers and/or URL links to back your ridiculous claims. You obviously never heard of the ultra-high performance malloc/free memory allocator Hoard. Nevermind the fact that garbage collection schemes tough every page in memory while they mark and sweep and defeat the CPU's high speed caches. Don't believe me? Read what Linus says on the topic.
Sometimes I have a Lua callback calling a C++ function which in turn invokes Lua code. This is fine, but the problems creep in when Lua becomes sentient and tries to take over the Starship Enterprise. This would never happen in C++ - it respects the chain of command.
Lua is the embedded interpreted language of choice for game designers. Lua's great for writing the game AI (you don't have to wait for a half hour C++ build). Lua's under 200K, threadsafe, has good OO abstractions, integrates with C very easily, and most important of all - it has a commercial friendly license.
This idea is certainly not new and has been mentioned on Slashdot many times: one bit of XML bloat that is 100% unnecessary is the need to name the closing tag. For example:
<tag_name>Foo</tag_name>
Is needlessly redundant. Too bad the XML spec is not changed to make the closing tag name optional similar to Lisp s-expressions:
<tag_name>Foo</>
since it is implicit anyway in a single rooted tree of nodes (as all XML documents are).
This would reduce XML overhead by about 20%. Hopefully the XML standards people are considering this for a future revision - but I doubt it.
Believe me - I hate SCO as much as the next guy, but Novell is partly to blame for this mess because they have so poorly managed the ownership of UNIX and its related intellectual property so that this situation could happen in the first place. I bet even they do not know what the hell they sold SCO or what they own at this point. Novell just got copyright assignment for the Sys V code a few months ago. For the record, what did they sell to SCO, anyway? And how much did SCO pay for whatever it is they bought?
Valgrind puts Linux on par with Solaris as far as state-of-the-art UNIX development environments go. Finally, a free alternative to Purify. All software will benefit from the amazing memory/cache/profiling analysis abilities of Valgrind. I cannot say enough good things about Valgrind. Next to GCC, Valgrind is the single most useful software package in any developer's toolkit.
Purify is the main reason why most UNIX development shops still use Sun equipment. With this obstacle removed expect development shops to abandon expensive Sun hardware altogether in favor of Linux.
Does anyone know whether Valgrind can be adapted to run on other x86 OSes like the various BSDs?
Nasal is a very well designed small embeddable language with a Javascript-like syntax and an LGPL license. I prefer it to Lua because I am not fond of Lua's Pascal-style syntax. Be aware that Nasal is not very battle-hardened yet and does not have even a 1/100th of the developer community of Lua.
Slashdot Mirror
in a wrestling ring with no referee and metal folding chairs conveniantly nearby.
Derivative systems - no big deal. I've worked in telco, supply chain management and finance fields - they are all the same except for the fact that the derivatives-related managers wave more money around, yell louder and have the biggest hissy fits. (And you talk of programmer prima donnas.)
Who do you think writes the very software frameworks that allow your B coder drones to plug away on day after day? Gee, I dunno, could it be... the A coders? You've likely inherited a successful software infrastructure from a buckaroo that came before you and you are merely milking and taking credit for it. And in spite of the great software you inherited it probably takes you six months to roll out the most minor feature and you think it's a huge victory for mankind.
Thank you for keeping the world running. I really appreciate that.
I contend that RMS not allowing a vote on C++ usage (or people not voting for fear of annoying RMS) is just the same as C++ being voted down.
GCC is a great compiler designed by brilliant people. This is not in dispute. Mere mortals like me just wish its learning curve was not quite as steep.
For a person who disagrees with what I wrote, you understand where I'm coming from. Yes, technically there was no vote on C++ - you're right. In the end the result is the same - GCC ain't gonna use C++ any time soon. Not having a vote is much worse than voting it down, in my opinion. The GCC project is very bureaucratic. On the other point you mentioned, too bad there is not a complete toy language for GCC for people to cut their teeth on. The GCC learning curve is pretty steep. I just can't help but think how much better a compiler it would be if coding for it would be easier.
I agree that C++ template meta-programming is a resource pig at compile time but it produces very quick and tight code for runtime. I think it was the Spirit example Pascal or HTML grammar that took 500 Megs to 1 Gig to compile on GCC but in the end it produced a 250K .o object file. Ideally, you only need to compile that file just once ;-).
If you are looking for a C++ only parser consider Spirit. It is a C++ lex/yacc equivalent where you do not need a preprocessor program of any kind - you write in 100% C++ only. But be warned - you need a gigabyte of memory and a lot of time to compile when you are dealing with large grammars as Spirit does all its magic with C++ templates and extensive operator overloading.
Of course you're right about taxes far outweighing transaction fees. I just wanted to debunk the often cited 'zero sum game' argument.
The casual Slashdot reader may roll his/her eyes when they see yet another Virtual Machine - but this project is much more than that. It's a complete compiler infrastructure project that will one day surpass GCC. Why? Because it's around ten times easier to understand and written in a modern language (C++) rather than C. An expert C++ programmer could start contributing code to LLVM in under a month; whereas an equivalent learning curve for GCC is at least a year. Writing new compiler passes or complete language front ends for LLVM is very straight-forward, for example. The LLVM AST has the advantage of having strong typechecking and not arcane tree macros as in GCC. LLVM is not burdened with the legal or philosophical wranglings of GCC where they do NOT WANT their compiler to be the backend of a commercial compiler and try their damnedest to obscure and change the programming API from release to release. The GCC "Toy" example language has not worked in many releases for this very reason.
GCC recently voted down using C++ in their core code. Perhaps LLVM at the very least will drag GCC into the modern age due to competition.
The VM part of LLVM is just icing on the cake.
(And yes, I am aware that LLVM uses GCC 3.4's C and C++ front-end code. That's a good thing for the short term. Perhaps longer term they will develop their own front-ends.)
The very nature of stock trading is that no money is created, it's only moved.
Not quite. Transaction fees are the friction in this system. Buying and selling stocks is not a zero sum game. The brokers and exchanges always come out ahead.
The python challenge scripts were available for only 6 months, but you had a full year to write a python bytecode interpreter. Anyway, Leo almost got the scripts working, to his credit.
Why not get behind an OSS implementation of the original ala kaffe or gcj, or push the OSS own Parrot?
Here's why.
"I do not like Parrot" (second paragraph after OSCON subtitle)
-Miguel
The Parrot team had ONE YEAR to complete the Pie-thon task - the challenge was made at OSCON 2003 for crying out loud! Meanwhile in less time than that the IronPython guy wrote a complete (and fast) Python to CLR translator by HIMSELF. Sorry, but the Parrot team's "dog ate my laptop" excuses don't hold water.
You can't talk about the ELF format without mentioning this gem. You learn a lot about the format when you push it to its limits.
- Copy the Linux system header files to the Cygwin box.
.o file. Try to get all your boxes to use the same directory structure.
- Build a GCC Linux-target cross compiler hosted on Cygwin.
- Run the distcc daemon on Cygwin making sure that it finds the Linux cross compiler binaries (gcc/g++) in the path first (use a script to launch the daemon).
- Point the Linux box to the Cygwin box via DISTCC_HOSTS and go.
Some notes:
- using -g (debug) distcc builds can lead to bizarre behavior because the source file path is embedded in the
- compiler versions must be IDENTICAL on all boxes if you intend to use C++. Don't trust your system's default g++ compiler - who knows what crazy patches it has - build one from scratch using the same GCC sources on ALL machines. C is more leniant - you can get away with vastly different versions of GCC if you only use C.
The RAM transfer speeds are so poor that it takes around a second to snap a picture with many of these 5 Megapixel cameras - by that time you can easily miss the shot.
Malloc is still ridiculously expensive compared compared to what a generational GC can do. A malloc is dozens to hundreds of instructions, while in many cases (eg: when you're following the typical functional-language allocation patterns), a generational GC can alloc in just a few instructions. And while the GC phase itself is hardly speedy, the amortized cost of the GC is much lower than the non-amortized cost of doing all those free()'s individually.
What a bunch of complete nonsense. Please put up some numbers and/or URL links to back your ridiculous claims. You obviously never heard of the ultra-high performance malloc/free memory allocator Hoard. Nevermind the fact that garbage collection schemes tough every page in memory while they mark and sweep and defeat the CPU's high speed caches. Don't believe me? Read what Linus says on the topic.
Sometimes I have a Lua callback calling a C++ function which in turn invokes Lua code. This is fine, but the problems creep in when Lua becomes sentient and tries to take over the Starship Enterprise. This would never happen in C++ - it respects the chain of command.
A Lua session in the Game Developers Conference in San Jose March 22-26, 2004... Lua in the Gaming Industry
Lua is the embedded interpreted language of choice for game designers. Lua's great for writing the game AI (you don't have to wait for a half hour C++ build). Lua's under 200K, threadsafe, has good OO abstractions, integrates with C very easily, and most important of all - it has a commercial friendly license.
Hardly an unbiased evaluation.
You're right - ask for your money back.
This idea is certainly not new and has been mentioned on Slashdot many times: one bit of XML bloat that is 100% unnecessary is the need to name the closing tag.
For example:
<tag_name>Foo</tag_name>
Is needlessly redundant.
Too bad the XML spec is not changed to make the closing tag name optional similar to Lisp s-expressions:
<tag_name>Foo</>
since it is implicit anyway in a single rooted tree of nodes (as all XML documents are).
This would reduce XML overhead by about 20%.
Hopefully the XML standards people are considering this for a future revision - but I doubt it.
a very simple design - uses just a subset of XML (no comments, macros, DTDs)
good error recovery
good service discovery
not tied to any vendor or language
not domain specific
bidirectional asynchronous communication - an XMPP session is just a pair of XML documents (one going in each direction).
decent speed
I see XMPP being as big as HTTP in the future. It will be the standard for interactive distributed communications.
Believe me - I hate SCO as much as the next guy, but Novell is partly to blame for this mess because they have so poorly managed the ownership of UNIX and its related intellectual property so that this situation could happen in the first place. I bet even they do not know what the hell they sold SCO or what they own at this point. Novell just got copyright assignment for the Sys V code a few months ago. For the record, what did they sell to SCO, anyway? And how much did SCO pay for whatever it is they bought?
Valgrind puts Linux on par with Solaris as far as state-of-the-art UNIX development environments go. Finally, a free alternative to Purify. All software will benefit from the amazing memory/cache/profiling analysis abilities of Valgrind. I cannot say enough good things about Valgrind. Next to GCC, Valgrind is the single most useful software package in any developer's toolkit.
Purify is the main reason why most UNIX development shops still use Sun equipment. With this obstacle removed expect development shops to abandon expensive Sun hardware altogether in favor of Linux.
Does anyone know whether Valgrind can be adapted to run on other x86 OSes like the various BSDs?
Nasal is a very well designed small embeddable language with a Javascript-like syntax and an LGPL license. I prefer it to Lua because I am not fond of Lua's Pascal-style syntax. Be aware that Nasal is not very battle-hardened yet and does not have even a 1/100th of the developer community of Lua.