When you are building a software application, you try to get everything synchronized, so all programmers will be able to understand and feel confident in each other's code.
Depends. In large projects, quiet often programmers are not familiar with each others code. But you are right: whenever you add a scripting language to the mix, you should make sure the quality standards are maintained.
Therefore, in a serious project, with millions invested, scripting can be a dangerous shortcut that may plague the project a year later.
[...]
Uniformity often leads to quality.
There is no uniformity in large projects. Perhaps the core is written in C++ or Java. But the database is accessed with SQL. Stored procedures have their own DB vendor-specific language. The build environment is made of a bunch shell scripts and makefiles with their own language. And the installation programs, application startup scripts, and a web GUI with huge dependency on JavaScript etc. etc.
On the other hand scripting languages can contribute big time to the overall quality of products. First, because scripting languages can really help to avoid some common mistakes, mainly pointer miseries. Second, because they can easily reduce code size to half or more. Less code, less bugs;
less coding, more time for testing!
The only way to be safe is not to
open any attachments, even if you think you know
what they are.
Now that's what I call the balkanization of
computing. We ended up with an operating
system/office applications combo which discourages
us opening e-mail attachments.
Conceptually, only the email protocol matters between the client and server.
Please don't forget the original question was about storing mail within the MUA. In this context, using the filesystem and a standard format like mbox, together with some kind of indexing is a very reasonable solution.
Re:The name of the sequel has been leaked out!
on
Tron 2.0 Game
·
· Score: 1
"A small bellows and vibrating reed, a sort of artificial speaking mechanism, was incorporated whereby the operator could signal "check!" by forcing air through a tube. The approximation of the word "check" was said to lack clarity..."
Randi says this was an improvement made by
Maelzel, who bought the machine after von
Kempelen's death, but I think this idea, too,
came from Kempelen's work, who spent his
last years researching speech synthesis. Quiet
successfully as he actually
did build
a speech synthetizer capable producing whole
words and short sentences. And this machine
was not a trick: it is exhibited in the Deutches
Museum in Munich, and, according to the author
of the link I mentioned, still functional.
On the other hand, guidebooks for destroying railroad tracks server no other purpose than destroying railroad tracks in attempts to disrupt the service, with the unfortunate possibility of killing people.
Destroying railroad tracks can serve a very useful
purpose, during war time for example. It is still
just a tool, like the brick or the screwdriver or
the A-bomb. It's the usage what matters.
Given that there is now a version of Vim for both Gnome & KDE, does it make sense for (X)Emacs to make the jump too? I know the origins of Xemacs are as much political as technical - but does it not make sense to try to branch off 2 versions of emacs into the 2 guis?
On the other hand, your list supports nicely his list of fallacies: the majority of the items here could not be written in VB or Excel by people who learned programming from books like "Teach Yourself C++ in 14 Easy Lessons" etc. Or: imagine the F16 computer giving you a login prompt one minute after hitting the reset button.
I think what Michi Henning is trying to tell us is that a very large part of this industry is heading to the wrong direction, forcing us to use general purpose computers and universal software tools. That's not the future. With my first VCR, I had to program the clock manually. My second one just knew what the time is after plugging the cable in.
IIRC, most biometric systems won't accept a finger that isn't alive. Worse, some of them will trigger a silent alarm if someone attempts to use a severed finger.
Now that's interesting. How do they achieve this? Do I have to pre-heat my stolen fingers?
... and you have a good point, too. I think the growth of bandwidth will end when the resolution of the virtual worlds served will reach the resolution of our senses (plus-minus a few terabits per second...). At that point, the data pipeline will be as good as the current water/electric etc. pipelines: no need to upgrade for long years.
But it is not only the bandwidth which may force you to switch. SMS is a killer application with ridiculously low bandwidth requirements. And mobility itself is a killer application.
There is propably no point to continue with
malloc-ing if a previous one fails. And having
the clean-up code duplicated may lead to
maintenance problems.
What I would do:
int allocate_3(void) {
int *p1, *p2, *p3;
int error = 0;
p1 = p2 = p3 = (int *)0;
cleanup:
if (p1) free(p1);
if (p2) free(p2);
if (p3) free(p3);
return error;
}
Other people, fearing of gotos, would prefer
putting the mallocs into a for(;;) loop, breaking
out when something goes wrong (and at the end,
of course). I don't like this but I consider it
as a valid alternative. The goals are the same in
both cases: avoid nesting in the code, and avoid
duplicating the cleanup handler.
The problem with GPRS is that the suppliers are likely to kill the market by charging too much and restricting the accessable sevices to a few WAP sites which the supplier has a relationship with (I'm told at least one telco in the UK does this, but I havn't checked it out).
There are some funny exceptions, like TeleDenmark, a Danish provider who couldn't figure out yet how to charge for data (instead of air time), so they don't charge at all, but call it "introductory price".
Slashdot Mirror
On the other hand scripting languages can contribute big time to the overall quality of products. First, because scripting languages can really help to avoid some common mistakes, mainly pointer miseries. Second, because they can easily reduce code size to half or more. Less code, less bugs; less coding, more time for testing!
#include <stdio.h>
Try this in the car, train, cafe etc. With Bluetooth you don't even have to remove your phone from your pocket.
There is a Wi-Fi enabled camera from Sanyo. Fairly useless right now I believe; might be interesting in a year or two.
Is there an SMB or NFS server for palmtops? One could achieve the same with a file server and a VNC client.
Actually he meant .JointPhotographicExpertsGroupTwoThousands.
...finally works with the old banking applet I'm forced to use. Cheers!
I think what Michi Henning is trying to tell us is that a very large part of this industry is heading to the wrong direction, forcing us to use general purpose computers and universal software tools. That's not the future. With my first VCR, I had to program the clock manually. My second one just knew what the time is after plugging the cable in.
Sure, and desktops existed way before computers. The best ideas are always obvious - after inventing them.
For many (graphical) applications, a desktop icon or menu entry should be enough - there is no need to add them to $PATH
But it is not only the bandwidth which may force you to switch. SMS is a killer application with ridiculously low bandwidth requirements. And mobility itself is a killer application.
There is propably no point to continue with
/* Here we do something with p1, p2, p3 */
malloc-ing if a previous one fails. And having
the clean-up code duplicated may lead to
maintenance problems.
What I would do:
int allocate_3(void) {
int *p1, *p2, *p3;
int error = 0;
p1 = p2 = p3 = (int *)0;
p1 = malloc(...);
if (!p1) {
error = 1;
goto cleanup;
}
p2 = malloc(...);
if (!p2) {
error = 1;
goto cleanup;
}
p3 = malloc(...);
if (!p3) {
error = 1;
goto cleanup;
}
cleanup:
if (p1) free(p1);
if (p2) free(p2);
if (p3) free(p3);
return error;
}
Other people, fearing of gotos, would prefer
putting the mallocs into a for(;;) loop, breaking
out when something goes wrong (and at the end,
of course). I don't like this but I consider it
as a valid alternative. The goals are the same in
both cases: avoid nesting in the code, and avoid
duplicating the cleanup handler.
...or HP's own PA-RISC.