On 11/16/2014 3:30 AM, "Ola Fosheim Grøstad"
> Real world 85% engineered solutions:
>
> 1. Titanic

Everyone likes to rag on the Titanic's design, but I've read a fair amount about it, and it's quite an unfair rap. It was, for its day, the safest ship afloat, and did represent a significant step forward in safety:

1. The watertight compartments were innovative and kept the Titanic afloat for hours. Without them, it would have sank very quickly. The damage the Titanic suffered was very unusual in its extensiveness, and would have sunk any ship of the day.

2. The wireless was new and state of the art, without it the Titanic would have sunk with all aboard without a trace, and what happened to it would have been a great mystery. The fault with the wireless had nothing to do with its engineering, but with its management (the California did not keep a 24 hr watch on the radio).

3. The hull steel was inferior by today's standards, but was the best available by the standards of its time.

4. The rudder was inadequate, but little was known at the time about how such large ships would handle, and they didn't exactly have computer simulation software available.

5. The oft-repeated thing about the lifeboats was a little unreasonable. The way ships usually sink it's very difficult to launch any lifeboats successfully. If the ship listed, the boats on the high side could not be launched at all, and if it tilted down at a steeper angle none of them could be launched. The way the Titanic sank, slowly and fairly levelly, enabling nearly all the boats to be launched, was very unusual. The idea was with the watertight compartments it would sink slowly enough that the boats could be used to ferry the passengers to safety. That in fact would have worked if the California had been monitoring the wireless.

It's unfair to apply the hubris of hindsight. Apply instead the standards and practices of the foresight, and the Titanic comes off very well.

It was not designed to drive full speed into an iceberg, and modern ships can't handle that, either. Actually, the Titantic would likely have fared better than modern ships if it didn't try to turn but simply rammed it head on. The watertight compartments would have kept it afloat.

For comparison, look what happened to that italian cruise ship a few years ago. It got a minor hole punched in the side by a rock, rolled over and sank.

On Sunday, 16 November 2014 at 17:46:09 UTC, Walter Bright wrote:
> Everyone likes to rag on the Titanic's design, but I've read a fair amount about it, and it's quite an unfair rap. It was, for its day, the safest ship afloat, and did represent a significant step forward in safety:

«The 20 lifeboats that she did carry could only take 1,178 people, even though there were about 2,223 on board.» http://en.wikipedia.org/wiki/Lifeboats_of_the_RMS_Titanic

Thats not even a 85% solution, it is a 53% solution.

> It's unfair to apply the hubris of hindsight. Apply instead the standards and practices of the foresight, and the Titanic comes off very well.

I don't know, my grandfather's uncle went with one of the expeditions around Greenland and they did not sink. That ship (Fram) was designed for being frozen into the ice as it was designed for being used in to reach the north pole. The shape of the hull was designed to "pop out" of the ice rather than being pushed down so that the ship could float over the arctic as part of the ice. It was later used for several trips, notably the famous trip to reach the south pole. That's a lot closer to a 100% engineering solution!

> It was not designed to drive full speed into an iceberg, and modern ships can't handle that, either.

It was not sane to drive at full speed I guess. There was a lot of arrogance in the execution around Titanic, both leaving with insufficient life boats and driving at full speed suggest a lack of understanding…


Returning to programming languages: if I cannot implement 100% of my design with a language then it is a non-solution. 85% is not enough.

In business applications people sometimes have to settle for ready-made 85% solutions and change their business practices to get the last 15%, but that is not good enough for systems programming IMO. That's how you think about frameworks, but not how you think about language design (or system level runtime).

On 11/16/2014 10:27 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Returning to programming languages: if I cannot implement 100% of my design with
> a language then it is a non-solution. 85% is not enough.

You can do anything with a language if it is Turing complete.


> In business applications people sometimes have to settle for ready-made 85%
> solutions and change their business practices to get the last 15%, but that is
> not good enough for systems programming IMO. That's how you think about
> frameworks, but not how you think about language design (or system level runtime).

Be careful you don't fall into kitchen sink syndrome. Add enough features, and the language becomes unusable. Features are almost never orthogonal, they always interact and interfere with each other. This applies to all engineering, not just languages. There are no 100% solutions.

For example, D doesn't support multiple inheritance. This is on purpose. Yes, some C++ programmers believe D is badly broken because of this. I don't at all believe it is unreasonable that one should make adaptations in design in order to use a language successfully.

After all, D is explicitly designed to be a "pragmatic" language.

On Sunday, 16 November 2014 at 18:36:01 UTC, Walter Bright wrote:
> You can do anything with a language if it is Turing complete.

That's not the point. If you have to avoid features because they aren't general enough or have to change the design to fit the language and not the hardware, then the language design becomes a problem.

> Be careful you don't fall into kitchen sink syndrome. Add enough features, and the language becomes unusable. Features are almost never orthogonal, they always interact and interfere with each other. This applies to all engineering, not just languages. There are no 100% solutions.

I think C is pretty close to a 98% solution for system level programming. Granted, it relies on macros to reach that.

