Morale of a story: ~ is the right choice for concat operator

IntegratedDimensions IntegratedDimensions at gmail.com
Fri May 25 23:57:03 UTC 2018


On Friday, 25 May 2018 at 23:05:51 UTC, Jonathan M Davis wrote:
> On Friday, May 25, 2018 22:23:07 IntegratedDimensions via 
> Digitalmars-d wrote:
>> On Friday, 25 May 2018 at 22:07:22 UTC, Dukc wrote:
>> > On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:
>> >> This ambiguity bug with + has been causing well-known 
>> >> problems since Algol. A *really* long time. Yet it gets 
>> >> constantly welded into new languages.
>> >
>> > Yeah. I could understand that choice for a language that 
>> > tries to be simple for beginners above everything else. But 
>> > for large-scale application language like C#, I quess this 
>> > just did not occur to them.
>>
>> I used to program in C# quite regularly and never had this 
>> issue. It is not a problem of the language but a problem of 
>> the programmer.
>>
>> A programmer should always know the types he is working and 
>> the functional semantics used. While it obviously has the 
>> potential to cause more problems it is not a huge deal in 
>> general. I might have been caught by that "bug" once or twice 
>> but it's usually an obvious fix. If you are moving from one 
>> language to another or haven't programming in one much you 
>> will have these types of problems, but they go away with 
>> experience. To degrade the language based on that is wrong. 
>> Languages should not be designed around noobs because then the 
>> programmers of that language stay noobs. Think BASIC. If all 
>> you did was programmed in basic then you would be considered a 
>> novice programmer by today's standards. If even you were an 
>> expert BASIC programmer, when you moved to a modern language 
>> you would be confused. For you to say that those languages are 
>> inferior because they don't do things like BASIC would be 
>> wrong, it is your unfamiliarity with the language and newer 
>> programming concepts that are the problem.
>>
>> A language will never solve all your problems as a programmer, 
>> else it would write the programs for us.
>
> Personally, I don't think that I've ever made the mistake of 
> screwing up + and concatenating instead of adding or vice 
> versa. And at the end of the day, the programmer does need to 
> know the tools that they're using and use them correctly. That 
> being said, the language (and other tools used for programming) 
> can often be designed in a way that reduces mistakes - and all 
> programmers make mistakes. e.g. in D, implicit fallthrough in 
> case statements is now illegal if the case statement is 
> non-empty. e.g.
>
> switch(i)
> {
>     case 0: // legal fallthrough
>     case 1:
>     {
>         foo(bar());
>         break;
>     }
>     case 2:
>     {
>         do(something());
>         // illegal fallthrough
>     }
>     default: return 17;
> }
>
> Instead, the programmer must put a control flow statement there 
> such as break or goto. e.g.
>
> switch(i)
> {
>     case 0: // legal fallthrough
>     case 1:
>     {
>         foo(bar());
>         break;
>     }
>     case 2:
>     {
>         do(something());
>         goto case; // now explicitly goes to the next case 
> statement
>     }
>     default: return 17;
> }
>
> Sure, it can be argued that this should be unnecessary and that 
> the programmer should just get it right, but it's not an 
> altogether uncommon bug to screw up case statements and 
> invadvertently fall through to the next one when you meant to 
> put a break or some other control statement there. Originally, 
> implicit fallthrough was perfectly legal in D just like it is 
> in C or C++. However, when it was made illegal, it caught quite 
> a few bugs in existing programs - including at companies using 
> D. This change to the language fixed bugs and almost certainly 
> saved people time and money.
>
> Designing a good programming language is a bit of an art. It's 
> not always easy to decide when the language should be picky 
> about something and when it should let the programmer shoot 
> themselves in the foot, but there are plenty of cases where 
> having the language be picky catches bugs that programmers 
> would otherwise make all the time, because we're not perfect.
>
> That's part of why we have @safe in D. It disallows all kinds 
> of perfectly legitimate code, because it's stuff that's easy 
> for the programmer to screw up and often hard for them to get 
> right, and by having large sections of the program restricted 
> in what is allowed prevents all kinds of bugs. Then in the 
> cases where the programmer actually needs to do the unsafe 
> stuff, they write @system code, manually verify that it's 
> correct, and mark it as @trusted so that it can be called from 
> @safe code. Then, when they run into a memory corruption issue 
> later, they have a relatively small portion of the program that 
> they need to inspect.
>
> A well-designed language enables the programmer to do their job 
> correctly and efficiently while protecting them from stupid 
> mistakes where reasonably possible. Using ~ instead of + costs 
> us almost nothing while preventing potential bugs. It's quickly 
> learned when you first start using D, and then the code is 
> clear about whether something is intended to be addition or 
> concatenation without the programmer having to study it 
> closely, and there are cases like what the OP described where 
> it actually allows the compiler to catch bugs. It's a simple 
> design decision with almost no cost that prevents bugs. That's 
> the kind of thing that we generally consider to be a win around 
> here.
>
> - Jonathan M Davis

I don't deny that there something things can make it more 
difficult. But there is a difference between a fundamentally 
unsound semantic and something that is just difficult for a 
typical programmer to get rid every time.

The difficult things become easier with time. It is not a valid 
assessment to claim a language is inferior in some way simply 
because someone unfamiliar with it runs in to problems.

No language is perfectly well designed and someone will always 
have problems in some way.  Obviously there are many things that 
D has done that have screwed the pooch. My point is simply that 
familiarity of a language is necessary to be able to properly 
criticize superficial differences.

What happens is that when you regulate behavior then that 
behavior becomes amplified.

So, you think by forcing programmers to use a break, goto, or 
return at the end of a case somes errors but really what it does 
it make programmers less aware of the problems. They become less 
effective programmers in the long run.

If you have a child, for example, and you always throw them in 
the pool with maximum amount of safety gear they never really 
learn to swim. You are trying to protect them from a *potential* 
problem but cause a real problem in stead. It is impossible to 
swim correctly with "floaties" because they change the physics 
and also offer a false sense of security.

So, for a potential problem that has other solutions(such as 
proper education) you have created a false sense of security, an 
unreal environment that creates a whole new set of problems, and 
get further away from the whole purpose. For the kid, the purpose 
of floaties is not to use them when you swim. They provably take 
away from the experience. Kids that can swim do not use them for 
a reason. Hence they are a handicap and forcing that handicap on 
someone permanently prevents them from growing.

The mentality that you think you can police everything and that 
you also have the experience and knowledge to protect everyone is 
ignorant and provably catastrophic in the long run. Take nuclear 
weapons. They are the "floaties"... a false sense of security 
that now will eventually destroy humanity because it is just a 
matter of time before they are used.

The fact is that people cannot and never will be able to properly 
design things that provide the perfect balance. When people error 
too much on regulation, control, and prediction, they always 
create more problems than the lack of. Just because everyone does 
it does not mean it is right.





More information about the Digitalmars-d mailing list