On Tuesday, 18 November 2014 at 13:50:59 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 18 November 2014 at 12:02:01 UTC, Paulo  Pinto wrote:
>....
>
> Nobody were forced to write code in C to target anything, it was a choice. And a choice that grew out of a focus on performance and the fact that people still dropped down to write machine language quit frequently. Mentality matters.
>
> Javascript is different, since it is "the exposed VM" in the browser, but even there you don't have to write in Javascript. You can write in a language that compiles to javascript.

Since when do developers use a different systems programming language than the one sold by the OS vendor?

Who has the pleasure to waste work hours writing FFI wrappers around SDK tools?

All successful systems programming languages, even if only for a few years, were tied to a specific OS.

--
Paulo

On Tuesday, 18 November 2014 at 14:56:42 UTC, Paulo  Pinto wrote:
> Since when do developers use a different systems programming language than the one sold by the OS vendor?
>
> Who has the pleasure to waste work hours writing FFI wrappers around SDK tools?
>
> All successful systems programming languages, even if only for a few years, were tied to a specific OS.

Depends on what you mean by system programming. I posit that most programs that have been written in C are primarily application level programs. Meaning that you could factor out the C component as a tiny unit and write the rest in another language… Most high level languages provide integration with C. These things are entirely cultural.

In the late 80s you could do the same stuff in Turbo Pascal as in C, and integrate with asm with no problem. Lots of decent software for MSDOS was written in TP, such as BBS server software dealing with many connections.

On regular micros you didn't have a MMU so there was actually a great penalty for using an unsafe language even during development: the OS would reboot (or you would get the famous guru meditation on Amiga). That sucked.

On Sunday, 16 November 2014 at 21:54:40 UTC, Walter Bright wrote:
> Besides, C was designed for the PDP-11, which had no such instructions.

BTW, this is not entirely correct. It had autoincrement on registers. This is the example given on Wikipedia:

 MOV #MSG,R1
1$: MOVB (R1)+,R0
 BEQ DONE
 .TTYOUT
 BR 1$
 .EXIT

MSG: .ASCIZ /Hello, world!/

The full example:

http://en.wikipedia.org/wiki/MACRO-11

So the print loop is 4 instructions (I assume .TTYOUT is a I/O instruction), with a length you would at least have 5 instructions and use an extra register, as you would have an additional compare.

