Is Python any less about homogenization than Java?
At least with Python, you get built-in hooks to OS facilities. That's the thing I've never understood about Java's popularity. What's the point of writing software if you can't make direct OS system calls? It's certainly a lot less fun.
Adopting LLVM could also potentially open the door for more seamlessly integrating other languages with Python code, because the underlying LLVM intermediate representation is largely language-neutral.
1. Loose coupling between S/W components is always better then tight integration. Always.
2. Regardless of what other languages you know, learn the shell. It's the language of the system, and it's the language of S/W integration. Sooner or later, you have to integrate your S/W into a larger system, and so there will always be a need for glue.
... and besides, researchers aren't code-monkeys and don't enjoy coding inane for-loops to read, clean, and display data.
Word.
I've worked with some absolutely brilliant researchers who produce code that would make you want to shoot yourself. They don't give a shit about the CODE; they care only about the RESULTS. And, it's the RESULTS that get published, not the code.
Nonetheless, it was never fun to try to maintain MATLAB code that used the following variable names in the same function: x xx xxx xxxx xxxxx
Make sure the language you choose gives you access to the OS via system calls. If you can't make a direct call to every function described in section 2 of the manual (without twisting your code into multi-language knots), then you should not choose that language.
You may never actually use system calls, but one day you'll be grateful that you can.
I have the great forturne ...
on
Anathem
·
· Score: 3, Insightful
... of NOT reading Stephenson's earlier books. This enabled me to enjoy greatly The Baroque Cycle, which I've read twice. FWIW, I don't think that Anathem is as good as The Baroque Cycle, but I may change my mind on a second reading.
At any rate, I'm glad I passed on Snow Crash, The Diamond Age, and Cryptonomicon. If I'd read them, I'd probably be another one of those purists who can't stand it when the object of their fanboi enthusiasms has the audacity to actually change and grow and not continue to be what they were.
If drought is a problem I suspect there isn't going to be a whole lot of humid air to extract water from.
Nonsense. Anyone who lives in Central Texas knows that
Our lovely summers consist of six months of near 100% humidity (and several weeks of 100 degree days), and
We're in a severe drought right now. We could really use some rain. This has a lot more to do with high-pressure systems than it does humidity. Humidity we got. Rain we don't.
More details here: http://www.llvm.org/devmtg/2008-08/ (Look for the topic - Flash C Compiler: Compiling C code to the Adobe Flash Virtual Machine)
While scrolling down looking for the Adobe talk, I found this:
Designflow: using LLVM to compile to Hardware - This project uses LLVM to compile code to a mixed hardware and software implementation. This detects pieces of programs that may be efficiently compiled to VHDL and synthesized them onto an FPGA. The rest of the program is compiled to PowerPC code and uses to drive the FPGA. The system automatically handles data migration and other handshaking between the two systems.
Waaaayyyy more interesting than LLVM for flash. This is cool!!!
Don't encrypt the whole drive. Set up some loop-back mounts via encfs.
Make sure that these mounts do NOT go in/etc/fstab, and that they are not mounted on boot. Manually mount them when you need to read/write the sensitive data. Manually unmount them when you're done with the data.
You machine will boot right up on power on, with no indication that there's encryped data on the drive. The drive can be imaged, but they'll just end up with encrypted data. It looks like normal files and directories, but with names that look like gibberish and content that looks like gibberish.
Most users do not understand the benefits of Windows Vista... Are you sure you mean the almost-constant nag screens? Are you sure you mean are you sure you mean the almost-constant nag screens?
All too often, Google has done the interesting 80% of the functionality and leaves the boring 20% of the cleanup, followthrough, polish and finish languishing in "beta" stage for months, years, forever.
Which explains why everybody and their dog wants to work at Google. Would that all software projects were run this way. Usually, 80% is more than good enough and the last 20% usually isn't worth the effort, except to PHBs and PHBeancounters. And to the goobers posting to comment sections.
Rule of thumb: The first 80% of a project takes 80% of the total effort. The remaining 20% of the project takes 80% of the total effort, again.
"High quality" employees succeed by figuring out how to constantly be more useful to their boss. Fair enough, but what does clothing style choice have to do with being useful?
As compression schemes go, XML is probably the worst I've encountered.
How can it be that XML is 10 years old, and there's STILL no industry-standard way to embed binary data into an XML document without base64 encoding. I want bits and bytes. I want small.
Slashdot Mirror
Sweden has.... choir singing and ABBA
Works for me. How do I become a legal resident?
Is Python any less about homogenization than Java?
At least with Python, you get built-in hooks to OS facilities. That's the thing I've never understood about Java's popularity. What's the point of writing software if you can't make direct OS system calls? It's certainly a lot less fun.
FTFA:
Adopting LLVM could also potentially open the door for more seamlessly integrating other languages with Python code, because the underlying LLVM intermediate representation is largely language-neutral.
So much for Parrot.
Sure, he was whipsmart and could churn out code that saved the company millions, but can we please stop enabling these people?"
Let me get this straight -- you'd rather prevent someone from saving your company millions of dollars?
If I were a manager, I'm pretty sure you'd have a hard time justifying this idea.
Could there be a more Kiwi sounding name than "Campbell Smith"?
1. Loose coupling between S/W components is always better then tight integration. Always.
2. Regardless of what other languages you know, learn the shell. It's the language of the system, and it's the language of S/W integration. Sooner or later, you have to integrate your S/W into a larger system, and so there will always be a need for glue.
It is called a Netbook with a web browser.
Great. Another gadget with a suck-ass backlit LCD display.
Has there ever been a backlit LCD display that didn't absolutely suck?
No? I didn't think so.
Hooray epaper!
Imagine a Beowul... oh, never mind.
For another perspective: When you start your company, the maximum number of people your company should ever have on the payroll is one.
... and besides, researchers aren't code-monkeys and don't enjoy coding inane for-loops to read, clean, and display data.
Word.
I've worked with some absolutely brilliant researchers who produce code that would make you want to shoot yourself. They don't give a shit about the CODE; they care only about the RESULTS. And, it's the RESULTS that get published, not the code.
Nonetheless, it was never fun to try to maintain MATLAB code that used the following variable names in the same function:
x
xx
xxx
xxxx
xxxxx
doing market research and seeing what people will buy
This is a great strategy for producing better and better wheels. But it's a terrible strategy for producing something that is better than a wheel.
Make sure the language you choose gives you access to the OS via system calls. If you can't make a direct call to every function described in section 2 of the manual (without twisting your code into multi-language knots), then you should not choose that language.
You may never actually use system calls, but one day you'll be grateful that you can.
... of NOT reading Stephenson's earlier books. This enabled me to enjoy greatly The Baroque Cycle, which I've read twice. FWIW, I don't think that Anathem is as good as The Baroque Cycle, but I may change my mind on a second reading.
At any rate, I'm glad I passed on Snow Crash, The Diamond Age, and Cryptonomicon. If I'd read them, I'd probably be another one of those purists who can't stand it when the object of their fanboi enthusiasms has the audacity to actually change and grow and not continue to be what they were.
If drought is a problem I suspect there isn't going to be a whole lot of humid air to extract water from.
Nonsense. Anyone who lives in Central Texas knows that
Oh, and that Willie Nelson is also getting in on this.
More details here: http://www.llvm.org/devmtg/2008-08/ (Look for the topic - Flash C Compiler: Compiling C code to the Adobe Flash Virtual Machine)
While scrolling down looking for the Adobe talk, I found this:
Designflow: using LLVM to compile to Hardware - This project uses LLVM to compile code to a mixed hardware and software implementation. This detects pieces of programs that may be efficiently compiled to VHDL and synthesized them onto an FPGA. The rest of the program is compiled to PowerPC code and uses to drive the FPGA. The system automatically handles data migration and other handshaking between the two systems.
Waaaayyyy more interesting than LLVM for flash. This is cool!!!
Not to mention the Shuffle.
Don't encrypt the whole drive. Set up some loop-back mounts via encfs.
/etc/fstab, and that they are not mounted on boot. Manually mount them when you need to read/write the sensitive data. Manually unmount them when you're done with the data.
Make sure that these mounts do NOT go in
You machine will boot right up on power on, with no indication that there's encryped data on the drive. The drive can be imaged, but they'll just end up with encrypted data. It looks like normal files and directories, but with names that look like gibberish and content that looks like gibberish.
... interpreted languageWhich explains why everybody and their dog wants to work at Google. Would that all software projects were run this way. Usually, 80% is more than good enough and the last 20% usually isn't worth the effort, except to PHBs and PHBeancounters. And to the goobers posting to comment sections.
Rule of thumb: The first 80% of a project takes 80% of the total effort. The remaining 20% of the project takes 80% of the total effort, again.
That POSIX layer isn't.
It's POSIX only in name, but function.
Unless I've missed somthing, the xop:Include element would be base64 encoded.
This doesn't address the requirement that binary data be encoded/decoded to/from base64.
As compression schemes go, XML is probably the worst I've encountered.
How can it be that XML is 10 years old, and there's STILL no industry-standard way to embed binary data into an XML document without base64 encoding. I want bits and bytes. I want small.