On Friday, 10 January 2020 at 09:33:01 UTC, Sebastiaan Koppe wrote:
> On Friday, 10 January 2020 at 09:00:53 UTC, Patrick Schluter wrote:
>> On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
>>> void main() {
>>>     int result;
>>>     do {
>>>         int c = 2;
>>>         if (c == 0)
>>>             break;
>>>         string op = "+";
>>>         if (op != "+")
>>>             break;
>>>         int c2 = 3;
>>>         if (c2 == 0)
>>>             break;
>>>         result = c + c2;
>>>     } while (false);
>>>     assert(result == 5);
>>> }
>>
>> Use goto, then people will know that these breaks are gotos in disguise and the code is more readable (less indentation, no confusion with a loop, no catastrophic nesting where you don't know where the break go to) and is much simpler to modify.
>>
>> void main() {
>>     int result;
>>     int c = 2;
>>     if (c == 0)
>>       goto skip;
>>     string op = "+";
>>     if (op != "+")
>>       goto skip;
>>     int c2 = 3;
>>     if (c2 == 0)
>>       goto skip;
>>     result = c + c2;
>> skip:
>>     assert(result == 5);
>> }
>>
>
> or don't do too many things at-once:
>
> void main() {
>   auto result() {
>     int c = 2;
>     if (c == 0)
>       return c;
>     string op = "+";
>     if (op != "+")
>       return c;
>     int c2 = 3;
>     if (c2 == 0)
>       return c;
>     return c + c2;
>   }
>   assert(result == 5);
> }

Yes. You can also consolidate

 void main() {
     int result;
     int c = 2;
     string op = "+";
     int c2 = 3;
     if (c != 0 && op == "+" && c2 != 0)
       result = c + c2;
     assert(result == 5);
 }

etc. but that was not the point of my rant.
It was strictly about the "non-looping loop goto obfuscation" construct.

On Thursday, 9 January 2020 at 19:55:40 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 9 January 2020 at 18:01:10 UTC, JN wrote:
>> Personally the things that I like about it is how clean it looks and how IDE support is taken into account when designing it.
>
> Designing with IDE support in mind from the start is the right approach today, absolutely right. Could give them a faster pick up.
>

Not only today, since Turbo Pascal for MS-DOS, the languages that have been designed with IDE support in mind, are the ones that ended up getting a long term place on my toolbox.

All others, I used to learn about new programming paradigms and approaches to solving problems, but at the end of the day IDE workflows and graphical tooling were too important to give away.

I find quite interesting, that although James Gosling was responsible for XEmacs, he is also on the IDE camp.

There is zero chance I'd use a language younger than 10 years old for a game.

 - No toolchain
 - No bugs discovered by an active community
 - No community, tutorials
 - No 3rd party libraries
 - No proof-by-fire that the language doesn't have a huge, project breaking "gotcha" that will only be noticed by a really smart programmer
 - NO PROOF that the language developer will even be around in a few years.

Dlang is at the cusp of the minimum I'd consider any viable game. Unless by "game" you mean like, a 1-3 month dev cycle that you don't support for years later and just throw on the Steam store and forget about.