Am 01.11.2014 um 23:23 schrieb Paulo Pinto:
> Am 01.11.2014 um 22:20 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
> <ola.fosheim.grostad+dlang@gmail.com>":
>> On Saturday, 1 November 2014 at 17:17:34 UTC, Paulo Pinto wrote:
>>> Another trend, which I find positive, is how many people are now
>>> (finally!) assuming that C widespread into the industry was after all
>>> not that good, in terms of bugs/line of code.
>>>
>>> Now we need another 30 years until D, Rust, Swift, Nim, <place
>>> language name here>, get to replace C and C++.
>>
>> Jonathan referenced Mike Action, who when asked about what C++ vs C said
>> he preferred C and that using C++ was cultural:
>>
>
> I mean in terms of unsafe code and the amount of money spent in research
> and bug fixing that could have been avoided, if C wasn't as it is.
>
> I wouldn't be that vocal about C if:
>
> - arrays were bound checked (just use a compiler flags and dataflow to
> remove them like any sane language)
>
> - enums were strong typed
>
> - had reference parameters
>
> - had namespaces or real modules
>
> - no implicit type conversions
>
> - had a sane macro system
>
> But I guess D already covers it...
>
>
> --
> Paulo

Forgot to mention, proper strings.

Paulo Pinto:

> - arrays were bound checked (just use a compiler flags and dataflow to remove them like any sane language)

D removes very little bound checks. No data flow is used for this.


> - enums were strong typed

D enums are only half strongly typed.


> - had namespaces or real modules

D module system has holes like Swiss cheese. And its design is rather simplistic.


> - no implicit type conversions

D has a large part of the bad implicit type conversions of C.


> - had a sane macro system

There's no macro system in D. Mixins are an improvement over the preprocessor, but they lead to messy code.


> But I guess D already covers it...

D solves only part of the problems. And you have not listed several important things. There's still a lot of way to go to have good enough system languages.

Bye,
bearophile

Am 01.11.2014 um 23:32 schrieb bearophile:
> Paulo Pinto:
>
>> - arrays were bound checked (just use a compiler flags and dataflow to
>> remove them like any sane language)
>
> D removes very little bound checks. No data flow is used for this.
>
>
>> - enums were strong typed
>
> D enums are only half strongly typed.
>
>
>> - had namespaces or real modules
>
> D module system has holes like Swiss cheese. And its design is rather
> simplistic.
>
>
>> - no implicit type conversions
>
> D has a large part of the bad implicit type conversions of C.
>
>
>> - had a sane macro system
>
> There's no macro system in D. Mixins are an improvement over the
> preprocessor, but they lead to messy code.
>
>
>> But I guess D already covers it...
>
> D solves only part of the problems. And you have not listed several
> important things. There's still a lot of way to go to have good enough
> system languages.
>
> Bye,
> bearophile

Maybe I should spend more time playing around with D, instead of just advocating it.

However JVM/.NET languages with a grain of C++ salt for JNI/PInvoke, are what my employer and our customers care about, so I can't justify to our customers any alternatives.

As for the issues, I was being nice to C as those are the issues I find more problematic.

--
Paulo

On Saturday, 1 November 2014 at 22:50:27 UTC, Paulo Pinto wrote:
> However JVM/.NET languages with a grain of C++ salt for JNI/PInvoke, are what my employer and our customers care about, so I can't justify to our customers any alternatives.

I don't think anyone would say that C/C++ would be alternatives to JVM/.NET. Which is what I find a bit frustrating about D forums. Whenever system level programming is discussed people are not really arguing from a performance perspective, but then I don't think they really need C/C++/D…

Anyway, I believe you can turn on bound checks with some C-compilers if you want it, but I don't think anyone who is looking for performance want them in release.

Related to game programming:

I noticed Jonathan being very negative to the web and web programming. Which is not without merits, but the funny thing is that the only thing that keeps the web from being a solid gaming platform is the lack of payment service that has a very low threshold.

