I've worked from 1988 to 1997, more or less, in large projects using varuious mixture of COBOL, C and so called 4GLs (Oracle).
Main "advantage" of COBOL should be that if you restrict usage to a given subset of the language you may have mediocre coders *and* a relatively low defect count.
Not much else to recommend it for, though.
The idea of using it for HTML generation is pretty ridicolous, because, at least in my experience, using COBOL doesn't really help you keeping a flexible mind about different "paradigms" and having to suddenly reason in terms of page requests, caching, static vs. dynamic etc. would probably be a little overwhelming for the skillset of the "existing workforce who already knows the language".
Minority Report took things in the right direction for the first 2/3rds. But that stupid "echo murder" crap leading upto the happy ending bit it.
About the "happy ending" part you cite...
SPOILER SPACE follows
Someone noted that the parts *after* the main lead "imprisonment" could just be manufactured hallucinations. In a previous sequence, one of the pre-crime squad gives an off-hand remark about the fact that when you are in the "punitive coma" you sleep whatever reality you want.
So everything we see after Cruise's character is captured could be his dream of how things should go, not necessarily reality itself.
This would explain the improbable ending and be quite faithful to Dick's ideas, even if the director does not clearly states how things "really are".
Correct me if I am mistaken, but didn't ArsDigita move everything to Java for its ACS framework?
Or was this blamed to the evil VCs, too, in the revisionist phase of Greenspun history?
I believe that the movie was an attempt to depict a sort of dream (hints: the claustrophobically framed shots, the daughter asking "are you in my dream too?" at the start, the final scene in which the main character is dressing up with what seems a renowned resolve... it could be that the last scene shows him getting ready for a new day after a very strange, but in the end "reassuring" dream).
If you accept my hypotesis, it works much better: nothing really makes sense, but the strange "internal logic" of dreams (see also the UFO book, and the car accident subplot) seems to be well captured by the story.
YMMV...
Re:Scott Myers
on
Effective Java
·
· Score: 2, Informative
Do you have any suggestion for a book or online resource where I could learn more about these things?
Regarding concurrent programming, I would go for "Taming Java Threads" by Allen Holub.
A lot people would also cite "Concurrent Programming in Java: Design Principles and Pattern" by Doug Lea.
Personally I prefer the first. The second one is far more complete in its exhaustive analysis of concurrent programming, but the first is more "hands-on".
Re:Who Actually USES These Patterns?
on
Design Patterns
·
· Score: 1
Virtually no one. I've been in the industry 10 years in banking and the scientific fields and I've yet to see any real programmers using this sort of stuff. Its written for ivory tower academics and students mainly.
I suppose you should qualify your experience a little better, before issuing such opinions. I suspect that you either use non-Object Oriented languages, or have failed to recognize some of the solutions you encountered as a classic pattern.
If you do work with OO tools and a DB, I really doubt you never used at least a couple of the basic patterns (especially Singleton).
These laws are not only scary, they are crazy. If serving people with disabilities is so important, then I'll do it, because it makes financial sense for me to do so. But if these people are largely irrelevant to my target market (say, I run a website for bird-watchers or target-shooting enthusiasts - should I be obligated to put up a version readable by vision-impaired people ?), I should have the right to ignore this segment of the market - at my own peril, of course.
If they're going to legislate me into putting in 'assistive technology' into my websites, why don't they force magazines to put out Braille versions, or make them supply audio-cassettes or CDs with the contents transcribed ? Why don't they widen airplane and car and bus seats so morbidly obese people can sit in them ?
Note that (at least from what I have seen here in Europe) the accessibility requirement is mandatory for public services sites only.
You are not forced to support blind "customers", but if you are, say, the webmaster for some government site, you are required to assist blind "citizens" to know what laws apply to them, for example.
I understand your position, but please do not equate citizens with customers.
Most of the messages I've seen so far seem to imply that the cost saving of not needing Windows are not enough to justify the switch for business users.
My question is, would it be possible (both technically and license-wise) to install this plugin (plus office) on just one big linux server and having multiple users log-in and use it through X-windows?
In this case I suppose that the savings would be greater, and you could also ensure centralized back-ups without any problem.
So, would it work?
4. The heires to the Flash Gordon fortune, who happened to be nuts over D&D, was the person who bought up most of TSR's outstanding stock and kicked Mr. Gygax out of TSR. (This is mainly what I read and heard about many years ago so take it with a grain of salt.) From what I heard, Mr. Gygax kicked out several of the people this lady liked from TSR and in a fit of revenge she did this.
Hate to nitpick, but the person you are referring should be Lorraine Williams, and she had rights to Buck Rogers, not Flash Gordon.
For a discussion of this, you can check a
detailed discussion which has just appeared on javalobby.
Be aware that the author is a staunch Java advocate, but I think it's interesting anyway...
>Maybe it's my failing, but I honestly don't know
>why any one chooses to use it with so many other
>(better) alternatives.
I used it extensively to supplement a java/oracle project on Solaris. The main modules were in Java, we used Perl to do the following:
a) Ad hoc reporting.
b) Utilities used by the Helpdesk people for routine checks
c) plumbing&interfacing with the OS, substituting shell scripts.
d) scripts to migrate/update data in the DB when required by a new version of the main sw.
Some of these (except "c") could have been done in Java, but by choosing Perl we could do some quick experiments or testing directly on the (remote) production machine using "vi", without the hassle of compiling code on it (which we considered a bad thing by itself).
We were also able to "subsidize" some of our development effort: most of the perl scripts were created and/or mantained by people who were not proficient with Java (like our DBA), and we found that this worked well enough: people armed with the Perl Cookbook could create a lot of functionalities in a short time.
The application field was related to remote management of telecom devices, so the ability to interface through telnet, sockets (even snmp, but we never needed to use it) was a real boon.
I left the original project, but keep in touch with people working on it, and Perl is still used a lot.
Please consider that nobody in the group knew Perl at the start. Most of the things I've listed had to be done by using Java, bash, awk. Even plain old C in a case.
We decided to introduce a scripting language before this hodgepodge of ad-hoc scripts reached "critical mess", and it worked for us.
I worked for three years on a medium-sized telco project. It started in Java, and kept growing.
Due to management decision (they did not want to invest in a proper RDBMS until the system reached a "critical" size) we had to persist most of the state of the system in a series of small files, organized in directories and subdirectories. Files were simple key/value sets, in plain ASCII text.
It worked fairly well, because we were able to react to changes and new requests fairly fast, and by leveraging the various Unix text-processing utilities we could create simple scripts for quick and dirty statistics, reports and so on.
When the dataset started growing we decided that plain shell scripts were not enough anymore (especially considering that the developers were not very fluent in Unix scripting). We did a brief survey, invested in a couple of books, and started using Perl to supplement our needs.
It worked very well. Most of the utilities were coded in Perl (or recoded to substitute the original scripts), and it proved invaluably useful to finally migrate our data to Oracle when management finally allowed use to move on.
I've left the project, but I still keep in contact with them, and for what I understand Perl is still used alongside with Java. The rule of thumb is that the main application is completely Java, but everything else (i.e. utilities, DB maintenance, ad-hoc reporting) is done in Perl.
What we did from the start is to always keep the two things clearly separate, and use the data as the only interface point between the two languages.
Our experience has been mostly positive, and Perl proved to be easy enough to learn/use for our needs (nobody claims to be or have become a Perl Guru, btw).
I'd be wary to use more than 2 languages (we even minimized PL-SQL usage for exactly this reason), though. And I'd prefer not to intermingle them as the original poster seems to do on a regular basis. I'd really prefer not to invoke processes written in "X" by a process created in "Y".
Our Perl stuff was either invoked by command line or launched by cron. Our choice could have been influenced by problems in invoking external processes in Java, but all in all I am very satisfied by the choice we made, and things worked well enough for us.
One of the problems we had was the fact that we never found a good IDE to work on both Java and Perl (on Solaris). The best bet would have been (IMHO) VisualSlickedit, but the expense was vetoed by the management.
(Yeah, I know, we should have used EMACS...)
This was not a major showstopper, but I think it would have been nice to be able to check, say, usage of a constant string like "OPEN" in both Java and Perl sources at the same time, from inside the same tool, in case we wanted to replace it with "UNPROCESSED" or "PENDING".
Slashdot Mirror
... done that, etc.
I've worked from 1988 to 1997, more or less, in large projects using varuious mixture of COBOL, C and so called 4GLs (Oracle).
Main "advantage" of COBOL should be that if you restrict usage to a given subset of the language you may have mediocre coders *and* a relatively low defect count.
Not much else to recommend it for, though.
The idea of using it for HTML generation is pretty ridicolous, because, at least in my experience, using COBOL doesn't really help you keeping a flexible mind about different "paradigms" and having to suddenly reason in terms of page requests, caching, static vs. dynamic etc. would probably be a little overwhelming for the skillset of the "existing workforce who already knows the language".
Could you provide a couple of titles you liked more than Gibson's and Matrix?
Thanks...
(Not that I necessarily disagree with your point... especially regarding The Matrix).
SPOILER SPACE follows
Someone noted that the parts *after* the main lead "imprisonment" could just be manufactured hallucinations. In a previous sequence, one of the pre-crime squad gives an off-hand remark about the fact that when you are in the "punitive coma" you sleep whatever reality you want.
So everything we see after Cruise's character is captured could be his dream of how things should go, not necessarily reality itself.
This would explain the improbable ending and be quite faithful to Dick's ideas, even if the director does not clearly states how things "really are".
Correct me if I am mistaken, but didn't ArsDigita move everything to Java for its ACS framework? Or was this blamed to the evil VCs, too, in the revisionist phase of Greenspun history?
---**** SPOILER BELOW ****---
I believe that the movie was an attempt to depict a sort of dream (hints: the claustrophobically framed shots, the daughter asking "are you in my dream too?" at the start, the final scene in which the main character is dressing up with what seems a renowned resolve... it could be that the last scene shows him getting ready for a new day after a very strange, but in the end "reassuring" dream). If you accept my hypotesis, it works much better: nothing really makes sense, but the strange "internal logic" of dreams (see also the UFO book, and the car accident subplot) seems to be well captured by the story. YMMV...
Adolf Hitler was a vegetarian.
Urban legend. Hitler followed a low-meat diet due to stomach and digestive problems, but wasn't a vegetarian.
Google away with "Hitler Vegetarian" as keys...
What about the insidious banana problem?
Do you have any suggestion for a book or online resource where I could learn more about these things?
Regarding concurrent programming, I would go for "Taming Java Threads" by Allen Holub.
A lot people would also cite "Concurrent Programming in Java: Design Principles and Pattern" by Doug Lea.
Personally I prefer the first. The second one is far more complete in its exhaustive analysis of concurrent programming, but the first is more "hands-on".
Virtually no one. I've been in the industry 10 years in banking and the scientific fields and I've yet to see any real programmers using this sort of stuff. Its written for ivory tower academics and students mainly.
I suppose you should qualify your experience a little better, before issuing such opinions. I suspect that you either use non-Object Oriented languages, or have failed to recognize some of the solutions you encountered as a classic pattern.
If you do work with OO tools and a DB, I really doubt you never used at least a couple of the basic patterns (especially Singleton).
These laws are not only scary, they are crazy. If serving people with disabilities is so important, then I'll do it, because it makes financial sense for me to do so. But if these people are largely irrelevant to my target market (say, I run a website for bird-watchers or target-shooting enthusiasts - should I be obligated to put up a version readable by vision-impaired people ?), I should have the right to ignore this segment of the market - at my own peril, of course.
If they're going to legislate me into putting in 'assistive technology' into my websites, why don't they force magazines to put out Braille versions, or make them supply audio-cassettes or CDs with the contents transcribed ? Why don't they widen airplane and car and bus seats so morbidly obese people can sit in them ? Note that (at least from what I have seen here in Europe) the accessibility requirement is mandatory for public services sites only.
You are not forced to support blind "customers", but if you are, say, the webmaster for some government site, you are required to assist blind "citizens" to know what laws apply to them, for example.
I understand your position, but please do not equate citizens with customers.
Most of the messages I've seen so far seem to imply that the cost saving of not needing Windows are not enough to justify the switch for business users. My question is, would it be possible (both technically and license-wise) to install this plugin (plus office) on just one big linux server and having multiple users log-in and use it through X-windows? In this case I suppose that the savings would be greater, and you could also ensure centralized back-ups without any problem. So, would it work?
4. The heires to the Flash Gordon fortune, who happened to be nuts over D&D, was the person who bought up most of TSR's outstanding stock and kicked Mr. Gygax out of TSR. (This is mainly what I read and heard about many years ago so take it with a grain of salt.) From what I heard, Mr. Gygax kicked out several of the people this lady liked from TSR and in a fit of revenge she did this.
Hate to nitpick, but the person you are referring should be Lorraine Williams, and she had rights to Buck Rogers, not Flash Gordon.
For a discussion of this, you can check a detailed discussion which has just appeared on javalobby. Be aware that the author is a staunch Java advocate, but I think it's interesting anyway...
>Maybe it's my failing, but I honestly don't know
>why any one chooses to use it with so many other
>(better) alternatives.
I used it extensively to supplement a java/oracle project on Solaris. The main modules were in Java, we used Perl to do the following:
a) Ad hoc reporting.
b) Utilities used by the Helpdesk people for routine checks
c) plumbing&interfacing with the OS, substituting shell scripts.
d) scripts to migrate/update data in the DB when required by a new version of the main sw.
Some of these (except "c") could have been done in Java, but by choosing Perl we could do some quick experiments or testing directly on the (remote) production machine using "vi", without the hassle of compiling code on it (which we considered a bad thing by itself).
We were also able to "subsidize" some of our development effort: most of the perl scripts were created and/or mantained by people who were not proficient with Java (like our DBA), and we found that this worked well enough: people armed with the Perl Cookbook could create a lot of functionalities in a short time.
The application field was related to remote management of telecom devices, so the ability to interface through telnet, sockets (even snmp, but we never needed to use it) was a real boon.
I left the original project, but keep in touch with people working on it, and Perl is still used a lot.
Please consider that nobody in the group knew Perl at the start. Most of the things I've listed had to be done by using Java, bash, awk. Even plain old C in a case.
We decided to introduce a scripting language before this hodgepodge of ad-hoc scripts reached "critical mess", and it worked for us.
Did you intentionally mispell HILTER in order to avoid Godwin's Law?
I worked for three years on a medium-sized telco project. It started in Java, and kept growing.
Due to management decision (they did not want to invest in a proper RDBMS until the system reached a "critical" size) we had to persist most of the state of the system in a series of small files, organized in directories and subdirectories. Files were simple key/value sets, in plain ASCII text.
It worked fairly well, because we were able to react to changes and new requests fairly fast, and by leveraging the various Unix text-processing utilities we could create simple scripts for quick and dirty statistics, reports and so on.
When the dataset started growing we decided that plain shell scripts were not enough anymore (especially considering that the developers were not very fluent in Unix scripting). We did a brief survey, invested in a couple of books, and started using Perl to supplement our needs.
It worked very well. Most of the utilities were coded in Perl (or recoded to substitute the original scripts), and it proved invaluably useful to finally migrate our data to Oracle when management finally allowed use to move on.
I've left the project, but I still keep in contact with them, and for what I understand Perl is still used alongside with Java. The rule of thumb is that the main application is completely Java, but everything else (i.e. utilities, DB maintenance, ad-hoc reporting) is done in Perl.
What we did from the start is to always keep the two things clearly separate, and use the data as the only interface point between the two languages.
Our experience has been mostly positive, and Perl proved to be easy enough to learn/use for our needs (nobody claims to be or have become a Perl Guru, btw).
I'd be wary to use more than 2 languages (we even minimized PL-SQL usage for exactly this reason), though. And I'd prefer not to intermingle them as the original poster seems to do on a regular basis. I'd really prefer not to invoke processes written in "X" by a process created in "Y".
Our Perl stuff was either invoked by command line or launched by cron. Our choice could have been influenced by problems in invoking external processes in Java, but all in all I am very satisfied by the choice we made, and things worked well enough for us.
One of the problems we had was the fact that we never found a good IDE to work on both Java and Perl (on Solaris). The best bet would have been (IMHO) VisualSlickedit, but the expense was vetoed by the management.
(Yeah, I know, we should have used EMACS...)
This was not a major showstopper, but I think it would have been nice to be able to check, say, usage of a constant string like "OPEN" in both Java and Perl sources at the same time, from inside the same tool, in case we wanted to replace it with "UNPROCESSED" or "PENDING".