I've said it before, and I'll say it again: as far as the US Government is concerned, especially since 9/11 and The Patriot Act, citizens have no expectation of privacy. If you think otherwise, you are deluding yourself. People keep saying, "Oh, the government will never lie to me. They are required to protect privacy." As if. The government will tell you what you want to hear to passify you, and when found out will either flush things down the Memory Hole or give you a nice 'mea culpa' and continue doing the same thing.
As far back as 1995 Ellen Alderman and Caroline Kennedy wrote in The Right To Privacy that our rights, especially those under the Fourth Ammendment, were slowly being eroded.
But as another poster said, the bulk of the American population don't know, and more importantly, don't care.
You must have pissed someone off in a previous life, because this is usually a non-trivial exercise, and the company is trying to do it on the cheap.
Presumably you speak Japanese.
Try Google, searching for localization and internationalization. There are some sites out there that discuss it, even for VB.
How much string processing will you need to do? Will there be data file changes? What is the scope of the UI changes required?
There are companies out there, like Lionbridge or Basis Technology, that make good money doing this for people. Usually they get called after a company has already spent too much trying to do it themselves.
"But that's really a separate issue. TIMTOWTDI isn't about the fact that there are lots of possible ways of coding a solution to a particular problem- that's true of any language. TIMTOWTDI is about Perl being non-orthogonal, i.e. built-in functions have overlapping capabilities."
It isn't about the vocabulary (well, not much: have four words for the same concept is just stupid in a programming language, IMHO). It's about syntax: consider the four or five different ways of writing references! Syntactic sugar on top of syntactic sugar. It's rediculous.
Well, this is really a benefit of code reading in general: learning other ways of doing something. The problem (as I see it) with TIMTOWTDI is that there are too many ways of doing some things, and these compound one another. Sure, if you read enough Perl you'll learn every possible of way of doing something in the language, but at what cost?
"Yep. EVERY language can be bent to horrid non-readability."
It is hard to write unreadable Python. It is not hard to write Python that is so "high-level" that you have to spend a lot of time figuring out what it is actually doing. A complex list comprehension can lead to some powerful code that does an amazing amount of stuff in a neat little package. To me this is different than the arbitrary line-noise you get with Perl.
So Perl 6 lets you define your own syntax so that someone reading your code neads to figure out what your ideas of the Right Language is? Wonderful. That will make things better for everyone.
Common LISP and Scheme's macro facilities can be used to define your own language constructs: see Paul Graham's On LISP for details on this. Or you can use the full power of SGML to redefine the characters in your "language". Or hell, TeX lets you redefine the world if you are so twisted, though to me TeX is more unreadable than Perl.
My issue with TIMTOWTDI and the relation to unreadable code is that it requires a greater load on the reader because they have to know (conceivably) all the ways something can be done in order to understand code from different people. TIMTOWTDI is wonderful when you are writing code for yourself, it's a PITA when you are reading someone elses code.
I agree with everything you say, though some languages make writing read-only code easier than others. APL comes to mind immediately. I did not intend to convey the fact that Perl was unreadable. Rather I feel that Perl gives you more rope to write unreadable code than other languages, like Python.
Of course you can write some incredibly terse code in Python too, especially with recent language additions.
And I would not include C in a list of languages for writing readable code in.
Because of Perl's TIMTOWTDI mantra reading other people's code can be an exercise in frustration, IMHO, because to grok what they have written you may end up delving into some of the more baroque syntax in the language. I've found that many people like writing incredibly terse code which makes its readibility incredibly difficult. While Schwartz may write comprehensible Perl, I expect that the bulk of Perl code in the wild is anything but. This is my biggest peave with the language, and how it can pride itself on this "feature" is beyond me.
For all non-Java development, unless mandated by a contract, I use GNU Emacs as my primary environment, with the GCC tool chain and GNU Make. This works amazingly well on all stages of development, but as others have said, keep things simple: try to avoid mazes of recursive makefiles, for example (read Peter Miller's Recursive Make Considered Harmful, then read it again.)
Your choice of tools will depend a bit on how cross-platform you need things to be. If you are developing now, or think you will be developing in the future, for multiple platforms and compilers, take that into account from the start and save yourself a lot of headache. Don't bother with AutoGen and friends unless you are distributing this to third parties: it's a PITA. It's great if you have absolutely no control over future systems, but otherwise there are better ways.
For Java development Eclipse is going to be your very good friend. I'm not a big fan of IDEs, but Eclipse is really nice insofar as it integrates with the Java language very well and can help you a lot. It's refactoring capabilities are worth the learning curve. Unfortunately I have not had a lot of luck getting ANT integration working, so I maintain a separate ant build file that I use for release builds in my projects.
For documentation purposes Doxygen is the thing to use. It has Emacs integration as well (written by yours truly). We use this to generate reference documentation, and then have Python scripts to massage the HTML output as we need. With its XML output you can use XSLT instead, though I haven't tried that. We need to produce multilingual documentation, and after many different attempts with tools have settled on LaTeX with a customized version of the Python macros. It works really well, if you can find doc writers who are comfortable writing with it. We are experimenting with Lyx to see how it integrates with our hand-coded documents. We use JavaDoc for Java reference documentation, though we could (should) migrate to Doxygen.
Other tools that are essential: Valgrind is a must use. I prefer it to Purify. Use Bugzilla for bug tracking: easy to set up and maintain. I recommend Perforce for your SCM. I'd avoid CVS. Give Subversion a look, but we've been happy with Perforce. Depends on how much you want to spend. We use AutoGen a lot to generate sources: very useful. And pick a scripting language you are all comfortable with and use it: Python is what we use, Perl works. It doesn't matter which one you use, as long as you're all comfortable with it. We have Python scripts that produce hourly summaries of Perforce activity, for example. We've tied our Bugzilla into Perforce... lots of things can be done.
Google's search engine is not written in Python. They write a lot of tools and supplemental applications in Python, but the code is decidedly not in an interpreted language, no matter how studly.
It is interesting, however, that they do not include samples in Python but do include.NET and Java. But think about it: I'm sure their target developer is one who is integrating this into an application. Also note that the Google API is SOAP based, and perhaps at the time they released the SDK originally the Python SOAP support was less than complete.
Google released their APIs years ago. Unfortunately they don't update them as often as one would like, such as adding better support for East Asian and RTL languages.
If Linux people are not paying for MS Office, then is it not reasonable that Microsoft would restrict them from downloading patches for it?
Well, I wasn't commenting on Microsoft's restrictions on downloading here. I actually think that policy is stupid knee-jerk reaction that is going to cause more harm than good.
How long will it take for the WINE people to figure out what the check is that IE is making and code around it?
But businesses would, which is probably why they never released this. Just think, all those orginizations who moved from microsoft to linux, would probably never have went back, because Linux+MS Office is way cheeper to license then Windows+MS Office.
Well, Windows comes on every user-level PC that the company I work for buys: it is calculated into the price, as we're all aware. The Office site-license would be just as expensive for Linux seats as Windows seats. And like it or not, non-tech savvy users are going to deal with XP's UI better than Gnome's.
Why don't more companies switch to OpenOffice or AbiWord or whatever else? Because while they are good, they don't do everything, and enough companies use features that aren't implemented well in these systems that they won't catch on. Both OO and AbiWord toss up their hands on most Word2003 documents my coworkers generate.
This argument just doesn't hold up for me. Historically software for Unix systems has been more expensive than the same app on user systems. This is a Bad Thing when there are OSS solutions that are better than most any commercial (think Valgrind vs. Purify.)
Anyway, I doubt that Microsoft releasing Office for Linux would help any more than their releasing Office for Mac OS X is cutting into their Windows market.
Cute --- I'm hardly a microsoft shill. I have no microsoft products on my Linux or FreeBSD boxen. The only Microsoft products I have on my Mac OS X machine is Virtual PC so I can do whatever Win32 development I need to do. All other uses of Microsoft stuff is done through remote desktop.
Yes they do [codeweavers.com]
OK, so you can pay $80 in addition to the $400 you spend on Office, all to run on Linux? Whatever. How many people using CrossOver Office are running licensed copies of the Windows software? Either way, they're SOL now.
How do you enter phone numbers or new calendar items on your iPod without hooking it up to a laptop? Is there another interface built into it to type stuff in?
I don't. For my usage I rarely if ever find myself needing to do this. Either I'm just adding someones business card, which I can just do as easily at my desk, or an appointment card, which I can also do at my desk.
When the PalmPilot came out I found that it could do 90% of what I could do on my Newton in a smaller package. I was using Grafiti on my Newton anyway, so it didn't make sense to keep using it.
Then I stopped taking notes on the Palm and just used it for calendar and contacts. One more thing to remember to take with me.
Now I can sync my (iCal) calendars and my address book to my iPod. I take that little white gem with me pretty much everywhere anyway, and it's doing 80-90% of what my PalmPilot did. And it "just works" on my Mac OS X box.
So it isn't a surprise that this is happening: few people really need to read and write email on the Blackberry. Can you not be disconnected for a few minutes a day?
Paul Graham's outstanding book On Lisp is what you want to read if this interests you at all. Indeed, pretty much anything he has written about Lisp is relevant. Lisp's macro system allows you to do this: you can define your own language constructs.
The book is out of print but can be downloaded from Paul's site,
When it was created in the early '90s it was indeed "Bare Bones". Over the intervening years features were added to make it more powerful and, perhaps, bloated. While I edit now with Emacs (since I like having a consistent environment across all four platforms I regularly develop on) BBEdit is always there, as it has been since its initial releases.
[...] on the grounds that there are far easier ways to DoS a system without using kernel exploits like that one.
That's a pretty specious argument --- even if there are easier ways, if people know how to do it then it will happen. This is little more than a corrolary to "security through obfuscation" and is quite surprising coming from the Linux Deities.
On MacOS X the tool you want is called Audio Hijack Pro and is works like a champ. You can intercept any audio stream being played on the machine, and allows you to apply any number of DSP effects to the intercepted stream. It totally rocks. I've used it to record streaming content from various radio programs which shall remain nameless, fscking RIAA.
I find that keeping outlines really helps. If I am using my TiBook then this is usually done in OmniOutliner, though I'm not averse to using Outline Mode in Emacs if I need to share these with others not using Mac OS X. For me being able to categorize my ideas in a hierarchical manner is a Good Thing. In times long gone I used to use Symantec's "MORE II", then UserLand's Frontier... outlines have been a consistent part of my design process.
You can also find good outliners for Palmtops as well, though it has been years since I installed one and I cannot remember the name of the one I used.
I've been using CiteSeer for years in my research, and still prefer it over Google Scholar.
For computing research CiteSeer and the ACM DL are the two places to go. Scholar may obviate the need for going to both places, someday, but for now it needs to mature a bit.
Slashdot Mirror
I've said it before, and I'll say it again: as far as the US Government is concerned, especially since 9/11 and The Patriot Act, citizens have no expectation of privacy. If you think otherwise, you are deluding yourself. People keep saying, "Oh, the government will never lie to me. They are required to protect privacy." As if. The government will tell you what you want to hear to passify you, and when found out will either flush things down the Memory Hole or give you a nice 'mea culpa' and continue doing the same thing.
As far back as 1995 Ellen Alderman and Caroline Kennedy wrote in The Right To Privacy that our rights, especially those under the Fourth Ammendment, were slowly being eroded.
But as another poster said, the bulk of the American population don't know, and more importantly, don't care.
You must have pissed someone off in a previous life, because this is usually a non-trivial exercise, and the company is trying to do it on the cheap.
Presumably you speak Japanese.
Try Google, searching for localization and internationalization. There are some sites out there that discuss it, even for VB.
How much string processing will you need to do? Will there be data file changes? What is the scope of the UI changes required?
There are companies out there, like Lionbridge or Basis Technology, that make good money doing this for people. Usually they get called after a company has already spent too much trying to do it themselves.
"But that's really a separate issue. TIMTOWTDI isn't about the fact that there are lots of possible ways of coding a solution to a particular problem- that's true of any language. TIMTOWTDI is about Perl being non-orthogonal, i.e. built-in functions have overlapping capabilities."
It isn't about the vocabulary (well, not much: have four words for the same concept is just stupid in a programming language, IMHO). It's about syntax: consider the four or five different ways of writing references! Syntactic sugar on top of syntactic sugar. It's rediculous.
Well, this is really a benefit of code reading in general: learning other ways of doing something. The problem (as I see it) with TIMTOWTDI is that there are too many ways of doing some things, and these compound one another. Sure, if you read enough Perl you'll learn every possible of way of doing something in the language, but at what cost?
"Yep. EVERY language can be bent to horrid non-readability."
It is hard to write unreadable Python. It is not hard to write Python that is so "high-level" that you have to spend a lot of time figuring out what it is actually doing. A complex list comprehension can lead to some powerful code that does an amazing amount of stuff in a neat little package. To me this is different than the arbitrary line-noise you get with Perl.
So Perl 6 lets you define your own syntax so that someone reading your code neads to figure out what your ideas of the Right Language is? Wonderful. That will make things better for everyone.
Common LISP and Scheme's macro facilities can be used to define your own language constructs: see Paul Graham's On LISP for details on this. Or you can use the full power of SGML to redefine the characters in your "language". Or hell, TeX lets you redefine the world if you are so twisted, though to me TeX is more unreadable than Perl.
My issue with TIMTOWTDI and the relation to unreadable code is that it requires a greater load on the reader because they have to know (conceivably) all the ways something can be done in order to understand code from different people. TIMTOWTDI is wonderful when you are writing code for yourself, it's a PITA when you are reading someone elses code.
I agree with everything you say, though some languages make writing read-only code easier than others. APL comes to mind immediately. I did not intend to convey the fact that Perl was unreadable. Rather I feel that Perl gives you more rope to write unreadable code than other languages, like Python.
Of course you can write some incredibly terse code in Python too, especially with recent language additions.
And I would not include C in a list of languages for writing readable code in.
Because of Perl's TIMTOWTDI mantra reading other people's code can be an exercise in frustration, IMHO, because to grok what they have written you may end up delving into some of the more baroque syntax in the language. I've found that many people like writing incredibly terse code which makes its readibility incredibly difficult. While Schwartz may write comprehensible Perl, I expect that the bulk of Perl code in the wild is anything but. This is my biggest peave with the language, and how it can pride itself on this "feature" is beyond me.
For all non-Java development, unless mandated by a contract, I use GNU Emacs as my primary environment, with the GCC tool chain and GNU Make. This works amazingly well on all stages of development, but as others have said, keep things simple: try to avoid mazes of recursive makefiles, for example (read Peter Miller's Recursive Make Considered Harmful, then read it again.)
Your choice of tools will depend a bit on how cross-platform you need things to be. If you are developing now, or think you will be developing in the future, for multiple platforms and compilers, take that into account from the start and save yourself a lot of headache. Don't bother with AutoGen and friends unless you are distributing this to third parties: it's a PITA. It's great if you have absolutely no control over future systems, but otherwise there are better ways.
For Java development Eclipse is going to be your very good friend. I'm not a big fan of IDEs, but Eclipse is really nice insofar as it integrates with the Java language very well and can help you a lot. It's refactoring capabilities are worth the learning curve. Unfortunately I have not had a lot of luck getting ANT integration working, so I maintain a separate ant build file that I use for release builds in my projects.
For documentation purposes Doxygen is the thing to use. It has Emacs integration as well (written by yours truly). We use this to generate reference documentation, and then have Python scripts to massage the HTML output as we need. With its XML output you can use XSLT instead, though I haven't tried that. We need to produce multilingual documentation, and after many different attempts with tools have settled on LaTeX with a customized version of the Python macros. It works really well, if you can find doc writers who are comfortable writing with it. We are experimenting with Lyx to see how it integrates with our hand-coded documents. We use JavaDoc for Java reference documentation, though we could (should) migrate to Doxygen.
Other tools that are essential: Valgrind is a must use. I prefer it to Purify. Use Bugzilla for bug tracking: easy to set up and maintain. I recommend Perforce for your SCM. I'd avoid CVS. Give Subversion a look, but we've been happy with Perforce. Depends on how much you want to spend. We use AutoGen a lot to generate sources: very useful. And pick a scripting language you are all comfortable with and use it: Python is what we use, Perl works. It doesn't matter which one you use, as long as you're all comfortable with it. We have Python scripts that produce hourly summaries of Perforce activity, for example. We've tied our Bugzilla into Perforce... lots of things can be done.
Google's search engine is not written in Python. They write a lot of tools and supplemental applications in Python, but the code is decidedly not in an interpreted language, no matter how studly.
It is interesting, however, that they do not include samples in Python but do include .NET and Java. But think about it: I'm sure their target developer is one who is integrating this into an application. Also note that the Google API is SOAP based, and perhaps at the time they released the SDK originally the Python SOAP support was less than complete.
And didn't O'Reilly publish a Hacks for it?
Yes, Google Hacks contains a couple of chapters on using the API.
Google released their APIs years ago. Unfortunately they don't update them as often as one would like, such as adding better support for East Asian and RTL languages.
If Linux people are not paying for MS Office, then is it not reasonable that Microsoft would restrict them from downloading patches for it?
Well, I wasn't commenting on Microsoft's restrictions on downloading here. I actually think that policy is stupid knee-jerk reaction that is going to cause more harm than good.
How long will it take for the WINE people to figure out what the check is that IE is making and code around it?
But businesses would, which is probably why they never released this. Just think, all those orginizations who moved from microsoft to linux, would probably never have went back, because Linux+MS Office is way cheeper to license then Windows+MS Office.
Well, Windows comes on every user-level PC that the company I work for buys: it is calculated into the price, as we're all aware. The Office site-license would be just as expensive for Linux seats as Windows seats. And like it or not, non-tech savvy users are going to deal with XP's UI better than Gnome's.
Why don't more companies switch to OpenOffice or AbiWord or whatever else? Because while they are good, they don't do everything, and enough companies use features that aren't implemented well in these systems that they won't catch on. Both OO and AbiWord toss up their hands on most Word2003 documents my coworkers generate.
This argument just doesn't hold up for me. Historically software for Unix systems has been more expensive than the same app on user systems. This is a Bad Thing when there are OSS solutions that are better than most any commercial (think Valgrind vs. Purify.)
Anyway, I doubt that Microsoft releasing Office for Linux would help any more than their releasing Office for Mac OS X is cutting into their Windows market.
quoth the shill
Cute --- I'm hardly a microsoft shill. I have no microsoft products on my Linux or FreeBSD boxen. The only Microsoft products I have on my Mac OS X machine is Virtual PC so I can do whatever Win32 development I need to do. All other uses of Microsoft stuff is done through remote desktop.
Yes they do [codeweavers.com]
OK, so you can pay $80 in addition to the $400 you spend on Office, all to run on Linux? Whatever. How many people using CrossOver Office are running licensed copies of the Windows software? Either way, they're SOL now.
If only MS had released a suite for Linux about 2 years ago, they'd be sailing pretty by now.
No they wouldn't. Linux people don't want to pay US$400 to use MS Office.
Interestingly enough, you just indicated that your iPod only does 72-81% of what your Newton did...
Yup, which means I have pretty modest needs. And my Newton didn't carry around 36G of music either.
How do you enter phone numbers or new calendar items on your iPod without hooking it up to a laptop? Is there another interface built into it to type stuff in?
I don't. For my usage I rarely if ever find myself needing to do this. Either I'm just adding someones business card, which I can just do as easily at my desk, or an appointment card, which I can also do at my desk.
When the PalmPilot came out I found that it could do 90% of what I could do on my Newton in a smaller package. I was using Grafiti on my Newton anyway, so it didn't make sense to keep using it.
Then I stopped taking notes on the Palm and just used it for calendar and contacts. One more thing to remember to take with me.
Now I can sync my (iCal) calendars and my address book to my iPod. I take that little white gem with me pretty much everywhere anyway, and it's doing 80-90% of what my PalmPilot did. And it "just works" on my Mac OS X box.
So it isn't a surprise that this is happening: few people really need to read and write email on the Blackberry. Can you not be disconnected for a few minutes a day?
Paul Graham's outstanding book On Lisp is what you want to read if this interests you at all. Indeed, pretty much anything he has written about Lisp is relevant. Lisp's macro system allows you to do this: you can define your own language constructs.
The book is out of print but can be downloaded from Paul's site,
http://paulgraham.com/onlisp.html.
XML is not God's Gift. XML has had delusions of grandeur pushed upon it. A nice simple representation has morphed into a horrible monster. Ugh.
When it was created in the early '90s it was indeed "Bare Bones". Over the intervening years features were added to make it more powerful and, perhaps, bloated. While I edit now with Emacs (since I like having a consistent environment across all four platforms I regularly develop on) BBEdit is always there, as it has been since its initial releases.
It's a good editor. People should deal.
-tree
BBEdit Engineer Emeritus
[...] on the grounds that there are far easier ways to DoS a system without using kernel exploits like that one.
That's a pretty specious argument --- even if there are easier ways, if people know how to do it then it will happen. This is little more than a corrolary to "security through obfuscation" and is quite surprising coming from the Linux Deities.
On MacOS X the tool you want is called Audio Hijack Pro and is works like a champ. You can intercept any audio stream being played on the machine, and allows you to apply any number of DSP effects to the intercepted stream. It totally rocks. I've used it to record streaming content from various radio programs which shall remain nameless, fscking RIAA.
I find that keeping outlines really helps. If I am using my TiBook then this is usually done in OmniOutliner, though I'm not averse to using Outline Mode in Emacs if I need to share these with others not using Mac OS X. For me being able to categorize my ideas in a hierarchical manner is a Good Thing. In times long gone I used to use Symantec's "MORE II", then UserLand's Frontier... outlines have been a consistent part of my design process.
You can also find good outliners for Palmtops as well, though it has been years since I installed one and I cannot remember the name of the one I used.
I've been using CiteSeer for years in my research, and still prefer it over Google Scholar.
For computing research CiteSeer and the ACM DL are the two places to go. Scholar may obviate the need for going to both places, someday, but for now it needs to mature a bit.