On Friday, 26 July 2013 at 14:17:45 UTC, Chris wrote:
> On Friday, 26 July 2013 at 14:05:12 UTC, H. S. Teoh wrote:
>> On Fri, Jul 26, 2013 at 03:18:03PM +0200, Chris wrote:
>> [...]
>>> I have learned to be wary of comparisons like that. Any language
>>> that is sponsored or owned by a big company always "outperforms"
>>> other languages, and at the end of the day they only want to bind
>>> you to their products, no matter how "open source" they are.
>>
>> +1.
>>
>> I'm skeptical of attempts to reduce everything down a single number or
>> three, that can serve as a basis for numerical (or hand-waving)
>> comparisons. As if programming languages were that simple that one could
>> place them neatly on what is effectively a scale of 1 to 10!
>>
>>
>>> You can basically proof whatever you want. Most of the discussions I
>>> have had don't revolve around whether the language is good or not,
>>> it's about what people have heard/read, "Who uses it?", "I've heard
>>> ..." "Someone said ..." I once told a guy about D. He said "Ah, D,
>>> old-fashioned!" and he showed me a link that said "C# has a more
>>> modern feature ... bla bla". How ... scientific!
>>
>> I get that a lot from Java fanboys. They make bold-sounding statements
>> like "Java is the future!", "Java is the best!", "D sucks, nobody uses
>> it!", "Java will get you a job easily!". But I've yet to hear some
>> factual evidence to back up these claims. Well, maybe except the last
>> one -- it's true that given Java's popularity, it has a high chance of
>> landing you a job. But the point is, just because it will land you a job
>> doesn't necessarily make it a *good* language, it merely shows that it's
>> a *popular* one.  Popular doesn't imply good.
>>
>>
>> T
>
> Yep. And I think that someone who knows D or any other language that is not mainstream is seriously into programming. If you know Java or Python, what does that mean? That you are a good programmer? If you know how to program, you can learn any language you want. The question is usually not "I wonder if I can write the program." the question is usally "I know what I have to do. But how do I do it in D, C, Java ...?" It's the how, not the if.

If I think about it, learning and knowing languages makes you a better programmer. If you know D, you become a better programmer in general. If you learn Objective-C or C or whatever, you become a better programmer. You learn new concepts and know what works and what doesn't, rather than sheepishly following rules as if they were universal laws. Ok, that's a bit off topic now.

On Friday, 26 July 2013 at 02:39:15 UTC, Walter Bright wrote:
> If you are writing a program that, if it fails will cause your car to crash, then you are a bad engineer and you need to report to the woodshed.
>
> As I've written before, imagining you can write a program that cannot fail, coupled with coming up with a requirement that a program cannot fail, is BAD ENGINEERING.
>
> ALL COMPONENTS FAIL.
>
> The way you make a system safe is design it so that it can withstand failure BECAUSE THE FAILURE IS GOING TO HAPPEN. I cannot emphasize this enough.
>

You emphasis it quite well, and that is certainly true for a car, a plane, or anything potentially dangerous.

Different tradeoff apply when you talk about a video game, a media player or and IRC client.

On Thursday, 25 July 2013 at 20:03:52 UTC, Peter Alexander wrote:
> The problem is all those last bits:
>
> - Line counts aren't a good measure of anything.

That's why some people prefer to compare a gzipped version of the source code. The gzipped version gives a more fair account of the code size.

On Fri, Jul 26, 2013 at 08:21:45PM +0200, SomeDude wrote:
> On Thursday, 25 July 2013 at 20:03:52 UTC, Peter Alexander wrote:
> >The problem is all those last bits:
> >
> >- Line counts aren't a good measure of anything.
> 
> That's why some people prefer to compare a gzipped version of the source code. The gzipped version gives a more fair account of the code size.

That's not true. Comments, esp. extensive DDoc comments, can carry a lot of information that isn't part of the code itself. That will contribute to the gzipped size. At the very least, you'd have to strip out comments before compressing to get an accurate idea of "how much code" there is.

The idea of using compression to quantify the amount of code is a clever one, though. Perhaps one way to improve it might be to have the compiler serialize the AST of the completely-parsed code, then we compress that serialized AST.

Still, it's hard to get from this (or any other) measurement of code size to the "expressiveness" of the language. An inexperienced coder might write rather verbosely where an expert coder would write in just a few concise lines; the quantity of code would differ in each case, so without knowing the level of mastery the coder has over the language, it's still difficult to quantify expressivity.

