On Friday, 12 May 2017 at 18:52:43 UTC, Joakim wrote:
> On Saturday, 6 May 2017 at 09:53:52 UTC, qznc wrote:
>> On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
>>> [...]
>>
>> Hm, Sociomantic removes the live captures the next day?
>>
>> One request: Chop the panel discussion into one clip per question/topic, please. Alternatively, provide some means to easily jump to the start of each question.
>
> Video of the exchange is now back up:
>
> https://www.youtube.com/watch?v=Lo6Q2vB9AAg#t=24m37s
>
> Question now starts at 22m:19s mark.

Oh no, my accent is terrible!
Time to stand in front of a mirror and rehersal :-).

When I said "outside community pressure", I meant "trends", but didn't make it clear then :(.

On Friday, 12 May 2017 at 04:08:52 UTC, Laeeth Isharc wrote:
> build tool.  We have extern(C++) which is great, and no other language has it.

Objective-C++/Swift.

> Maybe it's wrong to think about there being one true inheritor of the mantle of C and C++.  Maybe no new language will gain the market share that C has, and if so that's probably a good thing.  Mozilla probably never had any moments when they woke up and thought hmm maybe we should have used Go instead, and I doubt people writing network services think maybe Rust would have been better.

Yes, I think this is right, although C++ is taking over more and more of C's space. But there are still niches where C++ have a hard time going and C still dominates.

The problem is of course, that less and less software projects benefit from what C offers...

> But if you're a principal - ie in some way an owner of a business - you haven't got the luxury of fooling yourself, not if you want to survive and flourish.  The buck stops here, so it's a risk to use D, but it's also a risk not to use D - you can't pretend the conventional wisdom is without risk when it may not suit the problem that's before you. And it's your problem today and it's still your problem tomorrow, and that leads to a different orientation towards the future than being a cog in a vast machine where the top guy is measured by whether he beats earnings next quarter.

I don't really think all that many principals make such decisions without pressure from the engineers in the organization, unless it is for going with some big league name...

In general many leaders have been burned by using tooling from companies that has folded or not being able to fix issues. Which is a very good reason for going with the safe and well known. Most projects have enough uncertainty factors already so adding an extra uncertainty factor in the tooling is usually not the right choice.


> The web guys do have a lot of engineers but they have an inordinate influence on the culture.  Lots more code gets

Right, the web guys adopt bleeding edge tech like crazy, because the risk is low. The projects are small and they can start over with a new tech on the next project in a few months. They don't have to plan for sticking with the same tooling for years and years.


> And I am sure Walter is right about the importance of memory safety.  But outside of certain areas D isn't in a battle with Rust; memory safety is one more appealing modern feature of D.  To say it's important to get it right isn't to say it has to defeat Rust. Not that you implied this, but some people at dconf seemed to implicitly think that way.

Well, memory safety isn't a modern feature at all actually. Most languages provide it, C is a notable exception...

On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
> Walter: I believe memory safety will kill C.
>

Hi,

I think that comparing languages like D to C is not appropriate. C is a high level assembler and has different design goals. A useful document to refer to is:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1250.pdf

In particular: (although note the addition of facet f, which echoes the sentiment that security is important)

Keep the spirit of C. The Committee kept as a major goal to preserve the traditional
spirit of C. There are many facets of the spirit of C, but the essence is a community
sentiment of the underlying principles upon which the C language is based. For the Cx1
revision there is consensus to add a new facet f to the original list of facets. The new
spirit of C can be summarized in phrases like:

(a) Trust the programmer.
(b) Don't prevent the programmer from doing what needs to be done.
(c) Keep the language small and simple.
(d) Provide only one way to do an operation.
(e) Make it fast, even if it is not guaranteed to be portable.
(f) Make support for safety and security demonstrable.

Proverb e needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine's hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more
efficient on the target machine.

I think Linus Torvalds makes an important observation - he says in one of his talks is that the reason he likes C is that when he write C code he can visualize what the machine code will look like.

My feeling is that the C has traditionally been used in contexts where probably it should not be used - i.e. as a general purpose application development language. But I don't see how languages like D or Rust can replace C for certain types of use cases.

Regards
Dibyendu

On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
> (a) Trust the programmer.

That's the first and most deadly mistake. Buffer overflows and null pointers alone have caused hundreds of millions of dollars of damages. I think we can say that this trust is misplaced.

> (b) Don't prevent the programmer from doing what needs to be done.

In reality this manifests as "Don't prevent the programmer from doing anything, especially if they're about to shoot themself".

See the code examples throughout this thread.

> (c) Keep the language small and simple.
> (d) Provide only one way to do an operation.

lol

> (f) Make support for safety and security demonstrable.

LOL http://article.gmane.org/gmane.comp.compilers.llvm.devel/87749

>My conclusion is that C, and derivatives like C++, is a very
>dangerous language the write safety/correctness critical software
>in, and my personal opinion is that it is almost impossible to write
>*security* critical software in it.

