www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - You are a stupid programmer, you can't have that

reply IGotD- <nise nise.com> writes:
This is a general discussion which applies to all computer 
languages and also under several decades. What I have observed is 
that language designers see programmers misuse the language and 
introduce possible bugs and therefore remove features in 
languages. An analogy would limit the functionality of cars 
because people sometimes are involved in accidents, like 
automatic speed limiter (soon to be law in several countries).

Language designers seem to have a big brother attitude towards 
programmers and think they will save the world by introducing 
limitations.

Examples.

1.
Array indexes should be signed instead of unsigned because 
somehow programmers mess up loops among other things. Bjarne 
Stroustrup considered his unsigned index to be a historic 
mistake. While unsigned array indexes make perfectly sense, the 
bias towards signed seems to be that programmers are stupid. The 
question is, if can't make a for loop with unsigned math, 
shouldn't you look for another job?

2.
Somewhat related. when Java was designed, the designer (James 
Gosling I believe) claimed that programmers were too stupid to 
understand the difference between signed and unsigned math 
(despite often several years of university education) and removed 
signed math entirely from the language. The impact is that when 
unsigned math is required, you are forced to conversions and 
library solutions. Not ideal when an HW APIs deals with unsigned 
numbers for example.

You are welcome to add any other examples that you find 
significant for the discussion.


This partially applies to D in some extent but can often be found 
in other languages and mentality of several language designers.

The question is, do you think language designers go to far when 
trying to "save" programmers from misuse or not?
Do you think there can be approaches that both prevent bugs at 
the same time do not limit the language?
Aug 07
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 The question is, do you think language designers go to far when 
 trying to "save" programmers from misuse or not?
 Do you think there can be approaches that both prevent bugs at 
 the same time do not limit the language?
I think that a tool should not prevent unrecommended uses completely, but it should make them harder so it won't be done by mistake or because it's easier than the right way. Well, that's my standard philosophy to this issue anyway, but perhaps there are cases where that approach is too idealistic. But IMO it's what D usually does. Examples: String mixins. They can be used to do anything the C preprocessor can do (and more!), but the syntax is ugly so it's nicer to use normal templates, manifest constants, aliases or at least template mixins when they can do the job. `version` declarations. They do not allow expressions in them, but if one really needs expressions, `static if` will work around the problem. Default initialization. The shortest syntax will not introduce heisenbugs, but if performance is really that important there's still `=void`. Floats default initialized to NaN instead of 0. One can still initialize them to anything, but this forces to think about it.
Aug 07
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
 When Java was designed, the designer (James Gosling I believe) 
 claimed that programmers were too stupid to understand the 
 difference between signed and unsigned math (despite often 
 several years of university education) and removed signed math 
 entirely from the language. The impact is that when unsigned 
 math is required, you are forced to conversions and library 
 solutions.
It's hard to appreciate how good that Java decision was without maintaining large C++ codebases. Unsigned/signed math and the implicit conversions between them absolutely DO cause bugs in real-world code, the most prominent of which must be: #include <vector> #include <iostream> bool isArrayOrdered(std::vector<int>& vec) { for (size_t n = 0; n < vec.size() - 1; ++n) { if (vec[n] > vec[n+1]) return false; } return true; } int main(int argc, char** argv) { std::vector<int> v; // works if the array isn't empty // v.push_back(4); std::cout << isArrayOrdered(v); } See the bug in isArrayOrdered? It will fail with an empty array since: 1. vec.size() yields size_t 2. vec.size() - 1 stays unsigned, if the size was zero it is now the maximum possible size 3. and we have an unsigned comparison, with a very long loop which in this case will cause out of bounds (Solution: use + 1 on the other side of the comparison) Similar problems happen when people store image size with unsigned, or widget positions in unsigned, or dates in unsigned integers. All of these problems disappear: - if only signed integers are available. - if container length return a signed integer (and that's what D could have done...) - if comparison or arithmetic with mixed signedness is forbidden (but: lots of casts) Programmers do not actually learn about integer promotion except when forced by such bugs. It has nothing to with programmers being dumb or low-skilled, and everything to do with an economy of information: it's better if the problem doesn't exist in the first place. So I believe Java made a decision that saves up mental space.
Aug 07
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 7 August 2021 at 14:21:52 UTC, Guillaume Piolat 
wrote:

 See the bug in isArrayOrdered?
Gotchas like that are harmful but well-known, and the knowledge in our days spreads fast thanks to the internets. I believe an average C++ programmer today is less likely to make that mistake. On the other hand, we don't know how much harm the lack of unsigned types has caused. To claim that it is less harmful would be a case of survivorship bias.
Aug 07
prev sibling parent IGotD- <nise nise.com> writes:
On Saturday, 7 August 2021 at 14:21:52 UTC, Guillaume Piolat 
wrote:
 It's hard to appreciate how good that Java decision was without 
 maintaining large C++ codebases.
 Unsigned/signed math and the implicit conversions between them 
 absolutely DO cause bugs in real-world code, the most prominent 
 of which must be:

     #include <vector>
     #include <iostream>

     bool isArrayOrdered(std::vector<int>& vec)
     {
         for (size_t n = 0; n < vec.size() - 1; ++n)
         {
             if (vec[n] > vec[n+1])
                 return false;
         }
         return true;
     }

     int main(int argc, char** argv)
     {
         std::vector<int> v;
         // works if the array isn't empty
         // v.push_back(4);
         std::cout << isArrayOrdered(v);
     }


 See the bug in isArrayOrdered?

 It will fail with an empty array since:
 1. vec.size() yields size_t
 2. vec.size() - 1 stays unsigned, if the size was zero it is 
 now the maximum possible size
 3. and we have an unsigned comparison, with a very long loop 
 which in this case will cause out of bounds

 (Solution: use + 1 on the other side of the comparison)

 Similar problems happen when people store image size with 
 unsigned, or widget positions in unsigned, or dates in unsigned 
 integers.

 All of these problems disappear:
 - if only signed integers are available.
 - if container length return a signed integer (and that's what 
 D could have done...)
 - if comparison or arithmetic with mixed signedness is 
 forbidden (but: lots of casts)

 Programmers do not actually learn about integer promotion 
 except when forced by such bugs.
 It has nothing to with programmers being dumb or low-skilled, 
 and everything to do with an economy of information: it's 
 better if the problem doesn't exist in the first place.

 So I believe Java made a decision that saves up mental space.
Your example is a valid argument as well as you provide the solution for unsigned math. The most interesting with the example is that your example provide a one comparison solution for signed/unsigned. This type of error would quickly be found as it would generate an exception in both C++ and D. Then perhaps the lazy programmer would just do an extra check when the size is zero. For example bool isArrayOrdered(std::vector<int>& vec) { if (vec.empty()) { return true; } for (size_t n = 0; n < vec.size() - 1; ++n) { if (vec[n] > vec[n+1]) return false; } return true; } This would be better but requires an extra check, two comparisons. I think you provide an excellent example that the problem isn't signed/unsigned math but how you can use the arithmetics to your advantage regardless signed/unsigned. There are often solutions when using unsigned math and that is what I think the programmer should learn instead of limiting the language.
Aug 07
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/7/2021 6:05 AM, Dukc wrote:
 `version` declarations. They do not allow expressions in them, but if one
really 
 needs expressions, `static if` will work around the problem.
Many years back, some revisions were made in druntime to use enums and `static if` instead of versions. It didn't take long before the problems I warned about with #if expressions emerged. It's inevitable. I replaced it all with versions, and the problems went away. D's design is very much based on decades of my experience with unanticipated problems that arise from certain features, and my discussions with other experienced programmers and team leaders about what goes wrong and causes trouble. --- As for car analogies, I recall a TV show called "Pinks" where amateur drivers drag raced for pink slips. On one episode, a teenager showed up with his Beetle, in which he had installed a much more powerful engine. The christmas tree turned green, he popped the clutch, and snapped both rear axles. The car rolled 10 feet down the track and stopped. He sheepishly got out, suffering a humiliating defeat. He shows up again on another episode a few months later. This time, he says, he got the drive train upgraded for the power. But also, his Beetle had sprouted a full roll cage. The MC asked him about the cage, and he sheepishly rolled his eyes and said his mom made him put it in. The tree turns green, he popped the clutch, and launched down the track. About halfway down, a front axle gave way. As the car was going very fast, it promptly flipped and tumbled down the track, over and over, with pieces of the car flying off everywhere. The MC was all "oh my gawd" and everyone ran down the track to see if he was dead. There was nothing left of the car but the roll cage, with our hero strapped within. He was unhurt. All he said was "thank god for mom!"
Aug 08
next sibling parent reply user1234 <user1234 12.de> writes:
On Sunday, 8 August 2021 at 08:59:16 UTC, Walter Bright wrote:
[...]
 The tree turns green, he popped the clutch, and launched down 
 the track. About halfway down, a front axle gave way. As the 
 car was going very fast, it promptly flipped and tumbled down 
 the track, over and over, with pieces of the car flying off 
 everywhere. The MC was all "oh my gawd" and everyone ran down 
 the track to see if he was dead. There was nothing left of the 
 car but the roll cage, with our hero strapped within. He was 
 unhurt.

 All he said was "thank god for mom!"
