So why not require non-citizens to have the word "ALIEN" superimposed in big red letters on their licenses and also have their visa expiration date annotated?
You know what...a person can be a non-citizen with a "visa" that never expires. That's called "legal permanent resident", or, colloquially, "a green card holder".
And if you start tagging every permanent resident as potential terrorist, how's that more effective than any other overly broad scheme for identifying potential terrorists?
I didn't mean it was impossible to avoid runtime vtable lookup in Java, I said it was impossible to avoid virtual methods in Java. The difference is that while a JVM can optimize certain vtable lookups away, there is no way for the programmer to force this in a way portable across JVM implementations.
Re:One example of why the tests are BS
on
Java Faster Than C++?
·
· Score: 2, Interesting
The point he's making is that the C++ code is poorly written, and that might well affect benchmarking.
Also, if the activate function is virtual (no way to avoid it in Java), this is a runtime vtable lookup in the loop, whereas for a statically allocated object the address of the function would have been fixed at runtime. Granted, the cost is probably negligible to that of activate's implementation, but (a) it's impossible to know without actually profiling the code, and (b) the activate()'s implementation is likely to be as poorly written as the code that calls it.
Of course, all of this implies I was too lazy to actually look at the activate()'s code...this is Slashdot after all...
Maybe it's just me, and some fiddling with the settings would fix it, but neither less nor vi display UTF-8 properly, nor can vi properly handle UTF-8 input. I tried compiling mutt with various versions of ncurses/ncursesw and libiconv, and still couldn't get it to properly handle utf-8 messages. Again, not being an OS X expert, maybe I am just doing something wrong, but on SuSE and Gentoo all it takes to internationalize xterm is export LC_ALL=en_US.UTF8, so I expect something equally simple from OS X.
I'm honestly a little surprised that a network admin (as the author claims to be) would post this question.
Sure, he may be aware of ethereal/tcpdump, but why should he assume these tools suite his particular situation better than others (that he may be unaware of)? I, for one, read this thread to find out about new or obscure tools. I remember being surprised by a few entries in this list a year ago, and I am sure an updated copy would have a few more entries that I haven't heard about yet.
Well, some of us are not really huge fans of any OS/distro, as we are just trying to get the work done. And as far as getting work done, SuSE, in my experience, has always been worth its price. I personally view it the way I view German cars: well thought-out design, excellent engineering and superb build quality let me spend more time using the product rather than maintaining it.
I recently looked into forming an LLC in Massachusetts. LLC's minimum tax is second to only California, state income taxes suck, and the state was the last in the country to allow single-member LLCs. Not sure how that would qualify as a "magnet for high tech companies"...
I do go to ballgames to watch them. However, a ballgame takes 4+ hours off my evening, and having the ability to check e-mail once in that timeframe is sometimes invaluable. People use cell phones in the ballpark, and nobody complains...how is e-mail different?..
While I am not necessarily disagreeing with you, a couple points come to mind...
Please try going to IBM/HP/Oracle and tell them to implement you a 10 million dollar software solution but tell them you don't want them to spend time doing any actual planning. You'd just like them to start coding immediately.
IBM/HP/Oracle, as every big company, tend to have many clueless managers who need to attend meetings with other clueless managers. I am not necessarily saying that all diagrams are created solely for the sake of dumb managers looking smart in their meetings, but a lot of them are.
Another point, I am wondering how many diagramming is done in large distributed open-source projects? Do Linux/BSD/Postgres/whatever developers often exhange diagrams? Or does plain English suffice for them? Not being a developer on any of these projects, I don't know, but I would think that there is a lot less diagramming going on than there is in a big fat corporation, yet the results are often comparable, especially considering the difference in manpower. Would be interesting to hear from somebody with a first-hand knowledge...
It would probably be easier for you to find a provider that gives you ssh access. Then you can use SSH forwarding to establish an encrypted channel between your mailreader and POP3/IMAP server. SSH forwarding is a great SSH feature that you can use for a variety of other neat setups. Try ssh man page for more details.
I certainly agree. However, as someone who started with Unix and only really encountered Windows on my third job after college, I would like to note that it's not necessarily better on Windows.
When you want to find a phrase in Notepad (or MS Word), how is Edit->Find, or Ctrl-F more obvious than 'apropos search' on Unix is? I found myself repeatedly trying the 'View' menu when looking for a search/find command in Windows editors until I finally memorized that the Find command is under 'Edit'. When you memorize this as a fact with no underlying logic, it becomes as obvious as 'grep' is to a Unix user, but until then it's a struggle.
I don't think it is bad, though. You'll hear people complain about complex interfaces all the time, not necessarily in computing. A friend of mine was recently whining about skiing being hard because one pressures the left ski when turning right (and vice versa). I am sure that if one-year olds could really speak, they would tell us long stories about how much harder walking is than it really should be.
In short, to do non-trivial things properly, one has to invest some time in learning them. Until then, things you know seem to be easier than things you don't, even though in reality neither is necessarily more complex than the other.
A lot of what is done using templates (the STL for example) is purely
language preprocessing.
Conceptually, yes, but then compiling is just a bunch of preprocessing steps.
C++ template facility is fully aware of the rest of the language.
Sure, you can implement it in a preprocessor, but such a preprocessor would
have to understand its own target language syntax, thereby duplicating a
large part of compiler's functionality.
There are a few preprocessors of this type available for java (and other languages that don't have meta programming as part of thier spec). Many people do use them to generate code. Actually a lot of the NIO code in jdk1.4 is created in this manner. There are also libraries for java that contain STL functionality (again often created using code generation techniques).
Interesting. I still expect them to either significantly lack in
functionality compared to C++ templates, or accept a language that is very
different from Java. That being said, I would still love to take a look at
a Java preprocessor that is believed to be an adequate replacement for C++
templates.
As for RAII, most java constructs obay these principles. A file is opened when you construct its FileReader/FileInputStream/RandomAccessFile. It can be closed manualy, however if you do not it will (should) be closed when it gets GC'd. There are some poorly designed classes in java that do not obay the principles but that is true of any language.
Garbage collection is not deterministic -- that is, the language doesn't
define when garbage collector is run. Which renders it largely useless for
implementing RAII in a generic case. For memory (in most circumstances) you
don't care whether a garbage collector is run now or a couple processor intructions later. For other resources, it makes a difference: think about
releasing a mutex, for example...
I was pointing out that, as a language, Java doesn't support a few constructs that make it significantly easier to develop and maintain software (and thus, run-time speed is not all that matters to "anti-Java zealots" as the parent states). Most of the STL concepts, especially when you look beyond containers, cannot be expressed as compactly and as elegantly with Java as they are with C++. Ditto for the RAII idiom.
I personally don't care about Java being slow at run-time -- it is irrelevant to most of the problems I solve. I still often find Java lacking in other aspects.
Oh no... Speed is just part of the issue, and for me personally, far from the most important part. Check this, this,
this and this for more reasons why some people still don't find Java an adequate language for their jobs.
I currently make most of my living programming Java, yet I view it as either C++ for dummies or Python for suites, and either way, it doesn't match the original.
The thing is that this offshoring business is actually possible because of the success of the Internet. I often work from my local coffeehouse when I'm not in the office, or telecommuting from home. If all I'm doing is slinging bits, does it really matter where I am? Often the answer is no...
Actually, telecommuting is different from outsourcing (whether offshore or not) in that, for a business, a telecommuter is still an employee. The business has control over its own employees, but not over its supplier's employees. You may not necessarily see the telecommuter in the office every day, but you can switch him from one project to another, you can send him to a training, you can fire him, you can minimize the chances of him working for your competitor at night-time, you can prevent him from outsourcing his job to somebody else, and most importantly, it is you who gets to hire him. Once you outsource a job, you trust somebody else to do all of this.
Personally, I like Python more than other general-purpose programming languages, and I keep a copy of the Python interpreter running in an xterm on my desktop at all times. Python is no doubt a very clean (yet expressive) programming language, and it also has an enormous standard library. All of that makes it a nice general-purpose programming language. That being said, Python is not an adequate replacement for Shell as a tool for (to quote the original poster) "tying things together in an automated way" nor is it an adequate replacement for Shell as a lanugage for interactive terminal sessions. For one,
ls
is shorter than
import os os.system("ls")
For two, believe it or not, outside of Linux, Python doesn't necessarily come with a Unix system by default, and no, where I work (a huge financial company), they won't let you compile an external package on a production host. Nor does Python come with the default OpenBSD installation that I run on an old Pentium which I happily use as a router/firewall at home. Granted, it's not a big deal to install Python on OpenBSD, but really, it takes more time and probably effort than piping find to xargs, and that's about the most advanced "program" that I ever write on that OpenBSD machine.
To summarize, I believe that these two reasons (less verbose and always available) make shell a very viable scripting tool even today, in the presence of Python and Perl. And no, a shell script is not necessarily a mess when written by a good developer, just as Python code is not necessarily all clean and readable when written by a moron.
Patterns lead to cracks in the numbers that can be culled for weaknesses in the algorithm. This in turn leads to knowledge of what algorithm is being used, which in turn leads to a directed cryptanalysis of the data, exactly what true random numbers are meant to avoid.
Isn't it a fundamental idea behind cryptography that security of the encrypted data lies in the key, not in the algorithm? In other words, you don't try to protect the data by not revealing the algorithm, instead, you protect it by not revealing the key.
Slashdot Mirror
So why not require non-citizens to have the word "ALIEN" superimposed in big red letters on their licenses and also have their visa expiration date annotated?
You know what...a person can be a non-citizen with a "visa" that never expires. That's called "legal permanent resident", or, colloquially, "a green card holder".
And if you start tagging every permanent resident as potential terrorist, how's that more effective than any other overly broad scheme for identifying potential terrorists?
I didn't mean it was impossible to avoid runtime vtable lookup in Java, I said it was impossible to avoid virtual methods in Java. The difference is that while a JVM can optimize certain vtable lookups away, there is no way for the programmer to force this in a way portable across JVM implementations.
The point he's making is that the C++ code is poorly written, and that might well affect benchmarking.
Also, if the activate function is virtual (no way to avoid it in Java), this is a runtime vtable lookup in the loop, whereas for a statically allocated object the address of the function would have been fixed at runtime. Granted, the cost is probably negligible to that of activate's implementation, but (a) it's impossible to know without actually profiling the code, and (b) the activate()'s implementation is likely to be as poorly written as the code that calls it.
Of course, all of this implies I was too lazy to actually look at the activate()'s code...this is Slashdot after all...
Maybe it's just me, and some fiddling with the settings would fix it, but neither less nor vi display UTF-8 properly, nor can vi properly handle UTF-8 input. I tried compiling mutt with various versions of ncurses/ncursesw and libiconv, and still couldn't get it to properly handle utf-8 messages. Again, not being an OS X expert, maybe I am just doing something wrong, but on SuSE and Gentoo all it takes to internationalize xterm is export LC_ALL=en_US.UTF8, so I expect something equally simple from OS X.
Sure, he may be aware of ethereal/tcpdump, but why should he assume these tools suite his particular situation better than others (that he may be unaware of)? I, for one, read this thread to find out about new or obscure tools. I remember being surprised by a few entries in this list a year ago, and I am sure an updated copy would have a few more entries that I haven't heard about yet.
Well, some of us are not really huge fans of any OS/distro, as we are just trying to get the work done. And as far as getting work done, SuSE, in my experience, has always been worth its price. I personally view it the way I view German cars: well thought-out design, excellent engineering and superb build quality let me spend more time using the product rather than maintaining it.
I recently looked into forming an LLC in Massachusetts. LLC's minimum tax is second to only California, state income taxes suck, and the state was the last in the country to allow single-member LLCs. Not sure how that would qualify as a "magnet for high tech companies"...
I do go to ballgames to watch them. However, a ballgame takes 4+ hours off my evening, and having the ability to check e-mail once in that timeframe is sometimes invaluable. People use cell phones in the ballpark, and nobody complains...how is e-mail different?..
While I am not necessarily disagreeing with you, a couple points come to mind...
Please try going to IBM/HP/Oracle and tell them to implement you a 10 million dollar software solution but tell them you don't want them to spend time doing any actual planning. You'd just like them to start coding immediately.IBM/HP/Oracle, as every big company, tend to have many clueless managers who need to attend meetings with other clueless managers. I am not necessarily saying that all diagrams are created solely for the sake of dumb managers looking smart in their meetings, but a lot of them are.
Another point, I am wondering how many diagramming is done in large distributed open-source projects? Do Linux/BSD/Postgres/whatever developers often exhange diagrams? Or does plain English suffice for them? Not being a developer on any of these projects, I don't know, but I would think that there is a lot less diagramming going on than there is in a big fat corporation, yet the results are often comparable, especially considering the difference in manpower. Would be interesting to hear from somebody with a first-hand knowledge...
It would probably be easier for you to find a provider that gives you ssh access. Then you can use SSH forwarding to establish an encrypted channel between your mailreader and POP3/IMAP server. SSH forwarding is a great SSH feature that you can use for a variety of other neat setups. Try ssh man page for more details.
I certainly agree. However, as someone who started with Unix and only really encountered Windows on my third job after college, I would like to note that it's not necessarily better on Windows.
When you want to find a phrase in Notepad (or MS Word), how is Edit->Find, or Ctrl-F more obvious than 'apropos search' on Unix is? I found myself repeatedly trying the 'View' menu when looking for a search/find command in Windows editors until I finally memorized that the Find command is under 'Edit'. When you memorize this as a fact with no underlying logic, it becomes as obvious as 'grep' is to a Unix user, but until then it's a struggle.
I don't think it is bad, though. You'll hear people complain about complex interfaces all the time, not necessarily in computing. A friend of mine was recently whining about skiing being hard because one pressures the left ski when turning right (and vice versa). I am sure that if one-year olds could really speak, they would tell us long stories about how much harder walking is than it really should be.
In short, to do non-trivial things properly, one has to invest some time in learning them. Until then, things you know seem to be easier than things you don't, even though in reality neither is necessarily more complex than the other.
Conceptually, yes, but then compiling is just a bunch of preprocessing steps. C++ template facility is fully aware of the rest of the language. Sure, you can implement it in a preprocessor, but such a preprocessor would have to understand its own target language syntax, thereby duplicating a large part of compiler's functionality.
There are a few preprocessors of this type available for java (and other languages that don't have meta programming as part of thier spec). Many people do use them to generate code. Actually a lot of the NIO code in jdk1.4 is created in this manner. There are also libraries for java that contain STL functionality (again often created using code generation techniques).Interesting. I still expect them to either significantly lack in functionality compared to C++ templates, or accept a language that is very different from Java. That being said, I would still love to take a look at a Java preprocessor that is believed to be an adequate replacement for C++ templates.
As for RAII, most java constructs obay these principles. A file is opened when you construct its FileReader/FileInputStream/RandomAccessFile. It can be closed manualy, however if you do not it will (should) be closed when it gets GC'd. There are some poorly designed classes in java that do not obay the principles but that is true of any language.Garbage collection is not deterministic -- that is, the language doesn't define when garbage collector is run. Which renders it largely useless for implementing RAII in a generic case. For memory (in most circumstances) you don't care whether a garbage collector is run now or a couple processor intructions later. For other resources, it makes a difference: think about releasing a mutex, for example...
I was pointing out that, as a language, Java doesn't support a few constructs that make it significantly easier to develop and maintain software (and thus, run-time speed is not all that matters to "anti-Java zealots" as the parent states). Most of the STL concepts, especially when you look beyond containers, cannot be expressed as compactly and as elegantly with Java as they are with C++. Ditto for the RAII idiom.
I personally don't care about Java being slow at run-time -- it is irrelevant to most of the problems I solve. I still often find Java lacking in other aspects.
I currently make most of my living programming Java, yet I view it as either C++ for dummies or Python for suites, and either way, it doesn't match the original.
Actually, telecommuting is different from outsourcing (whether offshore or not) in that, for a business, a telecommuter is still an employee. The business has control over its own employees, but not over its supplier's employees. You may not necessarily see the telecommuter in the office every day, but you can switch him from one project to another, you can send him to a training, you can fire him, you can minimize the chances of him working for your competitor at night-time, you can prevent him from outsourcing his job to somebody else, and most importantly, it is you who gets to hire him. Once you outsource a job, you trust somebody else to do all of this.
For two, believe it or not, outside of Linux, Python doesn't necessarily come with a Unix system by default, and no, where I work (a huge financial company), they won't let you compile an external package on a production host. Nor does Python come with the default OpenBSD installation that I run on an old Pentium which I happily use as a router/firewall at home. Granted, it's not a big deal to install Python on OpenBSD, but really, it takes more time and probably effort than piping find to xargs, and that's about the most advanced "program" that I ever write on that OpenBSD machine.
To summarize, I believe that these two reasons (less verbose and always available) make shell a very viable scripting tool even today, in the presence of Python and Perl. And no, a shell script is not necessarily a mess when written by a good developer, just as Python code is not necessarily all clean and readable when written by a moron.
Right. I thought you were referring to the data encryption algorithm, but you apparently were talking about the key generation algorithm...
Patterns lead to cracks in the numbers that can be culled for weaknesses in the algorithm. This in turn leads to knowledge of what algorithm is being used, which in turn leads to a directed cryptanalysis of the data, exactly what true random numbers are meant to avoid.
Isn't it a fundamental idea behind cryptography that security of the encrypted data lies in the key, not in the algorithm? In other words, you don't try to protect the data by not revealing the algorithm, instead, you protect it by not revealing the key.