SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 03 | January | 2004 ]

<< Previous Message << >> Next Message >>


Date: Sat, 3 Jan 2004 11:55:36 PST8
From: "Bob" <tt336a5u02@sneakemail.com >
Reply-To: scoug-programming@scoug.com
To: scoug-programming@scoug.com
Subject: SCOUG-Programming: QA equals testing, Part One:Detection

** Reply to message from "Peter Skye pskye@peterskye.com" on Sat, 3 Jan 2004
11:08:03 PST8

> My perception is that Lynn is trying to eliminate the high-level source
> and "compile" directly from the specs.

I think you got it.

> You're suggesting that it is okay for the programmer to know how to
> write high-level without an intrinsic understanding of what happens
> underneath, and for some apps (Hello World) I'm sure that's true.

Yep.

> But if you want to start a list of all the times when understanding what
> happens with the calls, the drivers, the machine code, etc is necessary
> then you don't need me to start the list for you -- you can easily do it
> yourself based on your own experiences.
>
> Heck, Bob, I remember _you_ stating that OS/2 is not a real-time
> operating system, and how many Visual Basic guys would even know what
> you're talking about? How can they possibly be taught how to put
> "real-time operating system" in their specs without an understanding of
> lag, latency, interrupt stacking and thread priorities? The
> intermediate code has to be understandable to humans so that problems at
> that level can be fixed.

The knowledge needed to write a program depends on what the program needs to
do. For almost all applications the programmer does not need to know much
about the hardware (i.e. does not need to know the computer instruction set).
If you are writting the operating system or device drivers then you need to
know how the hardware works. When writting operating system code even using
SL/I there will still need to be a way to write machine instructions for some
small parts of the system, but these are very small parts, most of any
operating system can be written in a high level language.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


<< Previous Message << >> Next Message >>

Return to [ 03 | January | 2004 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.