[indeed](https://youtu.be/HNMlooJeJ2M?t=2453)
Aug 08
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/8/2021 6:57 AM, user1234 wrote:
 [indeed](https://youtu.be/HNMlooJeJ2M?t=2453)
Nice!
Aug 08
prev sibling next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Sunday, 8 August 2021 at 08:59:16 UTC, Walter Bright wrote:

 I replaced it all with versions, and the problems went away.
You have just dismissed the problems caused by your solution, as you often do.
Aug 08
next sibling parent reply Kyle Ingraham <kyle kyleingraham.com> writes:
On Sunday, 8 August 2021 at 14:30:29 UTC, Max Samukha wrote:
 On Sunday, 8 August 2021 at 08:59:16 UTC, Walter Bright wrote:

 I replaced it all with versions, and the problems went away.
You have just dismissed the problems caused by your solution, as you often do.
Why the personal attack? What does it add here? I see these from time to time and they distract from the topic at hand. Sometimes even souring the discussion.
Aug 08
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 8 August 2021 at 16:15:00 UTC, Kyle Ingraham wrote:
 Why the personal attack?
That's directly addressing the argument, not a personal attack. Imagine going to a mechanic and saying "my car shakes and thumps" and getting the answer "just don't drive it then, no more shaking!" True, but presumably you were driving the car for a reason, like maybe you had some place to be and that's not going to change. So you need some kind of solution. Maybe it is to ride a bike or take the bus, but you can't just ignore that need while saying "the problems went away".
Aug 08
next sibling parent jfondren <julian.fondren gmail.com> writes:
On Sunday, 8 August 2021 at 16:38:41 UTC, Adam D Ruppe wrote:
 On Sunday, 8 August 2021 at 16:15:00 UTC, Kyle Ingraham wrote:
 Why the personal attack?
That's directly addressing the argument, not a personal attack. Imagine going to a mechanic and saying "my car shakes and thumps" and getting the answer "just don't drive it then, no more shaking!"
Or rather, imagine going to a mechanic and saying "my engine heats up and stops", and getting the answer "yep, I checked it out and the radiator's busted. I replaced it for you. You won't be having them heat-ups anymore." And then, because the mechanic didn't go into sufficiently tedious detail to deflect uncharitable criticism, you blow up at him: "why are you COVERING UP the problem with my engine by replacing some random part?!"
Aug 08
prev sibling parent Kyle Ingraham <kyle kyleingraham.com> writes:
On Sunday, 8 August 2021 at 16:38:41 UTC, Adam D Ruppe wrote:
 On Sunday, 8 August 2021 at 16:15:00 UTC, Kyle Ingraham wrote:
 Why the personal attack?
That's directly addressing the argument, not a personal attack. Imagine going to a mechanic and saying "my car shakes and thumps" and getting the answer "just don't drive it then, no more shaking!" True, but presumably you were driving the car for a reason, like maybe you had some place to be and that's not going to change. So you need some kind of solution. Maybe it is to ride a bike or take the bus, but you can't just ignore that need while saying "the problems went away".
I got the same as what you describe up to “You have just dismissed the problems caused by your solution…”. I just felt there was more there without background context that didn’t need to be there.
Aug 16
prev sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Sunday, 8 August 2021 at 16:15:00 UTC, Kyle Ingraham wrote:

 Why the personal attack? What does it add here?
I did it out of frustration with an issue that has a long history. Shouldn't have done that, sorry. I promise not to post here again.
Aug 08
parent Kyle Ingraham <kyle kyleingraham.com> writes:
On Sunday, 8 August 2021 at 16:45:23 UTC, Max Samukha wrote:
 On Sunday, 8 August 2021 at 16:15:00 UTC, Kyle Ingraham wrote:

 Why the personal attack? What does it add here?
I did it out of frustration with an issue that has a long history. Shouldn't have done that, sorry. I promise not to post here again.
Definitely post here again. I only asked about something I had also been frustrated with. Don’t hold back your contribution because of my questions.
Aug 16
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/8/2021 7:30 AM, Max Samukha wrote:
 I replaced it all with versions, and the problems went away.
You have just dismissed the problems caused by your solution, as you often do.
The static if solution was written by people who asserted I was wrong, that they needed that power. I got involved in it is because the static if solution resulted in the predicted bugs, and it fell into my lap to fix the bugs. No programming technique is without problems, but it's better to use the technique with fewer problems. I cannot transfer my experience to others, I can only explain. If people want to do things their way on their projects, that's ok, but with the D project we need to follow best practices. Over time, as people gain experience with D and get comfortable with D best practices, the desire for #if expressions tends to fade, and the value in D's version system becomes evident.
Aug 08
prev sibling next sibling parent someone <someone somewhere.com> writes:
On Sunday, 8 August 2021 at 08:59:16 UTC, Walter Bright wrote:

First and foremost ... thanks for D; your language seems superb 
:) !

Second: you all are a welcoming community to outsiders/newbies, 
something not seen very often on these kind of projects.

 All he said was "thank god for mom!"
I am not complaining nor anything like it, I think you know what should have been done and proceeded accordingly giving your vast and indisputable experience and track record, but, as usual, there are two points-of-view for any given problem: I think I have a better analogy to the car-one: - NASA/JPL/Boeing/et-al vs SpaceX For instance JPL won't even let you a minor-minor-minor-deviation on any given issue and so their track record is almost astounding to say the least (let's forget about that *minor* issue involving a metric/imperial conversion). Think mom. Same for NASA/Boeing/and-family ... superb engineers thinking contingencies against the impossible. You got excellent track records but ... On the other side, when you let loose available unrestricted tools on the wild, you end up with things like SpaceX. The progress we are having right now in a very short span of time (I mean, we, as humanity, not as a SpaceX employee of course) is unheard off. Lots of out-of-the-box-thinkers and what-not at the expense of taking increased risk in order to succeed. And the whole establishment frantically playing catch-up. Which approach is better ? Both and neither one; it depends on the point-of-view. Why do I bring back this analogy ? Because when you give users unrestricted tools/hardware they'll surely find ways of doing things you can never dreamed of. That's how innovation works. At the expense of risk, of course, you can't have both at the same time. And in our tech-sphere, same with hardware vendors: they want you to use their products the way they suit them for whatever reasons ($) and people always find ways to build superb things out-of-the-intended use-case ... just think google and hardware vendors on the beginnings before this hyper-scale thing became into existence. Again: I am not complaining, I am very happy with D so far, it is your project, your language, you can do whatever you want with it the way you like :) It is just I found this such a goood topic !
Aug 08
prev sibling parent Mark <mt.rzezniczak gmail.com> writes:
On Sunday, 8 August 2021 at 08:59:16 UTC, Walter Bright wrote:
 All he said was "thank god for mom!"
Just an off-topic philosophical question here, but was he thanking god, his mom, or both?
Aug 09
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 This is a general discussion which applies to all computer 
 languages and also under several decades. What I have observed 
 is that language designers see programmers misuse the language 
 and introduce possible bugs and therefore remove features in 
 languages. An analogy would limit the functionality of cars 
 because people sometimes are involved in accidents, like 
 automatic speed limiter (soon to be law in several countries).

 Language designers seem to have a big brother attitude towards 
 programmers and think they will save the world by introducing 
 limitations.

 Examples.

 1.
 Array indexes should be signed instead of unsigned because 
 somehow programmers mess up loops among other things. Bjarne 
 Stroustrup considered his unsigned index to be a historic 
 mistake. While unsigned array indexes make perfectly sense, the 
 bias towards signed seems to be that programmers are stupid. 
 The question is, if can't make a for loop with unsigned math, 
 shouldn't you look for another job?

 2.
 Somewhat related. when Java was designed, the designer (James 
 Gosling I believe) claimed that programmers were too stupid to 
 understand the difference between signed and unsigned math 
 (despite often several years of university education) and 
 removed signed math entirely from the language. The impact is 
 that when unsigned math is required, you are forced to 
 conversions and library solutions. Not ideal when an HW APIs 
 deals with unsigned numbers for example.

 You are welcome to add any other examples that you find 
 significant for the discussion.


 This partially applies to D in some extent but can often be 
 found in other languages and mentality of several language 
 designers.

 The question is, do you think language designers go to far when 
 trying to "save" programmers from misuse or not?
 Do you think there can be approaches that both prevent bugs at 
 the same time do not limit the language?
"In programming language design, one of the standard problems is that the language grows so complex that nobody can understand it. One of the little experiments I tried was asking people about the rules for unsigned arithmetic in C. It turns out nobody understands how unsigned arithmetic in C works. There are a few obvious things that people understand, but many people don't understand it." https://www.artima.com/articles/james-gosling-on-java-may-2001 Turns out not everyone has an university degree for programming, and many known less than they actually are able to deliver, specifically when under stress and deadlines. By the way, Java supports unsigned math since Java 8 via unsigned math methods, if only people would actually bother to update, we are on version 16 now.
Aug 07
prev sibling next sibling parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 Somewhat related. when Java was designed, the designer (James 
 Gosling I believe) claimed that programmers were too stupid to 
 understand the difference between signed and unsigned math 
 (despite often several years of university education) and 
 removed signed math entirely from the language. The impact is 
 that when unsigned math is required, you are forced to 
 conversions and library solutions
Zig does stuff like this and it's why I can't take that language seriously. At all. To paraphrase what I was told by Zig's community and BDFL: "if there's multiple ways to do something then obviously dumb dumb programmer will get it completely wrong". I like programming languages that help me catch bugs (D or Rust), not languages that treat me like a 3 year old.
Aug 08
parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 8 August 2021 at 09:49:41 UTC, Dylan Graham wrote:
 On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 [snip]
Zig does stuff like this and it's why I can't take that language seriously. At all. To paraphrase what I was told by Zig's community and BDFL: "if there's multiple ways to do something then obviously dumb dumb programmer will get it completely wrong". I like programming languages that help me catch bugs (D or Rust), not languages that treat me like a 3 year old.
To be fair, I don't think lack of unsigned integers is a big deal. Because many operators do not care whether it's signed or unsigned that's being used, and for the remaining ones (divide, modulus, right shift) the language can define standard library functions. But I do agree in general that either Java does not have much faith in programmer ability, or they value implementation simplicity much more than readability. I can see no other reasons for disallowing free functions or requiring curly braces for every singe `if` or `while` statement. Or for requiring repeating `public` on every public member instead of just before the first one as in C++ (Haven't done much Java, forgive me if I recall the details wrong).
Aug 09
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 9 August 2021 at 12:14:27 UTC, Dukc wrote:
 On Sunday, 8 August 2021 at 09:49:41 UTC, Dylan Graham wrote:
 On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 [snip]
Zig does stuff like this and it's why I can't take that language seriously. At all. To paraphrase what I was told by Zig's community and BDFL: "if there's multiple ways to do something then obviously dumb dumb programmer will get it completely wrong". I like programming languages that help me catch bugs (D or Rust), not languages that treat me like a 3 year old.
To be fair, I don't think lack of unsigned integers is a big deal. Because many operators do not care whether it's signed or unsigned that's being used, and for the remaining ones (divide, modulus, right shift) the language can define standard library functions. But I do agree in general that either Java does not have much faith in programmer ability, or they value implementation simplicity much more than readability. I can see no other reasons for disallowing free functions or requiring curly braces for every singe `if` or `while` statement. Or for requiring repeating `public` on every public member instead of just before the first one as in C++ (Haven't done much Java, forgive me if I recall the details wrong).
You can kind of fake free functions with import static or method references. Compound statements aren't required for if/while, only a convention inherited from C best practices, goto fail from Apple showed the world why they are a good idea. Class members without visibility specificier default to package visibility, so they are public to remaining classes on the package or module (as of Java 9+).
Aug 09
prev sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Monday, 9 August 2021 at 12:14:27 UTC, Dukc wrote:
 I can see no other reasons for disallowing free functions or 
 requiring curly braces for every singe `if` or `while` 
 statement.