Furthermore, one could deliberately code in such a way as to maximize (or minimize) whatever chosen measure is used to evaluate the language, but that by no means reflects the *typical* usage of the language.

And even then, we have to deal with the problem space: not all languages are best at addressing all classes of programming challenges. It would be unfair, for example, to judge Java on the basis of how well one could write an OS in it, since the language just isn't designed for that sort of thing. You'd be running into all sorts of roadblocks everywhere that aren't present when you write other applications that Java is more suitable for.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.

On Friday, 26 July 2013 at 18:46:06 UTC, H. S. Teoh wrote:
> ...for example, to judge Java on the basis of how well one could write an OS in it

http://jos.sourceforge.net/

On 7/26/2013 3:54 AM, Max Samukha wrote:
> Only death statistics for a sufficiently long usage period could tell whether
> software + override is safer than purely software. Note that software + override
> is significantly more complex, which means a decrease in reliability of the
> system in whole.

Airliners make comprehensive use of overrides and redundancy. The proof that works is how incredibly overall reliable they are, despite regular failures of individual components.

Note that before the software brake madness, there were 3 redundant braking systems on a typical car. The front and back brakes were independent - one could lose all fluid and the other would still work. A third independent system was the mechanical emergency brake.

This system has been in place for 50 years and works great.

Hell, even if all three failed, you could still put the car in gear and turn the ignition off. It'll slow down pretty rapidly.

On Friday, 26 July 2013 at 19:24:44 UTC, Walter Bright wrote:
> Hell, even if all three failed, you could still put the car in gear and turn the ignition off. It'll slow down pretty rapidly.

I wouldn't recommend turning the ignition off. Most cars lose power steering in that situation which is can be just as bad as or worse than losing brakes.

Most cars (including automatics) allow you to manually switch to lower gears which will also slow you down.

On 7/26/2013 4:10 AM, John Colvin wrote:
> On Friday, 26 July 2013 at 05:13:37 UTC, Walter Bright wrote:
>> Software controlled brakes with no override? Madness!
>
> I presume you always had some override system with anything critical at Boeing?

ALWAYS! This was hammered into us. Millions of flights without fatalities? That couldn't possibly happen without such systematic design.

I am continually amazed at critical systems design in Fukushima and Deep Water Horizon that have no backups or overrides.

I'd fire any engineer that came to me the second time with a critical system design he argues "can't fail" and doesn't need a backup/override.


> P.S. I don't suppose you happened to work with Bogdan Hnat there? It's a long
> shot as I think you would have left before he started.

I left Boeing around 1982. I've never heard of Bogdan Hnat, and I think I would have remembered an unusual name like that :-)

On 7/26/2013 4:28 AM, Dicebot wrote:
> Also nothing that is powered from the same power source can't be considered
> fail-safe. ;)

Yup!

I had to laugh at the New Orleans practice of putting emergency generators in the basements.

Q. When do you need the emergency generators?
A. When the power grid goes down.

Q. What does the power grid power?
A. The pumps that keep the basements from flooding.

Q. When is the power grid most likely to fail?
A. When there's a storm that's likely to flood the basements.

Ya gotta just cry at the logic.

The basement of my house is designed so gravity will drain water out of it rather than requiring a sump pump. A sump pump was cheaper than the trenching required for a gravity drain, but losing everything in the basement would be far more expensive than trenching.

On 7/26/2013 5:28 AM, bearophile wrote:
> I agree. On the other hand in important system you usually also try to use more
> reliable single components, like military-grade resistors able to stand bigger
> temperature fluctuations. Safety must be pursued at all levels. That's why in
> both automotive and aeronautics for certain safety-critical routines they forbid
> recursion and require a static analysis of the max stack space the subprogram
> will require in all possible usages, to reduce a lot the probability of stack
> overflows.

Yes, and that's why your analysis of Rust's stack usage is inadequate in demonstrating it is safer.


> In some situations stack overflows are a security problem. Several persons have
> written programs to analyse the stack usage of Ada-SPARK programs. Ignoring the
> safety hazards caused by stack overflows, and ignoring the tools to avoid them
> in critical-purpose routines, is very bad engineering.

You can't have an undetected stack overflow if you use guard pages.


> I don't know the current situation on this, but I think they are trying to solve
> this problem in Rust, with some workaround.

I'll add that segmented stacks are a compiler feature, not a language feature. A D compiler could support segmented stacks without changing the language, provided calling C functions still works.

But I see no point. 32 bit code is already dead on OSX, and is rapidly dying on Linux and Windows. I hear from more and more outfits that they've transitioned to 64 bits and are not looking back.