Everyone I know turns off the findfast feature of Microsoft Office
(a.k.a. "runslow"). I'm not sure it's even enabled by default any
longer. I've seen non-techies install Office and then be mystified by
sluggish behavior and high levels of disk activity. The culprit was
findfast, indexing everything on the disk. Kill and disable findfast
and everything goes back to normal.
I'm sure that this eventually stops, once it is only necessary to
index new and changed documents. I never waited long enough to find
out.
Anyway, it's pretty obvious what's going to happen. This software is
going to be installed, and the poor PC support guys are going to be
flooded by complaints about sluggish systems, and everyone will just
live with it. The workplace gets a
tiny bit more hostile...
Remember that James Bond movie? Bond and some bad guy (Klaus Maria Bandauer?) were playing this nuke the planet video game on this big display that floated in space between the two players, and each time you got hit, you got zapped by the two joysticks you held. That was cool.
I was at McGill University in Montreal when these absurd laws were
passed. The DMCA looks sane in comparison. These language laws specify
things like the relative font sizes of English and French signs in
various contexts, and whether English is permitted at all. Every so
often, these "Tongue Troops" as they were known would do something
really spectacular and land on the front page of the regional or
national newspapers. For example, there was the time they forced an
English language bookstore to replace interior English signs with
French ones. Then there was the suggested list of French terms for
English words that had polluted French. For example, I think they
suggested something like "hambourgeois" to replace "hamburger", which
is in common use by everyone. When these laws went into effect, I
think I remember reading that the only similar laws existed in Libya.
So as another poster has mentioned, this is nothing new in
Quebec. And driving out (e-) commerce is nothing new. There was a mass
exodus of businesses in the last seventies and early eighties from
Montreal to Toronto.
Do you really expect to see three variables initialized to 0, 1 and 2 in a tight inner loop? The ridiculous PL/I initialization syntax sought to be concise, and this was achieved at the expense of clarity. This Perl construct seems the same. Just about any syntactic monstrosity can be justified on the grounds of performance, but you have to wonder how much it's really going to help in practice.
25 years ago, I spent many hours debugging a PL/I program to discover that some code I inherited relied on arcane initialization rules and got it wrong. How nice to know that untold generations of programmers will now have the same experience thanks to constructs like "my int ($pre, $in, $post) are constant = (0..2);"
I was never a Perl fan and I'm even less of one now. But out of curiosity, what possible justification is there for such a construct?
I was also happy to see Basic's "dim" recycled.
Really guys, haven't we learned anything since oh, I don't know, 1965?
To address all the postings pointing out that Linux distros also do bundling: The difference you're overlooking is that Microsoft is a monopoly, and they are using their monopoly in one market to harm competitors in another. That is illegal.
Microsoft's counter-argument is that they are just enhancing the OS (i.e. they aren't going into another market).
There is no limit on the database size. The limit is on the amount of mapped memory space in a single transaction, 1gb in your case.
You sometimes have to plan things carefully, (e.g. judicious use of ObjectStore references), to avoid running out of address space.
Are you sure that your lack of market penetration was not fundamentally because none of your customers had a good word to say about your product?
Well, Anonymous Coward, if that is your name, "none" is provably false. All I can say is that your experience was atypical based on the information I saw. Databases over 1gb were common, and most customers I met were very pleased with tech support.
I am one of the founders of Object Design (now Excelon Corp.) We had
the slickest OODBMS -- persistence was implemented by taking over
memory mapping, (no "overloading the arrow operator"). It was the
least obtrusive OODBMS. Other systems of the day required you to use
different string libraries or forego C/C++ standard arrays (for
example). Other systems arguably had better scalability or concurrency
models.
As someone else has pointed out, OODBMSs require a very different
skill set. The problem isn't that your typical SQL developer didn't
have these skills. The problem is that the things were ever referred
to as database systems.
If you walk into a potential customer selling a "database system",
then the database guys come and hear what you have to say. They ask
about SQL support and point-and-click development tools. They are
going to be looking for very high levels of concurrency, at isolation
levels below serializable.
Selling a "database system" meant that once we got past the early
adopters, we were selling against Oracle and we hit a wall. What we
should have done from day one was to sell persistence for C++.
We did start out like this, e.g. trying to convince ECAD vendors to
build
their products on top of ObjectStore. That had some limited success
because the customers knew that they needed persistence, but they were
C/C++ hackers at heart, and an RDBMS was a poor compromise.
A "database for C++ with no impedance mismatch"
sounds great to someone writing a 3d modeler.
We then
went on to apply the same logic selling to satisfied RDBMS
users without changing our strategy, and that's when things stalled.
That strategy was necessary in some ways, because we were venture-funded, and the VCs weren't going
to be happy with a small niche. They wanted something that would get into every insurance company and bank. However, by aiming high and failing (by VC standards), we abandoned our natural market too soon and avoided becoming a small success in that market.
This is utterly bizarre. What on earth is IBM buying? It can't be the
"brand". That was destroyed in the disastrous Illustra integration.
It can't be the software, which was crap. In 200 lines of code, I
wrote two different test cases, (only one of which was multithreaded), which crashed the Informix server.
It can't be the support
organization. Getting help from Informix support was a surreal
experience. There was the time I had to instruct one of their support
guys how to unzip a zip file. I had to explain to another one the
concept of a client, and introduce the fact that Informix was accessed
from one.
It can't be the advanced R&D: The aforementioned Illustra was
surpassed
in all ways by IBMs research out of their Santa Teresa Labs, and some
of this research has already found its way into DB/2.
Customer base?
I didn't think Informix had that much of a following.
Templates, at least as implemented by the various C++ compilers I've worked with, are a portability nightmare. Yes, type-safe collections would be nice, but if there has to be a choice between collections of Object (only) and C++-style templates, I'll take Java. Really portable templates would be nice, and then the collections API could be redone.
Your comments about destructors and const goes to your last point. You're right, if you try to program Java as you do C++ you're hosed. I realize that Java and C++ are quite different (even ignoring memory management). My main point is that if I had to code in C++ again, I'd throw out the things that Java threw out.
I did C++ for many years and I'm now much happier in Java. I have thought about what C++ features I'd use and not use if I had to go back, and I think I'd restrict myself to the Java subset. So I'd include polymorphism, single inheritance and access control (private, protected public). I'd throw out pointer arithmetic, operator overloading, and templates. I might even avoid embedded objects (e.g. class A { B b; };).
Maybe use a limited form of multiple inheritance, simulating Java interfaces.
Wow, you're really insecure and bigoted. In your worldview, all PhDs are underqualified, conceited, and out for your job. This based on a small sample you once saw at some college.
Either a PhD applying for one of your jobs really matches your expectations, in which case you shouldn't hire them, and if you do, it should quickly become clear how incompetent and conceited they are. Or he/she really is competent and interested in doing a good job instead of covering his ass, (which seems to be your main concern), and he/she probably does deserve to have your job.
You basically admit to discrimination (emphasis added): "My fear is that if I hire a PhD... With an MS degree, this problem is reduced and with a BS it is eliminated."
Or maybe your posting is a troll. OK, well you got me.
If you're really asking about practical matters: what would you say you were doing for all that time? Actually, you could probably make up some incredibly boring plausible thing and get away with it. Providing, of course, it weren't the first or second most recent thing on your resume.
I have a comp sci Ph.D. and 13 years of experience building software
products, so I know what I'm talking about on this topic from both
sides: trying to escape academe, and interviewing job candidates in
the same position.
An advanced degree is an indulgence if you want to work as a software engineer. Do it if you want to, but don't
expect it to improve your salary. The only thing that counts is years
"in the real world", i.e. writing code for a customer or product. I
mean that literally. If someone is trying to hire a software engineer
with five years of experience, then six years in grad school and one
year of experience will usually not get past a screening of the
resume.
A Ph.D. can actually be a hindrance. If you get one, many potential
employers will view you with suspicion for a number of reasons. The
attitudes I've seen are that if you have a Ph.D. you must:
think you're too good to write code, fix bugs, write release notes,
etc.
be lousy at writing code.
be incapable of writing efficient code.
be more concerned with cool ideas and theory than shipping
a product.
have outrageous salary demands.
have a problem dealing with holders of mere B.Sc. and M.Sc. degrees.
I have never seen these sorts of concerns applied to candidates with
an M.Sc. degree.
I'm definitely not saying that you shouldn't get an advanced degree. I
really enjoyed it, and I think the quality of my work (including code)
greatly benefits from my education. My point is that potential
employers may not see it this way.
I'm also not saying that you should go get a programming job right out
of high school. Learning the basics of complexity theory, data
structures and algorithms, compilers, databases, numerical analysis -- typical undergraduate courses --
is really important if you're going to be a serious software engineer.
From your article: Others become prima donnas, demanding large salaries and extreme benefits.
Why is it that a great software developer who demands rewards commensurate with his talents is necessarily a prima donna? Executives do this all the time and no one blinks. I think the problem is popular conceptions: executives are driven by greed while software developers are driven by love for what they do. In other words, it is out of character for a software developer to raise such base concerns as salary. Well that's ridiculous. If you love what you do, and you are a master of your craft, why not insist on what you are capable of earning? You can be sure that the managers and executives you're negotiating with take exactly the same approach.
As another writer said, peer review is definitely the way to go. If you were a large company and you had a lot to automate and justify, then maybe you would have to turn to metrics, but you don't.
Look at it this way: If your metrics contradict what your small band of hackers know is right, your hackers will be unhappy and quit. In other words, metrics would be, at best, as good as peer review, and at worst, they might do a lot of damage.
Slashdot Mirror
I sure as hell won't rent from them.
I'm sure that this eventually stops, once it is only necessary to index new and changed documents. I never waited long enough to find out.
Anyway, it's pretty obvious what's going to happen. This software is going to be installed, and the poor PC support guys are going to be flooded by complaints about sluggish systems, and everyone will just live with it. The workplace gets a tiny bit more hostile ...
Absolutely true, and furthermore there is no shitty code whatsoever written in C or Perl.
Remember that James Bond movie? Bond and some bad guy (Klaus Maria Bandauer?) were playing this nuke the planet video game on this big display that floated in space between the two players, and each time you got hit, you got zapped by the two joysticks you held. That was cool.
So as another poster has mentioned, this is nothing new in Quebec. And driving out (e-) commerce is nothing new. There was a mass exodus of businesses in the last seventies and early eighties from Montreal to Toronto.
This page has links describing how to control TVs from various Psion models in the 3 and 5 families. I've tried this on my 5mx -- works great.
Do you really expect to see three variables initialized to 0, 1 and 2 in a tight inner loop? The ridiculous PL/I initialization syntax sought to be concise, and this was achieved at the expense of clarity. This Perl construct seems the same. Just about any syntactic monstrosity can be justified on the grounds of performance, but you have to wonder how much it's really going to help in practice.
I was also happy to see Basic's "dim" recycled.
Really guys, haven't we learned anything since oh, I don't know, 1965?
Microsoft's counter-argument is that they are just enhancing the OS (i.e. they aren't going into another market).
Big deal. Leonard Wheat already pointed that out in his 2001 book.
There is no limit on the database size. The limit is on the amount of mapped memory space in a single transaction, 1gb in your case. You sometimes have to plan things carefully, (e.g. judicious use of ObjectStore references), to avoid running out of address space.
Well, Anonymous Coward, if that is your name, "none" is provably false. All I can say is that your experience was atypical based on the information I saw. Databases over 1gb were common, and most customers I met were very pleased with tech support.
As someone else has pointed out, OODBMSs require a very different skill set. The problem isn't that your typical SQL developer didn't have these skills. The problem is that the things were ever referred to as database systems.
If you walk into a potential customer selling a "database system", then the database guys come and hear what you have to say. They ask about SQL support and point-and-click development tools. They are going to be looking for very high levels of concurrency, at isolation levels below serializable.
Selling a "database system" meant that once we got past the early adopters, we were selling against Oracle and we hit a wall. What we should have done from day one was to sell persistence for C++. We did start out like this, e.g. trying to convince ECAD vendors to build their products on top of ObjectStore. That had some limited success because the customers knew that they needed persistence, but they were C/C++ hackers at heart, and an RDBMS was a poor compromise. A "database for C++ with no impedance mismatch" sounds great to someone writing a 3d modeler. We then went on to apply the same logic selling to satisfied RDBMS users without changing our strategy, and that's when things stalled.
That strategy was necessary in some ways, because we were venture-funded, and the VCs weren't going to be happy with a small niche. They wanted something that would get into every insurance company and bank. However, by aiming high and failing (by VC standards), we abandoned our natural market too soon and avoided becoming a small success in that market.
It can't be the software, which was crap. In 200 lines of code, I wrote two different test cases, (only one of which was multithreaded), which crashed the Informix server.
It can't be the support organization. Getting help from Informix support was a surreal experience. There was the time I had to instruct one of their support guys how to unzip a zip file. I had to explain to another one the concept of a client, and introduce the fact that Informix was accessed from one.
It can't be the advanced R&D: The aforementioned Illustra was surpassed in all ways by IBMs research out of their Santa Teresa Labs, and some of this research has already found its way into DB/2.
Customer base? I didn't think Informix had that much of a following.
So what is it? What? I just don't get it.
Get in line, sonny. They're still coming out with new versions of Ada, COBOL and FORTRAN.
... would be 7f6. (As in 0x7f6)
Your comments about destructors and const goes to your last point. You're right, if you try to program Java as you do C++ you're hosed. I realize that Java and C++ are quite different (even ignoring memory management). My main point is that if I had to code in C++ again, I'd throw out the things that Java threw out.
I really think that Java got it right.
Either a PhD applying for one of your jobs really matches your expectations, in which case you shouldn't hire them, and if you do, it should quickly become clear how incompetent and conceited they are. Or he/she really is competent and interested in doing a good job instead of covering his ass, (which seems to be your main concern), and he/she probably does deserve to have your job.
You basically admit to discrimination (emphasis added): "My fear is that if I hire a PhD ... With an MS degree, this problem is reduced and with a BS it is eliminated."
Or maybe your posting is a troll. OK, well you got me.
If you're really asking about practical matters: what would you say you were doing for all that time? Actually, you could probably make up some incredibly boring plausible thing and get away with it. Providing, of course, it weren't the first or second most recent thing on your resume.
Assertions More assertions Even more assertions And most importantly: work in Java
An advanced degree is an indulgence if you want to work as a software engineer. Do it if you want to, but don't expect it to improve your salary. The only thing that counts is years "in the real world", i.e. writing code for a customer or product. I mean that literally. If someone is trying to hire a software engineer with five years of experience, then six years in grad school and one year of experience will usually not get past a screening of the resume.
A Ph.D. can actually be a hindrance. If you get one, many potential employers will view you with suspicion for a number of reasons. The attitudes I've seen are that if you have a Ph.D. you must:
- think you're too good to write code, fix bugs, write release notes,
etc.
- be lousy at writing code.
- be incapable of writing efficient code.
- be more concerned with cool ideas and theory than shipping
a product.
- have outrageous salary demands.
- have a problem dealing with holders of mere B.Sc. and M.Sc. degrees.
I have never seen these sorts of concerns applied to candidates with an M.Sc. degree.I'm definitely not saying that you shouldn't get an advanced degree. I really enjoyed it, and I think the quality of my work (including code) greatly benefits from my education. My point is that potential employers may not see it this way.
I'm also not saying that you should go get a programming job right out of high school. Learning the basics of complexity theory, data structures and algorithms, compilers, databases, numerical analysis -- typical undergraduate courses -- is really important if you're going to be a serious software engineer.
Why is it that a great software developer who demands rewards commensurate with his talents is necessarily a prima donna? Executives do this all the time and no one blinks. I think the problem is popular conceptions: executives are driven by greed while software developers are driven by love for what they do. In other words, it is out of character for a software developer to raise such base concerns as salary. Well that's ridiculous. If you love what you do, and you are a master of your craft, why not insist on what you are capable of earning? You can be sure that the managers and executives you're negotiating with take exactly the same approach.
By the way, Salon is also promising additional content for the price of admission.
Look at it this way: If your metrics contradict what your small band of hackers know is right, your hackers will be unhappy and quit. In other words, metrics would be, at best, as good as peer review, and at worst, they might do a lot of damage.