(that's from the creator of clang btw)

> But I don't see how languages like D or Rust can replace C for certain types of use cases.

Maybe you can argue for the use of C in embedded systems and in OS's, although I see no reason why Rust can't eventually overtake C there. However, much of the internet's security critical systems (openssl, openssh, DNS systems, router firmware) are in C, and if Google's Project Zero are any indication, they all have ticking time bombs in them.

As I stated earlier in the thread, at some point, some company is going to get sued for criminal negligence for shipping software with a buffer overflow bug that caused a security breach.

It almost happened with Toyota. The auto industry has a C coding convention for safety called MISRA C, and it was brought up in court as to why Toyota's acceleration problems were entirely their fault. You can bet this will be brought up again.

On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:

> (a) Trust the programmer.

I don't understand this point. C doesn't offer the programmer much to work with. If you trust the programmer, shouldn't that mean you provide a large set of tools and let them decide which parts to use? C is pretty much "here are some pointers, go have fun".

On Sunday, 14 May 2017 at 01:30:47 UTC, Jack Stouffer wrote:
> It almost happened with Toyota. The auto industry has a C coding convention for safety called MISRA C, and it was brought up in court as to why Toyota's acceleration problems were entirely their fault. You can bet this will be brought up again.

1. Changing language won't change this, for that you need something that is formally proven (and even that assumes that the requirements spec is correct).

I found this book from 2012 on industry use of formal methods which seems to be available on Google Books:

https://books.google.no/books?id=E5sdDs00MuwC

2. What good does it do you to have your source code proven formally correct if your compiler can contain bugs? To get around that you need a formally verified compiler:

http://compcert.inria.fr/

So... We are back to C again.

On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
> On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
>> Walter: I believe memory safety will kill C.
>>
>
> Hi,
>
> I think that comparing languages like D to C is not appropriate. C is a high level assembler and has different design goals. A useful document to refer to is:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1250.pdf
>
> In particular: (although note the addition of facet f, which echoes the sentiment that security is important)
>
> Keep the spirit of C. The Committee kept as a major goal to preserve the traditional
> spirit of C. There are many facets of the spirit of C, but the essence is a community
> sentiment of the underlying principles upon which the C language is based. For the Cx1
> revision there is consensus to add a new facet f to the original list of facets. The new
> spirit of C can be summarized in phrases like:
>
> (a) Trust the programmer.
> (b) Don't prevent the programmer from doing what needs to be done.
> (c) Keep the language small and simple.
> (d) Provide only one way to do an operation.
> (e) Make it fast, even if it is not guaranteed to be portable.
> (f) Make support for safety and security demonstrable.
>
> Proverb e needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine's hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more
> efficient on the target machine.
>
If only the gcc and clang designers followed that rule. These <beeep> consider that undefined behaviour allows to break the code in any way they fancy (the nasal demon thing). While pragmaticists interpret it as do the thing that is the simplest to implement on that hardware. The most ridiculous example being the undefined behaviour of signed integer overflow. Signed integer overflow is undefined in C because some obscure platforms may not use 2 complements for the representation of integers. So INT_MAX+1 does not necessarily result in INT_MIN.
But completely removing the code when one encounters for example: if(val+1 == INT_MIN) is simply nuts.

On Sunday, 14 May 2017 at 02:11:36 UTC, bachmeier wrote:
> On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
>
>> (a) Trust the programmer.
>
> I don't understand this point. C doesn't offer the programmer much to work with. If you trust the programmer, shouldn't that mean you provide a large set of tools and let them decide which parts to use? C is pretty much "here are some pointers, go have fun".

Hi - I think this point really is saying that the type system in C is for convenience only - ultimately if you as a programmer want to manipulate memory in a certain way then C assumes you know what you are doing and why. As I said C is really a high level assembler.

Regards

On Sunday, 14 May 2017 at 02:11:36 UTC, bachmeier wrote:
> On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
>
>> (a) Trust the programmer.
>
> I don't understand this point. C doesn't offer the programmer much to work with. If you trust the programmer, shouldn't that mean you provide a large set of tools and let them decide which parts to use? C is pretty much "here are some pointers, go have fun".

The C99 Rationale also says: "The Committee is content to let C++ be the big and ambitious language. While some features of C++ may well be embraced, it is not the Committee’s intention that C become C++."

I read that as: C is mostly in preservation and fossilization mode. If you want new features look elsewhere. We will not rock the boat.

That is probably a good thing. C has its niche and it is comfortable there. If you want to beat C, it will not fight back. The only problem is to convince the C programmers to move.

On Sunday, 14 May 2017 at 01:30:47 UTC, Jack Stouffer wrote:
> On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
>> (a) Trust the programmer.
>
> That's the first and most deadly mistake. Buffer overflows and null pointers alone have caused hundreds of millions of dollars of damages. I think we can say that this trust is misplaced.
>

I should have added that the C11 charter also says:

<quote>
12. Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C Standard should take into account that programmers need the ability to check their work.
<endquote>

In real terms though tools like ASAN and Valgrind if used from the start usually allow you to catch most of the issues. Most likely even better tools for C will come about in time.


>> But I don't see how languages like D or Rust can replace C for certain types of use cases.
>
> Maybe you can argue for the use of C in embedded systems and in OS's, although I see no reason why Rust can't eventually overtake C there.

I think Rust is a promising language but I don't know enough about it to comment. My impression about Rust is that:

a) Rust has a steep learning curve as a language.
b) If you want to do things that C allows you to do, then Rust is no more safer than C.

Regards