Java is object oriented only language, hence it makes sense to not have free functions as in C++, and you actually do have free functions there. They are static methods. Braces are not required for control statements, but encouraged to avoid ambiguous then statements. Best regards, Alexandru
Aug 09
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 09, 2021 at 05:37:26PM +0000, Alexandru Ermicioi via Digitalmars-d
wrote:
 On Monday, 9 August 2021 at 12:14:27 UTC, Dukc wrote:
 I can see no other reasons for disallowing free functions or
 requiring curly braces for every singe `if` or `while` statement.
Java is object oriented only language, hence it makes sense to not have free functions as in C++, and you actually do have free functions there. They are static methods.
I find this to be silly OO-extremism on Java's part. Static methods of a singleton class are basically free global functions. Why can't they just *be* global free functions?! But nooo, that would not jive with the OO agenda, so we have to wrap that in a singleton class just to do lip service to the OO dogma and pacify the OO police. We're eating the greasy unhealthy food of global free functions, but to pacify our OO conscience we order the diet coke of a singleton class's static methods. Seriously, just call it what it is already.
 Braces are not required for control statements, but encouraged to
 avoid ambiguous then statements.
[...] This one I actually agree with. (Even if I do find it annoying sometimes.) Ambiguous statements are actually worse than they appear at first glance, because of long-term maintainability issues. Consider this code where braces are omitted: if (someCondition) doSomething(); else doSomethingElse(); finishUp(); Imagine if some time later somebody discovers a bug, and introduces this fix: if (someCondition) doSomething(); else doSomethingElse(); return 1; // <--- bugfix finishUp(); Had braces been required, the `return 1;` would have been introduced in the proper scope and there would have been no problem. But now this fix has introduced a new bug. T -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst
Aug 09
next sibling parent reply Daniel N <no public.email> writes:
On Monday, 9 August 2021 at 18:00:23 UTC, H. S. Teoh wrote:
 	if (someCondition)
 		doSomething();
 	else
 		doSomethingElse();
 		return 1;	// <--- bugfix
 	finishUp();

 Had braces been required, the `return 1;` would have been 
 introduced in the proper scope and there would have been no 
 problem. But now this fix has introduced a new bug.


 T
The above code will fail to compile in recent C/C++ compilers, because of suspected intentional backdoors hiding in plain sight using this technique. <source>:7:5: warning: this 'else' clause does not guard... [-Wmisleading-indentation] <source>:9:9: note: ...this statement, but the latter is misleadingly indented as if it were Thus there's no longer a good reason to avoid this style, unless you are using a compiler where this is not yet implemented.
Aug 09
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 09, 2021 at 06:23:42PM +0000, Daniel N via Digitalmars-d wrote:
 On Monday, 9 August 2021 at 18:00:23 UTC, H. S. Teoh wrote:
 	if (someCondition)
 		doSomething();
 	else
 		doSomethingElse();
 		return 1;	// <--- bugfix
 	finishUp();
 
 Had braces been required, the `return 1;` would have been introduced
 in the proper scope and there would have been no problem. But now
 this fix has introduced a new bug.
[...]
 The above code will fail to compile in recent C/C++ compilers, because
 of suspected intentional backdoors hiding in plain sight using this
 technique.
 
 <source>:7:5: warning: this 'else' clause does not guard...
 [-Wmisleading-indentation]
 <source>:9:9: note: ...this statement, but the latter is misleadingly
 indented as if it were
 
 Thus there's no longer a good reason to avoid this style, unless you
 are using a compiler where this is not yet implemented.
I would not trust a coding style that depends on the compiler to warn about mistakes. What if the compiler fails to issue the warning in some obscure corner cases? It's completely preventable: just don't write code this way. Besides, it's kinda sad that C is moving towards Python-style indentation sensitivity... T -- This is a tpyo.
Aug 09
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 9 August 2021 at 18:00:23 UTC, H. S. Teoh wrote:
 [snip]

 Imagine if some time later somebody discovers a bug, and 
 introduces this fix:

 	if (someCondition)
 		doSomething();
 	else
 		doSomethingElse();
 		return 1;	// <--- bugfix
 	finishUp();

 Had braces been required, the `return 1;` would have been 
 introduced in the proper scope and there would have been no 
 problem. But now this fix has introduced a new bug.


 T
I strongly prefer requiring the braces are here.
Aug 09
prev sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Monday, 9 August 2021 at 18:00:23 UTC, H. S. Teoh wrote:
 I find this to be silly OO-extremism on Java's part.  Static 
 methods of a singleton class are basically free global 
 functions.  Why can't they just *be* global free functions?!  
 But nooo, that would not jive with the OO agenda, so we have to 
 wrap that in a singleton class just to do lip service to the OO 
 dogma and pacify the OO police.  We're eating the greasy 
 unhealthy food of global free functions, but to pacify our OO 
 conscience we order the diet coke of a singleton class's static 
 methods.
Well, if you're picky, then no, static methods are not free functions in global space, but rather can be considered as methods of object representing the class of objects (x.class). They though are usually used as free functions, and people don't fuss over whether they a free or part of a class. I think java doesn't have any notion of a global space where you can put your funcs. There is just class and that is it. To note, I'm not defending the choices made for java by it's dev team, just stated some facts, and personal views. Best regards, Alexandru.
Aug 09
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 09, 2021 at 10:32:01PM +0000, Alexandru Ermicioi via Digitalmars-d
wrote:
 On Monday, 9 August 2021 at 18:00:23 UTC, H. S. Teoh wrote:
 I find this to be silly OO-extremism on Java's part.  Static methods
 of a singleton class are basically free global functions.  Why can't
 they just *be* global free functions?!  But nooo, that would not
 jive with the OO agenda, so we have to wrap that in a singleton
 class just to do lip service to the OO dogma and pacify the OO
 police.  We're eating the greasy unhealthy food of global free
 functions, but to pacify our OO conscience we order the diet coke of
 a singleton class's static methods.
Well, if you're picky, then no, static methods are not free functions in global space, but rather can be considered as methods of object representing the class of objects (x.class). They though are usually used as free functions, and people don't fuss over whether they a free or part of a class.
Frankly, that's just calling a duck an aquatic chicken with webbed feet. The class is a singleton (which kinda defeats the whole point of a *class* -- at that point it might as well be just a namespace, as far as effective semantics are), and the static method does not even take a reference to said singleton class, it's completely standalone and independent (aside from the FQN). It basically behaves like a global free function -- and is in fact the exact idiom Java uses when interfacing with C functions. The equivalence is practically 1-to-1. It quacks like a duck and waddles like a duck -- it's a duck. Calling it an aquatic class method with webbed feet is really only good for doing lip service to OO dogma. For all practical purposes, it's a free function.
 I think java doesn't have any notion of a global space where you can
 put your funcs. There is just class and that is it.
Yes, and this is why such a non-OO hack was introduced in the first place. Since anything existing outside a class is taboo in OO dogma, in order to rationalize away the non-OO-ness of a global free function we wrap it in the robes of a class and crown it as a method of that class. But the class is a singleton (and holds no state) and the method is static (does not depend on the class instance at all), which makes it painfully obvious that the entire intent is to rephrase "global free function" in terms that are less offensive to OO dogma. But regardless, this shoe-horning doesn't change the fact that it essentially, for all practical purposes, behaves like a global free function.
 To note, I'm not defending the choices made for java by it's dev team,
 just stated some facts, and personal views.
[...] No offense taken. I just find the OO extremism of Java to be laughable, that's all. Why not just admit that OO isn't the be-all and end-all of programming, and call free global functions what they are. This is why D's multi-paradigm approach makes so much more sense: sometimes one paradigm doesn't fit the problem, why not acknowledge it and allow a different paradigm to step in. Not every problem is a nail to which the OO hammer must be brought to bear. T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius
Aug 09
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 9 August 2021 at 23:09:30 UTC, H. S. Teoh wrote:
 ...
 No offense taken.  I just find the OO extremism of Java to be 
 laughable, that's all.  Why not just admit that OO isn't the 
 be-all and end-all of programming, and call free global 
 functions what they are.

 This is why D's multi-paradigm approach makes so much more 
 sense: sometimes one paradigm doesn't fit the problem, why not 
 acknowledge it and allow a different paradigm to step in.  Not 
 every problem is a nail to which the OO hammer must be brought 
 to bear.


 T
I love how people love to hate Java, yet have no words of hate (check methods from typeof(func)), Dart. How has D's multiparadigm helped to have a better marketshare than some of those extremist OOP languages?
Aug 09
next sibling parent reply Brian Tiffin <btiffin gnu.org> writes:
On Tuesday, 10 August 2021 at 06:23:39 UTC, Paulo Pinto wrote:
 On Monday, 9 August 2021 at 23:09:30 UTC, H. S. Teoh wrote:
 ...
 I love how people love to hate Java, yet have no words of hate 

 (check methods from typeof(func)), Dart.

 How has D's multiparadigm helped to have a better marketshare 
 than some of those extremist OOP languages?
