On Tuesday, 18 November 2014 at 12:18:16 UTC, Ola Fosheim Grøstad
wrote:
> On Tuesday, 18 November 2014 at 08:28:19 UTC, Paulo  Pinto wrote:
>> This is just one case, the CVE List gets updated every day and 90% of the issues are the usual C suspects regarding pointer misuse and out of bounds.
>
> Sure, but these are not a strict language issues since the same developers would turn off bounds-checking at the first opportunity anyway!
>
> Professionalism does not involve blaming the tool, it involves picking the right tools and process for the task. Unfortunately the IT industry has over time suffered from a lack of formal education and immature markets. Software is considered to work when it crash only once every 24 hours, we would not accept that from any other utility?
>
> I've never heard anyone in academia claim that C is anything more than a small step up from assembler (i.e. low level), so why allow intermediate skilled programmers to write C code if you for the same application would not allow an excellent programmer to write the same program in assembly (about the same risk of having a crash). People get what they deserve.
>
> Never blame the tool for bad management. You get to pick the tool and the process, right? Neither the tool or testing will ensure correct behaviour on its own. You have many factors that need to play together (mindset, process and the tool set).
>
> If you want a compiler that works, you're probably better off writing it in ML than in C, but people implement it in C. Why? Because they FEEL like it… It is not rational. It is emotional.

There are good answer to most of this but most importantly, this
do not contain anything actionable and is completely off topic(
reminder, the topic of the thread is SCOPE ).

Reader's time is precious, please don't waste it.

On Tuesday, 18 November 2014 at 23:48:27 UTC, Walter Bright wrote:
> On 11/18/2014 1:23 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> I am arguing against the position that it was a design mistake to keep the
>> semantic model simple and with few presumptions. On the contrary, it was the
>> design goal. Another goal for a language like C is ease of implementation so
>> that you can easily port it to new hardware.
>
> The proposals I made do not change that in any way, and if K&R designed C without those mistakes, it would have not made C more complex in the slightest.
>
>
>> VLAs have been available in gcc for a long time. They are not useless, I've used
>> them from time to time.
>
> I know you're simply being argumentative when you defend VLAs, a complex and useless feature, and denigrate simple ptr/length pairs as complicated.

Argumentative ?!! More like a fucking gaping fucking asshole. His
posts are the blight of this group.

On Wednesday, 19 November 2014 at 00:04:50 UTC, Walter Bright wrote:
> I know you're simply being argumentative when you defend VLAs, a complex and
> useless feature, and denigrate simple ptr/length pairs as complicated.

Wait, we are either discussing the design goals of the original C or the evolved C. VLAs did not fit the original C either, but in the google discussion you find people who find VLAs very useful. It looks a loot better than alloca. The reason it is made optional is to make embedded-C compilers easier to write, I think.

> But hey, it's simpler, faster, less code, less bug prone, easier to understand and uses less memory to:
>
> 1. strlen
> 2. allocate
…

Not faster, but if speed is no concern, sure. It seldom is when it comes to filenames.

> I know you said "just allocate a large fixed size buffer", but I hope you realize that such practice is the root cause of most buffer overflow bugs,

strcat() should never have been created, but strlcat is safe.

> Now, I know that you'll never concede destruction, after all, this is the internet, but give it up :-)

I always concede destruction :-)

On Wednesday, 19 November 2014 at 01:35:19 UTC, Alo Miehsof Datsørg wrote:
> Argumentative ?!! More like a fucking gaping fucking asshole. His
> posts are the blight of this group.

If you are going ad hominem, please post under your own name. I never go ad hominem, and therefore your response will achieve the exact opposite of what you are trying to achieve to ensure that ad hominem does not become an acceptable line of action.

On Wednesday, 19 November 2014 at 01:13:04 UTC, deadalnix wrote:
> There are good answer to most of this but most importantly, this
> do not contain anything actionable and is completely off topic(
> reminder, the topic of the thread is SCOPE ).

The topic is if "scope" is planned for deprecation. That has been answered.

The thread has been off topic for a long time, so please don't use moderation for silencing an opposing viewpoint from a single party. Unless you are a moderator, but then you should also point to the rules of the forum.

If you are a moderator, then you should first and foremost moderate people who go ad hominem without providing an identity.

Self-appointing moderation will always lead to a very bad situation. If the forums need moderation appoint a moderator.


> Reader's time is precious, please don't waste it.

Then don't read. The topic of this thread was never actionable. Sounds like you want a pure developers forum.

