Posted on 05/31/2010 7:32:31 PM PDT by Gomez
Interesting thread, until it devolved into a bunch of silly name-calling. Both of your perspectives on computing history were interesting to read. Thanks for taking the time.
Thank you for the history; some of it I had heard before, some not.
The observation about academics ignoring problem-spaces and [along with ‘industry’] trying to polish a turd brought to mind something that I do like about Ada: it seems to me, that Ada strongly encourages problem-space evaluation with its strong separation of interface and implementation [coupled with generics].
I agree about the “I need a drink” depressive feel of ‘industry.’ But I do see some hope, I got another [CS Type] friend of mine to about-face on his idea that manual handling of loop-control and temporary-variables-used-where-a-specific-record/struct-for-the-data were more desirable than the high-level approach. {Ex: Having three arrays for a bitmap, one for each of the B, G, & R values instead of one array with a data-type record of RGB-tuples.}
>Windows OS is arguably based on a C++ foundation.
Arguably, yes. Why do you think there were so many security-updates regarding “buffer overflows” in the past several years? I’d bet good money that [the majority] is due directly to C/C++’s inability to check the index of arrays.
>Thus your whole argument on the intrinsic infirmity of UNIX-origin products should also apply to Windows.
There was more than just UNIX-origin products in my premise; it was more accurately UNIX-design-philosophy-origin products.
Windows/Microsoft presents an interesting design-philosophy that is, I believe, a hybrid between the classic Apple’s user-is-the-target and C/Unix’s “offer people 70% of what they need” design-philosophies.
Windows/Micosoft DOES consider its users, and doesn’t shift all responsibilities off itself, but [on the other hand] they are quite capricious with UI consistency as the past several versions of office show.
>One should understand the arguments for using Windows are all situational assessments. Usually you have to use Windows because you use Windows and are dependent on some Windows-only software and system administrators who only know how to do Windows.
That is true. There is a basic level of knowledge & ability needed for operation of any tool (you don’t give a 7 year old a chainsaw and say “cut down that tree”).
At school, the CS lab has ONLY Linux installed on its computers; and almost every time I floated the idea of building an OS to one of my peers they would say something like “why don’t you download the source for Linux and use that?” [/frustrating]
>Interesting thread, until it devolved into a bunch of silly name-calling.
Thank you.
>Both of your perspectives on computing history were interesting to read. Thanks for taking the time.
I do like to argue [in the philosophic sense] because I do love understanding. A lot of bad software is written because the programmer does not understand the problem well; however, this should be caveatted by the observation that sometimes it is necessary to “blunder along” trying to implement a solution to that problem in order to gain understanding of it. {My first couple attempts at Huffman encoding/decoding, for example, I found to be particularly instructive.}
>Kerrigan is a figure skater.
>
>Kernigan is a C honcho.
Ah, you’re right... that’s what I get for being half-drunk AND typing too fast.
They’re still both gay though; one for being a figure skater and the other for C. ;)
That is what I like most about Ada, regardless of the version: The strong typing and interface building causes a guy to man up, tell his manager to STFU and the hacker goes off and *thinks* really hard about the problem space and decomposing same.
As I’ve observed before here on FR (years ago), there’s two completely different progressions of an assignment when one chooses Ada or C:
The C choice:
1. You get a problem from your customer or management.
2. You start coding.
3. Management starts pestering you for progress.
4. You get the program to compile, management gets off your back for a little bit, because now they have something to report to their management.
5. Yea, your code compiles - and it crashes spectacularly, like an airplane with one wing. Management comes back for more status, you tell them you’re debugging it. They accept this, you go back to debugging for another week.
6. You now have most of the bugs out, management comes in with a whole bunch of new features they want. You code them, repeat steps 1 through 5.
7. When you reach a point where you’re down to an “acceptable” number of bugs (”acceptable” being defined by management), you ship.
8. Start responding to customer/user complaints. Go to step 2 and repeat, only this time with a bottle in your hand.
OK, so we know how that turns out. That’s how most all of industry now works.
Here’s how it works for Ada:
1. You get a problem from the customer, spec or management.
2. You now go off to start thinking really hard about the problem, decomposing the problem into data structures, algorithms and (most importantly) interfaces and ‘contracts.’
3. You get the interface definitions coded. Management starts getting fidgety, because they hear no mention of “real coding” yet.
4. You get to now worry about data structures and data types now. You’re not writing bulk code yet, but some code is starting to appear. Management is really dancing around now, like they have ants in their panties, because there is no code appearing. They have no perspective on where to put your progress on their stupid GANNT charts.
5. Data structures done, you start coding. I like coding from the bottom up, where I can start getting a feel for whether the interfaces and data structures really “mesh” with hardware or outside interfaces. If they don’t, all the top-down programming in the world won’t work. One of the other things about the academics from the 70’s did was contaminate the heads of a lot of us with this “top-down” programming nonsense. Only comp-sci’s can get away with “top-down” programming. Engineers have to make software work with reality - ie, device drivers, human input, other devices, network protocols, etc. That’s reality, and reality is what ends up ruining many an elegant “top-down” design and implementation with ugly bits of the sordid past.
6. Keep working on the low level stuff until we’re done getting data into and out of our internal data structures. That done, we can start top-down if we want, or continue working up from the bottom. As we’re coming up from the bottom, all instances of type check overrides should disappear. If they don’t, stop - something is very wrong if, once we’re out of the low-level interfaces and code, we have to typecast. This is another reason why I like bottom-up implementation - properly done, it gives a BIG signal to the developer or team that the crap is about to hit the fan. How many projects using OOP have been screwed when they did these beautiful class hierarchies, only to realize too late that they ran face-first into the fragile base class problem? Same deal for me with hardware: if the data types don’t allow me to represent reality of the hardware above the interface without typecasting (even in C), then I’ve gone wrong in the data type or interface design.
7. Right about now, management is fairly mental. There’s no “compiled code,” there’s no beta test start, etc. There’s little progress that they can put on their GANNT charts, they can’t seem to quantify what you’re doing to the even more clueless management above them.
So your manager wants to add more people to “help you out.” You push back.
8. You keep coding the higher level stuff. As you compile, you get the usual errors out of a strongly typed project. A type that isn’t promoted right here, an interface breakage there. You’re fixing these as they come up, but the whole system isn’t building cleanly yet. Some of these errors expose holes in your data structure thinking, so you have to spend some time re-visiting lower level complete code. If you touch an interface, it means you need to revisit or at least re-compile everything that uses that interface.
Management is starting to offer to help you themselves - by camping out in your office.
9. You get the whole system to compile and build cleanly.
And as you’re testing it, hey, “it just works.”
Management is flabbergasted... and wondering whether the threat of camping in your cube is “what finally got that little SOB off the dime!” They don’t know (and most of them will never know) that the hard-nosed aspect of type and interface checking by Ada is what hammered you to run the straight and narrow path, and that a lot of what Ada complained about in the compile phase, if done in C, becomes stuff you find in the run-time debug phase.
Lessons learned:
1. Management cannot report what they cannot quantify, and the whole damn industry is now wed to the C approach to “rapid, crappy results.” Rapid, even crappy, results gets management off your back and gives them something to report. So they’re happy. They get progress they can show off - even if it crashes and dies. “That’s simply debugging,” they say.
2. Programmers get the wrong sort of encouragement for doing things right - more pressure from management, not less. Management still doesn’t seem to grok that the cheapest bugs to fix are the ones that aren’t put into the s/w in the first place.
3. Because these morons in management NEVER budget for software failures that are found in the field (and they’re never penalized for them), they don’t ‘get’ the benefit of Ada, which is lower number of insidious bugs shipped to the field. All management knows is that “Holy crap, was that a hair-raising project! We’ll never do _that_ again.”
Sad, but true.
Interesting.
I’ve been teaching myself Ada [I started about a year ago] and I REALLY like the “catch the bug at the earliest time” mentality: a bug caught in compile-time will never give you problems in run-time.
I’m working on producing a PostScript interpreter in Ada right now and I’ve run into an unanticipated error:
In a task I have an entry which has two parameters, an in out string parameter [for the consuming of a PS program] and an out parameter for the base-object class; I used an object-hierarchy for PostScript’s data-types. The problem is this, a ‘class variable needs to be assigned at its declaration. *sigh* This seems to shoot down the idea of having a task {which could be distributed on another machine, say} able to ‘eat’ postscript code and pop out the corresponding object.
Ultimately, I’m thinking that PostScript would be ideal for the transmission of visual-data in an OS; it would have the advantage of being a natural WYSIWYG for all applications regarding printing; as well as the elimination of the need for printer-drivers. (Assuming they’re postscript printers; even if they aren’t the “driver” would just need to be a translator from PS to that printer’s command-set.)
Interesting.
I’ve been teaching myself Ada [I started about a year ago] and I REALLY like the “catch the bug at the earliest time” mentality: a bug caught in compile-time will never give you problems in run-time.
I’m working on producing a PostScript interpreter in Ada right now and I’ve run into an unanticipated error:
In a task I have an entry which has two parameters, an in out string parameter [for the consuming of a PS program] and an out parameter for the base-object class; I used an object-hierarchy for PostScript’s data-types. The problem is this, a ‘class variable needs to be assigned at its declaration. *sigh* This seems to shoot down the idea of having a task {which could be distributed on another machine, say} able to ‘eat’ postscript code and pop out the corresponding object.
Ultimately, I’m thinking that PostScript would be ideal for the transmission of visual-data in an OS; it would have the advantage of being a natural WYSIWYG for all applications regarding printing; as well as the elimination of the need for printer-drivers. (Assuming they’re postscript printers; even if they aren’t the “driver” would just need to be a translator from PS to that printer’s command-set.)
NeXT (prior to acquisition by Apple, NeXT was run by Steve Jobs, so it is germane to this thread), used Display Postscript to do exactly what you want to do. I don’t have a whole bunch of pointers to their efforts and DPS in general, but you might want to check out their interfaces; if you create something compatible, there’s already DPS clients out there you could use for testing.
The only downside to DPS was the speed in the time of 10 years ago. Now, with multi-core CPU chips, DPS could be more viable, but at the time, it was slower than X11, so it sort of never went anywhere. But lots of people agree with your idea - PostScript is a far better image model and description language than other display engines.
On the thread topic, I would NB that Quartz, OS X’s display engine, has roots in DPS:
http://oreilly.com/pub/a/mac/2005/10/11/what-is-quartz.html
Yep, there’s a whole chapter in the PLRM [Postscript Language Reference Manual] about DPS...and while it *IS* tempting there are several things that make me wary about it:
1) the description says:
The Display PostScript system provides application programs with a device-independent imaging model for displaying information on a screen. It is only a component of a complete application programming environment, consisting of:
• The PostScript interpreter.
• The Client Library, a C language interface to the basic facilities of the Display PostScript system.
• pswrap, a preprocessor that facilitates invoking arbitrary PostScript language programs from a C program.
• Window system support libraries, such as one for the X Window System™.
• Operating system, runtime library, and libraries of higher-level tools.
The mandate of having the client library in C, as well as a preprocessor for C, goes completely against the grain of my [ultimate] OS goal to “use a high-level language as early as possible and as widely as possible to: improve portability, reduce the number of possible errors, and reduce the dependency on the underlying hardware.” (An OS, generally speaking, is merely a resource-manager; THAT idea is independent of the underlying hardware, yet the efficient implementation of any instance thereof MUST consider the underlying hardware.)
2) I haven’t gotten to the point of being able to actually display/render anything yet. Basically I have objects that map to the [basic] PostScript types... I don’t even have the operators yet. (though there is a stub for them.)
Ahhhhh I see where you’re going.
OK.
Very laudable. If I had more time, I’d offer to help. As it is, I barely have time to see my own shadow on some days...
LOL - That’s quite alright - I have a SourceForge account that I’m thinking of uploading the PostScript interpreter to; however I DO want it to be, well, compiling usefully before I do so.
When a company the size of Google decides to get completely off the MS bandwagon because of security, a lot of people are going to take notice. Plus, Google has the ability to fill some of the software gaps at the enterprise level that would make it easier for other people. Plus, corporate IS groups and upper management are sick and tired of dealing with virus attacks.
When that company (Google) is in a cut throat, no holds barred, fight to the death with Microsoft over search, Office, mobile, browser and everything else, most people will dismiss it for the propaganda stunt that it is. It’s like going to Joe McGinniss for an “objective” opinion of Sarah Palin.
” Plus, corporate IS groups and upper management are sick and tired of dealing with virus attacks.”
Windows 7 is at least as secure as any desktop OS out there. I should know. Been using it since beta with no problems at all.
Antivirus company Intego today announced that it has discovered a new spyware application capable of infecting computers running Mac OS X. The spyware, known as “OSX/OpinionSpy”, is downloaded and installed on users’ computers via the installation process for unrelated applications hosted on several popular download sites.
This spyware, OSX/OpinionSpy, performs a number of malicious actions, from scanning files to recording user activity, as well as sending information about this activity to remote servers and opening a backdoor on infected Macs.
http://www.freerepublic.com/focus/f-chat/2525418/posts
I *told* you Fortran rocked.
Seriously, I learned in Fortran because I was getting a PhD in quantum mechanical theory of molecular scattering.
And because I am now a dinosaur. ;-)
Cheers!
You might not like it, but here is another way to look at that datum.
Read the fourth paragraph.
(Microsoft was tacitly admitting they didn't have a rat's ass of a clue how better to re-invest the money into their own company for expansion, or into an acquisition, so it was best that they just give the money back to shareholders. Management FAIL.)
Cheers!
Not being a techie, but just an end user, I have no idea how much a Windows or Office install costs in the Enterprise end, but I do know that MS has always been able to charge a premium because they've successfully sold the concept that you can't run an enterprise without MS.
This could be a huge crack in that aura of invincibility on the desktop.
Cheers!
You can make a good living in QA off of the C choice, if management hasn't offshored QA to India "to save money".
Lesson 5:
If they have, you can make even MORE money fixing what the good subcontractors in India have reported "is working fine" when it blows up in management's face in front of customers.
Cheers!
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.