I may have started some of the jump on Java trend with the bumper car comment. *This may get long, as there are historical evolutions to cover, an old guy in the mood to ramble, and maybe pass on some learnin's, save a few younglings from some choice of programming tool angst.* I'm not going to speak for others, Paulo, but I find Java to be fun, not hated, more smirky amusing. *Now rambling to the room.* Being a fellow Canuck, I've followed the works of James Gosling with some interest, for a lot of years now. Back when it was Oak, and the smart agent in Oak was Duke, and Duke is still a very cool mascot. *Be sure to check out sc, the spreadsheet calculator, a TUI interface console spreadsheet with vi like key bindings. Something James also wrote, way back when as public domain code.* And some *personal* reasons behind the smirking at Java. When Java was first being hyped (and it was hyped, something like $500 million was allocated to advertising by Sun), I was programming in Forth on a Vax for a phone company. PCs were toys and core business adjacent, not core business tools, in my mind at the time. The web was a distraction, for science and amusement, viewed as business adjacent, not core. *At the time*. Could see the potential of Mosaic and the WWW, but would not have recommended it to a manager as a smart move for critical work. It was for the marketing department, not a competitor to telephony. The web did not seem like bigboy pants internet technology at the time, not like the more serious uses like Gopher, Telnet and FTP. :-) Attitude on the web changed fairly quickly, but Java still seemed like a toy. Real programmers wrote to machine code, not a play area sandbox. But, $500 million in advertising budget caught the eye of many a leader, and it was fun. Our Forth system was set to be superseded by an amalgam overlord system in C++, consolidating some 20 or 30 other large systems. Watched in predicted horror as three years of 300 people's time was wasted on project management and Grady Booch cloud diagram planning. 300 people. 3 years. The writing was on the wall when **zero** user level demo screens were available years after starting. *C++ isn't going to work, this needs to be in Java, was the next recommendation.* I think the Forth project we worked on (for many more years after the story from above) was finally retired a few years ago after being outsourced to a Vaxen emulator in Bangalore a decade ago. The amalgam is still in a continuing cycle of development startup followed by cancel and fail, last I heard. 25ish years later. Yet, unless given the runway we initially enjoyed with the Forth system, I would not recommend Forth for large scale systems. You need time to build an application vocabulary when using Forth in the large, and there is little chance for cost recovery during that phase. Given lead time, absolutely, but that'd be a rare management decision in the 3rd millennium. C++ rose to fame, in part, due to human pride. A sense of "I figured it out, ar'mant I smart". That's a powerful draw. For many, C++ is very smart. Smarter than some of us prideful programmers though. Java did not rise to fame on merit (it might have, more slowly). It rose to fame on aggressive marketing and expensive hype. Since the lock in had started, many companies have poured billions into JVM technology, to ensure its success at making reasonably fast bumper cars run in a sandbox. That's all ok, but I was young when it was just starting, and it smelled like a toy then. It still kinda smells like a toy, because of that initial bias. Useful for business adjacent pretty reporting and such. Haven't been paid to work in Java since 1998-ish, but have followed it along the way, 1.2 was just coming out, with the whole J2EE thing (or J2SE, or JDK, can't quite remember the marketing speak without looking it up). I'm not sure, but I'd wager some of that Java 1.2 is still in the marketing application we wrote, if the company still exists. Still enjoy exploring OpenJDK 11 now, and have an intrinsic FUNCTION JVM built into a version of GnuCOBOL, which should eventually be solid enough for us to advertise GnuCOBOL as ready to run any enterprise Java classes in an engine embedded in COBOL via JNI. *At its core, JDK Java is written in C and GnuCOBOL compiles via C.* I'm still that kind of biased internally, COBOL for core business, Java for some fluffy bits and pretty pictures. Also realize that the amount of .class code in the world is immense. Why not leverage it to help an enterprise pursue its goals, while counting all the beans in COBOL, integrated tightly? My bias to OOP is similar. Watched too many large scale failures come and go with C++ and Java rip and replace projects. But when determined and with deep enough pockets most failures can be silently buried, small successes over hyped until it all becomes legacy code anyway, ready to be replaced by Go, Ruby, Rust, Zig, or whatever is the lang hype du jour at the time. Except for the life expectancy of source code thing, I'd happily hype D to any management at any large company. But at 6ish years of life expectancy before being forced to manually update a codebase, it'd be a hard sell for large systems. Will recommend D for business adjacent short span productivity applications from now on though. How many sites still run Python 2 because the code borks in Python 3? How many sites will be on Java 8 until 2038 or beyond? The borks might be extremely trivial to a programmer, parens around arguments to `print` for instance, but when a non-tech boss sees the first `SyntaxError: Missing parentheses in call to 'print'. Did you mean print(name)?` they may just stick with Python 2 and get on with running their business. They paid for that code already. 10 years is nothing in that kind of time frame. They will wait until the pain of stagnation (or being mocked as archaic legacy) exceeds a threshold. Then they will pour money at the tech team, often times just to save face, and in a sour mood. There will always be another consultant ready to hype a tech, and promise a short cut to the promised land. Slow, long tail growth is the best kind of growth, in my old guy opinion. D is making sound decisions in the now it seems, growing slowly, which is sound in the long term. Now to convince the D dev team that we, the stupid programmers, leave behind code that may not age well if even a small language detail changes. Cover that base and businesses will follow. To keep a little bit more *in thread*, some of the decisions may be guard rail protect the programmer from the programmer decisions. Those aren't all bad. COBOL isn't active at 60 because it's great tech in the internet era, it's still active, with a huge market share, because it grew that big with a never shrinking codebase, that still compiles. Pennies are still pennies, core banking is still the same banking. If I'm not mistaken, the oldest still running codebase is a contract management system, MOCAS, for the U.S. department of defense. 60+ years old, mostly COBOL. There are billions on the line for the first team that can answer a still open call to convince DoD that a replacement won't drop any features or muck up any contracts in play at time of transition. Some have tried, all failed to convince the brass, so far. More famous, but still old is the SABRE airline reservation system, in COBOL/CICS. There are programs running in the IRS supporting the Individual Master File and Master Banking File projects still using (probably, these are not overly public source codes) COBOL sources written in 1962, recompiled for each new mainframe iteration. Java 8 is set to ~~enjoy~~ suffer a similar fate. As is Python 2, Perl 5, ... (whether the Python/Perl/... core contributors like it or not). Ruby, maybe not, but maybe. If you can convince a company to pay for some code, they are not going to want to pay for the same code again, even decades later. Ranting almost over. D design decisions seem like very sane long view decisions. But source codes need a longer life expectancy, or D may end up relegated to short and mid range development planning, ad infinitum. That's ok, if that is the end goal or an acceptable fate. D does not feel like a design effort with stupid in mind. The guard rails and preferred paths in D seem well planned and well placed. *Still new to D, could be completely wrong in the depths*. Protecting from tricks some people may feel comfortable with but keeping simple mistakes from being catastrophic, painful to find and fix or costly to maintain, is not limiting, in my opinion, at least not in a bad way. That goes for D or any other programming language tool chain. Have good, make well, excuse the long read and slow drift.
Aug 10
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 10, 2021 at 10:59:58AM +0000, Brian Tiffin via Digitalmars-d wrote:
[...]
 *Now rambling to the room.* Being a fellow Canuck, I've followed the
 works of James Gosling with some interest, for a lot of years now.
 Back when it was Oak, and the smart agent in Oak was Duke, and Duke is
 still a very cool mascot.
Haha, didn't realize Gosling was Canadian. Hooray for fellow Canuckians! ;-) [...]
 When Java was first being hyped (and it was hyped, something like $500
 million was allocated to advertising by Sun), [...]
 [...] Real programmers wrote to machine code, not a play area sandbox.
 But, $500 million in advertising budget caught the eye of many a
 leader, and it was fun.
Yep, that's the perception I had from the 90's. I was young and idealistic, and immediately smelled the hype behind Java -- and distrusted it. Almost 3 decades later, I still distrust it. But now, with history in hindsight, it is also abundantly clear that what drives programming language popularity is marketing budget. Technical merit plays at best a secondary role (if even). [...]
 Java did not rise to fame on merit (it might have, more slowly). It rose to
 fame on aggressive marketing and expensive hype.  Since the lock in had
 started, many companies have poured billions into JVM technology, to ensure
 its success at making reasonably fast bumper cars run in a sandbox.
Yes, and that is why marketing hype is ultimately the decider of technology adoption, not the technical merit itself. First, with a large enough budget, you attract the attention of the VIPs who make the decisions at the top level. They dictate the use of said tech among the lower ranks, and then over time the tech becomes entrenched, ensuring its continued use. Technical excellence does not play a major role here. If it works reasonably well, it will stay. And the longer it stays, the harder it becomes to displace it. Inertia is a powerful force. [...]
 My bias to OOP is similar.  Watched too many large scale failures come
 and go with C++ and Java rip and replace projects.
As Joel Spolsky once said: ... the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. ;-)
 But when determined and with deep enough pockets most failures can be
 silently buried, small successes over hyped until it all becomes
 legacy code anyway, ready to be replaced by Go, Ruby, Rust, Zig, or
 whatever is the lang hype du jour at the time.
Haha, this reminds me of one of my favorite Walter quotes: I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright But yeah, it's the hype that drives adoption. The technical merit, not so much. If at all. [...]
 Slow, long tail growth is the best kind of growth, in my old guy
 opinion.
I agree. But that's a hard sell in today's age of instant gratification. Nobody wants to -- nor has the time to -- gradually build up an infrastructure that will last for the long term. They want, and need, a solution NOW, and you better be able to deliver NOW, otherwise they will just move on to the next salesman who promises the here and now. And it's hard to fault them when the investors are knocking on their door asking when the promised results will materialize.
 D is making sound decisions in the now it seems, growing slowly, which
 is sound in the long term.  Now to convince the D dev team that we,
 the stupid programmers, leave behind code that may not age well if
 even a small language detail changes.  Cover that base and businesses
 will follow.