(As for concat, that I almost never use. In systems programming you mostly append to buffers and flush when the buffer is full. Don't need length for that. Even in javascript and python I avoid regular concat due to the inefficency of concat versus a buffered join.)

On 11/18/2014 4:18 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Never blame the tool for bad management.

To bring up the aviation industry again, they long ago recognized that "blame the pilot" and "blame the mechanics" is not how safe airplanes are made. They are made, in part, by fixing the tools so mistakes cannot happen, as even the best humans keep making mistakes.

C is a mistake-prone tool, and suggesting that programmers get better educated about how to use it does not work.

As I showed, a great deal of C's propensity for buffer overflows can be eliminated by a TRIVIAL change to the language, one that is fully backwards compatible, and takes NOTHING away from C's power. I've brought this up in conference presentations more than once, and the blank silence I get from C programmers just baffles me.

Blaming the tools is often appropriate.

On 11/18/2014 3:15 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright wrote:
>> C is a brilliant language. That doesn't mean it hasn't made serious mistakes
>> in its design. The array decay and 0 strings have proven to be very costly to
>> programmers over the decades.
>
> I'd rather say that it is the industry that has misappropriated C, which in my
> view basically was "typed portable assembly" with very little builtin
> presumptions by design. This is important when getting control over layout, and
> this transparency is a quality that only C gives me. BCPL might be considered to
> have more presumptions (such as string length), being a minimal "bootstrapping
> subset" of CPL.
>
> You always had the ability in C to implement arrays as a variable sized struct
> with a length and a trailing data section, so I'd say that the C provided type
> safe variable length arrays. Many people don't use it. Many people don't know
> how to use it. Ok, but then they don't understand that they are programming in a
> low level language and are responsible for creating their own environment. I
> think C's standard lib mistakingly created an illusion of high level programming
> that the language only partially supported.
>
> Adding the ability to transfer structs by value as a parameter was probably not
> worth the implementation cost at the time… Having a "magic struct/tuple" that
> transfer length or end pointer with the head pointer does not fit the C design.
> If added it should have been done as a struct and to make that work you would
> have to add operator overloading. There's an avalanche effect of features and
> additional language design issues there.
>
> I think K&R deserves credit for being able to say no and stay minimal, I think
> the Go team deserves the same credit. As you've experienced with D, saying no is
> hard because there are often good arguments for features being useful and
> difficult to say in advance with certainty what kind of avalanche effect adding
> features have (in terms of semantics, special casing and new needs for
> additional support/features, time to complete implementation/debugging). So
> saying no until practice shows that a feature is sorely missed is a sign of good
> language design practice.
>
> The industry wanted portability and high speed and insisted moving as a flock
> after C and BLINDLY after C++. Seriously, the media frenzy around C++ was
> hysterical despite C++ being a bad design from the start. The C++ media noise
> was worse than with Java IIRC. Media are incredibly shallow when they are trying
> to sell mags/books based on the "next big thing" and they can accelerate
> adoption beyond merits. Which both C++ and Java are two good examples of.
>
> There were alternatives such as Turbo Pascal, Modula-2/3, Simula, Beta, ML,
> Eiffel, Delphi and many more. Yet, programmers thought C was cool because it was
> "portable assembly" and "industry standard" and "fast" and "safe bet". So they
> were happy with it, because C compiler emitted fast code. And fast was more
> important to them than safe. Well, they got what they deserved, right?
>
> Not adding additional features is not a design mistake if you try hard to stay
> minimal and don't claim to support high level programming. The mistake is in
> using a tool as if it supports something it does not.
>
> You might be right that K&R set the bar too high for adding extra features. Yet
> others might be right that D has been too willing to add features. As you know,
> the perfect balance is difficult to find and it is dependent on the use context,
> so it materialize after the fact (after implementation). And C's use context has
> expanded way beyond the original use context where people were not afraid to
> write assembly.
>
> (But the incomprehensible typing notation for function pointers was a design
> mistake since that was a feature of the language.)

I'm sorry to say this, but these rationalizations as to why C cannot add a trivial enhancement that takes nothing away and solves most of the buffer overflow problems leaves me shaking my head.

(C has added useless enhancements, like VLAs.)

On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote: [...]
> I'm sorry to say this, but these rationalizations as to why C cannot add a trivial enhancement that takes nothing away and solves most of the buffer overflow problems leaves me shaking my head.
> 
> (C has added useless enhancements, like VLAs.)

What's the trivial thing that will solve most buffer overflow problems?


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada

On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:
>> I'm sorry to say this, but these rationalizations as to why C cannot
>> add a trivial enhancement that takes nothing away and solves most of
>> the buffer overflow problems leaves me shaking my head.
>
> What's the trivial thing that will solve most buffer overflow problems?

http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625

On Tuesday, 18 November 2014 at 15:36:58 UTC, Ola Fosheim Grøstad
wrote:
> On Tuesday, 18 November 2014 at 14:56:42 UTC, Paulo  Pinto wrote:
>> Since when do developers use a different systems programming language than the one sold by the OS vendor?
>>
>> Who has the pleasure to waste work hours writing FFI wrappers around SDK tools?
>>
>> All successful systems programming languages, even if only for a few years, were tied to a specific OS.
>
> Depends on what you mean by system programming. I posit that most programs that have been written in C are primarily application level programs. Meaning that you could factor out the C component as a tiny unit and write the rest in another language… Most high level languages provide integration with C. These things are entirely cultural.


In the 80's almost everything was system programming, even
business applications.

You are forgetting the UNIX factor again.

We only had C available in UNIX systems as compiled language.
HP-UX was the only commercial UNIX I used where we had access to
compilers for other languages.

So who would pay for third party tooling, specially with the way
software used to cost?

Then of course, many wanted to do on their CP/M, Spectrum and
similar systems the type of coding possible at work or
university, which lead to Small C and other C based compilers,
thus spreading the language outside UNIX.


>
> In the late 80s you could do the same stuff in Turbo Pascal as in C, and integrate with asm with no problem. Lots of decent software for MSDOS was written in TP, such as BBS server software dealing with many connections.

I was doing Turbo Pascal most of the time, by the time I learned C
with Turbo C 2.0, Turbo C++ 1.0 was just around the corner and I
only
touched pure C again on teachers and employers request.

>
> On regular micros you didn't have a MMU so there was actually a great penalty for using an unsafe language even during development: the OS would reboot (or you would get the famous guru meditation on Amiga). That sucked.

Amiga was programmed in Assembly. Except for Amos, we didn't use
anything else.

--
Paulo

On Tuesday, 18 November 2014 at 19:45:12 UTC, Walter Bright wrote:
> On 11/18/2014 3:15 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright wrote:
>>> C is a brilliant language. That doesn't mean it hasn't made serious mistakes
>>> in its design. The array decay and 0 strings have proven to be very costly to
>>> programmers over the decades.
>>
>> I'd rather say that it is the industry that has misappropriated C, which in my
>> view basically was "typed portable assembly" with very little builtin
>> presumptions by design. This is important when getting control over layout, and
>> this transparency is a quality that only C gives me. BCPL might be considered to
>> have more presumptions (such as string length), being a minimal "bootstrapping
>> subset" of CPL.
>>
>> You always had the ability in C to implement arrays as a variable sized struct
>> with a length and a trailing data section, so I'd say that the C provided type
>> safe variable length arrays. Many people don't use it. Many people don't know
>> how to use it. Ok, but then they don't understand that they are programming in a
>> low level language and are responsible for creating their own environment. I
>> think C's standard lib mistakingly created an illusion of high level programming
>> that the language only partially supported.
>>
>> Adding the ability to transfer structs by value as a parameter was probably not
>> worth the implementation cost at the time… Having a "magic struct/tuple" that
>> transfer length or end pointer with the head pointer does not fit the C design.
>> If added it should have been done as a struct and to make that work you would
>> have to add operator overloading. There's an avalanche effect of features and
>> additional language design issues there.
>>
>> I think K&R deserves credit for being able to say no and stay minimal, I think
>> the Go team deserves the same credit. As you've experienced with D, saying no is
>> hard because there are often good arguments for features being useful and
>> difficult to say in advance with certainty what kind of avalanche effect adding
>> features have (in terms of semantics, special casing and new needs for
>> additional support/features, time to complete implementation/debugging). So
>> saying no until practice shows that a feature is sorely missed is a sign of good
>> language design practice.
>>
>> The industry wanted portability and high speed and insisted moving as a flock
>> after C and BLINDLY after C++. Seriously, the media frenzy around C++ was
>> hysterical despite C++ being a bad design from the start. The C++ media noise
>> was worse than with Java IIRC. Media are incredibly shallow when they are trying
>> to sell mags/books based on the "next big thing" and they can accelerate
>> adoption beyond merits. Which both C++ and Java are two good examples of.
>>
>> There were alternatives such as Turbo Pascal, Modula-2/3, Simula, Beta, ML,
>> Eiffel, Delphi and many more. Yet, programmers thought C was cool because it was
>> "portable assembly" and "industry standard" and "fast" and "safe bet". So they
>> were happy with it, because C compiler emitted fast code. And fast was more
>> important to them than safe. Well, they got what they deserved, right?
>>
>> Not adding additional features is not a design mistake if you try hard to stay
>> minimal and don't claim to support high level programming. The mistake is in
>> using a tool as if it supports something it does not.
>>
>> You might be right that K&R set the bar too high for adding extra features. Yet
>> others might be right that D has been too willing to add features. As you know,
>> the perfect balance is difficult to find and it is dependent on the use context,
>> so it materialize after the fact (after implementation). And C's use context has
>> expanded way beyond the original use context where people were not afraid to
>> write assembly.
>>
>> (But the incomprehensible typing notation for function pointers was a design
>> mistake since that was a feature of the language.)
>
> I'm sorry to say this, but these rationalizations as to why C cannot add a trivial enhancement that takes nothing away and solves most of the buffer overflow problems leaves me shaking my head.
>
> (C has added useless enhancements, like VLAs.)

So useless that it became optional in C11.

https://groups.google.com/forum/#!topic/comp.std.c/AoB6LFHcd88

On Tuesday, 18 November 2014 at 19:42:20 UTC, Walter Bright wrote:
> To bring up the aviation industry again, they long ago recognized that "blame the pilot" and "blame the mechanics" is not how safe airplanes are made. They are made, in part, by fixing the tools so mistakes cannot happen, as even the best humans keep making mistakes.

Please note that I said it was a management issue. Clearly if management equip workers with unsafe tools that is bad. But there have always been safer tools available. It has always been possible to do things differently. It has always been possible to do risk assessment and adopt to it, in tools, education and process.

I am sure the aviation industry is doing a lot better than the IT industry!

> Blaming the tools is often appropriate.

If you are forced to use one while being asked to run for a deadline, sure.