I see some clear benefits with browsers/javascript's ability to compile directly to machine language on the fly. Just see what the demo scene are doing with code generators. So yeah, the code is slower, but perhaps not skillful use of it. Maybe we'll see 4K demo compos for asm.js and WebGL.

Btw, I read the Oberon07 spec the other day and interestingly Wirth included add/subtract with carry.  So Oberon has an edge there… :)

On Saturday, 1 November 2014 at 23:04:04 UTC, Ola Fosheim Grøstad wrote:
> I see some clear benefits with browsers/javascript's ability to compile directly to machine language on the fly. Just see what the demo scene are doing with code generators. So yeah, the code is slower, but perhaps not skillful use of it. Maybe we'll see 4K demo compos for asm.js and WebGL.

Oh well, I am out of touch with developments. Turns out they have 1K demo compos for javascript:

http://www.pouet.net/party.php?which=1570&when=2014

On 11/1/2014 4:04 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Anyway, I believe you can turn on bound checks with some C-compilers if you want
> it,

Won't work, because C arrays decay to pointers whenever passed to a function, so you lose all hope of bounds checking except in the most trivial of cases.

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

On 11/1/2014 3:32 PM, bearophile wrote:
> Paulo Pinto:
>
>> - arrays were bound checked (just use a compiler flags and dataflow to remove
>> them like any sane language)
>
> D removes very little bound checks. No data flow is used for this.

This is false.

>> - enums were strong typed
>
> D enums are only half strongly typed.

This is on purpose, because otherwise about half of what enums are used for would no longer be possible - such as bit flags.

A strongly typed enum can be made using a struct.


>> - had namespaces or real modules
>
> D module system has holes like Swiss cheese. And its design is rather simplistic.

Oh come on.


>> - no implicit type conversions
> D has a large part of the bad implicit type conversions of C.

D has removed implicit conversions that result in data loss. Removing the rest would force programs to use casting instead, which is far worse.


>> - had a sane macro system
> There's no macro system in D. Mixins are an improvement over the preprocessor,
> but they lead to messy code.

D doesn't have AST macros for very deliberate reasons, discussed at length here. It is not an oversight.


>> But I guess D already covers it...
> D solves only part of the problems. And you have not listed several important
> things. There's still a lot of way to go to have good enough system languages.

D does more than any other system language.

On Sunday, 2 November 2014 at 00:47:16 UTC, Walter Bright wrote:
> On 11/1/2014 4:04 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> Anyway, I believe you can turn on bound checks with some C-compilers if you want
>> it,
>
> Won't work, because C arrays decay to pointers whenever passed to a function, so you lose all hope of bounds checking except in the most trivial of cases.

There are bounds-checking extensions to GCC.

On 11/1/2014 3:26 PM, bearophile wrote:
> But you can run such compile-time tests only on template arguments, or on
> regular arguments of functions/constructors that are forced to run at
> compile-time. But for me this is _not_ enough. You can't implement the printf
> test example he shows (unless you turn the formatting string into a template
> argument of printf, this introduces template bloat

D has writefln which does not have printf's issues. There's no reason to add a feature for printf.

When I look at my code, it is very rare that I pass arguments to functions that would benefit from compile time checking. For those that might, there's always a rethinking of the feature, such as with printf/writefln.

On Sunday, 2 November 2014 at 00:56:37 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 2 November 2014 at 00:47:16 UTC, Walter Bright wrote:
>> On 11/1/2014 4:04 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> Anyway, I believe you can turn on bound checks with some C-compilers if you want
>>> it,
>>
>> Won't work, because C arrays decay to pointers whenever passed to a function, so you lose all hope of bounds checking except in the most trivial of cases.
>
> There are bounds-checking extensions to GCC.

And papers:

https://cseweb.ucsd.edu/~wchuang/HiPEAC-07-TaintBounds.pdf

http://www3.imperial.ac.uk/pls/portallive/docs/1/18619746.PDF

And projects:

http://sourceforge.net/projects/boundschecking/

…