[...] I think this is what Andrei has been saying every so often: stop deleting, start adding. I.e., never remove old features, just add new ones to be used in favor if necessary. If needed, deprecate and hide away old features (hide away the docs so that new people don't accidentally use it for new code), but never, ever remove it. If a new, better way to do something is discovered, add it to the language, highlight it front and center in the docs, but don't ever remove the old stuff. If we need to redesign Phobos, for example, do it in a new namespace, don't remove/replace the old one. Make it possible for the two to coexist. Accretion rather than replacement. OT1H the idealist in me screams "please break my code, fix the language to remove all the broken stuff!". OTOH the long-term code maintainer in me shakes his fists every time a compiler upgrade breaks one of my old projects. The solution to the conundrum is, accretion rather than replacement. Let the old code compile. Complain about deprecations if you have to, but don't ever make it not compile (unless it was an outright bug to have compiled in the first place). But new code can use the new stuff and benefit from it. T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Aug 10
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 10 August 2021 at 17:47:48 UTC, H. S. Teoh wrote:
 I think this is what Andrei has been saying every so often: 
 stop deleting, start adding.  I.e., never remove old features, 
 just add new ones to be used in favor if necessary.  If needed, 
 deprecate and hide away old features (hide away the docs so 
 that new people don't accidentally use it for new code), but 
 never, ever remove it. If a new, better way to do something is 
 discovered, add it to the language, highlight it front and 
 center in the docs, but don't ever remove the old stuff.  If we 
 need to redesign Phobos, for example, do it in a new namespace, 
 don't remove/replace the old one.  Make it possible for the two 
 to coexist.  Accretion rather than replacement.

 OT1H the idealist in me screams "please break my code, fix the 
 language to remove all the broken stuff!".  OTOH the long-term 
 code maintainer in me shakes his fists every time a compiler 
 upgrade breaks one of my old projects.

 The solution to the conundrum is, accretion rather than 
 replacement. Let the old code compile.  Complain about 
 deprecations if you have to, but don't ever make it not compile 
 (unless it was an outright bug to have compiled in the first 
 place).  But new code can use the new stuff and benefit from it.
Of course, the obvious counterargument is that this approach is exactly how you end up with a language like C++: powerful in the hands of experts, with a large and successful ecosystem, but packed to the gills with pitfalls and footguns for beginners to hurt themselves with. Ultimately, that's the question D's leadership has to answer. What's more important to D's future: existing users of D, or potential future users of D? C++ has a lot of inertia, and doesn't necessarily need to attract new users to continue being a successful language. But I'm not sure the same is true for D. If C++ holds onto legacy features that cause pain for beginners, people will grumble and put up with it, because C++ is so entrenched that they have no better option. If D does the same thing, people are more likely to just
Aug 10
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 10, 2021 at 06:46:57PM +0000, Paul Backus via Digitalmars-d wrote:
 On Tuesday, 10 August 2021 at 17:47:48 UTC, H. S. Teoh wrote:
[...]
 OT1H the idealist in me screams "please break my code, fix the
 language to remove all the broken stuff!".  OTOH the long-term code
 maintainer in me shakes his fists every time a compiler upgrade
 breaks one of my old projects.
 
 The solution to the conundrum is, accretion rather than replacement.
 Let the old code compile.  Complain about deprecations if you have
 to, but don't ever make it not compile (unless it was an outright
 bug to have compiled in the first place).  But new code can use the
 new stuff and benefit from it.
Of course, the obvious counterargument is that this approach is exactly how you end up with a language like C++: powerful in the hands of experts, with a large and successful ecosystem, but packed to the gills with pitfalls and footguns for beginners to hurt themselves with.
[...] Very true. Which is why one time I brought up this idea of embedding language version in source files. Perhaps right after the module declaration there could be an optional version declaration that states which language version the source file was written for: module mymodule; version = 2.097; ... If the version declaration is earlier than the current compiler version, it would enter compatibility mode in which it emulates the behaviour of a previous language version. But if the version declaration is up-to-date or omitted, the compiler would apply the latest version of the language, which may or may not break older features. That gives us a way to fix flaws in the language and reverse design decisions that were wrong in hindsight, yet without breaking old code. Newer code would then be encouraged to use the latest language version, that does not have the pitfalls of older language versions. Of course, in practice this will add a whole ton of extra work for the compiler devs, especially once the number of supported language versions increases. And it's not clear what to do if an older language construct has to interact with a newer, incompatible language feature. So I'm not sure how practical this will be. But if we could somehow pull it off, then we could *both* evolve the language and retain backward compatibility at the same time. T -- Fact is stranger than fiction.
Aug 10
parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Tuesday, 10 August 2021 at 19:18:47 UTC, H. S. Teoh wrote:
 Of course, in practice this will add a whole ton of extra work 
 for the compiler devs, especially once the number of supported 
 language versions increases.  And it's not clear what to do if 
 an older language construct has to interact with a newer, 
 incompatible language feature.  So I'm not sure how practical 
 this will be.  But if we could somehow pull it off, then we 
 could *both* evolve the language and retain backward 
 compatibility at the same time.


 T
Better in this case to have semi or full code migrator, that will automatically upgrade source code to latest version of d compiler. Then you won't require any extensive support of older versions of language, in the compiler itself.
Aug 10
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 10, 2021 at 07:23:52PM +0000, Alexandru Ermicioi via Digitalmars-d
wrote:
 On Tuesday, 10 August 2021 at 19:18:47 UTC, H. S. Teoh wrote:
 Of course, in practice this will add a whole ton of extra work for
 the compiler devs, especially once the number of supported language
 versions increases.  And it's not clear what to do if an older
 language construct has to interact with a newer, incompatible
 language feature.  So I'm not sure how practical this will be.  But
 if we could somehow pull it off, then we could *both* evolve the
 language and retain backward compatibility at the same time.
[...]
 Better in this case to have semi or full code migrator, that will
 automatically upgrade source code to latest version of d compiler.
 Then you won't require any extensive support of older versions of
 language, in the compiler itself.
This has been brought up many times, but I still see no actual progress in this area. We really need to make dfix a part of the official compiler default installation so that it's officially supported, and not merely an afterthought. Or even better yet, make it a part of the compiler (or at least auto-spawned by the compiler, the same way the linker is). The less external tools the user needs to manually invoke to make the upgrade happen, the better. In the ideal scenario, the act of running the compiler would auto-upgrade the source code in-place, and compile that instead of the original code. Of course, this may be too intrusive, so maybe hide it behind a compiler switch? When the switch is specified the compiler invokes dfix on the user's behalf, replaces the input file(s) with the upgraded versions, and compiles them, all in one go. Imagine how much better it is, if we could just: dmd -i -auto-upgrade my_project/*.d -of=profit ./profit and have everything Just Work(tm), rather than having to: dfix T -- Amateurs built the Ark; professionals built the Titanic.
Aug 10
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 10 August 2021 at 06:23:39 UTC, Paulo Pinto wrote:
 I love how people love to hate Java, yet have no words of hate 

 (check methods from typeof(func)), Dart.
In this case, Java was already raised as an example, so it was easiest to talk about it when criticizing the dogmatism about OO. restrictive as Java, because at least it has user-defined value types and operator overloading. I'll grant that this is probably not because Java would trust the quess I dislike scarce-featured languages in general - I'm not very tempted by Go either, not that I have tried. C is kind of fun to play with because of the low-level tricks, but I don't consider it a good general-purpose language either.
 How has D's multiparadigm helped to have a better marketshare 
 than some of those extremist OOP languages?
I don't think I have to explain the bandwagon fallacy for you, so I'm assuming you mean "How has D's multiparadigm helped to have a better marketshare than if it had an extremist attitude towards OOP?". Consider a simple bug report (https://issues.dlang.org/show_bug.cgi?id=22151) example I submitted recently. ```d void main() { *&main = *&main; } ``` have to be something like ```d struct S { static freeFun() { *&freeFun = *&freeFun; } } ``` Note that the comparison is fair - I'm still taking advantage of D's expressive power in the second example, by dropping the unnecessary `void` and visibility attribute. If every single small code snippet (or utility module) has to contain an enclosing `struct`, `class` or `union`, that totals to a HUGE readability price. Yes, allowing free functions does complicate modules, and includes the need for function hijack protection. But that pays back in a big way when it comes to readability. Also remember that you cannot have UFCS without free functions, `static` member functions. And frankly, that solution has NO upsides whatsoever compared to D. The programmer still needs to define the needless `class`, and language designers need to think about the module system and hijack protection just as hard as with free functions.
Aug 10
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Tuesday, 10 August 2021 at 06:23:39 UTC, Paulo Pinto wrote:

 I love how people love to hate Java, yet have no words of hate 

 (check methods from typeof(func)), Dart.

 How has D's multiparadigm helped to have a better marketshare 
 than some of those extremist OOP languages?
I think in both cases a better comparison is Scala, since it's so close to Java. Martin Odersky cleaned up the OOP and made it multiparadigm (with functional programming) and a lot of people liked it. Since it's a programming language, people do complain about Scala, but they complain about other things. The features that stand out about Java are the boilerplate and the lack of expressiveness, and in my opinion, those criticisms are correct. In one sense, the Java language designers agree, since they've copied so much from languages like Scala.
Aug 10
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 10, 2021 at 06:23:39AM +0000, Paulo Pinto via Digitalmars-d wrote:
 On Monday, 9 August 2021 at 23:09:30 UTC, H. S. Teoh wrote:
 ...
 No offense taken.  I just find the OO extremism of Java to be
 laughable, that's all.  Why not just admit that OO isn't the be-all
 and end-all of programming, and call free global functions what they
 are.
 
 This is why D's multi-paradigm approach makes so much more sense:
 sometimes one paradigm doesn't fit the problem, why not acknowledge
 it and allow a different paradigm to step in.  Not every problem is
 a nail to which the OO hammer must be brought to bear.
[...]
 I love how people love to hate Java, yet have no words of hate against

 from typeof(func)), Dart.
Whoa, slow down right there. My rant was against shoehorning every programming problem into a single paradigm, not against OOP itself. OOP certainly has its uses -- that's why D has it too! The problem comes when OOP zealots try to shove it down everyone's throats even when the problem at hand clearly does not fit the glove. I picked Java because that's the language I am most familiar with that exhibits this syndrome. I don't know enough (well, any) Smalltalk or Eiffel to be able to criticize them coherently, and I have not written a written in very small scales, and it does have some nice things about it. But I've not written enough non-trivial Python code to be able to criticize it effectively. But the point is that single-paradigm languages ultimately suffer from the shoehorn program: trying to shoehorn every programming problem into a single mold, even when it doesn't really fit. Certain algorithms are simply better expressed as an imperative loop that mutate variables; it's a royal pain in the neck to try to write the equivalent of such code in Lisp, for example. It's certainly *possible*, thanks to Turing completeness, but exhibits all the symptoms of dressing up a duck as an aquatic chicken with webbed feet: it's awkward, requires excessive paraphrases, and more complex than it really needs to be. The same can be said about writing range-based code in a language like C: you can do it, but it's awkward, error-prone, and just plain ugly. In a multi-paradigm language, you can choose the best paradigm to express the algorithm at hand, in the most convenient, clear way, without having to resort to the shoe-horn. It's faster to write, easier to read, and more maintainable in the long run. You can treat a duck as a duck instead of an aquatic chicken with webbed feet. It's so refreshing not to have to paraphrase yourself all the time.
 How has D's multiparadigm helped to have a better marketshare than
 some of those extremist OOP languages?
I don't understand where marketshare enters the equation. We're talking about how well a language fits a problem domain, not about the fashion contest that is today's programming language "market". (And incidentally, which language is most popular has very little to do with its technical merit, it is primarily determined by how much marketing capital it has and how well the marketing department sells it. With a large-enough marketing budget and a spark of marketing genius, you can sell *anything* to anyone. I have no interest in what's popular and what's not; what I look for is technical excellence, which is the true value.) T -- Дерево держится корнями, а человек - друзьями.
Aug 10
prev sibling next sibling parent reply Brian Tiffin <btiffin gnu.org> writes:
On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 ...
 Language designers seem to have a big brother attitude towards 
 programmers and think they will save the world by introducing 
 limitations.

 Examples.
 ...
 2.
 Somewhat related. when Java was designed, the designer (James 
 Gosling I believe) claimed that programmers were too stupid to 
 understand the difference between signed and unsigned math 
 (despite often several years of university education) and 
 removed signed math entirely from the language. The impact is 
 that when unsigned math is required, you are forced to 
 conversions and library solutions. Not ideal when an HW APIs 
 deals with unsigned numbers for example.

 You are welcome to add any other examples that you find 
 significant for the discussion.


 This partially applies to D in some extent but can often be 
 found in other languages and mentality of several language 
 designers.

 The question is, do you think language designers go to far when 
 trying to "save" programmers from misuse or not?
 Do you think there can be approaches that both prevent bugs at 
 the same time do not limit the language?
Just to point out that using Java as a sample seems a bit off. Java (well, the JVM) is the ultimate in restrictive. It's a compiler that doesn't emit CPU code, but safe(r) emulation in a sandbox. Java stormed the Enterprise world because Business managers wanted safer code, and are willing to slow everything down for an extra margin of safety. The JVM was not accepted en masse because bosses didn't trust users, but because they didn't trust the programmers. It kept those pesky cubicle workers one level away from **their** hardware. They were promised less show-stopping mistakes while still allowing the hiring of all the coders they need to help automate everyone else out of work. That James and the other Java designers decided to lessen signed/unsigned transition errors by simply removing unsigned, is just par for the JVM course. Walter seems to be trying to lead D development down paths he sees as smarter, and wiser in the large. I don't get the sense that D is being designed for stupid programmers, or limited because of stupid. At least nowhere near the same league as with the JVM decisions *which was purposely built because non-technical people don't trust programmers (lacking the skills to quickly determine if one is foolish or wise, but still want to hire them all while pursuing business goals)*. Just about everyone thinks they are a good driver, or they wouldn't drive. But seat belts still save a lot of lives. *Would probably save even more, if we didn't all drive that little bit faster feeling safer behind a seat belt, in cars now designed to crumple more for less crumpling of passengers*. They don't install guard rails on highways because *everyone* misses the turn, but some few might on a bad day, so there is a guard rail to limit the damage. I've always viewed the JVM as programming in bumper cars. There is a lot of fun to be had in bumper cars. You can learn a lot about yourself and others. Business leaders, particularly the non-technical, seem to agree. I'm still new to D, but see it's present and future as an easy to read and write *feels safer, is safer* programming environment, at speed, en masse. Have good, make well.
Aug 08
parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 8 August 2021 at 18:26:10 UTC, Brian Tiffin wrote:
 On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 ...
 Language designers seem to have a big brother attitude towards 
 programmers and think they will save the world by introducing 
 limitations.

 Examples.
 ...
 2.
 Somewhat related. when Java was designed, the designer (James 
 Gosling I believe) claimed that programmers were too stupid to 
 understand the difference between signed and unsigned math 
 (despite often several years of university education) and 
 removed signed math entirely from the language. The impact is 
 that when unsigned math is required, you are forced to 
 conversions and library solutions. Not ideal when an HW APIs 
 deals with unsigned numbers for example.

 You are welcome to add any other examples that you find 
 significant for the discussion.


 This partially applies to D in some extent but can often be 
 found in other languages and mentality of several language 
 designers.

 The question is, do you think language designers go to far 
 when trying to "save" programmers from misuse or not?
 Do you think there can be approaches that both prevent bugs at 
 the same time do not limit the language?
Just to point out that using Java as a sample seems a bit off. Java (well, the JVM) is the ultimate in restrictive. It's a compiler that doesn't emit CPU code, but safe(r) emulation in a sandbox. ....
If you are talking about Java 1.0 - 1.2, yeah. Since around 2000, AOT compilation has always been a capability in commercial JDKs like Excelsior JET, IBM RealTime WebSphere, Aonix, even GCC had GCJ until 2009. Nowadays PTC, Jamaica are still around, GraalVM exists, while the JIT cache from JRockit has been made part of OpenJDK, and IBM RealTime WebSphere are now part of IBM OpenJ9.
Aug 08
prev sibling next sibling parent reply cy <dlang verge.info.tm> writes:
On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 Array indexes should be signed instead of unsigned because 
 somehow programmers mess up loops among other things.
This bugs me to no end. It is not hard to understand the concept of `idx < size()` and anyone using `idx < size() - 1` should take a remedial course in basic Algebra, rather than fixing my language by not allowing me to say unsigned things. It's just not hard to remember to always use "less than" and "size" in your for loops. Reverse for loops are really the only exception, and that's just 1 more thing to remember `for(top=size(), top > 0; --top) { auto idx = top - 1; ... }` repeat for every program ever exactly the same way. I can accept a language that doesn't let me use unsigned arithmetic though, even if I grumble about it. I do approve of stuff that limits subtle errors in rarely encountered, esoteric situations, like how you can't have a multi-byte character inside a 1 byte literal. What really is a bad idea is stupid, fake encapsulation, that doesn't encapsulate anything and is just encouraging programmers to make things hard for other programmers purely for ego stroking, with no savings in complexity. So basically I think the `private:` keyword needs to go die in a fire.
 The question is, do you think language designers go to far when 
 trying to "save" programmers from misuse or not?
I believe the technical term these days for when language designers go too far trying to save programmers from misuse is "rust."
Aug 08
parent cy <dlang verge.info.tm> writes:
On Monday, 9 August 2021 at 01:37:09 UTC, cy wrote:
 `for(top=size(), top > 0; --top) { auto idx = top - 1; ... }`
Oh, and I really appreciate languages that don't allow me to use for loops with a single semicolon, refusing to assume that I meant to type a comma there.
Aug 08
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:

 Somewhat related. when Java was designed, the designer (James 
 Gosling I believe) claimed that programmers were too stupid to 
 understand the difference between signed and unsigned math 
 (despite often several years of university education) and 
 removed signed math entirely from the language. The impact is 
 that when unsigned math is required, you are forced to 
 conversions and library solutions. Not ideal when an HW APIs 
 deals with unsigned numbers for example.
Programmers are humans that write programs. I've surely written more than a million lines of code in my life (who knows how much, but that's definitely a lower bound) and I did not study unsigned math in college. I took one programming class and I've done a lot of independent study. Maybe I could figure out how to work with unsigned math, but why would I want to? I have better things to do with my time. But set all that aside. Anyone that's taught a university class will agree that you can't assume someone understands something just because they attended a lecture and took a test over it. I don't necessarily disagree that there are *some* cases of overly restrictive language design. I didn't last very long with Go for that reason. I just think unsigned math is not the best example. Switching to safe by default would be a better example.
Aug 09
next sibling parent reply Mark <mt.rzezniczak gmail.com> writes:
On Monday, 9 August 2021 at 15:15:53 UTC, bachmeier wrote:
 On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:

 Somewhat related. when Java was designed, the designer (James 
 Gosling I believe) claimed that programmers were too stupid to 
 understand the difference between signed and unsigned math 
 (despite often several years of university education) and 
 removed signed math entirely from the language. The impact is 
 that when unsigned math is required, you are forced to 
 conversions and library solutions. Not ideal when an HW APIs 
 deals with unsigned numbers for example.
Programmers are humans that write programs. I've surely written more than a million lines of code in my life (who knows how much, but that's definitely a lower bound) and I did not study unsigned math in college. I took one programming class and I've done a lot of independent study. Maybe I could figure out how to work with unsigned math, but why would I want to? I have better things to do with my time. But set all that aside. Anyone that's taught a university class will agree that you can't assume someone understands something just because they attended a lecture and took a test over it. I don't necessarily disagree that there are *some* cases of overly restrictive language design. I didn't last very long with Go for that reason. I just think unsigned math is not the best example. Switching to safe by default would be a better example.
Isn't unsigned math exist because we are limited in how many bits the number can hold? There's no concept of signed/unsigned for float/double/real. Which one is simpler that would introduce less complexity for the programmer writing code?
Aug 09
next sibling parent bachmeier <no spam.net> writes:
On Monday, 9 August 2021 at 16:14:49 UTC, Mark wrote:

 Isn't unsigned math exist because we are limited in how many 
 bits the number can hold? There's no concept of signed/unsigned 
 for float/double/real. Which one is simpler that would 
 introduce less complexity for the programmer writing code?
I'm definitely not qualified to answer such questions, but I can say I hate unsigned integers with a passion. See for instance https://forum.dlang.org/post/rdrqedmbknwrppbfixll forum.dlang.org
Aug 09
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 09, 2021 at 04:14:49PM +0000, Mark via Digitalmars-d wrote:
[...]
 Isn't unsigned math exist because we are limited in how many bits the
 number can hold? There's no concept of signed/unsigned for
 float/double/real. Which one is simpler that would introduce less
 complexity for the programmer writing code?
Floating-point, if anything, is *more* complex and comes with more pitfalls than signed/unsigned mistakes. Worse yet, it *appears* to behave like what most people imagine real numbers to behave, but in fact doesn't, which makes mistakes more likely, and also harder to catch because they usually only crop up in special corner cases while generally appearing to work correctly. Cf.: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html At the end of the day, it boils down to: you have to learn how your programming language and its types work. If you imagine you can just cowboy your way through programming without fully understanding what you're doing, you only have yourself to blame when the results are disappointing. As Walter once said: I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright T -- Windows 95 was a joke, and Windows 98 was the punchline.
Aug 09
parent reply bachmeier <no spam.net> writes:
On Monday, 9 August 2021 at 17:03:57 UTC, H. S. Teoh wrote:

 Floating-point, if anything, is *more* complex and comes with 
 more pitfalls than signed/unsigned mistakes. Worse yet, it 
 *appears* to behave like what most people imagine real numbers 
 to behave, but in fact doesn't, which makes mistakes more 
 likely, and also harder to catch because they usually only crop 
 up in special corner cases while generally appearing to work 
 correctly.
There's an important difference though. Signed/unsigned mistakes are a choice the programming language designer makes - Walter made his choice and Gosling made a different choice. You're more or less stuck with the limitations of floating point.
Aug 09
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 09, 2021 at 07:01:18PM +0000, bachmeier via Digitalmars-d wrote:
 On Monday, 9 August 2021 at 17:03:57 UTC, H. S. Teoh wrote:
 
 Floating-point, if anything, is *more* complex and comes with more
 pitfalls than signed/unsigned mistakes.
[...]
 There's an important difference though. Signed/unsigned mistakes are a
 choice the programming language designer makes - Walter made his
 choice and Gosling made a different choice. You're more or less stuck
 with the limitations of floating point.
Thing is, Java can (somewhat) get away with it because it's designed to run in an idealized VM environment, abstracted away from the ugly details of the underlying hardware. But D is a systems programming language, so it should not hide the ugly realities of the hardware that it runs on. By using a systems programming language you kinda signed up for this, in a sense. As Knuth once said: People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth That includes knowing the ugly realities of 2's complement arithmetic. T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
Aug 09
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 9 August 2021 at 19:23:14 UTC, H. S. Teoh wrote:
 As Knuth once said:

 	People who are more than casually interested in computers 
 should
 	have at least some idea of what the underlying hardware is 
 like.
 	Otherwise the programs they write will be pretty weird.
 	-- D. Knuth

 That includes knowing the ugly realities of 2's complement 
 arithmetic.
The way I remember it, 2's complement notation is a method of encoding signed integers as unsigned integers such that a CPU can use the same instructions and circuits for both signed and unsigned arithmetic. So, from the hardware's point of view, unsigned arithmetic is the pure, simple version, and signed arithmetic is the ugly, complex version. :)
Aug 09
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 09, 2021 at 08:18:26PM +0000, Paul Backus via Digitalmars-d wrote:
 On Monday, 9 August 2021 at 19:23:14 UTC, H. S. Teoh wrote:
 As Knuth once said:
 
 	People who are more than casually interested in computers should
 	have at least some idea of what the underlying hardware is like.
 	Otherwise the programs they write will be pretty weird.
 	-- D. Knuth
 
 That includes knowing the ugly realities of 2's complement
 arithmetic.
The way I remember it, 2's complement notation is a method of encoding signed integers as unsigned integers such that a CPU can use the same instructions and circuits for both signed and unsigned arithmetic. So, from the hardware's point of view, unsigned arithmetic is the pure, simple version, and signed arithmetic is the ugly, complex version. :)
Indeed! If you look at the assembly level, unsigned arithmetic is the one with straightforward instructions mapping 1-to-1 with arithmetic operations, whereas signed arithmetic is the one that involves carry bits and other such additional complications. T -- Heads I win, tails you lose.
Aug 09
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 9 August 2021 at 21:05:05 UTC, H. S. Teoh wrote:
 Indeed!  If you look at the assembly level, unsigned arithmetic 
 is the one with straightforward instructions mapping 1-to-1 
 with arithmetic operations, whereas signed arithmetic is the 
 one that involves carry bits and other such additional 
 complications.
They're literally identical for most operations; you can use the very same instructions and the only difference is how you interpret the data. In x86 they set both carry and overflow flags so you can decide which one you care about.
Aug 09
parent reply claptrap <clap trap.com> writes:
On Monday, 9 August 2021 at 22:01:33 UTC, Adam D Ruppe wrote:
 On Monday, 9 August 2021 at 21:05:05 UTC, H. S. Teoh wrote:
 Indeed!  If you look at the assembly level, unsigned 
 arithmetic is the one with straightforward instructions 
 mapping 1-to-1 with arithmetic operations, whereas signed 
 arithmetic is the one that involves carry bits and other such 
 additional complications.
They're literally identical for most operations; you can use the very same instructions and the only difference is how you interpret the data. In x86 they set both carry and overflow flags so you can decide which one you care about.
Since there's only ADD,SUB,MUL(IMUL),DIV(IDIV), it's about 50/50. Half the ops have only unsigned versions, half have signed and unsigned. IIRC the overflow flag is actually just for catching the error, not for actual arithmetic, since if you're doing signed multiword arithmetic you only use a signed word at the top. That's why there's ADC, SBB, but no equivalents for the overflow flag.
Aug 09
parent Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 9 August 2021 at 22:57:22 UTC, claptrap wrote:
 Since there's only ADD,SUB,MUL(IMUL),DIV(IDIV), it's about 
 50/50.
Well, mul is semi-agnostic. It only matters if you look at the high word (which is frequently discarded anyway) and I believe imul works either way. And there's also sar vs shr which are slightly different, while sal and shl are identical.
 IIRC the overflow flag is actually just for catching the error, 
 not for actual arithmetic, since if you're doing signed 
 multiword arithmetic you only use a signed word at the top.
aye.
Aug 09
prev sibling parent reply claptrap <clap trap.com> writes:
On Monday, 9 August 2021 at 21:05:05 UTC, H. S. Teoh wrote:
 On Mon, Aug 09, 2021 at 08:18:26PM +0000, Paul Backus via 
 Digitalmars-d wrote:
 On Monday, 9 August 2021 at 19:23:14 UTC, H. S. Teoh wrote:
 As Knuth once said:
 
 	People who are more than casually interested in computers 
 should
 	have at least some idea of what the underlying hardware is 
 like.
 	Otherwise the programs they write will be pretty weird.
 	-- D. Knuth
 
 That includes knowing the ugly realities of 2's complement 
 arithmetic.
The way I remember it, 2's complement notation is a method of encoding signed integers as unsigned integers such that a CPU can use the same instructions and circuits for both signed and unsigned arithmetic. So, from the hardware's point of view, unsigned arithmetic is the pure, simple version, and signed arithmetic is the ugly, complex version. :)
Indeed! If you look at the assembly level, unsigned arithmetic is the one with straightforward instructions mapping 1-to-1 with arithmetic operations, whereas signed arithmetic is the one that involves carry bits and other such additional complications.
The carry bit is for unsigned arithmetic, it's the overflow flag that is for signed arithmetic. On a 32 bit system carry indicates that bit 31 has overflowed into bit 32, and overflow indicates bit 30 has overflowed into bit 31. They are mainly for multiword arithmetic. And whats probably not obvious is that you need unsigned arithmetic to do multiword signed arithmetic, you only use signed arithmetic for the top most word.
Aug 09
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 09, 2021 at 10:49:13PM +0000, claptrap via Digitalmars-d wrote:
[...]
 And whats probably not obvious is that you need unsigned arithmetic to
 do multiword signed arithmetic, you only use signed arithmetic for the
 top most word.
Exactly!! This is why unsigned arithmetic is more basic and fundamental than signed arithmetic. The latter is built from the former, not the former from the latter. T -- "You know, maybe we don't *need* enemies." "Yeah, best friends are about all I can take." -- Calvin & Hobbes
Aug 09
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/9/2021 12:23 PM, H. S. Teoh wrote:
 As Knuth once said:
 
 	People who are more than casually interested in computers should
 	have at least some idea of what the underlying hardware is like.
 	Otherwise the programs they write will be pretty weird.
 	-- D. Knuth
 
 That includes knowing the ugly realities of 2's complement arithmetic.
A friend mine (a very smart one) back in college one day decided to learn programming. He got the Fortran specification(!), read it, and wrote a program. The program ran correctly, but incredibly slowly. Baffled, he took it to his programmer friend for help. The friend laughed, and said here's the problem: you're writing to a file in a loop: loop open the file append a character close the file instead of: open the file loop append character close the file My friend said he followed the spec, which said nothing at all about how file I/O actually worked.
Aug 10
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 10, 2021 at 11:29:35AM -0700, Walter Bright via Digitalmars-d wrote:
[...]
 A friend mine (a very smart one) back in college one day decided to
 learn programming. He got the Fortran specification(!), read it, and
 wrote a program.
Hey, what better way to learn a language than to get to the very definition of it? ;-)
 The program ran correctly, but incredibly slowly. Baffled, he took it
 to his programmer friend for help. The friend laughed, and said here's
 the problem: you're writing to a file in a loop:
 
     loop
         open the file
         append a character
         close the file
 
 instead of:
 
    open the file
    loop
       append character
    close the file
 
 My friend said he followed the spec, which said nothing at all about
 how file I/O actually worked.
:-D What the spec *doesn't* say is often just as important as, if not more important than, what it does say. :-) Reminds me of learning a foreign language by reading a dictionary... you can learn all the words, and even consult a book on grammar, but will it survive the first encounter with a native speaker? ;-) True story: one time, I found a particular foreign word from a dictionary, and thought that was how you referred to a particular thing. So I used that word with a native speaker. He stared at me for a moment with this strange look of incomprehension, and then suddenly comprehension gleamed in his eyes, and with a smile he explained that this was an archaic word that is no longer in widespread use, and that people these days use a different word for the same thing. He further added that if I were to use that word with somebody younger than him, they probably wouldn't even understand what it meant. Such is the peril of learning a language by spec without understanding the context in which it operates. :-) T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Aug 10
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/9/2021 12:01 PM, bachmeier wrote:
 There's an important difference though. Signed/unsigned mistakes are a choice 
 the programming language designer makes - Walter made his choice and Gosling 
 made a different choice. You're more or less stuck with the limitations of 
 floating point.
The thing about two's complement arithmetic, and IEEE floating point, is their faults are very well known. You can move your understanding of them from one language to the next. It's worthwhile to invest a few minutes learning about them if you're going to spend your career programming. Just like it's worthwhile learning about how tire adhesion works when looking forward to a decades of driving. (It can save your life.)
Aug 10
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/9/2021 8:15 AM, bachmeier wrote:
 I did not study unsigned math in college.
There are no classes in unsigned math.
 I took one 
 programming class and I've done a lot of independent study. Maybe I could
figure 
 out how to work with unsigned math, but why would I want to? I have better 
 things to do with my time.
It's worth spending 5 minutes to learn what 2's complement arithmetic is. https://en.wikipedia.org/wiki/Two%27s_complement#:~:text=Two's%20complement%20is%20a%20mathematical,two's%20complement%20is%202N.
Aug 10
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 10 August 2021 at 17:47:46 UTC, Walter Bright wrote:
 On 8/9/2021 8:15 AM, bachmeier wrote:
 I did not study unsigned math in college.
There are no classes in unsigned math.
Primary school is where unsigned arithmetic is tought. :-)
Aug 10
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 10 August 2021 at 21:51:51 UTC, Patrick Schluter 
wrote:
 On Tuesday, 10 August 2021 at 17:47:46 UTC, Walter Bright wrote:
 On 8/9/2021 8:15 AM, bachmeier wrote:
 I did not study unsigned math in college.
There are no classes in unsigned math.
Primary school is where unsigned arithmetic is tought. :-)
With unbound storage, base 10 and no wrapping.
Aug 10
prev sibling next sibling parent Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
On Tuesday, 10 August 2021 at 21:51:51 UTC, Patrick Schluter 
wrote:
 On Tuesday, 10 August 2021 at 17:47:46 UTC, Walter Bright wrote:
 On 8/9/2021 8:15 AM, bachmeier wrote:
 I did not study unsigned math in college.
There are no classes in unsigned math.
Primary school is where unsigned arithmetic is taught. :-)
No. There are classes in unsigned math - but very much later. They are called "Finite Fields Arithmetic" or even "binary polynomials over finite fields" and although it its not too complicated, it assumes a lot of base math knowledge to be understood well.
Aug 10
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 8/10/21 2:51 PM, Patrick Schluter wrote:

 Primary school is where unsigned arithmetic is tought. :-)
I was surprised at how quickly my son learned negative numbers at probably the age of 5 in less than 5 minutes. I am not exaggerating! I only said: "You know the numbers and you know zero... Well, actually there are the negative numbers on the other side too." (I used colored domino pieces to represent those three kinds.) That was it! :) I would show off to my friends by asking my son: -- "Let's say we are reading a book with copyright 2009. How old *were* you when that book was published?" After thinking 2 seconds: -- "Negative 4!" :) Ali
Aug 11
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/7/21 8:15 AM, IGotD- wrote:
 This is a general discussion which applies to all computer languages and 
 also under several decades. What I have observed is that language 
 designers see programmers misuse the language and introduce possible 
 bugs and therefore remove features in languages. An analogy would limit 
 the functionality of cars because people sometimes are involved in 
 accidents, like automatic speed limiter (soon to be law in several 
 countries).
 
 Language designers seem to have a big brother attitude towards 
 programmers and think they will save the world by introducing limitations.
 
 Examples.
 
 1.
 Array indexes should be signed instead of unsigned because somehow 
 programmers mess up loops among other things. Bjarne Stroustrup 
 considered his unsigned index to be a historic mistake. While unsigned 
 array indexes make perfectly sense, the bias towards signed seems to be 
 that programmers are stupid. The question is, if can't make a for loop 
 with unsigned math, shouldn't you look for another job?
If people who have made mistakes with unsigned math in loops were disqualified from programming, this place would be a ghost town. Also note that signed indexes are allowed (you can also use negative indexes)! It's the array LENGTH being unsigned which is a problem. Note also due to D promotion rules, using any unsigned values poisons all your other values to be unsigned (usually unexpectedly).
 2.
 Somewhat related. when Java was designed, the designer (James Gosling I 
 believe) claimed that programmers were too stupid to understand the 
 difference between signed and unsigned math (despite often several years 
 of university education) and removed signed math entirely from the 
 language. The impact is that when unsigned math is required, you are 
 forced to conversions and library solutions. Not ideal when an HW APIs 
 deals with unsigned numbers for example.
"too stupid" seems like an incorrect assessment. More like "too careless". Consider that it's not really unsigned math or signed math, but when you are doing math between signed and unsigned values, what should happen? That's where most people get into trouble. Note that signed math and unsigned math is identical, it's just most people aren't doing math around the value 2^31, but they do a lot around the value 0. I would love for D to use signed indexes for arrays, especially with 64-bit integers.
 The question is, do you think language designers go to far when trying 
 to "save" programmers from misuse or not?
 Do you think there can be approaches that both prevent bugs at the same 
 time do not limit the language?
Until the world of programming is ruled by perfect AI, please keep trying to fix my stupid human mistakes, thanks! However, I do know of cases that have gone too far. Like Swift eliminating for loops -- that one stung. -Steve
Aug 09
next sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 9 August 2021 at 16:27:28 UTC, Steven Schveighoffer 
wrote:
 However, I do know of cases that have gone too far. Like Swift 
 eliminating for loops -- that one stung.

 -Steve
Is this correct? for loops with classical C syntax are removed but you can still have for loops over ranges and the x...y syntax just makes an integer range of your liking. This is similar to foreach (i; 0 .. 3) in D. It's just a syntax change and bugs with ranges is probably just as easy as with the old C syntax.
Aug 09
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/9/21 1:14 PM, IGotD- wrote:
 On Monday, 9 August 2021 at 16:27:28 UTC, Steven Schveighoffer wrote:
 However, I do know of cases that have gone too far. Like Swift 
 eliminating for loops -- that one stung.
Is this correct?
Yes.
 for loops with classical C syntax are removed but you 
 can still have for loops over ranges and the x...y syntax just makes an 
 integer range of your liking. This is similar to foreach (i; 0 .. 3) in D.
There are more uses for traditional `for` loops than just looping over integers or ranges.
 
 It's just a syntax change and bugs with ranges is probably just as easy 
 as with the old C syntax.
The use case I had, I needed to rewrite into a sequence. Hm... Let me find the change: ```swift for var i = 0; (gridOrigin.x + CGFloat(i) * subGridSpacing.width) * scale < bounds.width; i += 1 { ... ``` I wrote a "for generator" sequence type that accepted a lambda for the condition. It now looks like: ```swift for i in forgen(0, condition: { (self.gridOrigin.x + CGFloat($0) * self.subGridSpacing.width) * self.scale < self.bounds.width }){ ... ``` This is just a hack, and not a full replacement. It takes an initial value and an increment (by default 1), and only works with Int. Honestly, it was a long time ago (heck, they probably removed more features and this won't compile now). There might be better ways. And I probably would have been fine with swift never having for loops. But to start out with them, and then remove them, seemed unnecessary. -Steve
Aug 09
prev sibling parent Yatheendra <gmail yath.com> writes:
 most people aren't doing math around the value 2^31, but they 
 do a lot around the value 0
Very true. I have shifted from looping 'N-1 to 0' to looping 'N to 1', naming the loop variable ith and not i, making 0 a natural sentinel value for ith in C-style (ith = N; ith > 0; --ith). The above is part of a late realization for me, as to how under-used and mis-used naming conventions are in programming. I appreciate "object-oriented style" C even more now for this reason (bespoke code in commercial settings, I wouldn't know about glib/gtk). Maybe -betterC with template support suffices for most programming use-cases (and we should be using dynamically typed languages for everything else).
Aug 25
prev sibling next sibling parent tausy <tausy protonmail.com> writes:
On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 This is a general discussion which applies to all computer 
 languages and also under several decades. What I have observed 
 is that language designers see programmers misuse the language 
 and introduce possible bugs and therefore remove features in 
 languages. An analogy would limit the functionality of cars 
 because people sometimes are involved in accidents, like 
 automatic speed limiter (soon to be law in several countries).

 Language designers seem to have a big brother attitude towards 
 programmers and think they will save the world by introducing 
 limitations.

 Examples.

 1.
 Array indexes should be signed instead of unsigned because 
 somehow programmers mess up loops among other things. Bjarne 
 Stroustrup considered his unsigned index to be a historic 
 mistake. While unsigned array indexes make perfectly sense, the 
 bias towards signed seems to be that programmers are stupid. 
 The question is, if can't make a for loop with unsigned math, 
 shouldn't you look for another job?

 2.
 Somewhat related. when Java was designed, the designer (James 
 Gosling I believe) claimed that programmers were too stupid to 
 understand the difference between signed and unsigned math 
 (despite often several years of university education) and 
 removed signed math entirely from the language. The impact is 
 that when unsigned math is required, you are forced to 
 conversions and library solutions. Not ideal when an HW APIs 
 deals with unsigned numbers for example.

 You are welcome to add any other examples that you find 
 significant for the discussion.


 This partially applies to D in some extent but can often be 
 found in other languages and mentality of several language 
 designers.

 The question is, do you think language designers go to far when 
 trying to "save" programmers from misuse or not?
 Do you think there can be approaches that both prevent bugs at 
 the same time do not limit the language?
If there wasn't a need for safe and restrictive languages they probably wouldn't exist. I'd say like most things in this world the drive to make languages safe and easy is money. https://money.cnn.com/2012/08/09/technology/knight-expensive-computer-bug/index.html People make mistakes, even the smartest "college/university educated" people. As well, if I want to start a business and I don't need to use a systems language like C that would be nice. I'm sure it's cheaper for a startup to hire python developers to write a backend than it would be to hire C/C++ developers to do the same thing. Another reason, even more important than the first, would be that bugs can and have killed people. https://theinsurancenerd.com/therac-25-a-computer-bug-that-killed-many/ https://www.linkedin.com/pulse/real-world-bugs-debugging-embedded-system-stanly-christoper I'd can probably say with certainty that the people working on these systems were intelligent, had a CS degree and they weren't to me, seem overly restrictive but the fact is I don't have to use or learn them. Imagine how restrictive a language that has mathematical proof that it's type safe, memory safe, runtime exception safe, data-race free and dead-lock free. Take a look at Pony. Too much for me, I'll pass. My point is that it's not that programmers are stupid it's just about safety.
Aug 09
prev sibling parent reply surlymoor <surlymoor cock.li> writes:
On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 [...]
Those examples don't feel all that insulting; then again, I am a stupid programmer. However, something that would sting is being deprived of generics because the Elder Gods deemed them too confusing.
Aug 10
parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 10 August 2021 at 08:22:04 UTC, surlymoor wrote:
 On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:
 [...]
Those examples don't feel all that insulting; then again, I am a stupid programmer. However, something that would sting is being deprived of generics because the Elder Gods deemed them too confusing.
Indeed, however after years of gatherings at the Eldery Mountains, a new revelation on the Book of Wisdom has been made visible on the Old World, an event that is deemed to happen every few centuries, upon which the Elder Gods have summoned the runes of generics, and great rejoice has spread throughout the land with festivities across all villages. https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md https://go2goplay.golang.org/
Aug 10