> For example, D doesn't support multiple inheritance. This is on purpose. Yes, some C++ programmers believe D is badly broken because of this. I don't at all believe it is unreasonable that one should make adaptations in design in order to use a language successfully.
>
> After all, D is explicitly designed to be a "pragmatic" language.

I am not sure if OO-inheritance and virtual functions are all that important for system level programming, but generally features should work across the board if it can be implemented efficiently. E.g. creating "weird" typing rules due to ease of implementation does not sit well with me.

Or to put it in more simple terms: figuring out how a programming language works is a necessary investment, but having to figure out how a programming language does not work and when is really annoying.

On 11/16/2014 10:52 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> I think C is pretty close to a 98% solution for system level programming.

Not at all in my view. It has two miserable failures:

1. C's Biggest Mistake

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

This made C far, far more difficult and buggy to work with than it should have been.


2. 0 terminated strings

This makes it surprisingly difficult to do performant string manipulation, and also results in a excessive memory consumption.


> Granted, it relies on macros to reach that.

And it's a crummy macro system, even for its day.


My above remarks should be put in context of when C was designed. As with the Titanic, it is unfair to apply modern sensibilities to it. But if we were to, a vast amount of C could be dramatically improved without changing its fundamental nature.

On Sunday, 16 November 2014 at 19:24:47 UTC, Walter Bright wrote:
> This made C far, far more difficult and buggy to work with than it should have been.

Depends on your view of C, if you view C as step above assembly then it makes sense to treat everything as pointers. It is a bit confusing in the beginning since it is more or less unique to C.

> 2. 0 terminated strings
>
> This makes it surprisingly difficult to do performant string manipulation, and also results in a excessive memory consumption.

Whether using sentinels is slow or fast depends on what you want to do, but it arguably save space for small strings (add a length + alignment and you loose ~6 bytes).

Also dealing with a length means you cannot keep everything in registers on simple CPUs.

A lexer that takes zero terminated input is a lot easier to write and make fast than one that use length.

Nothing prevents you from creating a slice as a struct though.

> sensibilities to it. But if we were to, a vast amount of C could be dramatically improved without changing its fundamental nature.

To me the fundamental nature of C is:

1. I can visually imagine how the code maps onto the hardware

2. I am not bound to a complicated runtime

On 11/16/2014 11:59 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Sunday, 16 November 2014 at 19:24:47 UTC, Walter Bright wrote:
>> This made C far, far more difficult and buggy to work with than it should have
>> been.
>
> Depends on your view of C, if you view C as step above assembly then it makes
> sense to treat everything as pointers.

If you read my article, the fix does not take away anything.


>> 2. 0 terminated strings
>>
>> This makes it surprisingly difficult to do performant string manipulation, and
>> also results in a excessive memory consumption.
> Whether using sentinels is slow or fast depends on what you want to do, but it
> arguably save space for small strings (add a length + alignment and you loose ~6
> bytes).
>
> Also dealing with a length means you cannot keep everything in registers on
> simple CPUs.
>
> A lexer that takes zero terminated input is a lot easier to write and make fast
> than one that use length.

I've worked enough with C to know that these arguments do not hold up in real code.


> Nothing prevents you from creating a slice as a struct though.

I've tried that, too. Doesn't work - the C runtime library prevents it, as well as every other library.


>> sensibilities to it. But if we were to, a vast amount of C could be
>> dramatically improved without changing its fundamental nature.
>
> To me the fundamental nature of C is:
>
> 1. I can visually imagine how the code maps onto the hardware
>
> 2. I am not bound to a complicated runtime

None of the fixes I've suggested impair that in any way.

On Sunday, 16 November 2014 at 20:26:36 UTC, Walter Bright wrote:
> If you read my article, the fix does not take away anything.

Yes, but that is just what all other languages had at the time, so leaving it out was obviously deliberate. I assume they wanted a very simple model where each parameter could fit in a register.

> I've worked enough with C to know that these arguments do not hold up in real code.

But you have to admit that older CPUS/tight RAM does have an effect? Even 8086 have dedicated string instructions with the ability to terminate on zero (REPNZ)

On 11/16/2014 12:44 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Sunday, 16 November 2014 at 20:26:36 UTC, Walter Bright wrote:
>> If you read my article, the fix does not take away anything.
>
> Yes, but that is just what all other languages had at the time, so leaving it
> out was obviously deliberate. I assume they wanted a very simple model where
> each parameter could fit in a register.

Since structs were supported, this rationale does not work.


>> I've worked enough with C to know that these arguments do not hold up in real
>> code.
> But you have to admit that older CPUS/tight RAM does have an effect? Even 8086
> have dedicated string instructions with the ability to terminate on zero (REPNZ)

Remember that I wrote successful C and C++ compilers for 16 bit 8086 machines, and programmed on it for a decade. I know about those instructions, and I'm familiar with the tradeoffs. It's not worth it.

Besides, C was designed for the PDP-11, which had no such instructions.

On Sun, 16 Nov 2014 19:59:52 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> A lexer that takes zero terminated input is a lot easier to write and make fast than one that use length.
that's why warp is faster than cpp? ;-)