If you want a community you need a lower threshold general forum. "D" is the general forum until it has been defined to not be so, but you do need a low threshold forum.

(I never give in to online bullies in unmoderated media… That gives them a foothold.)

On 11/18/2014 5:35 PM, "Alo Miehsof Datsørg" <Ola.Fosheim.Grostad@sucks.goat.ass>" wrote:
> Argumentative ?!! More like a fucking gaping fucking asshole. His
> posts are the blight of this group.

Rude posts are not welcome here.

On Wednesday, 19 November 2014 at 01:35:19 UTC, Alo Miehsof Datsørg wrote:
> On Tuesday, 18 November 2014 at 23:48:27 UTC, Walter Bright wrote:
>> On 11/18/2014 1:23 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> I am arguing against the position that it was a design mistake to keep the
>>> semantic model simple and with few presumptions. On the contrary, it was the
>>> design goal. Another goal for a language like C is ease of implementation so
>>> that you can easily port it to new hardware.
>>
>> The proposals I made do not change that in any way, and if K&R designed C without those mistakes, it would have not made C more complex in the slightest.
>>
>>
>>> VLAs have been available in gcc for a long time. They are not useless, I've used
>>> them from time to time.
>>
>> I know you're simply being argumentative when you defend VLAs, a complex and useless feature, and denigrate simple ptr/length pairs as complicated.
>
> Argumentative ?!! More like a fucking gaping fucking asshole. His
> posts are the blight of this group.

Wow that's uncalled for.

I don't always agree with Ola but his posts are rarely uninformed and often backed up with actual code examples or links supoprting his arguments. They generally lead to very interesting discussions on the forum.

Cheers,
uri

On Sunday, 16 November 2014 at 03:27:54 UTC, Walter Bright wrote:
> On 11/14/2014 4:32 PM, deadalnix wrote:
>> To quote the guy from the PL for video games video serie, a 85%
>> solution often is preferable.
>
> Spoken like a true engineer!

85% often means being at the bottom of the uncanny valey. 65% or 95% are more preferable.

On Thursday, 20 November 2014 at 10:24:30 UTC, Max Samukha wrote:
> On Sunday, 16 November 2014 at 03:27:54 UTC, Walter Bright wrote:
>> On 11/14/2014 4:32 PM, deadalnix wrote:
>>> To quote the guy from the PL for video games video serie, a 85%
>>> solution often is preferable.
>>
>> Spoken like a true engineer!
>
> 85% often means being at the bottom of the uncanny valey. 65% or 95% are more preferable.

85% is an image rather than an exact number. The point being,
every construct are good at some thing, and bad at other. Making
them capable of doing everything come at a great complexity cost,
so it is preferable to aim for a solution that cope well with
most use cases, and provide alternative solutions for the
horrible cases.

Many language make the mistake of thinking something is the holly
grail, be it OOP, functional programming or linear types. I do
think that it is a better engineering solution to provide a
decent support for all of theses, and doing so we don't need to
get them handle 100% of the case, as we have other language
construct/paradigm that suit better difficult cases anyway.

On Thursday, 20 November 2014 at 20:15:03 UTC, deadalnix wrote:
> Many language make the mistake of thinking something is the holly
> grail, be it OOP, functional programming or linear types. I do
> think that it is a better engineering solution to provide a
> decent support for all of theses, and doing so we don't need to
> get them handle 100% of the case, as we have other language
> construct/paradigm that suit better difficult cases anyway.

FWIW, among language designers it is usually considered a desirable trait to have orthogonality between constructs and let them be combinable in expressive ways. This reduce the burden on the user who then only have to truly understand the key concepts to build a clear mental image of the semantic model. Then you can figure out ways to add syntactical sugar if needed.

Having a smaller set of basic constructs makes it easier to prove correctness, which turn is important for optimization (which depends on the ability to prove equivalence over the pre/post semantics). It makes it easier to prove properties such as "@(un)safe". It also makes it easier to later extend the language.

Just think about all the areas "fibers" in D affect. It affects garbage collection and memory handling. It affects the ability to do deep semantic analysis. It affects implementation of fast multi-threaded ADTs. One innocent feature can have a great impact.

Providing a 70% solution like Go is fine as they have defined a narrow domain for the language, servers, thus as a programmer you don't hit the 30% they left out.

But D has not defined narrow use domain, so as a designer you cannot make up a good rationale for which 15-30% to leave out. Design is always related to a specific use scenario.

(I like the uncanny valley metaphor, had not thought about using it outside 3D. Cool association!)