Computer Science vs. Software Engineering (cont.)
kilmo: in regards to your comments regarding the usefulness (or lack thereof) of the output of the Computer Science department. First of all, it does not invalidate my point that most students come to the Technion's CS department to learn how to program or at least to get a certificate that will show their competence as programmers. (whether it indeed does is a different question).
Secondly, in regard to the post itself: my condolences. ;-). It is highly possible that 20% of the faculty cater to 80% of the students as far as their research is concerned, while 20% of the faculty cater to 80% of the students. From what I know of the Electrical Engineering department, a larger part of their research is more down to earth and useful. Maybe that what happens when you have a department dedicated to a theoretical science.
I know that in M.I.T., for example, there's one department for both Computer Science and Electrical Engineering. This removes the duplicacy of the courses between the two faculties that we see so much in the Technion, and also possibly injects a lot of practicality to them CS researchers.
Linux in Action revisited
Well, my suggestion to turn the Haifux' Welcome to Linux series into a shorter "Linux in Action" series was rejected (possibly for a good reason), but Linux in Action could still be a good idea as a complement to it. For instance, we could have a day full of Linux demonstrations, in a similar manner to the Linux Circus that took place a couple of years ago.
A Good Reference for Perl
Eran has recently installed RedHat Linux 9.0 in order to learn how to program better. He wanted to learn Perl, having heard so many good things about it, and so started out with my "Perl for Perl Newbies" series, which he claimed was very well written. Then he wanted to look something in the perl man pages, and said he could not make heads nor tails of them.
As he wasn't the first one I heard to express this amount of unhappiness from them, it got me thinking about writing a better reference for Perl, in a similar fashion to what Python and PHP have. So I brought this on perl5-porters and received many heated responses. Apparently, many people believed that the man pages should be left in their current not-so-idiot-proof state, or that it was rightful to expect people to pay to get a better reference.
From my experience getting my patches to the documentation into bleadperl, it was a relatively painful experience. While there were many people who actually had meaningful comments, there were always those few who complained that it's making them too wordy, or loses character out of the document. Eventually, most of my patches were accepted, but it was still a painful procedure, as it seems there isn't a consensus in the perl5-porters mailing list on the exact purpose of the perl*.pod documents.
Add this to the fact that I'm not sure that the Perl POD documents can ever be made very suitable for beginners, and that their organization is a bit lacking, and I think it may be a good idea to simply start a documentation project ("Doclanx" or "Reflanx" both named after the Phalanx project) from scratch that will produce a comprehensive reference that is more suitable for beginners. Our own codebase, our own rules, our own progress.
What I would like to do first or as I start is collect user stories about the existing documentation. That way we can tell how to best organize the new one.
ISP/Phone Company Support Incident
A couple of days ago I sank into an all-time low: I called the ISP support line and he actually guided me in something. It all started when my Internet connection got hanged out and nothing I tried to do to resolve it (restarting the modem, restarting the router) helped. So I called the ISP line. A support person answered and when I told him I had a NAT, he said I should connect the computer to the modem straight or else he can't help me. So I did (I have two Internet cards). Here he guided me through the procedure (my Windows networking configuration skills got a bit rusty lately), and then it still did not work. Then he heard that the modem was configured to use PPPoE, so he said that we either need to set it back to PPTP or he can't help me. (as usual, these support people are more clueless than us hackers or power-users). I knew that my father would not like it so I gave him my father.
My father got angry, and eventually disconnected and tried to contact the Phone company support team. They eventually said that the line was probably OK, and possibly the modem mis-configured itself. So we reset the modem (with a tooth-pick), and it went back to PPTP, but we were able to connect to the Internet again. Pheewww! Now we need to set it back to PPPoE sometime, but still it wasted a couple of good hours.
I read the beginning of the Browser Wars II: The Saga Continues article. It was quite entertaining, but short of useful information. But it got me thinking: as Mozilla (and browsers based on its engine, like Firebird) is mature and usable and MSIE is buggy as hell, and will only ship with new versions of the operating system, we can expect the user-base of Mozilla and similar alternative browsers to actually grow, at least not if it weren't for all those MSIE-only sites. But I thought of a way to accelerate it: start creating clean, standards' compliant web-sites that may or may not look well in Internet Explorer. I'm not saying that we should break them on purpose. Just not test them on it, and if people complain that they break tell people to switch to Mozilla or whatever. (as it will be good for them).
The question naturally rises why it is not equally as worse as web-sites that are MSIE-only. There are several reasons:
- MSIE 5.5 and above are specific to a certain operating system and architecture. Mozilla and similar browsers are truly cross-platform. - as such MSIE may not be available on the development platform of the web designer. I design all my sites and have tested them on MSIE by using the laptop. Now, I'm not going to bother.
- MSIE is not open source. Mozilla is - I cannot fix the bugs there even if I wanted to. If bugs exist in an open source project I can either fix them myself, hire someone else to do it, or blame myself for not doing either. With MSIE, I have every right to blame Microsoft for their incompetence. And I can have them eat their own arrogance.
- Users can always switch to Mozilla or whatever - I can always tell them to do so. On the other hand, I cannot switch to Internet Explorer if I'd like to use Linux (which I do).
- MSIE is not standards compliant while other browsers are - in fact, a prominent Microsoft engineer said standards-compliance is not a high priority for the MSIE team. Since I design according to web standards, I don't want the new Netscape Navigator 4 to be in my way.
- MSIE is not going to be maintained independently - the only prospect of getting a browser upgrade for MSIE is to buy a new OS. Buy a new OS just to get a new version of the browser? That's the joke of the month. Other browsers come with periodic upgrades with many improvements - all for free.
So that's it. I'm going to use such cool stuff such as CSS child selectors (html > body), max-width, Alpha-transparency PNGs, and :hover on elements besides links, as well as the full XSLT specification. I'm not going to break compatibility on purpose, but I certainly won't prevent a cool standards-complaint feature from inhibiting my pages. And I can't run MSIE on my choice of system, so Microsoft have themselves to blame if it doesn't work.
Finally, I may put the no-MSIE icon on each and everyone of my sites. With a link to a page explaining this new WWW order. No more Mister Nice Guy! Microsoft: adapt or perish!
(this scheme may not be an option for your organization's sites, but I'll apply it to mine)