ian@sibyl.eleceng.ua.OZ (Ian Dall) (04/07/90)
In article <19338@boulder.Colorado.EDU> wallwey@boulder.Colorado.EDU (WALLWEY DEAN WILLIAM) writes: >>As to software >>development environments, these remarks reveal only ignorance. > >Have you seen Microsoft C 5.1 or the Newer version 6.0 or even the new >32-bit version later this year-They where "ANSI-C" compatible even before >the ANSI group completely announced their final version! > . > . > . > Granted there may even be more editors available >for UNIX, but the true standard, which I by the way think is very poor >considering we are in the 90's with multiple MB machines, is vi. I don't like vi either. Note however, that you are comparing a bunch of extra software with what comes included in unix. Hardly a valid comparison. >95% of us use it. Even emacs on unix is better, but its not exactly that >"easy" to use and never seems to have a standard key binding. Well, change them! I personally consider GNU emacs, gcc and gdb make for a very productive programming environment. I'm not sure, but I suspect the Turbo Pascal/C style of edit/execute/debug functionality might be emacs inspired rather than the other way around! In an attempt to make this thread somewhat more "architectural", I think your original point was that the ability to make "shrink wrapped" binary software distributions was a significant factor in making an architecture attractive. I wonder if this is fundamentally true, or whether the public just doesn't care? Would they really care if there auto installation (*) did a compliation instead of just copies and edits? The big variable in making the installation of unix software (from source) idiot proof is variants of the operating system. It is rare that the actual machine architecture intrudes. It *is* possible to make the installation idiot proof if you constrain your software to running on only the major unix variants. That is still an improvement on the One OS/One Architecture PC world. If you want a good example of copeing with a very large range of Unix variants almost automatically, try installing one of Larry Wall's programs sometime! (*) I *hate* autoinstallations. You never know what they are doing behind your back. It wouldn't be so bad if they actually told you what they are doing, but usually it is totally undocumented what files are modified, what new files are created, whether backup copies are made of any files which are modified and how to uninstall the changes if necessary. (This experience was actually with kernel changes to Xenix to support new hardware. But I should think it is generally applicable). The shrink wrap software purveyors attitude is "trust us". I am unhappy with that. I want to know what is going on on any system I have control over. -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.
seanf@sco.COM (Sean Fagan) (04/11/90)
This doesn't really belong here. Followup's to comp.os.misc. Also note that '>> ' (note space) is also wallwey, not Tim. In article <19338@boulder.Colorado.EDU> wallwey@boulder.Colorado.EDU (WALLWEY DEAN WILLIAM) writes: >In article <22946@watdragon.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes: >>Well, one data point; I use a vanilla 8 Mb 25Mhz 386 clone running 386/ix and > >Note you have 8MB and the person I know has only 4MB. This may, and >probably is, the main difference between the system performances. (That is >why I included his memory size in the original article!) Yes. However, the main reason for X being so slow with 4 Mb is because of limited memory storage, and multiple copies of the same stuff. Shared libraries should help immensely, despite the inheirent disadvantage, speed-wise, that SysV's shared library mechanism poses. >> OS/2's Presentation Manager is much faster!... >> you can run OS/2 (witch I think is better than UNIX for the average user ... >> With OS/2, the environment power for programs parallels that of UNIX, >> with design tools for C that make their UNIX equivalents of Vi, CC, LINT and >> DBX, look like they are from the dark ages!... That's really funny. (Note my company, first of all.) I'm going to make some points below, but wanted to point out that statement first. >>development environments, these remarks reveal only ignorance. > >Have you seen Microsoft C 5.1 or the Newer version 6.0 or even the new >32-bit version later this year-They where "ANSI-C" compatible even before >the ANSI group completely announced their final version! Uhm, uSoft C 5.1 or 6.0 is *not* ANSI compliant, although some of us are working extremely hard to make it as much so as possible. In either 5.1 or 6.0, under DOS, try something like: extern int sprintf (const char *, const char *fmt, ...); Legal ANSI-C, yet uSoft C gets a syntax error. *Anyway*, that's not the point, but you really should have your facts straight. >I have >experience with Microsoft C 5.1 and the error messages that I get from >it are much better (my opinion) and informative than lints. So this makes OS/2 better than Unix? Despite the fact that SCO UNIX (tm, tm) uses uSoft C (5.1++, in 3.2)? Despite the fact that the filesystem is faster under Unix than DOS (or OS/2)? >As for editors, well this is a moot point. You can have >just about any type of editor you want under OS/2! ---PM based, interactive >with the compiler, vi, emacs, any of a dozen programmer editors, a >couple of religious(hope I don't offend) program editors like Brief and >M, with many of the above taking advangtage of the mouse and the enhanced >keyboards on the PC. I'll believe emacs (*true* emacs: lisp interpreter and everything) when I see it. Under OS/2, you are *still* limited to 64k segments. Brief (or a clone, actually) is available under *nix. vi originated under *nix. (Note, btw, that emacs and vi can both use the mouse, to some advantage, under sco *nix; I'm sure other people can do something up on other unices just as well.) Emacs Compilation-mode works very well, as far as I'm concerned, although I will admit that QuickC is faster than most C compilers I've seen on *86-base *nix (however, /bin/cc on an Amdahl is faster, by at least one order of magnitude, than even QuickC, and can handle large programs). So, tell me: how do you call up your home machine from work to check your mail? When your housemate is busy running Lotus under DOS, how do you play with your wonder Logitech debugger? What?! You mean you *can't*?! What an inferior OS... -- -----------------+ Sean Eric Fagan | "It's a pity the universe doesn't use [a] segmented seanf@sco.COM | architecture with a protected mode." uunet!sco!seanf | -- Rich Cook, _Wizard's Bane_ (408) 458-1422 | Any opinions expressed are my own, not my employers'.