linux-os (Dick Johnson) wrote:
> On Mon, 24 Apr 2006, J.A. Magallon wrote:
>
>> On Mon, 24 Apr 2006 22:52:12 +0100, Alan Cox <[email protected]> wrote:
>>
>>> On Llu, 2006-04-24 at 15:36 -0600, Jeff V. Merkey wrote:
>>>> C++ in the kernel is a BAD IDEA. C++ code can be written in such a
>>>> convoluted manner as to be unmaintainable and unreadable.
>>> So can C.
>>>
>>>> All of the hidden memory allocations from constructor/destructor
>>>> operatings can and do KILL OS PERFORMANCE.
>>> This is one area of concern. Just as big a problem for the OS case is
>>> that the hidden constructors/destructors may fail.
>> Tell me what is the difference between:
...clear readable code...
>>
>> and
>>
>> SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
>> {}
...double bagger...
> I'd like to write modules in FORTRAN, myself. Unless you have been
> writing software since computers were programmed with diode-pins, one
> tends to think that the first programming language learned is the
> best. It's generally because they are all bad, and once you learn how
> to make the defective language do what you want, you tend to identify
> with it. Identifying with one's captors, the Stockholm syndrome,
> that's what these languages cause.
No, I wouldn't touch any of the early languages I learned, the first one
I liked was ALGOL-60. The software for GE's first CT scanner was
developed in ALGOL-60. I liked PL/1 when GE was part of the MULTICS
project, and the whole BCPL->B->C family was fun, although I do like C
best. GE had an implementation language called I-language which was a
great system language, but they buried it instead of releasing it. I
hated FORTRAN, LISP and APL, although I wrote a lot of each, predicted
that Ada would not be popular, but I like PERL. I wrote text tools in
TRAC (look that one up ;-) but that's kind of all it did well.
If you hadn't made this next point I would have...
>
> But, a master carpenter has many tools. He chooses the best for each
> task. When you need to make computer hardware do what you want, in
> a defined manner, in the particular order in which you require,
> you use assembly language to generate the exact machine-code required.
> It is possible to compromise a bit and use a slightly higher-level
> procedural language called C. One loses control of everything with
> any other language. Note that before C was invented, all operating
> system code was written in assembly.
Hate to tell you, C came about a decade after MULTICS was written in
PL/1, and I think DEC had VMS out in BLISS before C. C came from B (as
did IMP68), which came from BCPL.
>
> C++ wasn't written for this kind of work. It was written so that a
> programmer didn't have to care how something was done only that somehow
> it would get done. Also, as you peel away the onion skins from many
> C++ graphics libraries, you find inside the core that does the work.
> It's usually written in C.
C++ allows more abstraction than C, unfortunately too many people go
right past past abstraction to obfuscation. With operator overloading
it's possible to generate write-only code, and programs where "A=B+C"
does file operations :-( That doesn't belong in an operating system, C
is the right choice.
Sorry for the history lesson, you got me thinking about my first languages.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Thu, 27 Apr 2006 18:55:02 -0400 Bill Davidsen wrote:
> linux-os (Dick Johnson) wrote:
> > On Mon, 24 Apr 2006, J.A. Magallon wrote:
>
> If you hadn't made this next point I would have...
> >
> > But, a master carpenter has many tools. He chooses the best for each
> > task. When you need to make computer hardware do what you want, in
> > a defined manner, in the particular order in which you require,
> > you use assembly language to generate the exact machine-code required.
> > It is possible to compromise a bit and use a slightly higher-level
> > procedural language called C. One loses control of everything with
> > any other language. Note that before C was invented, all operating
> > system code was written in assembly.
>
> Hate to tell you, C came about a decade after MULTICS was written in
> PL/1, and I think DEC had VMS out in BLISS before C. C came from B (as
> did IMP68), which came from BCPL.
and Burroughs used Algol for multi-proc (master/slave, not SMP)
virtual memory OSes in the 1960s. :)
---
~Randy
> C++ allows more abstraction than C, unfortunately too many people go
> right past past abstraction to obfuscation. With operator overloading
> it's possible to generate write-only code, and programs where "A=B+C"
> does file operations :-( That doesn't belong in an operating system, C
> is the right choice.
> -bill davidsen ([email protected])
I reject any argument of the type "because a language *allows* you to do X,
and X is not always good, the language is bad". Now, if the language
*required* you to do bad things, that would be a different story.
If I could demonstrate ways to do bad things in C that don't belong in an
operating system, would that convince you that C is not the right choice?
For example, C allows easy use of floating point math, which doesn't belong
in an operating system either.
DS