* Fun with C @ 2011-04-16 17:02 George P. 2011-04-16 20:04 ` Nasser M. Abbasi ` (3 more replies) 0 siblings, 4 replies; 124+ messages in thread From: George P. @ 2011-04-16 17:02 UTC (permalink / raw) Spend few days chasing bug in embedded C project which can drilled down to this. Consider the following program, and all reasonable men will expect the result to be negative. Not in C, and it is not a compiler bug :-( And offcorse none of the three comilers I cheched did not bother to issue a warning at least.. #include <stdio.h> int main() { unsigned n = 128; int i = -2048; int r; r = i / n; printf("R = %d\n", r); return 0; } ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 17:02 Fun with C George P. @ 2011-04-16 20:04 ` Nasser M. Abbasi 2011-04-16 21:12 ` Ludovic Brenta 2011-04-16 22:03 ` George P. 2011-04-17 6:26 ` KK6GM ` (2 subsequent siblings) 3 siblings, 2 replies; 124+ messages in thread From: Nasser M. Abbasi @ 2011-04-16 20:04 UTC (permalink / raw) On 4/16/2011 10:02 AM, George P. wrote: > Spend few days chasing bug in embedded C project which can drilled > down to this. Consider the following program, and all reasonable men > will expect the result to be negative. Not in C, and it is not a > compiler bug :-( > > And offcorse none of the three comilers I cheched did not bother to > issue a warning at least.. > > #include<stdio.h> > > int main() > { > unsigned n = 128; > int i = -2048; > int r; > > r = i / n; > > printf("R = %d\n", r); > > return 0; > } $ gcc -Wall t.c $ ./a.out R = 33554416 That is why we all love C. Best Job security in the world for programmers. There are always "issues" to fix. You see, you yourself had to work for few days on this one. If you had used Ada, or any other more strongly typed languages, then you'll be done early, then the manager will have come in and saw you sitting doing nothing becuase your program is done, and you'll be out of work. So, you should be very happy you are working on C. --Nasser ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 20:04 ` Nasser M. Abbasi @ 2011-04-16 21:12 ` Ludovic Brenta 2011-04-16 21:42 ` jimmaureenrogers ` (3 more replies) 2011-04-16 22:03 ` George P. 1 sibling, 4 replies; 124+ messages in thread From: Ludovic Brenta @ 2011-04-16 21:12 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > On 4/16/2011 10:02 AM, George P. wrote: >> Spend few days chasing bug in embedded C project which can drilled >> down to this. Consider the following program, and all reasonable men >> will expect the result to be negative. Not in C, and it is not a >> compiler bug :-( >> >> And offcorse none of the three comilers I cheched did not bother to >> issue a warning at least.. >> >> #include<stdio.h> >> >> int main() >> { >> unsigned n = 128; >> int i = -2048; >> int r; >> >> r = i / n; >> >> printf("R = %d\n", r); >> >> return 0; >> } > > > $ gcc -Wall t.c > $ ./a.out > R = 33554416 So R = 2**25 - 16, the correct answer is -16, so the actual result is the correct one except for bit 24, which is 1 when it should be zero. Out of curiosity, is this actual result a predictable consequence of the language definition, or is it undefined behavior? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 21:12 ` Ludovic Brenta @ 2011-04-16 21:42 ` jimmaureenrogers 2011-04-17 7:17 ` Georg Bauhaus ` (2 subsequent siblings) 3 siblings, 0 replies; 124+ messages in thread From: jimmaureenrogers @ 2011-04-16 21:42 UTC (permalink / raw) On Apr 16, 3:12 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > "Nasser M. Abbasi" <n...@12000.org> writes: > > > > > > > On 4/16/2011 10:02 AM, George P. wrote: > >> Spend few days chasing bug in embedded C project which can drilled > >> down to this. Consider the following program, and all reasonable men > >> will expect the result to be negative. Not in C, and it is not a > >> compiler bug :-( > > >> And offcorse none of the three comilers I cheched did not bother to > >> issue a warning at least.. > > >> #include<stdio.h> > > >> int main() > >> { > >> unsigned n = 128; > >> int i = -2048; > >> int r; > > >> r = i / n; > > >> printf("R = %d\n", r); > > >> return 0; > >> } > > > $ gcc -Wall t.c > > $ ./a.out > > R = 33554416 > > So R = 2**25 - 16, the correct answer is -16, so the actual result is > the correct one except for bit 24, which is 1 when it should be zero. > > Out of curiosity, is this actual result a predictable consequence of the > language definition, or is it undefined behavior? > > -- > Ludovic Brenta.- Hide quoted text - > > - Show quoted text - This is actually predictable. The C compiler implicitly converted the negative value to an unsigned representation of the same bit pattern. The division was performed on that converted value. Note that this wonderful behavior is also expected using C++, because of its compatibility with C. Jim Rogers ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 21:12 ` Ludovic Brenta 2011-04-16 21:42 ` jimmaureenrogers @ 2011-04-17 7:17 ` Georg Bauhaus 2011-04-17 8:29 ` Martin 2011-04-17 18:19 ` George P. 2011-04-17 8:40 ` Georg Bauhaus 2011-04-18 1:04 ` Peter C. Chapin 3 siblings, 2 replies; 124+ messages in thread From: Georg Bauhaus @ 2011-04-17 7:17 UTC (permalink / raw) On 4/16/11 11:12 PM, Ludovic Brenta wrote: > "Nasser M. Abbasi"<nma@12000.org> writes: >> $ gcc -Wall t.c >> $ ./a.out >> R = 33554416 > > So R = 2**25 - 16, the correct answer is -16, so the actual result is > the correct one except for bit 24, which is 1 when it should be zero. > > Out of curiosity, is this actual result a predictable consequence of the > language definition, or is it undefined behavior? Why, it is the same in Ada. with Ada.Text_IO; use Ada.Text_IO; with Ada.Unchecked_Conversion; procedure Conv is type UInt is mod 2**32; type Int is range -2**31 .. 2**31 -1; function To_UInt is new Ada.Unchecked_Conversion(Int, UInt); N: UInt := 128; I: Int := -2048; R : Int; begin R := Int(To_UInt(I) / N); Put_Line ("R =" & Int'Image(R)); end; ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 7:17 ` Georg Bauhaus @ 2011-04-17 8:29 ` Martin 2011-04-17 18:19 ` George P. 1 sibling, 0 replies; 124+ messages in thread From: Martin @ 2011-04-17 8:29 UTC (permalink / raw) On Apr 17, 8:17 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > On 4/16/11 11:12 PM, Ludovic Brenta wrote: > > > "Nasser M. Abbasi"<n...@12000.org> writes: > >> $ gcc -Wall t.c > >> $ ./a.out > >> R = 33554416 > > > So R = 2**25 - 16, the correct answer is -16, so the actual result is > > the correct one except for bit 24, which is 1 when it should be zero. > > > Out of curiosity, is this actual result a predictable consequence of the > > language definition, or is it undefined behavior? > > Why, it is the same in Ada. > > with Ada.Text_IO; use Ada.Text_IO; > with Ada.Unchecked_Conversion; > > procedure Conv is > > type UInt is mod 2**32; > type Int is range -2**31 .. 2**31 -1; > > function To_UInt is new Ada.Unchecked_Conversion(Int, UInt); > N: UInt := 128; > I: Int := -2048; > R : Int; > begin > R := Int(To_UInt(I) / N); > Put_Line ("R =" & Int'Image(R)); > end; Yes, the Ada version is _much_ more obvious and understandable But I suspect the _intent_ is of the original code is (probably): with Ada.Text_IO; use Ada.Text_IO; procedure Conv is type UInt is mod 2**32; type Int is range -2**31 .. 2**31 -1; N: UInt := 128; I: Int := -2048; R : Int; begin R := I / Int (N); Put_Line ("R =" & Int'Image(R)); end; -- Martin ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 7:17 ` Georg Bauhaus 2011-04-17 8:29 ` Martin @ 2011-04-17 18:19 ` George P. 1 sibling, 0 replies; 124+ messages in thread From: George P. @ 2011-04-17 18:19 UTC (permalink / raw) On Apr 17, 3:17 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > On 4/16/11 11:12 PM, Ludovic Brenta wrote: > > > "Nasser M. Abbasi"<n...@12000.org> writes: > >> $ gcc -Wall t.c > >> $ ./a.out > >> R = 33554416 > > > So R = 2**25 - 16, the correct answer is -16, so the actual result is > > the correct one except for bit 24, which is 1 when it should be zero. > > > Out of curiosity, is this actual result a predictable consequence of the > > language definition, or is it undefined behavior? > > Why, it is the same in Ada. > > with Ada.Text_IO; use Ada.Text_IO; > with Ada.Unchecked_Conversion; > > procedure Conv is > > type UInt is mod 2**32; > type Int is range -2**31 .. 2**31 -1; > > function To_UInt is new Ada.Unchecked_Conversion(Int, UInt); > N: UInt := 128; > I: Int := -2048; > R : Int; > begin > R := Int(To_UInt(I) / N); > Put_Line ("R =" & Int'Image(R)); > end; Not exactly, here you have at least freedom and understanding what is being cast to what. As I mentioned I have no problem C# giving compile error, screeming - tell me exactly what to do here. BTW, it defaults result to a long int, complaining about assigning it to int. Not to mentioned that negative integer number may be larger then unsigned. I am now looking at the rest the code to see where else could be the same type of cr..p. George ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 21:12 ` Ludovic Brenta 2011-04-16 21:42 ` jimmaureenrogers 2011-04-17 7:17 ` Georg Bauhaus @ 2011-04-17 8:40 ` Georg Bauhaus 2011-04-18 1:04 ` Peter C. Chapin 3 siblings, 0 replies; 124+ messages in thread From: Georg Bauhaus @ 2011-04-17 8:40 UTC (permalink / raw) On 4/16/11 11:12 PM, Ludovic Brenta wrote: > Out of curiosity, is this actual result a predictable consequence of the > language definition, or is it undefined behavior? C's definitions of what happens to arithmetic operands look like an interesting exercise in making definitions (work). The standard seems to land the resulting rules somewhere between Ada types and the effect of Ada.Unchecked_Conversion. It is not unchecked conversion, I think. C's rules do not assume a specific bit representation of arithmetic types, IINM. An interesting consequence is that the C99 Rationale lists specific circumstances in which a result "must be dubbed _questionably signed_". But, "(...) of course, _all of these ambiguities can be avoided by a judicous use of casts_." -- C99 Rationale, �6.3.1.1 A difference between C and Ada here will be the difference between *can* and *must*, as in "can be avoided using casts" and "must be stated using conversions". Consider programmers shouting I can! or I must! If the first means "I can do it!" and latter means "It forces me to do that...", this puts humans in two opposing camps. Guess who will be considered to have the more positive attitude. :-) (Placement in this or that group will not be based on a consistent set of facts, of course, but with such a set, we we'd have much less to shout at each other...) ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 21:12 ` Ludovic Brenta ` (2 preceding siblings ...) 2011-04-17 8:40 ` Georg Bauhaus @ 2011-04-18 1:04 ` Peter C. Chapin 2011-04-18 2:14 ` George P. 3 siblings, 1 reply; 124+ messages in thread From: Peter C. Chapin @ 2011-04-18 1:04 UTC (permalink / raw) On Sat, 16 Apr 2011 23:12:37 +0200, Ludovic Brenta <ludovic@ludovic-brenta.org> wrote: >Out of curiosity, is this actual result a predictable consequence of the >language definition, or is it undefined behavior? It is standard. It's part of the rules for "usual arithmetic conversions" described in section 6.3.1.8 of the C99 standard. In particular when unsigned int and int are mixed in operations like this, the signed int is converted to its corresponding unsigned value using the rules in 6.3.1.3 (which typically amounts to just reinterpreting the bit pattern). As someone who has used C for many years, I don't find this particularly strange. It is an example of why unsigned types are tricky and should be avoided unless one has a specific reason for using them. Many compilers (or other analysis tools) can produce warning messages about this if you ask for them. Peter ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 1:04 ` Peter C. Chapin @ 2011-04-18 2:14 ` George P. 0 siblings, 0 replies; 124+ messages in thread From: George P. @ 2011-04-18 2:14 UTC (permalink / raw) On Apr 17, 9:04 pm, Peter C. Chapin <PCha...@vtc.vsc.edu> wrote: > On Sat, 16 Apr 2011 23:12:37 +0200, Ludovic Brenta > > <ludo...@ludovic-brenta.org> wrote: > >Out of curiosity, is this actual result a predictable consequence of the > >language definition, or is it undefined behavior? > > It is standard. It's part of the rules for "usual arithmetic conversions" > described in section 6.3.1.8 of the C99 standard. In particular when > unsigned int and int are mixed in operations like this, the signed int is > converted to its corresponding unsigned value using the rules in 6.3.1.3 > (which typically amounts to just reinterpreting the bit pattern). > > As someone who has used C for many years, I don't find this particularly > strange. It is an example of why unsigned types are tricky and should be > avoided unless one has a specific reason for using them. > > Many compilers (or other analysis tools) can produce warning messages about > this if you ask for them. > > Peter Now since looking through rest of the code run into another puzzle. Seems that filter works correctly, but should it? Assuming that px->acc and pbr is unsigned short, px->lopass is unsigned char (byte) . // Lo-pass Filter px->acc += (pbr - (px->acc >> FILT)); px->lopass= (px->acc >> FILT); As I unserstand, in this case it does not matter wether (pbr - (px- >acc >> FILT)) will resilt in large positive number instead of small negative since overflow on addition will still bring it to right result. So we have expression that conceptually wrong, but produce right answer. How would C purist rewrite this code? ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 20:04 ` Nasser M. Abbasi 2011-04-16 21:12 ` Ludovic Brenta @ 2011-04-16 22:03 ` George P. 1 sibling, 0 replies; 124+ messages in thread From: George P. @ 2011-04-16 22:03 UTC (permalink / raw) On Apr 16, 4:04 pm, "Nasser M. Abbasi" <n...@12000.org> wrote: > On 4/16/2011 10:02 AM, George P. wrote: > > > > > Spend few days chasing bug in embedded C project which can drilled > > down to this. Consider the following program, and all reasonable men > > will expect the result to be negative. Not in C, and it is not a > > compiler bug :-( > > > And offcorse none of the three comilers I cheched did not bother to > > issue a warning at least.. > > > #include<stdio.h> > > > int main() > > { > > unsigned n = 128; > > int i = -2048; > > int r; > > > r = i / n; > > > printf("R = %d\n", r); > > > return 0; > > } > > $ gcc -Wall t.c > $ ./a.out > R = 33554416 > > That is why we all love C. Best Job security in the world > for programmers. > > There are always "issues" to fix. You see, you yourself had to > work for few days on this one. If you had used Ada, or any other > more strongly typed languages, then you'll be done early, > then the manager will have come in and saw you sitting > doing nothing becuase your program is done, and you'll be out > of work. > > So, you should be very happy you are working on C. > > --Nasser Was difficult to find this one. Unsigned was used as counter to compute average which could have both signs. Were looking elsewhere since code seemed to be so logical: dividing on unsigned integer should always give the result less then argument. With C disregard to overflow, seems to be strange such a sudden concern to types converting everything to higher ranked unsigned. I do work in C/C++ on one project out of necessity (TI DSP). Despite very strict coding conventions this one still sneaked in. No issue for ADA and C# gives compile error (fair). Again, at least compiler warning will be nice IMHO. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 17:02 Fun with C George P. 2011-04-16 20:04 ` Nasser M. Abbasi @ 2011-04-17 6:26 ` KK6GM 2011-04-17 6:59 ` Georg Bauhaus 2011-04-17 19:19 ` Elias Salomão Helou Neto 2011-04-23 23:07 ` Gerd 3 siblings, 1 reply; 124+ messages in thread From: KK6GM @ 2011-04-17 6:26 UTC (permalink / raw) On Apr 16, 10:02 am, "George P." <george.p...@gmail.com> wrote: > Spend few days chasing bug in embedded C project which can drilled > down to this. Consider the following program, and all reasonable men > will expect the result to be negative. Not in C, and it is not a > compiler bug :-( > > And offcorse none of the three comilers I cheched did not bother to > issue a warning at least.. > > #include <stdio.h> > > int main() > { > unsigned n = 128; > int i = -2048; > int r; > > r = i / n; > > printf("R = %d\n", r); > > return 0; > > > > }- Hide quoted text - > > - Show quoted text - Wow and wow. I've been writing C all my adult life and I didn't realize this could or would happen. I would have said that the unsigned would be promoted to signed. I'm going to include this example in my push to use Ada in our next project. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 6:26 ` KK6GM @ 2011-04-17 6:59 ` Georg Bauhaus 2011-04-17 16:15 ` KK6GM 0 siblings, 1 reply; 124+ messages in thread From: Georg Bauhaus @ 2011-04-17 6:59 UTC (permalink / raw) On 4/17/11 8:26 AM, KK6GM wrote: > Wow and wow. I've been writing C all my adult life and I didn't > realize this could or would happen. I would have said that the > unsigned would be promoted to signed. > > I'm going to include this example in my push to use Ada in our next > project. Be careful that there are no C savvy people around. You are demonstrating a lack of understanding of C basics! ("Stupid!") That lack is not (in their view, and it's their view that counts) a good start for asking for a different language. Had you read section 2.7 of K&R (or A.6), you'd have expected the result you got: arithmetic operators will convert their arguments following the rules of the C language definition. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 6:59 ` Georg Bauhaus @ 2011-04-17 16:15 ` KK6GM 2011-04-17 19:35 ` Elias Salomão Helou Neto 0 siblings, 1 reply; 124+ messages in thread From: KK6GM @ 2011-04-17 16:15 UTC (permalink / raw) On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > On 4/17/11 8:26 AM, KK6GM wrote: > > > Wow and wow. I've been writing C all my adult life and I didn't > > realize this could or would happen. I would have said that the > > unsigned would be promoted to signed. > > > I'm going to include this example in my push to use Ada in our next > > project. > > Be careful that there are no C savvy people around. > You are demonstrating a lack of understanding of C basics! > ("Stupid!") > That lack is not (in their view, and it's their view that counts) > a good start for asking for a different language. > > Had you read section 2.7 of K&R (or A.6), you'd have expected > the result you got: arithmetic operators will convert their > arguments following the rules of the C language definition. Yes, I understand how the "stupid" argument works in the C community. I'm going to ask some other programmers tomorrow and see how many of them get this right. I'm guessing our situation will be similar to the situation at the OP's workplace, where presumably competent programmers still got clobbered by this language-legal insanity. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 16:15 ` KK6GM @ 2011-04-17 19:35 ` Elias Salomão Helou Neto 2011-04-17 20:18 ` KK6GM ` (2 more replies) 0 siblings, 3 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-17 19:35 UTC (permalink / raw) On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote: > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> > wrote: > > > > > > > > > > > On 4/17/11 8:26 AM, KK6GM wrote: > > > > Wow and wow. I've been writing C all my adult life and I didn't > > > realize this could or would happen. I would have said that the > > > unsigned would be promoted to signed. > > > > I'm going to include this example in my push to use Ada in our next > > > project. > > > Be careful that there are no C savvy people around. > > You are demonstrating a lack of understanding of C basics! > > ("Stupid!") > > That lack is not (in their view, and it's their view that counts) > > a good start for asking for a different language. > > > Had you read section 2.7 of K&R (or A.6), you'd have expected > > the result you got: arithmetic operators will convert their > > arguments following the rules of the C language definition. > > Yes, I understand how the "stupid" argument works in the C community. > I'm going to ask some other programmers tomorrow and see how many of > them get this right. I'm guessing our situation will be similar to > the situation at the OP's workplace, where presumably competent > programmers still got clobbered by this language-legal insanity. Most programmers are competent in their views. Few really are and it does not matter what is the actual language. For example, looks like you feel you are competent in C, but are you? "I would expect unsigned to int conversion" is just unacceptable! Someone has written a line of code without knowing what it does. Is it a language problem? Not that C is spectacular, but blaming the language here is not fair. Minimally competent C programmers do know about such conversions. If you don't you suck as a C programmer. If you suck as a C programmer, please do not try to advocate any other language over it, this _is_ stupid! Maybe Ada over C is a smart choice, but advocating it without having a strong knowledge of both is unacceptable. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 19:35 ` Elias Salomão Helou Neto @ 2011-04-17 20:18 ` KK6GM 2011-04-18 19:47 ` Elias Salomão Helou Neto 2011-04-17 22:26 ` Georg Bauhaus 2011-04-18 0:12 ` George P. 2 siblings, 1 reply; 124+ messages in thread From: KK6GM @ 2011-04-17 20:18 UTC (permalink / raw) On Apr 17, 12:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com> wrote: > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote: > > > > > > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> > > wrote: > > > > On 4/17/11 8:26 AM, KK6GM wrote: > > > > > Wow and wow. I've been writing C all my adult life and I didn't > > > > realize this could or would happen. I would have said that the > > > > unsigned would be promoted to signed. > > > > > I'm going to include this example in my push to use Ada in our next > > > > project. > > > > Be careful that there are no C savvy people around. > > > You are demonstrating a lack of understanding of C basics! > > > ("Stupid!") > > > That lack is not (in their view, and it's their view that counts) > > > a good start for asking for a different language. > > > > Had you read section 2.7 of K&R (or A.6), you'd have expected > > > the result you got: arithmetic operators will convert their > > > arguments following the rules of the C language definition. > > > Yes, I understand how the "stupid" argument works in the C community. > > I'm going to ask some other programmers tomorrow and see how many of > > them get this right. I'm guessing our situation will be similar to > > the situation at the OP's workplace, where presumably competent > > programmers still got clobbered by this language-legal insanity. > > Most programmers are competent in their views. Few really are and it > does not matter what is the actual language. For example, looks like > you feel you are competent in C, but are you? > > "I would expect unsigned to int conversion" is just unacceptable! > Someone has written a line of code without knowing what it does. Is it > a language problem? Not that C is spectacular, but blaming the > language here is not fair. Minimally competent C programmers do know > about such conversions. If you don't you suck as a C programmer. If > you suck as a C programmer, please do not try to advocate any other > language over it, this _is_ stupid! > - Show quoted text - So, the spankings begin. :) What is a competent programmer? One who has made a good living using the language for 30 years, with no complaints as to my competency? That's my only claim. Perhaps the programmers in the OP's organization would make a similar claim. I guess in some perfect world we wouldn't need any of the myriad of checking and verification tools and rules that people use to protect themselves from their chosen programming language. You are making a classic "CMM0" argument, where heroic programmers are necessary to acheive semi-acceptable results. You criticize those who do not know some arcane language rule, when I think the real criticism shoult be for a language, any language, that blows up on -2048/128. C is a Steam Age language. It served a purpose, but it is a sign of unseriousness and immaturity in our industry that it is still so widely used, that the terms "C" and "best practice" can ever be found together. I work at a company that uses a lot of very large and dangerous machines for manufacturing. They would not for a moment stand for their machines to be as dangerous as C is. Nor would their insurers nor the various government organizations to which they must account. It's not enough any more to say "Yes, C may silently rip the scalp off of your head, or chop off your arm, but only if you don't know all the rules and obey them without fail." Are we to be forever stuck in the year 1900, programming language-wise? -2048/128 = 33554416 (or whatever your int size produces). There's little more to say. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 20:18 ` KK6GM @ 2011-04-18 19:47 ` Elias Salomão Helou Neto 2011-04-18 22:11 ` Peter C. Chapin 0 siblings, 1 reply; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-18 19:47 UTC (permalink / raw) On Apr 17, 5:18 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote: > On Apr 17, 12:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com> > wrote: > > > > > > > > > > > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote: > > > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> > > > wrote: > > > > > On 4/17/11 8:26 AM, KK6GM wrote: > > > > > > Wow and wow. I've been writing C all my adult life and I didn't > > > > > realize this could or would happen. I would have said that the > > > > > unsigned would be promoted to signed. > > > > > > I'm going to include this example in my push to use Ada in our next > > > > > project. > > > > > Be careful that there are no C savvy people around. > > > > You are demonstrating a lack of understanding of C basics! > > > > ("Stupid!") > > > > That lack is not (in their view, and it's their view that counts) > > > > a good start for asking for a different language. > > > > > Had you read section 2.7 of K&R (or A.6), you'd have expected > > > > the result you got: arithmetic operators will convert their > > > > arguments following the rules of the C language definition. > > > > Yes, I understand how the "stupid" argument works in the C community. > > > I'm going to ask some other programmers tomorrow and see how many of > > > them get this right. I'm guessing our situation will be similar to > > > the situation at the OP's workplace, where presumably competent > > > programmers still got clobbered by this language-legal insanity. > > > Most programmers are competent in their views. Few really are and it > > does not matter what is the actual language. For example, looks like > > you feel you are competent in C, but are you? > > > "I would expect unsigned to int conversion" is just unacceptable! > > Someone has written a line of code without knowing what it does. Is it > > a language problem? Not that C is spectacular, but blaming the > > language here is not fair. Minimally competent C programmers do know > > about such conversions. If you don't you suck as a C programmer. If > > you suck as a C programmer, please do not try to advocate any other > > language over it, this _is_ stupid! > > - Show quoted text - > > So, the spankings begin. :) > > What is a competent programmer? One who has made a good living using > the language for 30 years, with no complaints as to my competency? > That's my only claim. Perhaps the programmers in the OP's > organization would make a similar claim. I guess in some perfect > world we wouldn't need any of the myriad of checking and verification > tools and rules that people use to protect themselves from their > chosen programming language. > > You are making a classic "CMM0" argument, where heroic programmers are > necessary to acheive semi-acceptable results. You criticize those who > do not know some arcane language rule, when I think the real criticism > shoult be for a language, any language, that blows up on -2048/128. > > C is a Steam Age language. It served a purpose, but it is a sign of > unseriousness and immaturity in our industry that it is still so > widely used, that the terms "C" and "best practice" can ever be found > together. > > I work at a company that uses a lot of very large and dangerous > machines for manufacturing. They would not for a moment stand for > their machines to be as dangerous as C is. Nor would their insurers > nor the various government organizations to which they must account. > It's not enough any more to say "Yes, C may silently rip the scalp off > of your head, or chop off your arm, but only if you don't know all the > rules and obey them without fail." Are we to be forever stuck in the > year 1900, programming language-wise? Yes, at least while the huge codebase written in C remains. What is dumbness, ignoring it or living with it? Go and use Ada for your safety critical software, but there are uses for C too, if you don't know. Do you know what is dumbness? Trying to create "A Language to Rule them All". Ada is Ada and C is C. I have never seen a real numeric library in Ada, there are tons written in FORTRAN, C and C++. Now go and advocate Ada for those folks too, you surely know more than all of us about numeric programming don't you? Or why would we keep using a year 1900 programming language? Go and advocate Ada for system programming, of course there is no Ada OS in use today simply because all system programmers are stupid and stubborn and prefer C or C++ over the much better Ada. Ada is for everything. Now, this is dumbness. Have you ever heard me saying Ada sucks? No, because saying it is stupid. As it is also stupid to say that C sucks. Neither FORTRAN or assembly sucks as well. Use each language where it should be used and this is being smart. Maybe even Java has its proper place. Anyone who says "C sucks", "Ada sucks", "FORTRAN sucks", "C++ sucks", is being stupid. The way to go is to select the proper tool for the job. Maybe "C sucks for safety-critical embedded systems" would be better. And C will never suck only because its type promotion system. While it is not intuitive it is pretty simple and easy to understand: are you mixing unsigned and int and wish to obtain a signed integer? Use a cast to int on the unsigned. This is really very difficult to learn, isn't it? > > -2048/128 = 33554416 (or whatever your int size produces). There's > little more to say. If this is your argument against C, there is nothing to say. I dislike those rules too and when I was a beginner they used to surprise me as well. But now I know what I am doing and I refuse to keep whining against it. I am not such a sissy. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 19:47 ` Elias Salomão Helou Neto @ 2011-04-18 22:11 ` Peter C. Chapin 0 siblings, 0 replies; 124+ messages in thread From: Peter C. Chapin @ 2011-04-18 22:11 UTC (permalink / raw) On Mon, 18 Apr 2011 12:47:56 -0700 (PDT), Elias Salom�o Helou Neto <eshneto@gmail.com> wrote: >Have you ever heard me saying Ada sucks? No, because saying it is >stupid. As it is also stupid to say that C sucks. Neither FORTRAN or >assembly sucks as well. Use each language where it should be used and >this is being smart. Maybe even Java has its proper place. It is true that different languages are good at different things. It is also politically correct to argue that every language has its place, etc. Yet it is also true that there are real technical differences between languages and some languages are just plain better than others. Ada competes with C in the same application areas. I think that any application for which it is reasonable to deploy a C program is also a good application for Ada (and visa-versa). Considering the technical differences in the languages it is difficult to see what advantage C has over Ada aside from a difference in popularity, tool and library support, etc (not that those are insignificant differences but they are not really related to the merits of the language itself). Comparing Ada to C++ is more interesting. Again both languages tend to make sense in similar application areas and C++, unlike C, provides extensive facilities for creating and using abstractions (like Ada). Peter ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 19:35 ` Elias Salomão Helou Neto 2011-04-17 20:18 ` KK6GM @ 2011-04-17 22:26 ` Georg Bauhaus 2011-04-18 19:12 ` Elias Salomão Helou Neto 2011-05-08 23:41 ` wilso 2011-04-18 0:12 ` George P. 2 siblings, 2 replies; 124+ messages in thread From: Georg Bauhaus @ 2011-04-17 22:26 UTC (permalink / raw) On 4/17/11 9:35 PM, Elias Salom�o Helou Neto wrote: > Someone has written a line of code without knowing what it does. Is it > a language problem? Not that C is spectacular, but blaming the > language here is not fair. Minimally competent C programmers do know > about such conversions. OK, that's a claim. Michael Barr seem to have found results contradicting it if the "minimum" is what you minimally find with professional C programmers. In his netrino.com embedded C quiz, he found that US takers got at D+ on average. That's a real world, observable minimum, then. I suggest turning to observable facts and away from normative ontology for a moment. Towards justifiable language design. Whenever a statistical phenomenon is observed, many start looking for correlations and hypotheses. Here, we have errors related to the / operation and the promotion rules of C's $6.3.1. Is there a correlation? Will the correlation between error rates and language rules be the same if using another language? Is that other language intrinsically better or worse, then? If there is a correlation between the frequency of a number of programming errors (in this case related to +,-,*,/ etc) and the way the corresponding part of the programming language is defined (in this case operand treatment), then I suggest the following Hypothesis 1: A language A is better designed than another B if, after comparable introduction to the languages, programmers of an A-group make fewer mistakes than programmers of a B-group when implementing the same algorithm. If so, then competent, informed language *design* will have to consider expected error rates when defining the language. Because the definitions affect error rates. A second perspective: Definition: The complexity of / (or another language feature) is the number of concepts that a human mind will have to connect properly in order to use / (or another language feature) correctly. Assumption: Programming is a human activity. Since programs express human ideas, clear means of expression reflect programmer intentions better than formally implicit means that in addition depend on statements outside the language, as is the case with C's fundamental types. I suggest, then, Hypothesis 2: A language A is better designed than another B if an understanding and using the language properly is less complex, that is, in order to express the same algorithm, (a) it requires thinking about fewer interconnected, possibly implicit concepts and (b) depends less on statements outside the language. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 22:26 ` Georg Bauhaus @ 2011-04-18 19:12 ` Elias Salomão Helou Neto 2011-04-18 20:56 ` KK6GM 2011-04-18 21:01 ` Georg Bauhaus 2011-05-08 23:41 ` wilso 1 sibling, 2 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-18 19:12 UTC (permalink / raw) On Apr 17, 7:26 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > On 4/17/11 9:35 PM, Elias Salomão Helou Neto wrote: > > > Someone has written a line of code without knowing what it does. Is it > > a language problem? Not that C is spectacular, but blaming the > > language here is not fair. Minimally competent C programmers do know > > about such conversions. > > OK, that's a claim. Michael Barr seem to have found results > contradicting it if the "minimum" is what you minimally > find with professional C programmers. In his netrino.com embedded > C quiz, he found that US takers got at D+ on average. > That's a real world, observable minimum, then. > > I suggest turning to observable facts and away from > normative ontology for a moment. Towards justifiable > language design. > > Whenever a statistical phenomenon is observed, > many start looking for correlations and hypotheses. > Here, we have errors related to the / operation and > the promotion rules of C's $6.3.1. Is there a correlation? > Will the correlation between error rates and language > rules be the same if using another language? > Is that other language intrinsically better or worse, then? > > If there is a correlation between the frequency of a number > of programming errors (in this case related to +,-,*,/ etc) > and the way the corresponding part of the programming language > is defined (in this case operand treatment), then I suggest > the following > > Hypothesis 1: > > A language A is better designed than another B if, > after comparable introduction to the languages, > programmers of an A-group make fewer mistakes than > programmers of a B-group when implementing the same > algorithm. > > If so, then competent, informed language *design* will have to > consider expected error rates when defining the language. > Because the definitions affect error rates. > > A second perspective: > > Definition: The complexity of / (or another language feature) is > the number of concepts that a human mind will have to connect > properly in order to use / (or another language feature) correctly. > > Assumption: Programming is a human activity. > Since programs express human ideas, clear means of expression reflect > programmer intentions better than formally implicit means that > in addition depend on statements outside the language, as is the > case with C's fundamental types. > > I suggest, then, > > Hypothesis 2: > > A language A is better designed than another B if an > understanding and using the language properly is less complex, > that is, in order to express the same algorithm, > > (a) it requires thinking about fewer interconnected, possibly > implicit concepts and > > (b) depends less on statements outside the language. Ok, Ada is better than C, but if you wish we can find a metric whereby C is better than Ada as well. I won't argue on that. Specially, your metric seems to imply that Ada is much better for those who find it hard to think, most people after all. It is just that industry standard is no standard. Hired programmers are dumb and incompetent - because those are cheap, there are lots of them. Look above for someone who say that has been programming professionally in C for 30 years but doesn't know type promotion rules. If you are to design a language for those guys, good luck. I am a researcher, I do not have to, that's why I am happy with C++. Those who have designed C, have done so for people with brain, for real computer scientists. It is not the way to go with professional programmers these days, so don't blame C for its popularity. Of course Ada is a better approach for the masses. You've made your point: programmers, as it happens with people in general, are dumb. Let us create a language for them. However, here is my piece of advice: it won't work. See Ariane 5's example. Ada may give programmers a false sense of security, leading to even more sloppiness. If I knew it well, I guess I would advocate Ada for parallel programming. Even the smartest researcher gets surprised sometimes by the perils of concurrent software and some extra safety here is really welcome. As long as it does not come at expense of performance, of course, since this is likely the goal in parallel software. Surely Ada would be a good and justifiable choice for most industrial programming projects, but this is not what C was planned for - don't blame it. Is an airplane's fault if someone without proper knowledge tries to fly it and kills hundreds? Is a spaceship fault if an airplane pilot feels competent to fly it and ends up killing thousands? Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 19:12 ` Elias Salomão Helou Neto @ 2011-04-18 20:56 ` KK6GM 2011-04-18 21:01 ` Georg Bauhaus 1 sibling, 0 replies; 124+ messages in thread From: KK6GM @ 2011-04-18 20:56 UTC (permalink / raw) On Apr 18, 12:12 pm, Elias Salomão Helou Neto <eshn...@gmail.com> wrote: > > <industrial programming projects> is not what C was planned for - don't > blame it. Here we agree. C is what it is, it never claimed to be One Language To Rule Them All. But it is a sign of our industry's lack of maturity that it has been used in so many areas where it is not the most suitable choice, and was never the most suitable choice. C (and C++) are highly unsafe languages. That is why they require so many tools and restrictions to be used reliably. But our industry continues to pound that square peg into every possible shape of holes. And so, inevitably, we end up with e.g. C code certified to DO-178B Level A that still has 10 times the anomalies of certified Ada code, and 100 times the anomalies of certified SPARK code. It defies logic. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 19:12 ` Elias Salomão Helou Neto 2011-04-18 20:56 ` KK6GM @ 2011-04-18 21:01 ` Georg Bauhaus 2011-04-18 21:20 ` Nasser M. Abbasi 2011-04-19 1:10 ` Elias Salomão Helou Neto 1 sibling, 2 replies; 124+ messages in thread From: Georg Bauhaus @ 2011-04-18 21:01 UTC (permalink / raw) On 4/18/11 9:12 PM, Elias Salom�o Helou Neto wrote: > On Apr 17, 7:26 pm, Georg Bauhaus<rm.dash-bauh...@futureapps.de> >> I suggest turning to observable facts and away from >> normative ontology for a moment. Towards justifiable >> language design. Unfortunately, when it comes to empirical research into the effects of language definitions, hardly anyone ever finds a scientific approach worthwhile. > if you wish we can find a metric whereby > C is better than Ada as well. I'm eager to add more metrics to my collection programming language metrics. C's pointer arithmetic is unchecked, unlike Ada's, and thus faster. (A experiment that some embedded C people found fair resulted in a ratio of 10:12). Another metric. So we have three PL metrics and three hypotheses for a start. > I won't argue on that. Specially, your > metric seems to imply that Ada is much better for those who find it > hard to think, most people after all. Uhm, no, that's a misunderstanding, Ada requires quite some thinking, it is just that its basic types do not require so much thinking. I should stress one *major* concern of my favorite approach to language definition: Smart brains should not have to spend time with tackling basic programming techniques. In any language. They should have all their thinking capacity engaged in thinking about smart solutions. Not in keeping track of types' implicit sizes. That's wasted effort. (PC-lint -w 4 seems to confirm this view.) If mastering a relatively basic feature of a language requires much learning, then this investment should be compared to its results. What is the return on investment a programmer spent on implicit type size education, say? Among the observable results are these: (a) you know how to use basic programming features (b) you take pride in this ability (c) you can set yourself apart from others without the skill Which skill is, nota bene, knowing how to write basics. > Of course Ada is a better approach for the masses. Certainly not in full. Like C++. Because no big, detailed language will ever work for the masses. Subsets may do so, as a starting point, I think. > However, here is my piece of advice: it won't work. See Ariane 5's > example. I understand your idea, I think, but it is this very example that has surprisingly little to do with languages, in spite of all the ambitious remarks made about the case. Have you had time to look into the report? > Ada may give programmers a false sense of security, leading > to even more sloppiness. Hmm... Is there an operational definition useful to turn this claim into a hypothesis? I had thought that Ada culture nurtures awareness of security issues more than false beliefs in "secure languages". > Surely Ada would be a good and justifiable choice for most industrial > programming projects, but this is not what C was planned for - don't > blame it. Complaints were addressing using C in industrial projects because of the effects it has in industrial projects. There is evidence that different fundamental type systems help non-dumb people solve their problems more successfully. People will still be using C libraries and additional code generators, as a replacement for a better suited type system. If something is going to replace C, it sure mustn't look like Ada. Just be like it in some ways. That's the crucial part, I think. Keeps face. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 21:01 ` Georg Bauhaus @ 2011-04-18 21:20 ` Nasser M. Abbasi 2011-04-19 2:43 ` George P. 2011-04-19 1:10 ` Elias Salomão Helou Neto 1 sibling, 1 reply; 124+ messages in thread From: Nasser M. Abbasi @ 2011-04-18 21:20 UTC (permalink / raw) On 4/18/2011 2:01 PM, Georg Bauhaus wrote: > > Smart brains should not have to spend time with tackling basic > programming techniques. In any language. They should have all > their thinking capacity engaged in thinking about smart solutions. > Not in keeping track of types' implicit sizes. That's wasted effort. > (PC-lint -w 4 seems to confirm this view.) > > If mastering a relatively basic feature of a language requires > much learning, then this investment should be compared to its results. > What is the return on investment a programmer spent on implicit > type size education, say? > Exactly. the above is the main point that needs to stressed. Someone who programs in C/C++ and other weakly typed languages, can spend 5 days to find a bug, then they would feel so proud of themselves, and may be even get a raise from the boss, because they keep finding more bugs. But if they would have used a better language, a more strongly typed language, then this time would have been saved to work on the design and the algorithm itself, and think about the problem itself. May be even use the saved time to write more test cases, instead of wasted hours debugging pointers and type mismatches problems, and But then these warrior programmers would not longer feel like they are in a battle anymore when 'coding'. So programming would not be 'fun' any more. --Nasser ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 21:20 ` Nasser M. Abbasi @ 2011-04-19 2:43 ` George P. 2011-04-19 18:05 ` Vinzent Hoefler 0 siblings, 1 reply; 124+ messages in thread From: George P. @ 2011-04-19 2:43 UTC (permalink / raw) On Apr 18, 5:20 pm, "Nasser M. Abbasi" <n...@12000.org> wrote: > On 4/18/2011 2:01 PM, Georg Bauhaus wrote: > > Someone who programs in C/C++ and other weakly > typed languages, can spend 5 days to find a bug, > then they would feel so proud of themselves, and may > be even get a raise from the boss, because they > keep finding more bugs. > > But if they would have used a better language, > a more strongly typed language, then this time would > have been saved to work on the design and the algorithm > itself, and think about the problem itself. > >... > > --Nasser How true. I know good C coders that show very little interest in application part of software design. The pride is built around performance gains individual can produce. That rarely exceeds 10-20% though. The fundamental difference between C and other languages in my view, is that C is not exactly a high level programming language. It is built around simple mini-computer architecture and as such is limited by it. It has it's place ofcorse. After all, one can write compilers generating C code. Coming back to my project here is the JSF Coding standard rules that we follow indeed states: http://www2.research.att.com/~bs/JSF-AV-rules.pdf AV Rule 162 Signed and unsigned values shall not be mixed in arithmetic or comparison operations. Rationale: Mixing signed and unsigned values is error prone as it subjects operations to numerous arithmetic conversion and integral promotion rules. Obviously that one slipped through. No wonder since these rules are 141 pages long. Well, computers are still programmed by humans (unfortunately) ;-) -- ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 2:43 ` George P. @ 2011-04-19 18:05 ` Vinzent Hoefler 2011-04-19 19:34 ` George P. 0 siblings, 1 reply; 124+ messages in thread From: Vinzent Hoefler @ 2011-04-19 18:05 UTC (permalink / raw) George P. wrote: > Coming back to my project here is the JSF Coding standard rules that > we follow indeed states: > > http://www2.research.att.com/~bs/JSF-AV-rules.pdf > > AV Rule 162 > Signed and unsigned values shall not be mixed in arithmetic or > comparison operations. One question: Did you just forget to launch the appropriate checker or does nobody actually check if those rules are obeyed? Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 18:05 ` Vinzent Hoefler @ 2011-04-19 19:34 ` George P. 2011-04-19 20:08 ` Georg Bauhaus 0 siblings, 1 reply; 124+ messages in thread From: George P. @ 2011-04-19 19:34 UTC (permalink / raw) On Apr 19, 2:05 pm, "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote: > George P. wrote: > > Coming back to my project here is the JSF Coding standard rules that > > we follow indeed states: > > >http://www2.research.att.com/~bs/JSF-AV-rules.pdf > > > AV Rule 162 > > Signed and unsigned values shall not be mixed in arithmetic or > > comparison operations. > > One question: Did you just forget to launch the appropriate checker > or does nobody actually check if those rules are obeyed? > > Vinzent. > > -- > A C program is like a fast dance on a newly waxed dance floor by people carrying > razors. > -- Waldi Ravens We simply follow the styling described here. I don' know of any checker for LM JSF. MISRA would be too strict for our needs. It is an imaging device with built-in AI. G. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 19:34 ` George P. @ 2011-04-19 20:08 ` Georg Bauhaus 0 siblings, 0 replies; 124+ messages in thread From: Georg Bauhaus @ 2011-04-19 20:08 UTC (permalink / raw) On 4/19/11 9:34 PM, George P. wrote: > We simply follow the styling described here. I don' know of any > checker for LM JSF. MISRA would be too strict for our needs. It is an > imaging device with built-in AI. Shamelessly pasting your original example into the DIY box at Gimpel Software, without triggering anything related to MISRA, it gives: FlexeLint for C/C++ (Unix) Vers. 9.00f, Copyright Gimpel Software 1985-2010 --- Module: diy.c (C) 1 /* Enter your C code here - you can delete this line. */ 2 3 4 #include <stdio.h> 5 6 int main() 7 { 8 unsigned n = 128; 9 int i = -2048; 10 int r; 11 _ 12 r = i / n; diy.c 12 Warning 573: Signed-unsigned mix with divide diy.c 12 Info 737: Loss of sign in promotion from int to unsigned int diy.c 12 Info 713: Loss of precision (assignment) (unsigned int to int) 13 14 printf("R = %d\n", r); 15 16 return 0; 17 } ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 21:01 ` Georg Bauhaus 2011-04-18 21:20 ` Nasser M. Abbasi @ 2011-04-19 1:10 ` Elias Salomão Helou Neto 2011-04-19 14:28 ` Georg Bauhaus 2011-04-25 11:06 ` Paul Colin Gloster 1 sibling, 2 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-19 1:10 UTC (permalink / raw) > Uhm, no, that's a misunderstanding, Ada requires quite some thinking, > it is just that its basic types do not require so much thinking. > > I should stress one *major* concern of my favorite approach to > language definition: > > Smart brains should not have to spend time with tackling basic > programming techniques. In any language. They should have all > their thinking capacity engaged in thinking about smart solutions. > Not in keeping track of types' implicit sizes. That's wasted effort. > (PC-lint -w 4 seems to confirm this view.) There is no time spent thinking about promotions in C when you learn it. It is surely mor difficult to learn, so you've still made your point. > > If mastering a relatively basic feature of a language requires > much learning, then this investment should be compared to its results. > What is the return on investment a programmer spent on implicit > type size education, say? > > Among the observable results are these: > > (a) you know how to use basic programming features > > (b) you take pride in this ability > > (c) you can set yourself apart from others without the skill > > Which skill is, nota bene, knowing how to write basics. Ok, I understand, just please notice that I am not taking pride for anything. It is quite the opposite, those who don't know the basics should be ashamed of screaming "C sucks". > > > Of course Ada is a better approach for the masses. > > Certainly not in full. Like C++. Because no big, detailed language > will ever work for the masses. Subsets may do so, as a starting > point, I think. > > > However, here is my piece of advice: it won't work. See Ariane 5's > > example. > > I understand your idea, I think, but it is this very example that > has surprisingly little to do with languages, in spite of all > the ambitious remarks made about the case. Have you had time to > look into the report? I did not. But what I meant was basically that: people will keep doing dumbness because they are just people (me included). No matter what language is used. > > Ada may give programmers a false sense of security, leading > > to even more sloppiness. > > Hmm... Is there an operational definition useful to turn this claim > into a hypothesis? I had thought that Ada culture nurtures awareness > of security issues more than false beliefs in "secure languages". No there is not and I should not have said that without thinking a little bit more about it. > > > Surely Ada would be a good and justifiable choice for most industrial > > programming projects, but this is not what C was planned for - don't > > blame it. > > Complaints were addressing using C in industrial projects because of the > effects it has in industrial projects. There is evidence that different > fundamental type systems help non-dumb people solve their problems more > successfully. People will still be using C libraries and additional > code generators, as a replacement for a better suited type system. I would like to see this evidence. > > If something is going to replace C, it sure mustn't look like Ada. > Just be like it in some ways. That's the crucial part, I think. > Keeps face. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 1:10 ` Elias Salomão Helou Neto @ 2011-04-19 14:28 ` Georg Bauhaus 2011-04-19 17:40 ` Jeffrey Carter 2011-04-21 14:52 ` Elias Salomão Helou Neto 2011-04-25 11:06 ` Paul Colin Gloster 1 sibling, 2 replies; 124+ messages in thread From: Georg Bauhaus @ 2011-04-19 14:28 UTC (permalink / raw) On 4/19/11 3:10 AM, Elias Salom�o Helou Neto wrote: > what I meant was basically that: people will keep doing > dumbness because they are just people (me included). No matter what > language is used. Agree. Perhaps one language can make being stupid more difficult than another, then. >> There is evidence that different >> fundamental type systems help non-dumb people solve their problems more >> successfully. People will still be using C libraries and additional >> code generators, as a replacement for a better suited type system. > > I would like to see this evidence. One comparative study, not entirely free of all bias I would think, but pretty close to standard experiments yielding valid data, was conducted over several years, by John W. McCormick. It is about a project that switched not subjects or algorithms but the language. The result was published in August 2000 as http://www.crosstalkonline.org/storage/issue-archives/2000/200008/200008-McCormick.pdf From which is this quote: "Upon reading the project listings and team member diaries, I concluded that the major advantages of Ada for these students were, in order of importance: � Modeling of scalar objects. � Strong typing. � Range constraints. � Enumeration types. � Parameter modes that reflect the problem rather than the mechanism. � Named parameter association. � (...)" (There may be news on this, ACM lists a 2008 experience report.) ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 14:28 ` Georg Bauhaus @ 2011-04-19 17:40 ` Jeffrey Carter 2011-04-21 14:52 ` Elias Salomão Helou Neto 1 sibling, 0 replies; 124+ messages in thread From: Jeffrey Carter @ 2011-04-19 17:40 UTC (permalink / raw) On 04/19/2011 07:28 AM, Georg Bauhaus wrote: > > One comparative study, not entirely free of all bias I would think, > but pretty close to standard experiments yielding valid data, > was conducted over several years, by John W. McCormick. It is > about a project that switched not subjects or algorithms but the > language. The result was published in August 2000 as > http://www.crosstalkonline.org/storage/issue-archives/2000/200008/200008-McCormick.pdf In addition to McCormick's report, there's the Rational comparison of 2 Ada-compiler projects: archive.adaic.com/intro/ada-vs-c/cada_art.html archive.adaic.com wasn't responding for me, but Google has it cached. -- Jeff Carter "We call your door-opening request a silly thing." Monty Python & the Holy Grail 17 ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 14:28 ` Georg Bauhaus 2011-04-19 17:40 ` Jeffrey Carter @ 2011-04-21 14:52 ` Elias Salomão Helou Neto 2011-04-21 18:58 ` Georg Bauhaus 1 sibling, 1 reply; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-21 14:52 UTC (permalink / raw) On Apr 19, 11:28 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > On 4/19/11 3:10 AM, Elias Salomão Helou Neto wrote: > > > what I meant was basically that: people will keep doing > > dumbness because they are just people (me included). No matter what > > language is used. > > Agree. Perhaps one language can make being stupid more difficult > than another, then. > > >> There is evidence that different > >> fundamental type systems help non-dumb people solve their problems more > >> successfully. People will still be using C libraries and additional > >> code generators, as a replacement for a better suited type system. > > > I would like to see this evidence. > > One comparative study, not entirely free of all bias I would think, > but pretty close to standard experiments yielding valid data, > was conducted over several years, by John W. McCormick. It is > about a project that switched not subjects or algorithms but the > language. The result was published in August 2000 ashttp://www.crosstalkonline.org/storage/issue-archives/2000/200008/200... I've had a difficult time reading the report because the authoring software did not embed the fonts (this kind of thing makes me itch), making it difficult to read it in full because metrics were wrong. This is not my fault, the document simply was not made to be read by others if fonts were not embedded. > From which is this quote: > > "Upon reading the project listings and team member diaries, > I concluded that the major advantages of Ada for these > students were, in order of importance: > • Modeling of scalar objects. > – Strong typing. > – Range constraints. > – Enumeration types. > • Parameter modes that reflect the problem rather than the mechanism. > • Named parameter association. > • (...)" You've quoted those which make sense. But what about "Arrays whose indices do not have to begin at zero"? While it is a workaround and I don't actually recommend it, in C you can simply declare an array with a size slightly (+1) larger and use it as it started at 1. Also, students of an introductory course do not qualify as "non-dumb". Most professional programmers are dumb and had likely gone through some kind of course like that. Anyway, it is good evidence in favor of Ada for embedded projects written by real-life programmers, but I don't remember to have disagreed that Ada would be better for non- competent (real-life) programmers. For the record, I've recently seen in this newsgroup a discussion on how difficult is to hire good programmers, most couldn't even do the most basic bit manipulation in whatever language. That's why I say that real-life programmers are non competent. So, ok, you're right in advocating Ada. It is just not fair to bash C. Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 14:52 ` Elias Salomão Helou Neto @ 2011-04-21 18:58 ` Georg Bauhaus 2011-04-21 19:27 ` Hyman Rosen 0 siblings, 1 reply; 124+ messages in thread From: Georg Bauhaus @ 2011-04-21 18:58 UTC (permalink / raw) On 4/21/11 4:52 PM, Elias Salom�o Helou Neto wrote: > You've quoted those which make sense. But what about "Arrays whose > indices do not have to begin at zero"? While it is a workaround and I > don't actually recommend it, in C you can simply declare an array with > a size slightly (+1) larger and use it as it started at 1. Another instance of the *but you can roll it* argument ;-). Certainly true, and creative, but misses one thing IMHO. The index type of an Ada array induces the compiler to test for correct index values. Similarly, the compiler will complain when a case distinction does not exactly cover the whole set of values in a type. Change the set of values in a type and watch the Ada compiler tell you which dependent declarations will now be incorrect, or where a case value isn't handled by a case statement. Suppose you could do the following in C. I trust that C programmers would find this really cool: #include <stdint.h> enum Color {Red, Green, Blue}; typedef uint8_t rgb_intensity; int main(void) { rgb_intensity things[enum Color]; // This Here return 0; } a = http://itunes.apple.com/de/album/this-here/id218299914?i=218299916 listen(a[0]); A := http://itunes.apple.com/de/album/this-here/id218299914?i=218299916 Listen(To => A(A'First)); ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 18:58 ` Georg Bauhaus @ 2011-04-21 19:27 ` Hyman Rosen 2011-04-28 5:13 ` David Thompson 0 siblings, 1 reply; 124+ messages in thread From: Hyman Rosen @ 2011-04-21 19:27 UTC (permalink / raw) On 4/21/2011 2:58 PM, Georg Bauhaus wrote: > Suppose you could do the following in C. I trust that > C programmers would find this really cool: > > #include <stdint.h> > > enum Color {Red, Green, Blue}; > typedef uint8_t rgb_intensity; > > int main(void) > { > rgb_intensity things[enum Color]; // This Here > return 0; > } That doesn't work for C because a variable of an enum type may hold any integer value up to the number of bits taken by the largest enumerator (with a variation for negatives that isn't important here). The C enum concept is meant to encompass literals used as bit masks as well as singular values. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 19:27 ` Hyman Rosen @ 2011-04-28 5:13 ` David Thompson 2011-04-28 13:41 ` Hyman Rosen 0 siblings, 1 reply; 124+ messages in thread From: David Thompson @ 2011-04-28 5:13 UTC (permalink / raw) On Thu, 21 Apr 2011 15:27:40 -0400, Hyman Rosen <hyrosen@mail.com> wrote: > On 4/21/2011 2:58 PM, Georg Bauhaus wrote: > > Suppose you could do the following in C. I trust that > > C programmers would find this really cool: > > > > #include <stdint.h> > > > > enum Color {Red, Green, Blue}; > > typedef uint8_t rgb_intensity; > > > > int main(void) > > { > > rgb_intensity things[enum Color]; // This Here > > return 0; > > } > > That doesn't work for C because a variable of an enum type > may hold any integer value up to the number of bits taken s/up to/up to at least/ > by the largest enumerator (with a variation for negatives > that isn't important here). The C enum concept is meant to > encompass literals used as bit masks as well as singular > values. However, for the many C enums that are just sequential integers -- the default -- you can do this: enum Color { Red,Green,Blue, Color_BOUND }; some_t array [Color_BOUND]; // Red..Blue are valid subscripts This helps *some* especially in maintenance. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-28 5:13 ` David Thompson @ 2011-04-28 13:41 ` Hyman Rosen 2011-05-05 8:39 ` David Thompson 0 siblings, 1 reply; 124+ messages in thread From: Hyman Rosen @ 2011-04-28 13:41 UTC (permalink / raw) On 4/28/2011 1:13 AM, David Thompson wrote: > On Thu, 21 Apr 2011 15:27:40 -0400, Hyman Rosen<hyrosen@mail.com> > wrote: >> That doesn't work for C because a variable of an enum type >> may hold any integer value up to the number of bits taken >> by the largest enumerator (with a variation for negatives >> that isn't important here). The C enum concept is meant to >> encompass literals used as bit masks as well as singular >> values. > > s/up to/up to at least/ C++ restricts the permitted values, as per 7.2/6: For an enumeration where e{min} is the smallest enumerator and e{max} is the largest, the values of the enumeration are the values of the underlying type in the range b{min} to b{max}, where b{min} and b{max} are, respectively, the smallest and largest values of the smallest bit-field that can store e{min} and e{max}. On a two's-complement machine, b{max} is the smallest value ≥ max(|e{min}|-1,|e{max}|) of the form 2**M-1; b{min} is 0 if e{min} ≥ 0 and -(b{max}+1) otherwise. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-28 13:41 ` Hyman Rosen @ 2011-05-05 8:39 ` David Thompson 0 siblings, 0 replies; 124+ messages in thread From: David Thompson @ 2011-05-05 8:39 UTC (permalink / raw) On Thu, 28 Apr 2011 09:41:57 -0400, Hyman Rosen <hyrosen@mail.com> wrote: > On 4/28/2011 1:13 AM, David Thompson wrote: > > On Thu, 21 Apr 2011 15:27:40 -0400, Hyman Rosen<hyrosen@mail.com> > > wrote: > >> That doesn't work for C because a variable of an enum type > >> may hold any integer value up to the number of bits taken > >> by the largest enumerator (with a variation for negatives > >> that isn't important here). The C enum concept is meant to > >> encompass literals used as bit masks as well as singular > >> values. > > > > s/up to/up to at least/ > > C++ restricts the permitted values, as per 7.2/6: <snip> C++ kinda does; C doesn't. C++ makes each enum type a distinct type _implemented_ as some 'underlying' integral type with the additional constraint you quoted, plus restriction on conversion, and ability to overload. Trying to convert a value outside that range is 'unspecified' which means an implementation can use whatever it wants, and needn't document or diagnose; every C++ implementation I've seen just uses the out-of-range value up to the range of the underlying type, which gives the same effect as C although not officially guaranteed. C makes an enum type _be_ an integer type, with all the properties including value range of that type. To be exact it says 'compatible', and some other places in C 'compatible' is weaker than identity, but for enum there I see no detectable difference. A C99 implementation can have extended integer types, which could cover all bit widths, but usually it provides, and uses for enums, only a few. In fact in C it is easy and common for the compiler to just use type 'int' for all enum types. (In C enums can't exceed int, so this is always safe, though not always optimal; in C++ they can, but the underlying type can exceed int only if necessary. Of course on many machines nowadays int and long are the same size anyway, and C++1X with long long hasn't been approved yet last I looked.) ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 1:10 ` Elias Salomão Helou Neto 2011-04-19 14:28 ` Georg Bauhaus @ 2011-04-25 11:06 ` Paul Colin Gloster 2011-04-25 11:00 ` Georg Bauhaus 1 sibling, 1 reply; 124+ messages in thread From: Paul Colin Gloster @ 2011-04-25 11:06 UTC (permalink / raw) [-- Attachment #1: Type: TEXT/PLAIN, Size: 2291 bytes --] Elias Salomão Helou Neto <eshneto@gmail.com> sent on April 18th, 2011: |--------------------------------------------------------------------------| |"> Uhm, no, that's a misunderstanding, Ada requires quite some thinking, | |> it is just that its basic types do not require so much thinking. | |> | |> I should stress one *major* concern of my favorite approach to | |> language definition: | |> | |> Smart brains should not have to spend time with tackling basic | |> programming techniques. In any language. They should have all | |> their thinking capacity engaged in thinking about smart solutions. | |> Not in keeping track of types' implicit sizes. That's wasted effort. | |> (PC-lint -w 4 seems to confirm this view.) | | | |There is no time spent thinking about promotions in C when you learn | |it. It is surely mor difficult to learn, so you've still made your | |point. | | | |[..]" | |--------------------------------------------------------------------------| Hi, It was suspected in John R. Anderson; and Robin Jeffries, "Novice LISP Errors: Undetected Losses of Information from Working Memory", "Human-Computer Interaction", Volume 1, 1985 that people can successfully learn to overcome minor problems, but when they later are trying to solve harder problems then they make simple mistakes which they had already learnt to not make. As an example, Elias Salomão Helou Neto has skillfully used English, but seems to have misspelt "not" with "mor" when devoting brainpower to a discussion instead of a spelling test. Anyway, the C example explicitly involved int and unsigned int and there is no guarantee that int is signed int though it is with many compilers. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-25 11:06 ` Paul Colin Gloster @ 2011-04-25 11:00 ` Georg Bauhaus 2011-04-25 12:12 ` Martin 0 siblings, 1 reply; 124+ messages in thread From: Georg Bauhaus @ 2011-04-25 11:00 UTC (permalink / raw) On 4/25/11 1:06 PM, Paul Colin Gloster wrote: > It was suspected in John R. Anderson; and Robin Jeffries, "Novice LISP > Errors: Undetected Losses of Information from Working Memory", > "Human-Computer Interaction", Volume 1, 1985 that people can > successfully learn to overcome minor problems, but when they later are > trying to solve harder problems then they make simple mistakes which > they had already learnt to not make. The impact of typos and other glitches seems a most interesting criterion for error classification and how a language facilitates ease of checking. > Anyway, the C example explicitly involved int and unsigned int and > there is no guarantee that int is signed int though it is with > many compilers. That int is signed is defined by the language C, I think. C99, § 6.2.5 ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-25 11:00 ` Georg Bauhaus @ 2011-04-25 12:12 ` Martin 2011-04-25 18:39 ` Paul Colin Gloster 0 siblings, 1 reply; 124+ messages in thread From: Martin @ 2011-04-25 12:12 UTC (permalink / raw) On Apr 25, 12:00 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > On 4/25/11 1:06 PM, Paul Colin Gloster wrote: > > > It was suspected in John R. Anderson; and Robin Jeffries, "Novice LISP > > Errors: Undetected Losses of Information from Working Memory", > > "Human-Computer Interaction", Volume 1, 1985 that people can > > successfully learn to overcome minor problems, but when they later are > > trying to solve harder problems then they make simple mistakes which > > they had already learnt to not make. > > The impact of typos and other glitches seems a most interesting criterion > for error classification and how a language facilitates ease of checking. > > > Anyway, the C example explicitly involved int and unsigned int and > > there is no guarantee that int is signed int though it is with > > many compilers. > > That int is signed is defined by the language C, I think. > C99, § 6.2.5 Keep reading: C99, §6.7.2 "5. Each of the comma-separated sets designates the same type, except that for bit-fields, it is implementation-defined whether the specifier int designates the same type as signed int or the same type as unsigned int." Now, I can see at least 2 ways this could be read...the imp-def appears to be imp-def! ;-) -- Martin ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-25 12:12 ` Martin @ 2011-04-25 18:39 ` Paul Colin Gloster 0 siblings, 0 replies; 124+ messages in thread From: Paul Colin Gloster @ 2011-04-25 18:39 UTC (permalink / raw) [-- Attachment #1: Type: TEXT/PLAIN, Size: 1217 bytes --] Martin <martin.dowie@BTOpenWorld.com> sent on April 25th, 2011: |---------------------------------------------------------------------| |"[..] | | | |C99, §6.7.2 | | | |"5. Each of the comma-separated sets designates the same type, except| |that for bit-fields, it is implementation-defined whether the | |specifier int designates the same type as signed int or the same type| |as unsigned int." | | | |Now, I can see at least 2 ways this could be read...the imp-def | |appears to be imp-def! ;-) | | | |-- Martin" | |---------------------------------------------------------------------| Mr. Dowie, Thank you for the amusing observation. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 22:26 ` Georg Bauhaus 2011-04-18 19:12 ` Elias Salomão Helou Neto @ 2011-05-08 23:41 ` wilso 2011-05-20 10:41 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 124+ messages in thread From: wilso @ 2011-05-08 23:41 UTC (permalink / raw) To: Georg Bauhaus On Sun, 17 Apr 2011 18:26:13 -0400, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote: > On 4/17/11 9:35 PM, Elias Salomï¿œo Helou Neto wrote: > >> Someone has written a line of code without knowing what it does. Is it >> a language problem? Not that C is spectacular, but blaming the >> language here is not fair. Minimally competent C programmers do know >> about such conversions. > > OK, that's a claim. Michael Barr seem to have found results > contradicting it if the "minimum" is what you minimally > find with professional C programmers. In his netrino.com embedded > C quiz, he found that US takers got at D+ on average. > That's a real world, observable minimum, then. > > I suggest turning to observable facts and away from > normative ontology for a moment. Towards justifiable > language design. > > Whenever a statistical phenomenon is observed, > many start looking for correlations and hypotheses. > Here, we have errors related to the / operation and > the promotion rules of C's $6.3.1. Is there a correlation? > Will the correlation between error rates and language > rules be the same if using another language? > Is that other language intrinsically better or worse, then? > > If there is a correlation between the frequency of a number > of programming errors (in this case related to +,-,*,/ etc) > and the way the corresponding part of the programming language > is defined (in this case operand treatment), then I suggest > the following > > Hypothesis 1: > > A language A is better designed than another B if, > after comparable introduction to the languages, > programmers of an A-group make fewer mistakes than > programmers of a B-group when implementing the same > algorithm. > > If so, then competent, informed language *design* will have to > consider expected error rates when defining the language. > Because the definitions affect error rates. > > A second perspective: > > Definition: The complexity of / (or another language feature) is > the number of concepts that a human mind will have to connect > properly in order to use / (or another language feature) correctly. > > Assumption: Programming is a human activity. > Since programs express human ideas, clear means of expression reflect > programmer intentions better than formally implicit means that > in addition depend on statements outside the language, as is the > case with C's fundamental types. > > I suggest, then, > > Hypothesis 2: > > A language A is better designed than another B if an > understanding and using the language properly is less complex, > that is, in order to express the same algorithm, > > (a) it requires thinking about fewer interconnected, possibly > implicit concepts and > > (b) depends less on statements outside the language. a number of studies of this sort were done in the 70s. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net --- ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-05-08 23:41 ` wilso @ 2011-05-20 10:41 ` Yannick Duchêne (Hibou57) 2011-05-20 16:04 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 124+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-20 10:41 UTC (permalink / raw) Le Mon, 09 May 2011 01:41:20 +0200, wilso <leon.winslow@notes.udayton.edu> a écrit: >> In his netrino.com embedded >> C quiz I just did the test, and get 9 correct answers over 10. Is that enough to win the “How to Prioritize RTOS Tasks DVD” ? :D Hope someone will create the same for Ada in the future… the price could be a cool e-Book from Jean-Pierre Rosen :D -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-05-20 10:41 ` Yannick Duchêne (Hibou57) @ 2011-05-20 16:04 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 124+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-20 16:04 UTC (permalink / raw) Le Fri, 20 May 2011 12:41:53 +0200, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit: > the price could be a cool e-Book from Jean-Pierre Rosen :D I was to mean “priZe”, sorry. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 19:35 ` Elias Salomão Helou Neto 2011-04-17 20:18 ` KK6GM 2011-04-17 22:26 ` Georg Bauhaus @ 2011-04-18 0:12 ` George P. 2011-04-18 19:24 ` Elias Salomão Helou Neto 2 siblings, 1 reply; 124+ messages in thread From: George P. @ 2011-04-18 0:12 UTC (permalink / raw) On Apr 17, 3:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com> wrote: > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote: > > > > > > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> > > wrote: > > > > On 4/17/11 8:26 AM, KK6GM wrote: > > > > > Wow and wow. I've been writing C all my adult life and I didn't > > > > realize this could or would happen. I would have said that the > > > > unsigned would be promoted to signed. > > > > > I'm going to include this example in my push to use Ada in our next > > > > project. > > > > Be careful that there are no C savvy people around. > > > You are demonstrating a lack of understanding of C basics! > > > ("Stupid!") > > > That lack is not (in their view, and it's their view that counts) > > > a good start for asking for a different language. > > > > Had you read section 2.7 of K&R (or A.6), you'd have expected > > > the result you got: arithmetic operators will convert their > > > arguments following the rules of the C language definition. > > > Yes, I understand how the "stupid" argument works in the C community. > > I'm going to ask some other programmers tomorrow and see how many of > > them get this right. I'm guessing our situation will be similar to > > the situation at the OP's workplace, where presumably competent > > programmers still got clobbered by this language-legal insanity. > > Most programmers are competent in their views. Few really are and it > does not matter what is the actual language. For example, looks like > you feel you are competent in C, but are you? > > "I would expect unsigned to int conversion" is just unacceptable! > Someone has written a line of code without knowing what it does. Is it > a language problem? Not that C is spectacular, but blaming the > language here is not fair. Minimally competent C programmers do know > about such conversions. If you don't you suck as a C programmer. If > you suck as a C programmer, please do not try to advocate any other > language over it, this _is_ stupid! > > Maybe Ada over C is a smart choice, but advocating it without having a > strong knowledge of both is unacceptable.- Hide quoted text - > > - Show quoted text - Seems that someone never worked on projects of more then few thousand lines of code, supports multiple hardware platforms and yes after programming for 30+ years in it can tell C sucks. Wonder if sudden acceleration in Toyota cars was not caused by "intuitive" C typing conversions. G. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 0:12 ` George P. @ 2011-04-18 19:24 ` Elias Salomão Helou Neto 2011-04-19 1:22 ` George P. 0 siblings, 1 reply; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-18 19:24 UTC (permalink / raw) On Apr 17, 9:12 pm, "George P." <george.p...@gmail.com> wrote: > On Apr 17, 3:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com> > wrote: > > > > > > > > > > > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote: > > > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> > > > wrote: > > > > > On 4/17/11 8:26 AM, KK6GM wrote: > > > > > > Wow and wow. I've been writing C all my adult life and I didn't > > > > > realize this could or would happen. I would have said that the > > > > > unsigned would be promoted to signed. > > > > > > I'm going to include this example in my push to use Ada in our next > > > > > project. > > > > > Be careful that there are no C savvy people around. > > > > You are demonstrating a lack of understanding of C basics! > > > > ("Stupid!") > > > > That lack is not (in their view, and it's their view that counts) > > > > a good start for asking for a different language. > > > > > Had you read section 2.7 of K&R (or A.6), you'd have expected > > > > the result you got: arithmetic operators will convert their > > > > arguments following the rules of the C language definition. > > > > Yes, I understand how the "stupid" argument works in the C community. > > > I'm going to ask some other programmers tomorrow and see how many of > > > them get this right. I'm guessing our situation will be similar to > > > the situation at the OP's workplace, where presumably competent > > > programmers still got clobbered by this language-legal insanity. > > > Most programmers are competent in their views. Few really are and it > > does not matter what is the actual language. For example, looks like > > you feel you are competent in C, but are you? > > > "I would expect unsigned to int conversion" is just unacceptable! > > Someone has written a line of code without knowing what it does. Is it > > a language problem? Not that C is spectacular, but blaming the > > language here is not fair. Minimally competent C programmers do know > > about such conversions. If you don't you suck as a C programmer. If > > you suck as a C programmer, please do not try to advocate any other > > language over it, this _is_ stupid! > > > Maybe Ada over C is a smart choice, but advocating it without having a > > strong knowledge of both is unacceptable.- Hide quoted text - > > > - Show quoted text - > > Seems that someone never worked on projects of more then few thousand > lines of code, supports multiple hardware platforms and yes after > programming for 30+ years in it can tell C sucks. > > Wonder if sudden acceleration in Toyota cars was not caused by > "intuitive" C typing conversions. Now you're making hypothesis. I don't even know the problem the, less so the language of the code, but rest assured that it was a programmer's fault. Or a compiler bug. One thing that can't be the cause is the language. Maybe lack of knowledge of it, but not the language per se. And nobody said type promotion rules in C are intuitive. They are what they are, they won't change, is it smart to keep complaining instead of go read a book? You say C sucks, ok it is an opinion. I would say someone who doesn't know type promotion rules and considers himself competent in C sucks far more. Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 19:24 ` Elias Salomão Helou Neto @ 2011-04-19 1:22 ` George P. 2011-04-19 2:06 ` Elias Salomão Helou Neto 0 siblings, 1 reply; 124+ messages in thread From: George P. @ 2011-04-19 1:22 UTC (permalink / raw) On Apr 18, 3:24 pm, Elias Salomão Helou Neto <eshn...@gmail.com> wrote: > On Apr 17, 9:12 pm, "George P." <george.p...@gmail.com> wrote: > > > > > > > On Apr 17, 3:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com> > > wrote: > > > > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote: > > > > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> > > > > wrote: > > > > > > On 4/17/11 8:26 AM, KK6GM wrote: > > > > > > > Wow and wow. I've been writing C all my adult life and I didn't > > > > > > realize this could or would happen. I would have said that the > > > > > > unsigned would be promoted to signed. > > > > > > > I'm going to include this example in my push to use Ada in our next > > > > > > project. > > > > > > Be careful that there are no C savvy people around. > > > > > You are demonstrating a lack of understanding of C basics! > > > > > ("Stupid!") > > > > > That lack is not (in their view, and it's their view that counts) > > > > > a good start for asking for a different language. > > > > > > Had you read section 2.7 of K&R (or A.6), you'd have expected > > > > > the result you got: arithmetic operators will convert their > > > > > arguments following the rules of the C language definition. > > > > > Yes, I understand how the "stupid" argument works in the C community. > > > > I'm going to ask some other programmers tomorrow and see how many of > > > > them get this right. I'm guessing our situation will be similar to > > > > the situation at the OP's workplace, where presumably competent > > > > programmers still got clobbered by this language-legal insanity. > > > > Most programmers are competent in their views. Few really are and it > > > does not matter what is the actual language. For example, looks like > > > you feel you are competent in C, but are you? > > > > "I would expect unsigned to int conversion" is just unacceptable! > > > Someone has written a line of code without knowing what it does. Is it > > > a language problem? Not that C is spectacular, but blaming the > > > language here is not fair. Minimally competent C programmers do know > > > about such conversions. If you don't you suck as a C programmer. If > > > you suck as a C programmer, please do not try to advocate any other > > > language over it, this _is_ stupid! > > > > Maybe Ada over C is a smart choice, but advocating it without having a > > > strong knowledge of both is unacceptable.- Hide quoted text - > > > > - Show quoted text - > > > Seems that someone never worked on projects of more then few thousand > > lines of code, supports multiple hardware platforms and yes after > > programming for 30+ years in it can tell C sucks. > > > Wonder if sudden acceleration in Toyota cars was not caused by > > "intuitive" C typing conversions. > > Now you're making hypothesis. I don't even know the problem the, less > so the language of the code, but rest assured that it was a > programmer's fault. Or a compiler bug. One thing that can't be the > cause is the language. Maybe lack of knowledge of it, but not the > language per se. > > And nobody said type promotion rules in C are intuitive. They are what > they are, they won't change, is it smart to keep complaining instead > of go read a book? > > You say C sucks, ok it is an opinion. I would say someone who doesn't > know type promotion rules and considers himself competent in C sucks > far more. > > Elias.- Hide quoted text - > > - Show quoted text - Oh really? So C is the language of cyborgs that never have bad days, never argue with their girlfriends and never go late night drinking? And sure none of such people should be allowed to design embedded systems :-) ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 1:22 ` George P. @ 2011-04-19 2:06 ` Elias Salomão Helou Neto 2011-04-19 2:37 ` Bill Findlay 2011-04-19 3:00 ` George P. 0 siblings, 2 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-19 2:06 UTC (permalink / raw) On Apr 18, 10:22 pm, "George P." <george.p...@gmail.com> wrote: > On Apr 18, 3:24 pm, Elias Salomão Helou Neto <eshn...@gmail.com> > wrote: > > > > > > > > > > > On Apr 17, 9:12 pm, "George P." <george.p...@gmail.com> wrote: > > > > On Apr 17, 3:35 pm, Elias Salomão Helou Neto <eshn...@gmail.com> > > > wrote: > > > > > On Apr 17, 1:15 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote: > > > > > > On Apr 16, 11:59 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> > > > > > wrote: > > > > > > > On 4/17/11 8:26 AM, KK6GM wrote: > > > > > > > > Wow and wow. I've been writing C all my adult life and I didn't > > > > > > > realize this could or would happen. I would have said that the > > > > > > > unsigned would be promoted to signed. > > > > > > > > I'm going to include this example in my push to use Ada in our next > > > > > > > project. > > > > > > > Be careful that there are no C savvy people around. > > > > > > You are demonstrating a lack of understanding of C basics! > > > > > > ("Stupid!") > > > > > > That lack is not (in their view, and it's their view that counts) > > > > > > a good start for asking for a different language. > > > > > > > Had you read section 2.7 of K&R (or A.6), you'd have expected > > > > > > the result you got: arithmetic operators will convert their > > > > > > arguments following the rules of the C language definition. > > > > > > Yes, I understand how the "stupid" argument works in the C community. > > > > > I'm going to ask some other programmers tomorrow and see how many of > > > > > them get this right. I'm guessing our situation will be similar to > > > > > the situation at the OP's workplace, where presumably competent > > > > > programmers still got clobbered by this language-legal insanity. > > > > > Most programmers are competent in their views. Few really are and it > > > > does not matter what is the actual language. For example, looks like > > > > you feel you are competent in C, but are you? > > > > > "I would expect unsigned to int conversion" is just unacceptable! > > > > Someone has written a line of code without knowing what it does. Is it > > > > a language problem? Not that C is spectacular, but blaming the > > > > language here is not fair. Minimally competent C programmers do know > > > > about such conversions. If you don't you suck as a C programmer. If > > > > you suck as a C programmer, please do not try to advocate any other > > > > language over it, this _is_ stupid! > > > > > Maybe Ada over C is a smart choice, but advocating it without having a > > > > strong knowledge of both is unacceptable.- Hide quoted text - > > > > > - Show quoted text - > > > > Seems that someone never worked on projects of more then few thousand > > > lines of code, supports multiple hardware platforms and yes after > > > programming for 30+ years in it can tell C sucks. > > > > Wonder if sudden acceleration in Toyota cars was not caused by > > > "intuitive" C typing conversions. > > > Now you're making hypothesis. I don't even know the problem the, less > > so the language of the code, but rest assured that it was a > > programmer's fault. Or a compiler bug. One thing that can't be the > > cause is the language. Maybe lack of knowledge of it, but not the > > language per se. > > > And nobody said type promotion rules in C are intuitive. They are what > > they are, they won't change, is it smart to keep complaining instead > > of go read a book? > > > You say C sucks, ok it is an opinion. I would say someone who doesn't > > know type promotion rules and considers himself competent in C sucks > > far more. > > > Elias.- Hide quoted text - > > > - Show quoted text - > > Oh really? So C is the language of cyborgs that never have bad days, > never argue with their girlfriends and never go late night drinking? > And sure none of such people should be allowed to design embedded > systems :-) No, not cyborgs, it is the language of nerds. They don't drink and about girlfriends, you've gotta be kidding! Also all of their days are bad, so they're used to it. :-) Now, seriously, what I meant is that bashing C without knowing the basics doesn't make anyone look smart. It is quite the opposite. And I repeat, whining is not the way to go here. Yes, C is dangerous, unsafe and difficult to master, but let us be men and use it well if required. I believe making assumptions about language behavior is danger. There are historical reasons why C is the way it is. Some of them were wrong, now we know, but it won't change - mainly because of the huge codebase. So, let's have fun with C, why not? I have fun with C, C++, TeX, Lisp, Pascal, Matlab, etc. Right now I am trying to find time to study Ada - more fun! I am sure I will share you guys' view about how Ada is good and safe, but it is really unlikely that I am going to become such a sissy and fill this newsgroups with foolish complaints. And as a side note, even sober, I have recently written a heavily templated C++ ray tracer which I instantiated with unsigneds as indices and signeds as difference types. There was a mixed expression that gave me some trouble, and I do understand the problem people mention in this thread. What I do not understand is how people can show pride in not knowing the language! And I can't see me whining that much because of something that won't (because it can't) change - the C language. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 2:06 ` Elias Salomão Helou Neto @ 2011-04-19 2:37 ` Bill Findlay 2011-04-19 3:00 ` George P. 1 sibling, 0 replies; 124+ messages in thread From: Bill Findlay @ 2011-04-19 2:37 UTC (permalink / raw) On 19/04/2011 03:06, in article 2693b280-bbe2-45ea-8355-e96ccbc381f9@a26g2000vbo.googlegroups.com, "Elias Salom�o Helou Neto" <eshneto@gmail.com> wrote: ... > Yes, C is dangerous, unsafe and difficult to master, > but LET US BE MEN and use it well if required. ... > IT IS REALLY UNLIKELY THAT I AM GOING TO BECOME SUCH A SISSY > and fill this newsgroups with foolish complaints. It is a truth universally acknowledged that defenders of C eventually stoop to macho posturing. -- Bill Findlay with blueyonder.co.uk; use surname & forename; ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 2:06 ` Elias Salomão Helou Neto 2011-04-19 2:37 ` Bill Findlay @ 2011-04-19 3:00 ` George P. 1 sibling, 0 replies; 124+ messages in thread From: George P. @ 2011-04-19 3:00 UTC (permalink / raw) On Apr 18, 10:06 pm, Elias Salomão Helou Neto <eshn...@gmail.com> wrote: > On Apr 18, 10:22 pm, "George P." <george.p...@gmail.com> wrote: > > > > > > > > Oh really? So C is the language of cyborgs that never have bad days, > > never argue with their girlfriends and never go late night drinking? > > And sure none of such people should be allowed to design embedded > > systems :-) > > No, not cyborgs, it is the language of nerds. They don't drink and > about girlfriends, you've gotta be kidding! Also all of their days are > bad, so they're used to it. > :-) > > Now, seriously, what I meant is that bashing C without knowing the > basics doesn't make anyone look smart. It is quite the opposite. And I > repeat, whining is not the way to go here. Yes, C is dangerous, unsafe > and difficult to master, but let us be men and use it well if > required. > > I believe making assumptions about language behavior is danger. There > are historical reasons why C is the way it is. Some of them were > wrong, now we know, but it won't change - mainly because of the huge > codebase. So, let's have fun with C, why not? I have fun with C, C++, > TeX, Lisp, Pascal, Matlab, etc. Right now I am trying to find time to > study Ada - more fun! I am sure I will share you guys' view about how > Ada is good and safe, but it is really unlikely that I am going to > become such a sissy and fill this newsgroups with foolish complaints. > > And as a side note, even sober, I have recently written a heavily > templated C++ ray tracer which I instantiated with unsigneds as > indices and signeds as difference types. There was a mixed expression > that gave me some trouble, and I do understand the problem people > mention in this thread. What I do not understand is how people can > show pride in not knowing the language! And I can't see me whining > that much because of something that won't (because it can't) change - > the C language.- Hide quoted text - > > - Show quoted text - I thought you was the first accusing incompetence here. I respect your talents in mastering so many languages, but for many of us languages are just tools to solve problems. Thinking of the problem is hard enough. Thus, combing throuh code trying to figure out what compiler will do is just ectra distruction. I understand very well that C is sort of F1 racing car. It's all good, but if you are in freight business investing in F1 car is of questionable value (except for promotion). For those of us who is in commercial application development cost/value becomes of importance. What we are getting in costs? Special bread of coders, lengthy development cycle (you admitted yourself your excapade with templates), possibility of having sleeping bugs. Now what will be the value? 10-20% performance? Sometime we are forced to use languages by hardware vendors... G. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 17:02 Fun with C George P. 2011-04-16 20:04 ` Nasser M. Abbasi 2011-04-17 6:26 ` KK6GM @ 2011-04-17 19:19 ` Elias Salomão Helou Neto 2011-04-17 23:26 ` Gautier write-only 2011-04-20 5:11 ` J-P. Rosen 2011-04-23 23:07 ` Gerd 3 siblings, 2 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-17 19:19 UTC (permalink / raw) On Apr 16, 2:02 pm, "George P." <george.p...@gmail.com> wrote: > Spend few days chasing bug in embedded C project which can drilled > down to this. Consider the following program, and all reasonable men > will expect the result to be negative. Not in C, and it is not a > compiler bug :-( All reasonable men will try to learn the language before programming. The mentioned behavior is the one C is supposed to have, whether you like it or not. It one of the first thing I teach in my C classes: type promotions in expression. They may be dumb, or may not, I will not argue on that. But being reasonable is knowing the tool before trying to use it. Is this also a bug? int i = 1; int j = 2; double result = i / j; printf("%lf\n", result); results in 0 being output. Oh my god, C can't perform arithmetic division! More fun with C? ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 19:19 ` Elias Salomão Helou Neto @ 2011-04-17 23:26 ` Gautier write-only 2011-04-17 23:43 ` Nasser M. Abbasi 2011-04-18 19:13 ` Elias Salomão Helou Neto 2011-04-20 5:11 ` J-P. Rosen 1 sibling, 2 replies; 124+ messages in thread From: Gautier write-only @ 2011-04-17 23:26 UTC (permalink / raw) On 17 avr, 21:19, Elias Salomão Helou Neto <eshn...@gmail.com> wrote: > All reasonable men will try to learn the language before programming. Waw! Then you won't meet many reasonable people in companies (or perhaps only among those who never program)... ______________________________________________________________________________ Gautier's Ada programming -- http://gautiersblog.blogspot.com/search/label/Ada NB: follow the above link for a valid e-mail address ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 23:26 ` Gautier write-only @ 2011-04-17 23:43 ` Nasser M. Abbasi 2011-04-18 19:16 ` Elias Salomão Helou Neto 2011-04-18 19:13 ` Elias Salomão Helou Neto 1 sibling, 1 reply; 124+ messages in thread From: Nasser M. Abbasi @ 2011-04-17 23:43 UTC (permalink / raw) On 4/17/2011 4:26 PM, Gautier write-only wrote: > On 17 avr, 21:19, Elias Salom�o Helou Neto<eshn...@gmail.com> wrote: > >> All reasonable men will try to learn the language before programming. > > Waw! Then you won't meet many reasonable people in companies (or > perhaps only among those who never program)... I must have been doing something really wrong all those years, becuase the only way I learned a new language was by programming in it. --Nasser ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 23:43 ` Nasser M. Abbasi @ 2011-04-18 19:16 ` Elias Salomão Helou Neto 2011-04-18 23:10 ` Randy Brukardt 0 siblings, 1 reply; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-18 19:16 UTC (permalink / raw) On Apr 17, 8:43 pm, "Nasser M. Abbasi" <n...@12000.org> wrote: > On 4/17/2011 4:26 PM, Gautier write-only wrote: > > > On 17 avr, 21:19, Elias Salom o Helou Neto<eshn...@gmail.com> wrote: > > >> All reasonable men will try to learn the language before programming. > > > Waw! Then you won't meet many reasonable people in companies (or > > perhaps only among those who never program)... > > I must have been doing something really wrong all those years, > becuase the only way I learned a new language was by > programming in it. Without even reading a book about it? You are doing things terribly wrong. Of course programming is the best way to learn, but not without a good book to read while practicing. Furthermore, have you being learning while writing code for a critical embedded system? If so, you should be in jail. Only those who already know what is doing should code this stuff. Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 19:16 ` Elias Salomão Helou Neto @ 2011-04-18 23:10 ` Randy Brukardt 2011-04-19 1:36 ` Elias Salomão Helou Neto 0 siblings, 1 reply; 124+ messages in thread From: Randy Brukardt @ 2011-04-18 23:10 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1539 bytes --] "Elias Salom�o Helou Neto" <eshneto@gmail.com> wrote in message news:d169b543-eed4-4a0a-a295-e391c198463e@j9g2000prj.googlegroups.com... On Apr 17, 8:43 pm, "Nasser M. Abbasi" <n...@12000.org> wrote: ... >> I must have been doing something really wrong all those years, >> becuase the only way I learned a new language was by >> programming in it. > >Without even reading a book about it? You are doing things terribly >wrong. Of course programming is the best way to learn, but not without >a good book to read while practicing. There aren't always books to read. We wrote a partial Ada *compiler* back in 1980 from a description circulated by our professor (Janus/Ada originally started in a compiler construction course). The only book that we had (and we didn't get that until near the end of the class when we had already decided to commercialize it) was the 1980 Ada Reference Manual. I'm pretty sure that we had already converted the entire compiler into Ada code (so it could compile itself) before we saw any of the early Ada textbooks. (The Pyle textbook that we distributed with the compiler didn't come out until late 1981, I think.) That was OK, Ada wasn't that different than Pascal which we both already knew well. I recall being asked on several occassions why we were able to build an Ada compiler is so much less time and manpower than everyone else. And there was no secret -- we used Ada and probably didn't spend as much time debugging as others. Randy. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-18 23:10 ` Randy Brukardt @ 2011-04-19 1:36 ` Elias Salomão Helou Neto 2011-04-20 23:14 ` Randy Brukardt 0 siblings, 1 reply; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-19 1:36 UTC (permalink / raw) On Apr 18, 8:10 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > "Elias Salomão Helou Neto" <eshn...@gmail.com> wrote in messagenews:d169b543-eed4-4a0a-a295-e391c198463e@j9g2000prj.googlegroups.com... > On Apr 17, 8:43 pm, "Nasser M. Abbasi" <n...@12000.org> wrote: > ... > > >> I must have been doing something really wrong all those years, > >> becuase the only way I learned a new language was by > >> programming in it. > > >Without even reading a book about it? You are doing things terribly > >wrong. Of course programming is the best way to learn, but not without > >a good book to read while practicing. > > There aren't always books to read. C books? Come on! > We wrote a partial Ada *compiler* back in > 1980 from a description circulated by our professor (Janus/Ada originally > started in a compiler construction course). Surely the first Ada compiler you wrote wasn't coded in Ada itself. Haven't you read any book about the language used to code the compiler before? Weren't the professor's description a kind of "book"? So keep saying people that they do not need to study the language they intend to write code on. This is really smart, isn't it? > The only book that we had (and > we didn't get that until near the end of the class when we had already > decided to commercialize it) was the 1980 Ada Reference Manual. So you're again trying to claim you have written a compiler without knowledge of the language to be compiled? It must be some kind of magic, for sure. Again, what about the description by your teacher? > I'm pretty > sure that we had already converted the entire compiler into Ada code (so it > could compile itself) before we saw any of the early Ada textbooks. (The > Pyle textbook that we distributed with the compiler didn't come out until > late 1981, I think.) After writing an Ada compiler it is very unlikely for someone not to know the language. There are lots of C textbooks, why not to use them? Nonsense. Also, please notice that I've recommended a book for those that are learning the language, not for those who have already mastered it (but even so a good reference manual is invaluable). > > That was OK, Ada wasn't that different than Pascal which we both already > knew well. This is dangerous. People seem to believe C is like Pascal or BASIC. Is this knowing C? This is the kind of misconception we have to fight. No programmer should claim to know C (or any other language) if he/she doesn't really knows it. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-19 1:36 ` Elias Salomão Helou Neto @ 2011-04-20 23:14 ` Randy Brukardt 2011-04-21 16:19 ` Elias Salomão Helou Neto 0 siblings, 1 reply; 124+ messages in thread From: Randy Brukardt @ 2011-04-20 23:14 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 6762 bytes --] "Elias Salom�o Helou Neto" <eshneto@gmail.com> wrote in message news:86748003-860f-4729-ae26-55be1e58ac2b@d27g2000vbz.googlegroups.com... >On Apr 18, 8:10 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: >> "Elias Salom�o Helou Neto" <eshn...@gmail.com> wrote in >> messagenews:d169b543-eed4-4a0a-a295-e391c198463e@j9g2000prj.googlegroups.com... >> On Apr 17, 8:43 pm, "Nasser M. Abbasi" <n...@12000.org> wrote: >> ... >> >> >> I must have been doing something really wrong all those years, >> >> becuase the only way I learned a new language was by >> >> programming in it. >> >> >Without even reading a book about it? You are doing things terribly >> >wrong. Of course programming is the best way to learn, but not without >> >a good book to read while practicing. >> >> There aren't always books to read. > >C books? Come on! We're not talking about C specifically, we're talking about "a new language". >> We wrote a partial Ada *compiler* back in >> 1980 from a description circulated by our professor (Janus/Ada originally >> started in a compiler construction course). > >Surely the first Ada compiler you wrote wasn't coded in Ada itself. >Haven't you read any book about the language used to code the compiler >before? Sure, but irrelevant, since we had to create test programs for the compiler in Ada (gotta test that it works), and that requires some understanding of the language. > Weren't the professor's description a kind of "book"? Depends on what you meant by "good book". A raw language description (as in the professor's handful of mimographed sheets) or even the Ada Reference Manual doesn't seem to be a "good book" about programming in the language. I had presumed that you meant "textbook" when you said "book", because otherwise your statement doesn't seem to say anything useful (by definition you'd have to read a language description to program, but there is no such requirement to read a book about how best to program in a particular language). Even so, the professor's description looked nothing like a "book", in any sense of the term. So you have to be so expansive about the meaning of "book" to have made a meaningless statement. > So keep saying people that they do not need to study the language they > intend to write code on. This is really smart, isn't it? Huh? I said no such thing. I simply said that you don't necessarily need a "book". I meant "textbook" when I said that, but it is really strictly true as well: you need a "language description", but it surely doesn't need to be in the form of a book -- it could be a handful of loose pages, it could be a a web site somewhere, a help file, or even a program editor. Go back and re-read the statement that you made: "...but not without a good book to read while practicing.". I disagree with this statement as written, and I explained why. I also didn't feel any need to insult you when disagreeing with you, which does not help your point any. >> The only book that we had (and >> we didn't get that until near the end of the class when we had already >> decided to commercialize it) was the 1980 Ada Reference Manual. > >So you're again trying to claim you have written a compiler without >knowledge of the language to be compiled? It must be some kind of >magic, for sure. Again, what about the description by your teacher? It surely was not a "book". And by no stretch of the imagination, a "good book"! These days, I hardly expect anyone to expect requiring a "book" to do anything. Even counting "e-books" as "books", there are a lot of information sources which have nothing to do with "books". It was a lot harder to understand back in 1981, yet it still happened then (and even then there were a lot of information sources having nothing to do with books - papers, magazine articles, seminars, lectures, computer-aided-instruction). >> I'm pretty >> sure that we had already converted the entire compiler into Ada code (so >> it >> could compile itself) before we saw any of the early Ada textbooks. (The >> Pyle textbook that we distributed with the compiler didn't come out until >> late 1981, I think.) > >After writing an Ada compiler it is very unlikely for someone not to >know the language. There are lots of C textbooks, why not to use them? >Nonsense. We're not talking about C specifically, we're talking about "a new language" in general. And I doubt I would *buy* a textbook these days; pretty much everything one needs is on-line (and often not in the form of a book!). >Also, please notice that I've recommended a book for those that are >learning the language, not for those who have already mastered it (but >even so a good reference manual is invaluable). Again, I don't give a hose about C; I see no reason to waste my time with obscure language wars. (Ada is best, and that's it. :-) >> That was OK, Ada wasn't that different than Pascal which we both already >> knew well. > >This is dangerous. People seem to believe C is like Pascal or BASIC. >Is this knowing C? This is the kind of misconception we have to fight. Maybe *you* have to fight it. I happen to think that a language that is unnecessarily different than what a typical programmer would expect is dangerous. (And yes, Ada suffers from this in a few places as well -- and those things are also dangerous.) A lot of people (not me, thankfully) have to program in a polyglot of languages, and remembering the obscure rules of one or the other without confusing them is difficult. We had this problem in the first year of Janus/Ada, when we were programming in Pascal, Modula I (for classes), and Ada all at the same time. Lots of mistakes made where they differed -- luckily most of those were compile-time failures and thus didn't cause bugs. >No programmer should claim to know C (or any other language) if he/she >doesn't really knows it. I don't claim to know C (anymore), but that doesn't prevent me from hating it. :-) The one project I was forced to write in C (rather than Pascal or Modula) during my university days was the only such project that didn't work at the deadline. (And I was annoyed enough to spend several hours afterwards figuring out why it didn't work - the bug turned out to be a missing pointer dereference which the C compiler was happy to ignore.) Since then, I've learned to detest the C syntax -- I don't even get to hating the semantics. The only C I do is to read it well enough to be able to write interfaces to C APIs. I realize this is somewhat irrational, which is why I try to stay out of language wars -- there is no way to win (I'm more likely to marry a supermodel than I am to change my mind about C! :-) Randy. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-20 23:14 ` Randy Brukardt @ 2011-04-21 16:19 ` Elias Salomão Helou Neto 2011-04-21 17:36 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-21 16:19 UTC (permalink / raw) > We're not talking about C specifically, we're talking about "a new > language". New to the programmer or to the world? If it is the former, I still recommend a book. A textbook will take you from the basics to the more advanced features of the language. This is the way to learn. By skipping the first steps people simply won't know the most basic stuff, such as C's type promotions. Instead, people like to program by "trial and error". Which will rarely, if ever, work. > > >> We wrote a partial Ada *compiler* back in > >> 1980 from a description circulated by our professor (Janus/Ada originally > >> started in a compiler construction course). > > >Surely the first Ada compiler you wrote wasn't coded in Ada itself. > >Haven't you read any book about the language used to code the compiler > >before? > > Sure, but irrelevant, since we had to create test programs for the compiler > in Ada (gotta test that it works), and that requires some understanding of > the language. Not at all irrelevant. Test programs are not real-life programs, while a compiler surely is. Furthermore, the language description you had from your professor had to be deeply studied in order to get the compiler working. So you've had to learn from the most basic to the most advanced feature of the language. > Depends on what you meant by "good book". A raw language description (as in > the professor's handful of mimographed sheets) or even the Ada Reference > Manual doesn't seem to be a "good book" about programming in the language. I > had presumed that you meant "textbook" when you said "book". Ok. > Go back and re-read the statement that you made: "...but not without a good > book to read while practicing.". I disagree with this statement as written, > and I explained why. I also didn't feel any need to insult you when > disagreeing with you, which does not help your point any. Did I insult you? Sorry if I did. But I keep the reasoning: go and read a book before programming. One that progressively goes from the basic to the advanced features in a reasonable way. You are a talented programmer and learned Ada from a description. But you did not start to write random code in Ada. You had a solid foundation on it because you had to be precise when writing the compiler. I am sure you will notice how different it is from just "starting coding and making it compile". > These days, I hardly expect anyone to expect requiring a "book" to do > anything. Even counting "e-books" as "books", there are a lot of information > sources which have nothing to do with "books". It was a lot harder to > understand back in 1981, yet it still happened then (and even then there > were a lot of information sources having nothing to do with books - papers, > magazine articles, seminars, lectures, computer-aided-instruction). I still do not recommend any of those as means for a beginner to learn a language: papers are not for beginners; magazine articles are too vague or too specific; seminars are usually too short to be of any use for beginners and they are, decause of being short, focused on a too narrow or too vague subject; lectures are good, but good lecturers will likely indicate a bibliography, which will include textbooks if it is intended to beginners. Perhaps computer-aided-instruction, but I haven't seen it in use, so I do not recommend it. Remember, I am a professor. I do lecture and present seminars. And no, seminars won't teach you how to program. Neither will the lectures, unless followed by laboratory classes and homeworks, which should be done alongside a good book on the subject. Honestly, I do not like students taking notes of my lectures, they should be paying attention and latter they should use the recommended book as a reference. Unless I've explicitly stated otherwise. > >After writing an Ada compiler it is very unlikely for someone not to > >know the language. There are lots of C textbooks, why not to use them? > >Nonsense. > > We're not talking about C specifically, we're talking about "a new language" > in general. I don't get it. Which new language may someone want to learn for which there is no good textbook available? Again, do you mean "new to the programmer" or "new to the world"? > And I doubt I would *buy* a textbook these days; pretty much everything one > needs is on-line (and often not in the form of a book!). Even though there is plenty information on the internet, books are still worth buying, I am sure of that. You can't (legally) find the really good textbooks on-line neither you can find anything comparable to those textbooks. Good information still has its price. As a test, find me a replacement for "C++ Primer" on-line. > >Also, please notice that I've recommended a book for those that are > >learning the language, not for those who have already mastered it (but > >even so a good reference manual is invaluable). > > Again, I don't give a hose about C; I see no reason to waste my time with > obscure language wars. (Ada is best, and that's it. :-) It is true that I said "learning _the_ language" and that it referred to C, but it surely applies to any language. > Maybe *you* have to fight it. I happen to think that a language that is > unnecessarily different than what a typical programmer would expect is > dangerous. (And yes, Ada suffers from this in a few places as well -- and > those things are also dangerous.) Ops. I think you're wrong here. Programming languages _must_ be different from each other, otherwise there would not be reason for so many to exist. And some new, useful, paradigms appear that can't be natural to any programmer simply because it did not exist before its invention! > I don't claim to know C (anymore), but that doesn't prevent me from hating > it. :-) I did not mean that you claim to do so, but that other did when they should not. > I realize this is somewhat irrational, which is why I try to stay out of > language wars -- there is no way to win (I'm more likely to marry a > supermodel than I am to change my mind about C! :-) I am not quite into language wars too. I have never advocated one language over another, just look at my posts above. So, forget C and good luck in marrying a supermodel. When it happens, if she has any friends, please introduce me to them :-) Elias ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 16:19 ` Elias Salomão Helou Neto @ 2011-04-21 17:36 ` Dmitry A. Kazakov 2011-04-21 17:43 ` Hyman Rosen 2011-04-22 6:16 ` Elias Salomão Helou Neto 2011-04-21 23:29 ` Randy Brukardt 2011-04-25 11:22 ` Paul Colin Gloster 2 siblings, 2 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-21 17:36 UTC (permalink / raw) On Thu, 21 Apr 2011 09:19:08 -0700 (PDT), Elias Salom�o Helou Neto wrote: > Ops. I think you're wrong here. Programming languages _must_ be > different from each other, otherwise there would not be reason for so > many to exist. And some new, useful, paradigms appear that can't be > natural to any programmer simply because it did not exist before its > invention! Nope. A counterexample is natural languages. There are many of them. They are different in some senses and same in others. Languages existed before poetry, novels, scripts and graffiti were invented. I doubt that a language (natural or formal) can be designed for new paradigms. Rather it is so that so-called "paradigms" are imprinted in our brains and languages just reflect the ways we are thinking. This, I think, can explain popularity of such outrageously poor languages like C. C programmers are in majority simply because most of programmers do think as they write. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 17:36 ` Dmitry A. Kazakov @ 2011-04-21 17:43 ` Hyman Rosen 2011-04-21 19:44 ` Dmitry A. Kazakov 2011-04-22 6:16 ` Elias Salomão Helou Neto 1 sibling, 1 reply; 124+ messages in thread From: Hyman Rosen @ 2011-04-21 17:43 UTC (permalink / raw) On 4/21/2011 1:36 PM, Dmitry A. Kazakov wrote: > C programmers are in majority simply because most > of programmers do think as they write. Why do you believe that Ada programmers do not also do that? I don't know Ada, but if I were to sit down to write an Ada program I would also write it as I was thinking, and would simply add and modify types and interfaces as needed. I expect I would also compile frequently and let the compiler tell me where I missed a spot and then just go and fix it up. In fact, it seems to me that Ada is more conducive to think-and-type than C is, because the compiler is better at telling you when you've gotten something wrong. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 17:43 ` Hyman Rosen @ 2011-04-21 19:44 ` Dmitry A. Kazakov 0 siblings, 0 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-21 19:44 UTC (permalink / raw) On Thu, 21 Apr 2011 13:43:46 -0400, Hyman Rosen wrote: > On 4/21/2011 1:36 PM, Dmitry A. Kazakov wrote: >> C programmers are in majority simply because most > > of programmers do think as they write. > > Why do you believe that Ada programmers do not also do that? Certainly they do! > I don't know Ada, but if I were to sit down to write an Ada > program I would also write it as I was thinking, and would > simply add and modify types and interfaces as needed. I expect > I would also compile frequently and let the compiler tell me > where I missed a spot and then just go and fix it up. In fact, > it seems to me that Ada is more conducive to think-and-type > than C is, because the compiler is better at telling you when > you've gotten something wrong. Yes, but in order to value this you must be comfortable with this way of thinking. Most programmers are not. They feel the "Ada's way" constraining rather than helping. You can make Ada more popular only through an extensive training and selection. Compare it with guitar playing. When you start, you find proper hand positions extremely demanding. Not every must play guitar, but programmers are just too many. Like a good musician can learn to play any instrument, any good C programmer can easily switch to Ada and enjoy it. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 17:36 ` Dmitry A. Kazakov 2011-04-21 17:43 ` Hyman Rosen @ 2011-04-22 6:16 ` Elias Salomão Helou Neto 2011-04-22 9:21 ` Dmitry A. Kazakov 2011-04-22 12:15 ` J-P. Rosen 1 sibling, 2 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-22 6:16 UTC (permalink / raw) On Apr 21, 2:36 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Thu, 21 Apr 2011 09:19:08 -0700 (PDT), Elias Salom o Helou Neto wrote: > > > Ops. I think you're wrong here. Programming languages _must_ be > > different from each other, otherwise there would not be reason for so > > many to exist. And some new, useful, paradigms appear that can't be > > natural to any programmer simply because it did not exist before its > > invention! > > Nope. A counterexample is natural languages. There are many of them. They > are different in some senses and same in others. Languages existed before > poetry, novels, scripts and graffiti were invented. > I doubt that a language (natural or formal) can be designed for new > paradigms. > Rather it is so that so-called "paradigms" are imprinted in our > brains and languages just reflect the ways we are thinking. Could you please elaborate on that? I understand (and mostly agree with) your claim that all paradigms are imprinted in our brains, but I'd rather still call one of them new if it is the first time it is actually explicitly stated and used for a purpose such as designing a programming language. > This, I think, > can explain popularity of such outrageously poor languages like C. C > programmers are in majority simply because most of programmers do think as > they write. Yep. That's a major problem. No matter how much I try to teach people to think before coding, they won't do so. But I don't think that Ada makes it any better, does it? It is not a claim, since I could not do it without knowing Ada, but rather a truly interested question. And I fail to see why is C so "outrageously poor". My view is that professional programmers deserve much more this epithet than C does. Remember all those guys you've interviewed that couldn't mentally do an XOR with 0xFF? My tendency is to say they're the ones who are "outrageously poor". Of course this is a rather good justification for Ada to be more widely adopted. As I've said elsewhere on this thread, Ada's premises are far more realistic than C's ones. But it does not make C a lame language. Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-22 6:16 ` Elias Salomão Helou Neto @ 2011-04-22 9:21 ` Dmitry A. Kazakov 2011-04-22 13:18 ` Hyman Rosen 2011-04-23 2:08 ` Elias Salomão Helou Neto 2011-04-22 12:15 ` J-P. Rosen 1 sibling, 2 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-22 9:21 UTC (permalink / raw) On Thu, 21 Apr 2011 23:16:47 -0700 (PDT), Elias Salom�o Helou Neto wrote: > On Apr 21, 2:36�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Thu, 21 Apr 2011 09:19:08 -0700 (PDT), Elias Salom o Helou Neto wrote: >> >>> Ops. I think you're wrong here. Programming languages _must_ be >>> different from each other, otherwise there would not be reason for so >>> many to exist. And some new, useful, paradigms appear that can't be >>> natural to any programmer simply because it did not exist before its >>> invention! >> >> Nope. A counterexample is natural languages. There are many of them. They >> are different in some senses and same in others. Languages existed before >> poetry, novels, scripts and graffiti were invented. >> I doubt that a language (natural or formal) can be designed for new >> paradigms. >> Rather it is so that so-called "paradigms" are imprinted in our >> brains and languages just reflect the ways we are thinking. > > Could you please elaborate on that? I understand (and mostly agree > with) your claim that all paradigms are imprinted in our brains, but > I'd rather still call one of them new if it is the first time it is > actually explicitly stated and used for a purpose such as designing a > programming language. I think that all significant paradigms are already stated. All languages we are talking about are equivalent in terms of Turing completeness. Paradigms are of course finer than that, but still I believe that there is nothing significantly new left. All these agent-, aspect-, cloud-, extreme-, whatever stuff was known and used before 1980. >> This, I think, >> can explain popularity of such outrageously poor languages like C. C >> programmers are in majority simply because most of programmers do think as >> they write. > > Yep. That's a major problem. No matter how much I try to teach people > to think before coding, they won't do so. Not every man or woman can program. I doubt that programming should be taught to people specializing on other majors. Sorry guys, programming is not a modern lingua franca. > But I don't think that Ada > makes it any better, does it? It is not a claim, since I could not do > it without knowing Ada, but rather a truly interested question. I agree. Ada is a tool, it is no cure. Nevertheless, future professional programmers should never be exposed to C as the first language. It is like teaching physics in the school. Pupils first learn the physics of XIX century. When they made 3/4, they are told: guys, that was wrong! Here is how it goes! Programmers must learn concepts and techniques which C cannot illustrate. What C can illustrate is how not to program. > And I fail to see why is C so "outrageously poor". My view is that > professional programmers deserve much more this epithet than C does. > Remember all those guys you've interviewed that couldn't mentally do > an XOR with 0xFF? My tendency is to say they're the ones who are > "outrageously poor". One poor with another poor does not make it good. My point is that poor programmers prefer poor languages. Both are in majority and without selection this state will maintain itself infinitely. So the first step for programming to become engineering will be deliberate extermination of certain language features and practices, which dominate in C. Having said that, I don't claim that Ada is that ideal language. It is a long way ahead. Even so, there is no reason to look back trying to move forward. > Of course this is a rather good justification for Ada to be more > widely adopted. As I've said elsewhere on this thread, Ada's premises > are far more realistic than C's ones. But it does not make C a lame > language. C is poor for teaching because it takes too much noise to illustrate basic programming concepts like array, string, result of a function etc. It is full of silly limitations, which programmers must learn to circumvent, before they get at the core ideas. In the end they learn only these tricks and think that programming is about that, lacking understanding of software engineering as a whole. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-22 9:21 ` Dmitry A. Kazakov @ 2011-04-22 13:18 ` Hyman Rosen 2011-04-22 15:17 ` Dmitry A. Kazakov 2011-04-23 2:08 ` Elias Salomão Helou Neto 1 sibling, 1 reply; 124+ messages in thread From: Hyman Rosen @ 2011-04-22 13:18 UTC (permalink / raw) On 4/22/2011 5:21 AM, Dmitry A. Kazakov wrote: > Not every man or woman can program. I doubt that programming > should be taught to people specializing on other majors. No, you're wrong about that. It is correct that not everyone can program, but many people exhibit a talent for it regardless of their major, and may not know that because they've never tried. If you limit teaching programming to those who are majoring in software-related fields, you'll lose a lot of possible talent. > software engineering When I was still reading computer journals many years ago, it seemed to me that papers on software engineering were only about doing various kinds of measurements of the development process, and were dull and useless. They were never about how to program well. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-22 13:18 ` Hyman Rosen @ 2011-04-22 15:17 ` Dmitry A. Kazakov 0 siblings, 0 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-22 15:17 UTC (permalink / raw) On Fri, 22 Apr 2011 09:18:20 -0400, Hyman Rosen wrote: > On 4/22/2011 5:21 AM, Dmitry A. Kazakov wrote: >> Not every man or woman can program. I doubt that programming >> should be taught to people specializing on other majors. > > No, you're wrong about that. It is correct that not everyone > can program, but many people exhibit a talent for it regardless > of their major, and may not know that because they've never tried. They may have a talent to knitting. So what? Programming is not a fundamental knowledge like mathematics or physics that any educated person must know. > If you limit teaching programming to those who are majoring in > software-related fields, you'll lose a lot of possible talent. I don't care of a surgeon having some talent to programming. I care of programmers. I don't want either programming surgeons or programmers performing surgical operations. >> software engineering > > When I was still reading computer journals many years ago, it > seemed to me that papers on software engineering were only about > doing various kinds of measurements of the development process, and > were dull and useless. Right, CS is not a science and programming is not engineering. These papers are as scientific as knitting journals... > They were never about how to program well. Yep, differently to them people publishing knitting musters at least can knit. (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-22 9:21 ` Dmitry A. Kazakov 2011-04-22 13:18 ` Hyman Rosen @ 2011-04-23 2:08 ` Elias Salomão Helou Neto 2011-04-23 7:23 ` Dmitry A. Kazakov ` (2 more replies) 1 sibling, 3 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-23 2:08 UTC (permalink / raw) On Apr 22, 6:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > I think that all significant paradigms are already stated. All languages we > are talking about are equivalent in terms of Turing completeness. Paradigms > are of course finer than that, but still I believe that there is nothing > significantly new left. All these agent-, aspect-, cloud-, extreme-, > whatever stuff was known and used before 1980. I must mention that it is always like that, people tend to believe that every paradigm is already around until someone comes up with a "new" one. But it may pretty well be the case that you're right and they're all already stated, I guess there is just no way to know. > Not every man or woman can program. I doubt that programming should be > taught to people specializing on other majors. Sorry guys, programming is > not a modern lingua franca. Surely you're right. But still I have to teach my students... > Nevertheless, future professional programmers should never be exposed to C > as the first language. It is like teaching physics in the school. Pupils > first learn the physics of XIX century. When they made 3/4, they are told: > guys, that was wrong! Here is how it goes! Programmers must learn concepts > and techniques which C cannot illustrate. What C can illustrate is how not > to program. When it comes to physics, the main reason to teach classical mechanical is that it is actually a good approximation to modern theories and the math is far more simple. Nobody will say "guys, that was wrong!" because that is not wrong, it just must be used within its valid limits. Rockets reached the moon based on computations that used classical Newtonian mechanics. It is quite different with programming languages, as C is actually harder than Pascal, which is a great tool for teaching programming. Only for the record, my current students are not supposed to become professional programmers, but physicists. Not that it actually matters, since those who should become professionals are exposed to C as a first programming language as well in here. > C is poor for teaching because it takes too much noise to illustrate basic > programming concepts like array, string, result of a function etc. It is > full of silly limitations, which programmers must learn to circumvent, > before they get at the core ideas. In the end they learn only these tricks > and think that programming is about that, lacking understanding of software > engineering as a whole. C is terrible for teaching, but it is not up to me to decide which language to teach in those introductory classes. Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 2:08 ` Elias Salomão Helou Neto @ 2011-04-23 7:23 ` Dmitry A. Kazakov 2011-04-23 9:42 ` Georg Bauhaus 2011-04-23 18:37 ` Elias Salomão Helou Neto 2011-04-23 15:23 ` George P. 2011-04-23 16:56 ` Nasser M. Abbasi 2 siblings, 2 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-23 7:23 UTC (permalink / raw) On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salom�o Helou Neto wrote: > On Apr 22, 6:21�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >> Nevertheless, future professional programmers should never be exposed to C >> as the first language. It is like teaching physics in the school. Pupils >> first learn the physics of XIX century. When they made 3/4, they are told: >> guys, that was wrong! Here is how it goes! Programmers must learn concepts >> and techniques which C cannot illustrate. What C can illustrate is how not >> to program. > > When it comes to physics, the main reason to teach classical > mechanical is that it is actually a good approximation to modern > theories and the math is far more simple. Nobody will say "guys, that > was wrong!" because that is not wrong, it just must be used within its > valid limits. I heard that wrong argument so many times. > Rockets reached the moon based on computations that used > classical Newtonian mechanics. So? Linux was written in C, does it justify C? [I hope your students do not build rockets (:-))] > It is quite different with programming languages, as C is actually > harder than Pascal, which is a great tool for teaching programming. In which sense is C harder? I bet students find it simple. It is hard to teach concepts of software design on example of C? But Newtonian mechanics is perfect for teaching cosmology, quantum effects, optics, fields etc? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 7:23 ` Dmitry A. Kazakov @ 2011-04-23 9:42 ` Georg Bauhaus 2011-04-23 10:23 ` Dmitry A. Kazakov 2011-04-23 18:37 ` Elias Salomão Helou Neto 1 sibling, 1 reply; 124+ messages in thread From: Georg Bauhaus @ 2011-04-23 9:42 UTC (permalink / raw) On 4/23/11 9:23 AM, Dmitry A. Kazakov wrote: > On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salomão Helou Neto wrote: >> It is quite different with programming languages, as C is actually >> harder than Pascal, which is a great tool for teaching programming. > > In which sense is C harder? C is harder to learn from the ground up, as your first formalism, when measured by the number of non-intuitive and non-essential fundamental concepts that students must all understand in order to understand and use fundamental ideas of C. Notions are formed by distinction. Formally, each distinction D(n) means another fork in the "tree of rules" that a human mind must climb when trying to understand what's in the leaves. Humans have limited capacity when following decision trees in any case, not just when learning. More so when topics change along the way, as is the case with C, as explained below. Changing topics requires context switching---which is another distinction, thus f(D(n)) where f >= id. Some of C's concepts will draw students of C to syntax, others to operating systems, rather than focusing their attention on what should be a meaningful part of C program text, You might be so familiar with these distinct notions that you have forgotten that it once was difficult to keep them apart: you just saw these different pieces of C text but they all looked alike! Teaching C, then, by force is lacking modularization, in the following sense. For example, C offers distinctions that are non-essential when seen from the viewpoint of teaching programming subjects. Yet, they must be understood by the novices should they need to to write programs, which, I think, they usually do. - The statement and the block (of statements), and why and how to write them Typically, a distraction: Mostly offered when the subject is C's case distinction with if/else. When teaching conditionals, the focus should be on conditional execution. It will easily be on whether or not you need braces, and what the braces mean, and about what happens if you do or don't write "else" and then do or do not write braces, Blocks/statements confront novices with recursion at the level of grammars---when they are trying to understand if/else. But recursive definition is not an easy concept in itself. Observe students (in the general sense of the word "students", i.e. including pupils, or hobbyists) trying to understand mathematical induction, which requires recursive thought. It takes time and practice to become acquainted, and then induction at school was usually about natural numbers, not symbols, or about how you yourself write. Entire books like "The Little Functionaler" by Friedman / Felleisen are all about recursive definitions. They aren't easy. Intrinsically, recursive definitions are very close to circular definition, which, as you know, are vicious. - C's shorthands Too many things in one piece. Professional typists learn how to write first. Shouldn't students of C (as a first language) do this, too? (Typists need to learn the rules of written natural language first. Orthography. Then, I imagine, other practical things about writing.) Only then they, typists, learn how to use shorthands. C culture, I believe, does not call *x++ a shorthand. It calls it an idiom. It is even possible to argue that there is no shorthand at all because everything is (mostly) well defined and not an abbreviation. But this argument misses modularity of attention: one thing at a time. The above expression requires that the student isolates each single effect, and separates it from the others. Then thinks about implicit order and such. Why should beginners in programming become familiar with shorthands so very early? Note how C's shorthands are totally different from the definitions of "A Programming Language", i.e. APL languages. There, TTBOMK, every symbol has one (or two) well defined meaning(s) that do not "abbreviate". Or that could easily be written in another way, as is the case with C when, e.g. isolating the constituent parts of *x++. The sum of 1 .. 100 in APL is +/⍳100 which, in Python, reads reduce(plus, range(101)) where def plus(x, y): return x + y That is not to say that using "/" as reduction operator and not division might not be confusing at first. It is also not to say that ⍳ and the many other operator symbols won't take time to learn. But APL's mode of expression does not conflate so many things into one piece, and fewer of them are about syntax or precedence. - main and its (int argc, char* argv[]), that C shares with Java. You will see lengthy discussions of what these mean. And how they come to be, out of nowhere (known). Or how they could be passed to the program and that argv[0] is of a different quality than argv[n], n > 0. Similarly, about return 0; the teacher will have to explain why in a Boolean context 0 means false but in the context of operating systems, 0 means OK. And what this has to do with the C program in the first place. - file scope. An important feature of C---and its OS... You'll need to know operating system concepts including file system concepts before you can understand program text. What is it that warrants dragging the file systems into it? Why can't we understand the text of programs without the external notion of a file? K&R have no need to ship their book split suitably into files. They don't! I guess I could go on for some time... And I haven't mentioned pointers at all and how they relate to arrays and to the + operator, ... Is this a sense in which C is harder when you want to learn the fundamentals of programming? ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 9:42 ` Georg Bauhaus @ 2011-04-23 10:23 ` Dmitry A. Kazakov 0 siblings, 0 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-23 10:23 UTC (permalink / raw) On Sat, 23 Apr 2011 11:42:51 +0200, Georg Bauhaus wrote: > On 4/23/11 9:23 AM, Dmitry A. Kazakov wrote: >> On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salom�o Helou Neto wrote: > >>> It is quite different with programming languages, as C is actually >>> harder than Pascal, which is a great tool for teaching programming. >> >> In which sense is C harder? > > C is harder to learn from the ground up, as your first formalism, > when measured by the number of non-intuitive and non-essential > fundamental concepts that students must all understand in order > to understand and use fundamental ideas of C. [...] > Is this a sense in which C is harder when you > want to learn the fundamentals of programming? True, but this does not imply difficulty to learn. It depends on the goals set. People *feel* they know C very quickly. The fact that they actually do not know it and even less know software engineering does not change that felt easiness. This is why I asked for the meaning of being hard. Nobody cares that C is hard from the stand point of software engineering because nobody cares about the latter. Is it hard to learn how to use a hammer? 1. No 2. What for? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 7:23 ` Dmitry A. Kazakov 2011-04-23 9:42 ` Georg Bauhaus @ 2011-04-23 18:37 ` Elias Salomão Helou Neto 2011-04-23 21:36 ` Dmitry A. Kazakov 1 sibling, 1 reply; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-23 18:37 UTC (permalink / raw) On Apr 23, 4:23 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salomão Helou Neto wrote: > > > On Apr 22, 6:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > > wrote: > > >> Nevertheless, future professional programmers should never be exposed to C > >> as the first language. It is like teaching physics in the school. Pupils > >> first learn the physics of XIX century. When they made 3/4, they are told: > >> guys, that was wrong! Here is how it goes! Programmers must learn concepts > >> and techniques which C cannot illustrate. What C can illustrate is how not > >> to program. > > > When it comes to physics, the main reason to teach classical > > mechanical is that it is actually a good approximation to modern > > theories and the math is far more simple. Nobody will say "guys, that > > was wrong!" because that is not wrong, it just must be used within its > > valid limits. > > I heard that wrong argument so many times. Certainly you've not heard it from good physicists, but from rather stupid ones. Let me state it clearly: Classical Mechanics isn't wrong at all. It is the best and most useful approximation for a wide range of phenomena. Why would someone use Quantum Mechanics or Relativity to compute velocities when designing an automatic train control system? > > Rockets reached the moon based on computations that used > > classical Newtonian mechanics. > > So? Linux was written in C, does it justify C? I was justifying Classical Mechanics. But Linux' success kind of justifies C as a system language, but let us not argue on that. > [I hope your students do not build rockets (:-))] I hope they eventually will. I just hope they do not use C. > > It is quite different with programming languages, as C is actually > > harder than Pascal, which is a great tool for teaching programming. > > In which sense is C harder? I bet students find it simple. It is hard to > teach concepts of software design on example of C? Bauhaus explained it very well. And why on earth would I be teaching software design on an introductory course on programming? It is much more about algorithm, data structures and the language itself. > But Newtonian mechanics > is perfect for teaching cosmology, quantum effects, optics, fields etc? Do you want to teach this stuff to high school students? I don't get your idea here. Elias ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 18:37 ` Elias Salomão Helou Neto @ 2011-04-23 21:36 ` Dmitry A. Kazakov 2011-04-24 11:27 ` Peter C. Chapin 0 siblings, 1 reply; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-23 21:36 UTC (permalink / raw) On Sat, 23 Apr 2011 11:37:00 -0700 (PDT), Elias Salom�o Helou Neto wrote: > On Apr 23, 4:23�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Fri, 22 Apr 2011 19:08:33 -0700 (PDT), Elias Salom�o Helou Neto wrote: >> >>> On Apr 22, 6:21�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> >>> wrote: >> >>>> Nevertheless, future professional programmers should never be exposed to C >>>> as the first language. It is like teaching physics in the school. Pupils >>>> first learn the physics of XIX century. When they made 3/4, they are told: >>>> guys, that was wrong! Here is how it goes! Programmers must learn concepts >>>> and techniques which C cannot illustrate. What C can illustrate is how not >>>> to program. >> >>> When it comes to physics, the main reason to teach classical >>> mechanical is that it is actually a good approximation to modern >>> theories and the math is far more simple. Nobody will say "guys, that >>> was wrong!" because that is not wrong, it just must be used within its >>> valid limits. >> >> I heard that wrong argument so many times. > > Certainly you've not heard it from good physicists, but from rather > stupid ones. Let me state it clearly: Classical Mechanics isn't wrong > at all. It is the best and most useful approximation for a wide range > of phenomena. 3.14 might be a useful approximation of Pi, but not Pi. > Why would someone use Quantum Mechanics or Relativity to > compute velocities when designing an automatic train control system? Why would anybody consider the Earth round? Let us start teaching students that the Earth is flat, after all it is a useful approximation for building construction. Later you can tell them that it is not very flat... >>> It is quite different with programming languages, as C is actually >>> harder than Pascal, which is a great tool for teaching programming. >> >> In which sense is C harder? I bet students find it simple. It is hard to >> teach concepts of software design on example of C? > > Bauhaus explained it very well. And why on earth would I be teaching > software design on an introductory course on programming? Maybe because it supposed to be *introductory*? Is it an introduction into C or into programming? I have no idea how to teach students programming, I doubt that it must or can be taught, but it is obvious to me as a consumer, that what is taught is mostly useless and often damaging. > It is much more about algorithm, data structures and the language itself. A "Newtonian mechanics" of coding. Again, I am not a teacher, but programming today is not very much about algorithms, structures and even concrete languages. Not that fresh students knew much about algorithms or structures, that is not their biggest problem. >> But Newtonian mechanics >> is perfect for teaching cosmology, quantum effects, optics, fields etc? > > Do you want to teach this stuff to high school students? I don't get > your idea here. Certainly yes, if it is about physics. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 21:36 ` Dmitry A. Kazakov @ 2011-04-24 11:27 ` Peter C. Chapin 2011-04-24 13:53 ` Dmitry A. Kazakov 2011-04-24 20:37 ` Georg Bauhaus 0 siblings, 2 replies; 124+ messages in thread From: Peter C. Chapin @ 2011-04-24 11:27 UTC (permalink / raw) On Sat, 23 Apr 2011 23:36:36 +0200, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: >Why would anybody consider the Earth round? Let us start teaching students >that the Earth is flat, after all it is a useful approximation for building >construction. Later you can tell them that it is not very flat... It sounds like you think that's a bad thing. In fact when constructing a building you don't take into account the curvature of the Earth. For example you don't use spherical trigonometry to lay out the foundation. Students learning about building construction certainly know (from elsewhere) that the Earth is not flat but they also don't want to hear about it in their course. Similarly students in an introductory physics course know that Newtonian physics isn't the last word on the subject but they are happy to study a more basic (and still useful) system to start. You've said repeatedly that you are not a teacher and, frankly, it shows. I can tell you based on my 25 years of experience teaching that attempting to teach relativity and quantum mechanics, in any sort of significant way, to first year physics students would be a disaster. They don't have the mathematical background, for one thing, to handle it. I think similar comments apply to programming education. That said, I do agree with one point that you've made: programming languages can be a distraction. I actually had a student recently suggest to me that we teach our first programming course using pseudo-code instead of C (we are a computer engineering program so C seems like the right first language). He said, "that way students could focus on organizing their program rather than on getting some strange code to compile." It would be an interesting experiment to try that, but I'm not sure it would help in the long run. In later courses I want them to write programs that compile and work so they will need to deal with that issue sooner or later. Which is easier to teach first? It's unclear. Peter ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 11:27 ` Peter C. Chapin @ 2011-04-24 13:53 ` Dmitry A. Kazakov 2011-04-24 19:07 ` Nasser M. Abbasi 2011-04-24 20:37 ` Georg Bauhaus 1 sibling, 1 reply; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-24 13:53 UTC (permalink / raw) On Sun, 24 Apr 2011 07:27:10 -0400, Peter C. Chapin wrote: > On Sat, 23 Apr 2011 23:36:36 +0200, "Dmitry A. Kazakov" > <mailbox@dmitry-kazakov.de> wrote: > >>Why would anybody consider the Earth round? Let us start teaching students >>that the Earth is flat, after all it is a useful approximation for building >>construction. Later you can tell them that it is not very flat... > > It sounds like you think that's a bad thing. Yes, is see no reason in teaching lies, even if lies are simpler than the truth. > In fact when constructing a building you don't take into account the > curvature of the Earth. For example you don't use spherical trigonometry to > lay out the foundation. Students learning about building construction > certainly know (from elsewhere) that the Earth is not flat but they also > don't want to hear about it in their course. The question was in the order. First teach that the Earth is round and only then say that the curvature is so small that it can be ignored for the case at hand. > You've said repeatedly that you are not a teacher and, frankly, it shows. I > can tell you based on my 25 years of experience teaching that attempting to > teach relativity and quantum mechanics, in any sort of significant way, to > first year physics students would be a disaster. They don't have the > mathematical background, for one thing, to handle it. Really? I see no significant difference in their mathematics. Difference is when functional, differential analysis, integration is needed. And it is much too late to me anyway. The fundamentals of the relativity theory and quantum mechanics should be taught in the school, before they get spoiled. I am so certain about this because as a schoolboy I was exposed to an experimental program which started mathematics right from the set theory and used formalisms from the beginning. On the contrary physics was taught traditionally "wrong". The program was soon scrapped, but I still remember how much simpler it was comparing to physics, though I was little interested in mathematics that time. My worst experience was later, when reading a manual of physics "for advanced", which on 10 pages calculated waves would be emitted by a moving electron using classical physics and no differential analysis(!), just in order to state on the last page that all this was just rubbish, the right way you learn later when attend high school. This remains to me the epitaph of modern education. > I think similar comments apply to programming education. That said, I do > agree with one point that you've made: programming languages can be a > distraction. I actually had a student recently suggest to me that we teach > our first programming course using pseudo-code instead of C (we are a > computer engineering program so C seems like the right first language). He > said, "that way students could focus on organizing their program rather > than on getting some strange code to compile." Well, but pseudo-code itself is a distraction, a remnant of the procedural paradigm mostly concentrating on the algorithm. It is not the way or at least not the whole way the software is written now. Here I see the same problem, education tries to follow the historical way of scholarship instead of cutting dark corners. > It would be an interesting experiment to try that, but I'm not sure it > would help in the long run. In later courses I want them to write programs > that compile and work so they will need to deal with that issue sooner or > later. Which is easier to teach first? It's unclear. I don't know. How about teaching them how to write a bug report and never ever say "I did nothing, it worked yesterday"? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 13:53 ` Dmitry A. Kazakov @ 2011-04-24 19:07 ` Nasser M. Abbasi 2011-04-24 19:46 ` Dmitry A. Kazakov 0 siblings, 1 reply; 124+ messages in thread From: Nasser M. Abbasi @ 2011-04-24 19:07 UTC (permalink / raw) On 4/24/2011 6:53 AM, Dmitry A. Kazakov wrote: > > The question was in the order. First teach that the Earth is round and only > then say that the curvature is so small that it can be ignored for the case > at hand. > Mr Kazakov; In every other argument your were part of in this forum, I've seen you always as right and on the correct end, except for this one :) Do then you start teaching students nonlinear systems before linear systems? Since, real systems in reality are non-linear, but we linearized things to be able to understand them and approximate the very complex behavior to something we can analyze. Only in advanced courses we start to study how to analyze non-linear systems. Your point that we should start learning general relativity before classical mechanics makes no sense to me. Then why not start with string theory first before general relativity? Lets teach string theory and quantum relativity as well to high school students before F=ma? I really lost trying to understand your views here. Best, --Nasser ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 19:07 ` Nasser M. Abbasi @ 2011-04-24 19:46 ` Dmitry A. Kazakov 2011-04-24 21:20 ` Nasser M. Abbasi 2011-04-24 22:23 ` Elias Salomão Helou Neto 0 siblings, 2 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-24 19:46 UTC (permalink / raw) On Sun, 24 Apr 2011 12:07:37 -0700, Nasser M. Abbasi wrote: > Do then you start teaching students nonlinear systems before > linear systems? If you are going to teach them pendulum, would it make much sense to pretend it linear? x is a pretty good approximation of sin(x) near 0. BTW, there is an important difference between empirical and fundamental laws of nature. > Your point that we should start learning general relativity > before classical mechanics makes no sense to me. My point is that historic views need not to be taught. Anyway, importance of classic mechanics looks overestimated. You cannot see planets when living in a large city, but do can the computer on your desk. Explain why it works using Newtonian mechanics. > Then why not start with string theory first before general > relativity? String theory is not yet generally accepted. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 19:46 ` Dmitry A. Kazakov @ 2011-04-24 21:20 ` Nasser M. Abbasi 2011-04-24 22:33 ` Elias Salomão Helou Neto 2011-04-25 7:09 ` Dmitry A. Kazakov 2011-04-24 22:23 ` Elias Salomão Helou Neto 1 sibling, 2 replies; 124+ messages in thread From: Nasser M. Abbasi @ 2011-04-24 21:20 UTC (permalink / raw) On 4/24/2011 12:46 PM, Dmitry A. Kazakov wrote: > On Sun, 24 Apr 2011 12:07:37 -0700, Nasser M. Abbasi wrote: > >> Do then you start teaching students nonlinear systems before >> linear systems? > > If you are going to teach them pendulum, would it make much sense to > pretend it linear? x is a pretty good approximation of sin(x) near 0. > It is not pretending, it is approximation. A good one, if the angle is small. Buildings, rockets, trains, advanced control systems are designed based on linear system theory, and somehow they seem to work just fine. My teacher kept telling us this all the time. He should know :) > BTW, there is an important difference between empirical and fundamental > laws of nature. > And what makes you think GR is fundamental and classical mechanics is not? We do not know what the fundamental laws of nature are, if we did, we would have a unified field theory, which we do not. GR works well in large scale, but not too well at at the nano-scale, so it can't be a fundamental law of nature. Everything we learn can be viewed as approximation to how nature work. >> Your point that we should start learning general relativity >> before classical mechanics makes no sense to me. > > My point is that historic views need not to be taught. My view is the opposite. I learn a subject better by learning how it came about. I like to read old papers and books more than new ones, because it gives me more insight into the subject. Even if the old views are no longer the most accurate ones on the subject. > Anyway, importance > of classic mechanics looks overestimated. You cannot see planets when > living in a large city, but do can the computer on your desk. Explain why > it works using Newtonian mechanics. > Do not understand. >> Then why not start with string theory first before general >> relativity? > > String theory is not yet generally accepted. > It is tought at many schools allready. Any way, the point is that, there are many models of nature, some are more complicated than others. If a model works well for what one wants to do, and the model is simpler, use that mathematical model. Telling a civil engineer they need to learn GR first in order to design a building do not make any sense. --Nasser ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 21:20 ` Nasser M. Abbasi @ 2011-04-24 22:33 ` Elias Salomão Helou Neto 2011-04-25 7:09 ` Dmitry A. Kazakov 1 sibling, 0 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-24 22:33 UTC (permalink / raw) On Apr 24, 6:20 pm, "Nasser M. Abbasi" <n...@12000.org> wrote: > >> Do then you start teaching students nonlinear systems before > >> linear systems? > > > If you are going to teach them pendulum, would it make much sense to > > pretend it linear? x is a pretty good approximation of sin(x) near 0. > > It is not pretending, it is approximation. A good one, if the angle is > small. Buildings, rockets, trains, advanced control systems are > designed based on linear system theory, and somehow they seem to > work just fine. My teacher kept telling us this all the time. He should > know :) Dmitry seems to deny the value of proper approximations, he is clearly not a physicist :-) Neither am I, but as an Applied Mathematician I do value them. > > BTW, there is an important difference between empirical and fundamental > > laws of nature. > > And what makes you think GR is fundamental and classical mechanics > is not? We do not know what the fundamental laws of nature are, if > we did, we would have a unified field theory, which we do not. GR works > well in large scale, but not too well at at the nano-scale, so it > can't be a fundamental law of nature. What are fundamental laws of nature? We will never be able to tell. In fact, all we have are empirical laws, but some seem to don't understand it. > > Everything we learn can be viewed as approximation to how nature work. Yep! > >> Your point that we should start learning general relativity > >> before classical mechanics makes no sense to me. > > > My point is that historic views need not to be taught. > > My view is the opposite. I learn a subject better by learning how > it came about. I like to read old papers and books more than new ones, > because it gives me more insight into the subject. Even if the > old views are no longer the most accurate ones on the subject. Dmitry's viewpoint scared me at first, but I guess he meant that not everything should be taught in physics school. No one could deny the value of history, not even such a controversial guy :-) > > Anyway, importance > > of classic mechanics looks overestimated. You cannot see planets when > > living in a large city, but do can the computer on your desk. Explain why > > it works using Newtonian mechanics. > > Do not understand. Nobody could. He is confusing things because the presence of "mechanics" in "quantum mechanics". > > >> Then why not start with string theory first before general > >> relativity? > > > String theory is not yet generally accepted. > > It is tought at many schools allready. Any way, the point > is that, there are many models of nature, some are > more complicated than others. If a model works well for > what one wants to do, and the model is simpler, use that > mathematical model. > > Telling a civil engineer they need to learn GR first in order > to design a building do not make any sense. Does it? Elias ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 21:20 ` Nasser M. Abbasi 2011-04-24 22:33 ` Elias Salomão Helou Neto @ 2011-04-25 7:09 ` Dmitry A. Kazakov 2011-04-25 20:46 ` Maciej Sobczak 1 sibling, 1 reply; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-25 7:09 UTC (permalink / raw) On Sun, 24 Apr 2011 14:20:59 -0700, Nasser M. Abbasi wrote: > On 4/24/2011 12:46 PM, Dmitry A. Kazakov wrote: >> On Sun, 24 Apr 2011 12:07:37 -0700, Nasser M. Abbasi wrote: >> >>> Do then you start teaching students nonlinear systems before >>> linear systems? >> >> If you are going to teach them pendulum, would it make much sense to >> pretend it linear? x is a pretty good approximation of sin(x) near 0. > > It is not pretending, it is approximation. A good one, if the angle is > small. No, it is a catastrophic approximation because linear system cannot oscillate. >> BTW, there is an important difference between empirical and fundamental >> laws of nature. > > And what makes you think GR is fundamental and classical mechanics > is not? It is a relationship of laws. A law is fundamental to another when it is or thought to be derived from the former. >>> Your point that we should start learning general relativity >>> before classical mechanics makes no sense to me. >> >> My point is that historic views need not to be taught. > > My view is the opposite. I learn a subject better by learning how > it came about. I like to read old papers and books more than new ones, > because it gives me more insight into the subject. Even if the > old views are no longer the most accurate ones on the subject. Then you should start with astrology. To me the goal of education is giving a scientific view on the world. >> Anyway, importance >> of classic mechanics looks overestimated. You cannot see planets when >> living in a large city, but do can the computer on your desk. Explain why >> it works using Newtonian mechanics. > > Do not understand. Take Newtonian mechanics and use it to describe the computer hardware as a physical system. > Any way, the point > is that, there are many models of nature, some are > more complicated than others. If a model works well for > what one wants to do, and the model is simpler, use that > mathematical model. Do you order the models according to: 1. the time when they first appeared (e.g. the light-bearing aether theory) 2. their adequateness (e.g. Ptolemy's system vs. Copernican) 3. their place in the physical model of the world (fundamentals) > Telling a civil engineer they need to learn GR first in order > to design a building do not make any sense. It does, because building construction is secondary according to the classification 3. A civil engineer must know physics (en large), before diving into the resistance of materials. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-25 7:09 ` Dmitry A. Kazakov @ 2011-04-25 20:46 ` Maciej Sobczak 2011-04-25 21:19 ` George P. 2011-04-26 6:18 ` Dmitry A. Kazakov 0 siblings, 2 replies; 124+ messages in thread From: Maciej Sobczak @ 2011-04-25 20:46 UTC (permalink / raw) On Apr 25, 9:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > No, it is a catastrophic approximation because linear system cannot > oscillate. What? A simple hanging spring can oscillate while being purely linear. There are also capacitors connected with coils, etc. > Take Newtonian mechanics and use it to describe the computer hardware as a > physical system. Easy: http://www.youtube.com/watch?v=yzJqYl9EHgA See also related videos, they are all fun. And instructive. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-25 20:46 ` Maciej Sobczak @ 2011-04-25 21:19 ` George P. 2011-04-26 6:18 ` Dmitry A. Kazakov 1 sibling, 0 replies; 124+ messages in thread From: George P. @ 2011-04-25 21:19 UTC (permalink / raw) On Apr 25, 4:46 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote: > On Apr 25, 9:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > > > No, it is a catastrophic approximation because linear system cannot > > oscillate. > > What? A simple hanging spring can oscillate while being purely linear. > There are also capacitors connected with coils, etc. > I guess he meant sustained oscillations.? ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-25 20:46 ` Maciej Sobczak 2011-04-25 21:19 ` George P. @ 2011-04-26 6:18 ` Dmitry A. Kazakov 2011-04-26 6:58 ` Nasser M. Abbasi 2011-04-26 20:57 ` Maciej Sobczak 1 sibling, 2 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-26 6:18 UTC (permalink / raw) On Mon, 25 Apr 2011 13:46:40 -0700 (PDT), Maciej Sobczak wrote: > On Apr 25, 9:09�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >> No, it is a catastrophic approximation because linear system cannot >> oscillate. > > What? A simple hanging spring can oscillate while being purely linear. That system is not linear. >> Take Newtonian mechanics and use it to describe the computer hardware as a >> physical system. > > Easy: > > http://www.youtube.com/watch?v=yzJqYl9EHgA > > See also related videos, they are all fun. And instructive. As well as contests on throwing mobile phones. What I meant was: take the i486 and describe its [electric] behavior by means of Newtonian mechanics. Of course it need not to be a detailed description, only a sketch how it could be done considering that its components (electrons etc) are rigid bodies. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-26 6:18 ` Dmitry A. Kazakov @ 2011-04-26 6:58 ` Nasser M. Abbasi 2011-04-26 8:39 ` Dmitry A. Kazakov 2011-04-26 20:57 ` Maciej Sobczak 1 sibling, 1 reply; 124+ messages in thread From: Nasser M. Abbasi @ 2011-04-26 6:58 UTC (permalink / raw) On 4/25/2011 11:18 PM, Dmitry A. Kazakov wrote: > On Mon, 25 Apr 2011 13:46:40 -0700 (PDT), Maciej Sobczak wrote: > >> On Apr 25, 9:09 am, "Dmitry A. Kazakov"<mail...@dmitry-kazakov.de> >> wrote: >> >>> No, it is a catastrophic approximation because linear system cannot >>> oscillate. >> >> What? A simple hanging spring can oscillate while being purely linear. > > That system is not linear. > One should really attribute linearity or not to the equations that describes the motion of the system. The pendulum itself is just the pendulum, and saying that the pendulum itself is not linear, I do not think is very exact, but I know you meant the equation of motion when you said that. So, now lets talk then about the equation of motion. Again, under small angle approximation, the equation of motion of the pendulum can be approximated to linear one. When the angle is large, then the approximation is not a good one, and one must use the non-linear equation of motion to make better prediction of its motion. So, we back to square one. We make a mathematical model of the physical problem, and if the approximation we make to this model seems to give good results for our needs, then that is the model we should use. One can use GR equations (10 highly non-linear coupled PDE's [1]) to describe the equation of motion of the pendulum, and after making all the approximations needed to account for slow motion of the pendulum blob (relative to speed of light :), its small mass (relative to earth) hence small space-time curvature, and after numerically solving them, one will get the same results within a tolerance of error that can be ignored for all practical reasons, as the one we get with a simple model based on F=ma and small angle approximation. So, you can use GR to solve the pendulum problem, and I can use F=ma, and in the end, we will get the same results for all practical reason, except I used a very simplified model, and you used a very complicated model, of the same physical problem. What matter is if the result of the model agrees well to the observed behavior. Any way, this is how engineers look at things :) --Nasser [1]http://en.wikipedia.org/wiki/Einstein_field_equations ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-26 6:58 ` Nasser M. Abbasi @ 2011-04-26 8:39 ` Dmitry A. Kazakov 0 siblings, 0 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-26 8:39 UTC (permalink / raw) On Mon, 25 Apr 2011 23:58:37 -0700, Nasser M. Abbasi wrote: > On 4/25/2011 11:18 PM, Dmitry A. Kazakov wrote: >> On Mon, 25 Apr 2011 13:46:40 -0700 (PDT), Maciej Sobczak wrote: >> >>> On Apr 25, 9:09 am, "Dmitry A. Kazakov"<mail...@dmitry-kazakov.de> >>> wrote: >>> >>>> No, it is a catastrophic approximation because linear system cannot >>>> oscillate. >>> >>> What? A simple hanging spring can oscillate while being purely linear. > >> That system is not linear. > > One should really attribute linearity or not to the equations that > describes the motion of the system. > The pendulum itself is just the pendulum, and saying that > the pendulum itself is not linear, I do not think is very exact, > but I know you meant the equation of motion when you said that. > > So, now lets talk then about the equation of motion. > > Again, under small angle approximation, the equation of motion > of the pendulum can be approximated to linear one. When > the angle is large, then the approximation is not a good one, > and one must use the non-linear equation of motion to make > better prediction of its motion. > > So, we back to square one. I am not. The Ptolemy's system is a fair approximation of planet movement. Moreover, it is asymptotically correct, and mathematically represents the first ever example of harmonic analysis (a very important tool in engineering). All that does not make it "right". The Copernican system, which is plain numerically wrong, and also wrong from the relativity theory point of view, is taught as a "truth". You cannot ignore the context. > We make a mathematical model > of the physical problem, and if the approximation we make > to this model seems to give good results for our needs, then > that is the model we should use. Yes, except the cases where results cannot be verified, and discarding the context makes anything unverifiable. Models you are talking about exist in a larger context taken for granted. For example, you presume that laws do not change with the time etc. Just consider models where time would be a function of some system parameters. There is an infinite number of models fitting given system. Among these only models consistent with more fundamental laws and principles are considered. Empiric models are subordinate. You can consider deploying such a model (like F=ma) only after stating its conformance to a more fundamental theory (the relativity theory). As an engineer you also must show the boundaries within your empiric model can be used. > Any way, this is how engineers look at things :) You mean those programming in C? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-26 6:18 ` Dmitry A. Kazakov 2011-04-26 6:58 ` Nasser M. Abbasi @ 2011-04-26 20:57 ` Maciej Sobczak 2011-04-27 8:00 ` Dmitry A. Kazakov 1 sibling, 1 reply; 124+ messages in thread From: Maciej Sobczak @ 2011-04-26 20:57 UTC (permalink / raw) On Apr 26, 8:18 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > What? A simple hanging spring can oscillate while being purely linear. > > That system is not linear. Taking into account your further response to Nasser, I take that you mean the *real* hanging spring. OK. But then, I don't see anybody in the whole world who could explain how it works (the more details, the more shaky it is), not mentioning the i486 CPU. In which case I no longer understand what you are trying to prove in this thread. > What I meant was: take the i486 and describe its [electric] behavior by > means of Newtonian mechanics. Of course it need not to be a detailed > description, only a sketch OK, so welcome back to simplified models. Hanging spring is a linear system then. :-) > how it could be done considering that its > components (electrons etc) are rigid bodies. It's pointless. It was not designed at this level of detail (higher-level abstractions and reusable design modules were used instead), so there is no point in describing its behaviour at this level. In which case I again don't understand what you are trying to prove. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-26 20:57 ` Maciej Sobczak @ 2011-04-27 8:00 ` Dmitry A. Kazakov 2011-04-27 8:19 ` Georg Bauhaus 2011-04-28 7:02 ` Maciej Sobczak 0 siblings, 2 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-27 8:00 UTC (permalink / raw) On Tue, 26 Apr 2011 13:57:32 -0700 (PDT), Maciej Sobczak wrote: > On Apr 26, 8:18�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >>> What? A simple hanging spring can oscillate while being purely linear. >> >> That system is not linear. > > Taking into account your further response to Nasser, I take that you > mean the *real* hanging spring. No, I mean that x(t) =A sin(2Pi f t) + x0 is not a linear function of time. I didn't mean effects non-ideal pendulums have. >> What I meant was: take the i486 and describe its [electric] behavior by >> means of Newtonian mechanics. Of course it need not to be a detailed >> description, only a sketch > > OK, so welcome back to simplified models. Hanging spring is a linear > system then. :-) No, it is not. Linear meant to be its position. For this the acceleration must be 0. You used "linear" in the sense that one of the forces is a linear function of position. That does not give you a linear solution. >> how it could be done considering that its >> components (electrons etc) are rigid bodies. > > It's pointless. > > It was not designed at this level of detail (higher-level abstractions > and reusable design modules were used instead), so there is no point > in describing its behaviour at this level. > In which case I again don't understand what you are trying to prove. In XIX century a physicist would claim that knowing all initial states and velocities [and electric charges] of particles he would be able to describe i486 (running Linux etc) with any given precision. Today, we know that he could not. Which is the whole point. Newtonian mechanics fails to explain how a simple (single core! (:-)) processor works. In fact it cannot describe a single transistor. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-27 8:00 ` Dmitry A. Kazakov @ 2011-04-27 8:19 ` Georg Bauhaus 2011-04-27 9:32 ` Dmitry A. Kazakov 2011-04-28 7:02 ` Maciej Sobczak 1 sibling, 1 reply; 124+ messages in thread From: Georg Bauhaus @ 2011-04-27 8:19 UTC (permalink / raw) On 4/27/11 10:00 AM, Dmitry A. Kazakov wrote: > In XIX century a physicist would claim that knowing all initial states and > velocities [and electric charges] of particles he would be able to describe > i486 (running Linux etc) with any given precision. Today, we know that he > could not. Which is the whole point. Newtonian mechanics fails to explain > how a simple (single core! (:-)) processor works. In fact it cannot > describe a single transistor. Can you describe the effect of a set of interconnected computer transistors using Boolean functions? ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-27 8:19 ` Georg Bauhaus @ 2011-04-27 9:32 ` Dmitry A. Kazakov 0 siblings, 0 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-27 9:32 UTC (permalink / raw) On Wed, 27 Apr 2011 10:19:36 +0200, Georg Bauhaus wrote: > On 4/27/11 10:00 AM, Dmitry A. Kazakov wrote: > >> In XIX century a physicist would claim that knowing all initial states and >> velocities [and electric charges] of particles he would be able to describe >> i486 (running Linux etc) with any given precision. Today, we know that he >> could not. Which is the whole point. Newtonian mechanics fails to explain >> how a simple (single core! (:-)) processor works. In fact it cannot >> describe a single transistor. > > Can you describe the effect of a set of interconnected > computer transistors using Boolean functions? That depends on what you understand under "effect." Considering a model where elements are ideal switches, no, I cannot describe it using Boolean functions. With switches I can build an oscillator, that would break the model. Oscillators are incomputable. But all that is beyond the point. The first computers were mechanical. Recently it was claimed in c.l.a. that quantum computing too would be Turing complete. Maybe it would, but that could not make quantum mechanics a Newtonian one. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-27 8:00 ` Dmitry A. Kazakov 2011-04-27 8:19 ` Georg Bauhaus @ 2011-04-28 7:02 ` Maciej Sobczak 2011-04-28 7:41 ` Dmitry A. Kazakov 1 sibling, 1 reply; 124+ messages in thread From: Maciej Sobczak @ 2011-04-28 7:02 UTC (permalink / raw) On Apr 27, 10:00 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > >>> What? A simple hanging spring can oscillate while being purely linear. > No, I mean that x(t) =A sin(2Pi f t) + x0 is not a linear function of time. You got it backwards. Completely. The above equation does not define the spring mechanics. It only describes the *observable effect* of this mechanics. In other words, harmonic oscillation is not a cause of spring movement, it is a consequence of the spring being a linear system. The spring itself has no idea that it should oscillate at all. Let's bring some Ada back to this discussion: with Ada.Text_IO; procedure Spring is Initial_Position : constant := 0.0; Initial_Velocity : constant := 10.0; Spring_Rigidity : constant := 1.0; Mass : constant := 1.0; Time_Unit : constant := 0.1; Position : Long_Float := Initial_Position; Velocity : Long_Float := Initial_Velocity; procedure Show_Position is P : Integer := 40 + Integer (Position); Off_Screen : Boolean := False; begin if P <= 0 then P := 0; Off_Screen := True; end if; if P >= 79 then P := 79; Off_Screen := True; end if; for I in 1 .. P loop Ada.Text_IO.Put (' '); end loop; if not Off_Screen then Ada.Text_IO.Put ('*'); else Ada.Text_IO.Put ('!'); end if; Ada.Text_IO.New_Line; end Show_Position; procedure Compute_New_Position is Force : Long_Float; Acceleration : Long_Float; Shift : Long_Float; begin Force := -1.0 * Position * Spring_Rigidity; Acceleration := Force / Mass; Velocity := Velocity + Acceleration * Time_Unit; Shift := Velocity * Time_Unit; Position := Position + Shift; end Compute_New_Position; begin loop Show_Position; delay Time_Unit; Compute_New_Position; end loop; end Spring; The above program is a discrete simulator of a purely linear system. The sine function is never used there and the program has no freaking idea that it should oscillate in a harmonic way. Yet it does. Enjoy! I don't care about the exact math, but as far as I understand it, purely harmonic oscillations (that is, a single component in the spectrum) come from purely linear systems. If the underlying system is not linear, then the resulting oscillation (if it exists at all) will include additional harmonics. Try to mess with the equations in the above program, like make the force a square function of position or make force dependent also on velocity, etc. and the oscillation will become less pure. I leave to math geeks to come up with exact Fourier spectrum for each such tweak. In which case I still don't understand what you have failed to prove. But hey, at least the discussion is related to Ada again. :-) -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-28 7:02 ` Maciej Sobczak @ 2011-04-28 7:41 ` Dmitry A. Kazakov 2011-04-28 10:24 ` Peter C. Chapin 0 siblings, 1 reply; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-28 7:41 UTC (permalink / raw) On Thu, 28 Apr 2011 00:02:36 -0700 (PDT), Maciej Sobczak wrote: > On Apr 27, 10:00�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >>>>> What? A simple hanging spring can oscillate while being purely linear. > >> No, I mean that x(t) =A sin(2Pi f t) + x0 is not a linear function of time. > > You got it backwards. Completely. > > The above equation does not define the spring mechanics. It is not an equation, it is a solution of some second-order differential equation [equations themselves can be linear or not, which is unrelated to the issue]. > It only describes the *observable effect* of this mechanics. BTW, the only effects are the observable ones. > The above program is a discrete simulator of a purely linear system. No, what you gave was a numeric solution of the differential equation. Whatever technique used to solve it, that does not change the nature of the system, obviously. (Numeric solutions are not only non-linear, they are not continuous) > The sine function is never used there and the program has no freaking > idea that it should oscillate in a harmonic way. Where you saw a program that used the sine function? There is no such thing on digital computers, only approximations of. What a surprise, these approximations use +, -, *, / math and rational numbers! Does it make sine, rational, linear? No. > In which case I still don't understand what you have failed to prove. > But hey, at least the discussion is related to Ada again. :-) Indeed. My thesis is no need to know C in order to learn Ada! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-28 7:41 ` Dmitry A. Kazakov @ 2011-04-28 10:24 ` Peter C. Chapin 2011-04-28 13:56 ` Dmitry A. Kazakov 0 siblings, 1 reply; 124+ messages in thread From: Peter C. Chapin @ 2011-04-28 10:24 UTC (permalink / raw) On Thu, 28 Apr 2011 09:41:51 +0200, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: >> The above equation does not define the spring mechanics. > >It is not an equation, it is a solution of some second-order differential >equation [equations themselves can be linear or not, which is unrelated to >the issue]. It's not unrelated to the issue at all. A system is called a "linear system" because it is described by a linear differential equation. That's a matter of definitition. Of course you can use the term "linear system" to mean something else, but that will make it hard for you to communicate with others... as evidenced by this thread. Peter ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-28 10:24 ` Peter C. Chapin @ 2011-04-28 13:56 ` Dmitry A. Kazakov 2011-05-03 1:19 ` Nasser M. Abbasi 0 siblings, 1 reply; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-28 13:56 UTC (permalink / raw) On Thu, 28 Apr 2011 06:24:45 -0400, Peter C. Chapin wrote: > On Thu, 28 Apr 2011 09:41:51 +0200, "Dmitry A. Kazakov" > <mailbox@dmitry-kazakov.de> wrote: > >>> The above equation does not define the spring mechanics. >> >>It is not an equation, it is a solution of some second-order differential >>equation [equations themselves can be linear or not, which is unrelated to >>the issue]. > > It's not unrelated to the issue at all. A system is called a "linear > system" because it is described by a linear differential equation. That's a > matter of definitition. Not really. Your definition is derived from this one: http://en.wikipedia.org/wiki/Linear_system which is applied to an open system with an input and output. I meant a closed system, which motion is described by a linear function of time. The definition above cannot applied to a close system, only to some parts of. Nobody so far argued that sine is a linear function because it is a solution of a linear differential equation. OK, let it be linear, my point is that it still would be inappropriate to use linear x instead of "linear" sin(x) to describe motion of a pendulum. [This reminds me "fruitful" discussions about "arrays" of C. Why should it always end this way?] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-28 13:56 ` Dmitry A. Kazakov @ 2011-05-03 1:19 ` Nasser M. Abbasi 2011-05-03 6:05 ` J-P. Rosen ` (2 more replies) 0 siblings, 3 replies; 124+ messages in thread From: Nasser M. Abbasi @ 2011-05-03 1:19 UTC (permalink / raw) Speaking about C again, I found this article "Ten Reasons to Teach and Learn Computer Programming in C" http://iel.ucdavis.edu/publication/WhyC.html "1. C is one of foundations for modern information technology (IT) and computer science (CS)." I think that is true. "2. C is the most commonly used programming language in industry. True again. "3. C is the language of choice for programming embedded and mechatronic systems with hardware interfaces" I think we all can agree on this. C is more popular that Ada in this area. "4. C is one of the most commonly used programming languages in colleges and universities." True also. "5. C excels as a model programming language." I would probably argue about this being very accurate. "6. C is the base for all other programming languages." There is some truth to this. "8. C is a standardized programming language with international standards." I would not argue against this. "9. Computer programming is becoming a necessary skill for many professions." Very true. "10. Computer programming can develop student's critical thinking capabilities." True also. I think the author makes many points that seem to be valid, yet somehow I can't agree that these are still good reasons to teach programming using C at schools. I learned Pascal for programming at school, and I think that was a good thing (tm). Any way, I thought some here might like to see the above article given this topic is all about C and such ;) --Nasser ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-05-03 1:19 ` Nasser M. Abbasi @ 2011-05-03 6:05 ` J-P. Rosen 2011-05-03 6:15 ` Ludovic Brenta 2011-05-03 15:34 ` Bill Findlay 2011-05-03 7:53 ` Georg Bauhaus 2011-05-03 9:29 ` Simon Wright 2 siblings, 2 replies; 124+ messages in thread From: J-P. Rosen @ 2011-05-03 6:05 UTC (permalink / raw) Le 03/05/2011 03:19, Nasser M. Abbasi a �crit : Interesting to see how true facts can be diverted by omission. Mainly, the issue is not whether C can be used for teaching, but whether it is the best vehicle for teaching. Quite different > Speaking about C again, I found this article > > "Ten Reasons to Teach and Learn Computer Programming in C" > > http://iel.ucdavis.edu/publication/WhyC.html > > > "1. C is one of foundations for modern information technology (IT) and > computer science (CS)." > > I think that is true. But not the only one. > "2. C is the most commonly used programming language in industry. > > True again. The implicit assumption is that "most used" implies "best for teaching". I would challenge that. > "3. C is the language of choice for programming embedded and mechatronic > systems with hardware interfaces" > > I think we all can agree on this. C is more popular that Ada in this area. Certainly not the domain you want to start teaching with. > "4. C is one of the most commonly used programming languages in colleges > and universities." > > True also. Agree, unfortunately. > "5. C excels as a model programming language." > > I would probably argue about this being very accurate. C was never defined as a modeling language, that statement is very surprising. > "6. C is the base for all other programming languages." > > There is some truth to this. This is totally wrong, at least for the "all" part. There is a C family of language, there is also an Algol family of languages (including Pasca, Ada and Eiffel), a Lisp family of languages, etc. This statement is typical of people who have never been exposed to other than the C family of languages. Only people who have knowledge of many different languages should make statements like this. > "8. C is a standardized programming language with international standards." > > I would not argue against this. True, but far from being the only one. > "9. Computer programming is becoming a necessary skill for many > professions." > > Very true. But not related to C as a teaching language. > "10. Computer programming can develop student's critical thinking > capabilities." > > True also. But also not related to C as a teaching language. > I think the author makes many points that seem to be valid, yet somehow > I can't agree that these are still good reasons to teach programming > using C at schools. Note that except for 4), nothing in these points is related to C's ability of being a vehicle for teaching. My main objection, from the POV of many years of teaching, is that one of the most difficult notions for beginners is pointers - and you can't do much in C without pointers. > I learned Pascal for programming at school, and I think that was a good > thing (tm). Strongly agree :-) ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-05-03 6:05 ` J-P. Rosen @ 2011-05-03 6:15 ` Ludovic Brenta 2011-05-03 7:43 ` Dmitry A. Kazakov 2011-05-03 15:34 ` Bill Findlay 1 sibling, 1 reply; 124+ messages in thread From: Ludovic Brenta @ 2011-05-03 6:15 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> writes: >> "4. C is one of the most commonly used programming languages in colleges >> and universities." >> >> True also. > Agree, unfortunately. > >> "10. Computer programming can develop student's critical thinking >> capabilities." >> >> True also. > But also not related to C as a teaching language. The problem is that teaching C will teach students not to think! or rather, to think uncritically and simply going with the herd like lemmings. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-05-03 6:15 ` Ludovic Brenta @ 2011-05-03 7:43 ` Dmitry A. Kazakov 0 siblings, 0 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-05-03 7:43 UTC (permalink / raw) On Tue, 03 May 2011 08:15:03 +0200, Ludovic Brenta wrote: > The problem is that teaching C will teach students not to think! or > rather, to think uncritically and simply going with the herd like > lemmings. I disagree. I think it does teach students, alas to mostly *wrong* practices. Unfortunately this is sometimes more damaging than just innocent ignorance. Also, a premature exposing to C brings a lot of critical thinking towards other languages and techniques. It would be unfair to blame C for that, because this attitude is rather derived from its position of strength, than from the language itself. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-05-03 6:05 ` J-P. Rosen 2011-05-03 6:15 ` Ludovic Brenta @ 2011-05-03 15:34 ` Bill Findlay 1 sibling, 0 replies; 124+ messages in thread From: Bill Findlay @ 2011-05-03 15:34 UTC (permalink / raw) On 03/05/2011 07:05, in article ipo5up$h78$1@dont-email.me, "J-P. Rosen" <rosen@adalog.fr> wrote: [much that I agree with] > Le 03/05/2011 03:19, Nasser M. Abbasi a �crit : >> "6. C is the base for all other programming languages." >> >> There is some truth to this. > This is totally wrong, at least for the "all" part. There is a C family > of language, there is also an Algol family of languages (including > Pasca, Ada and Eiffel), a Lisp family of languages, etc. To say nothing of FORTAN and COBOL! C is in fact the Morlock descendent of Algol, via CPL (which was heavily Algol-influenced), and BCPL. Ada, of course, is the noble scion of the family. 8-) > This statement is typical of people who have never been exposed to other > than the C family of languages. Only people who have knowledge of many > different languages should make statements like this. This [original] statement is about as ignorant as the claim I once saw in some Linux kernel documentation, to the effect that virtual memory was introduced by the VAX 11/780. >> I learned Pascal for programming at school, and I think that was a good >> thing (tm). > Strongly agree :-) But not as good a thing as learning via Ada would have been (I speak from personal experience of teaching both to beginners). -- Bill Findlay with blueyonder.co.uk; use surname & forename; ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-05-03 1:19 ` Nasser M. Abbasi 2011-05-03 6:05 ` J-P. Rosen @ 2011-05-03 7:53 ` Georg Bauhaus 2011-05-03 9:29 ` Simon Wright 2 siblings, 0 replies; 124+ messages in thread From: Georg Bauhaus @ 2011-05-03 7:53 UTC (permalink / raw) On 5/3/11 3:19 AM, Nasser M. Abbasi wrote: > Speaking about C again, I found this article > > "Ten Reasons to Teach and Learn Computer Programming in C" > > http://iel.ucdavis.edu/publication/WhyC.html A. The article demonstrates a stunning absence of teaching criteria. Which I would argue is a Must when you write about teaching, right? (J.-P. Rosen mentions a few issues.) B. The article bases its claims on a number of logical fallacies. Which is a paradox when a CS teacher writes about teaching programming. C. The article does reflect (a) the author's attitude when approaching the means of teaching (b) choices when making a career D. The article does not give details of what it means for a student to be competitive, although it does allude to apparently serving a segment of the labor market. But, empirically challenged, is C in your CV worth as much as say, C++ or Labview? Does it matter how well you actually program in C? > "1. C is one of foundations for modern information technology (IT) and computer science (CS)." > > I think that is true. We should know about the foundations, hence C. What about the other foundations of IT? At which point on the way towards general foundational knowledge are students capable of learning from C? More importantly, what do they learn? Good things or bad things? > "2. C is the most commonly used programming language in industry. > > True again. Same. > "3. C is the language of choice for programming embedded and mechatronic systems with hardware interfaces" > > I think we all can agree on this. C is more popular that Ada in this area. Based on the same ubiquity in embedded programming, teachers must then suggest assembly language, too. Why does he restrict his conclusion (in 3.)to be C? (Fallacy) > "4. C is one of the most commonly used programming languages in colleges and universities." > > True also. The author does not present evidence. This is simply not acceptable in an academic setting (ucdavis.edu). Looking at "Based on my teaching, research, and industrial experience, I believe..." we might expect to read about teaching, research, and industrial experience founding the belief. Alas, he doesn't bother. (C being taught at universities is not my experience. But this is hardly an argument. Do we have data?) > "5. C excels as a model programming language." > > I would probably argue about this being very accurate. Paragraph 5 has much of a text template where C and other languages would be interchangeable. Besides that, and in accordance with its template characteristic, the argument does, again, not give a single reason that favors C. There are no comparisons with languages considered modeling languages. He claims that studying C can serve as a foundation. He gives no evidence that C is a good or better foundation for modeling than just about anything. > "6. C is the base for all other programming languages." > > There is some truth to this. And there are consequences of the part that is true about C being the base of other languages. (a) Ruby 1.8 and characters. Does not work, been hard to correct. (b) Language work need to bridle C's open ends. (c) Porting C, hence languages, works in theory, less so in practice. Of course, the quantifier "all" is not just wrong, it is deceiving. > "8. C is a standardized programming language with international standards." > > I would not argue against this. How does ISO standardization relate to teaching? Java is not ISO standardized. How does ISO relate to being a competitive student? He considers "competitive" important, but writes against Matlab and Mathematica. (Logical Inconsistency) > "9. Computer programming is becoming a necessary skill for many professions." > > Very true. As Dmitry Kazakov has recently explained, programming is not just a "skill for...", it is a profession. When professional programs are needed, you need professional programmers, don't you? > "10. Computer programming can develop student's critical thinking capabilities." > > True also. "...can be trained in C". can not be trained in not-C? (Fallacy) Do we want future programmers to be trained is solving accidental problems whose cause is really nothing more than a language deficiency here and there, e.g. C's lack of expressibility at the fundamental data type level? > I can't agree that these are still good reasons to teach programming > using C at schools. Yes. This article is a joke by all scientific standards. The author does not compare, even though he claims to know alternatives. He does not give reasons where reasons are expected, "Reason" is a word in the article's title. There are many logical errors. Alas, marketing always outweighs what is intrinsic to teaching. Also, marketing easily defeats the logical habits of computer scientists when rhetoric is needed to overcome the embarrassing state of, by the looks of it, pedagogical ignorance. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-05-03 1:19 ` Nasser M. Abbasi 2011-05-03 6:05 ` J-P. Rosen 2011-05-03 7:53 ` Georg Bauhaus @ 2011-05-03 9:29 ` Simon Wright 2 siblings, 0 replies; 124+ messages in thread From: Simon Wright @ 2011-05-03 9:29 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > "Ten Reasons to Teach and Learn Computer Programming in C" > > http://iel.ucdavis.edu/publication/WhyC.html Interesting that a lot of the time he talks about "C/C++". Such wildly different languages! ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 19:46 ` Dmitry A. Kazakov 2011-04-24 21:20 ` Nasser M. Abbasi @ 2011-04-24 22:23 ` Elias Salomão Helou Neto 2011-04-25 7:10 ` Dmitry A. Kazakov 1 sibling, 1 reply; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-24 22:23 UTC (permalink / raw) On Apr 24, 4:46 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > Anyway, importance > of classic mechanics looks overestimated. You cannot see planets when > living in a large city, but do can the computer on your desk. Explain why > it works using Newtonian mechanics. Why would anyone try it? Newton mechanics is about movement and gravity. I guess you confuse things because of the term "mechanics" in "quantum mechanics". You're the one who should try to explain why rocks fall using quantum mechanics. I see you have a great deal of difficult in separating each problem's domain. > > Then why not start with string theory first before general > > relativity? > > String theory is not yet generally accepted. But Newtonian mechanics is. You must understand it. We don't teach Aristotle's viewpoint, it is not about teaching historic views, but rather an useful and simply understandable theory. And a correct one, whether you want it or not, Newton's mechanics is correct within a huge range of values. In fact, if quantum mechanics did not agree with classical mechanics in the macroscopic world ("classical" quantum mechanics would agree with Newton's theory even at the microscopic realm), it would not have been accepted. The same holds for relativity when velocities are not really high and masses are not huge. It makes a lot of sense teaching the classical viewpoint first, if not for any other reason, to justify new theories by showing that they agree with it. What you want to is to teach theories that are only useful for a much smaller set of problems than Newton's theory is. And to forget Newton's theory. Sorry, but it is far from being wise. It is quite the opposite: it is being fundamentalist. And there is more to that. Quantum mechanics is, as of today, not fully compatible with relativity. Should we pick which of them to teach? Is any of them wrong? Newton's mechanic is the midterm, with each of the theories agree well. Not to teach it, really? There is no correct fundamental theory in physics. There will never be, at least it will not be possible for us to ascertain that it is. All we have are good models that work within certain range of phenomena. Arguably, Newtonian mechanics is the most useful of all them. Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 22:23 ` Elias Salomão Helou Neto @ 2011-04-25 7:10 ` Dmitry A. Kazakov 0 siblings, 0 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-25 7:10 UTC (permalink / raw) On Sun, 24 Apr 2011 15:23:04 -0700 (PDT), Elias Salom�o Helou Neto wrote: > On Apr 24, 4:46�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >> Anyway, importance >> of classic mechanics looks overestimated. You cannot see planets when >> living in a large city, but do can the computer on your desk. Explain why >> it works using Newtonian mechanics. > > Why would anyone try it? Because that is the goal of education. People must see physics as a method of understanding physical world. So is programming, it is not about how to move the mouse cursor, it is about how to program those damned things and how to understand the way things are programmed. P.S. I find this discussion very illuminating. At least it explains to me why we, software industry guys, are so unsatisfied with the output of the education system. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 11:27 ` Peter C. Chapin 2011-04-24 13:53 ` Dmitry A. Kazakov @ 2011-04-24 20:37 ` Georg Bauhaus 1 sibling, 0 replies; 124+ messages in thread From: Georg Bauhaus @ 2011-04-24 20:37 UTC (permalink / raw) Peter C. Chapin <PChapin@vtc.vsc.edu> wrote: > It would be an interesting experiment to try that, but I'm not sure it > would help in the long run. In later courses I want them to write programs > that compile and work so they will need to deal with that issue sooner or > later. Which is easier to teach first? It's unclear. one thing seems certain, though. (1) it is students who should learn all those things. (2) "we" know a certain minimum if things that must be understood in order for the whole to make "sense" from (1) it follows that we can inquire into what students already know. from (1) it follows that we can ask professionals for help with what they can possibly grasp (amount and diversity of information, for example) Then build a formal model, approximate, of learning capacity. From (2), it follows that there exists a model of computation that is didactically complete. (Meyer writes about such a model.) The choice of subjects and languages, then, is a matter of matching the two above. It is a good hint IMHO that our masters learned how to program computers that were a lot simpler than a PC! And do not start introductions to the basics of computing by giving detailed explanations of 7 segment displays. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 2:08 ` Elias Salomão Helou Neto 2011-04-23 7:23 ` Dmitry A. Kazakov @ 2011-04-23 15:23 ` George P. 2011-04-23 17:28 ` Nasser M. Abbasi 2011-04-23 16:56 ` Nasser M. Abbasi 2 siblings, 1 reply; 124+ messages in thread From: George P. @ 2011-04-23 15:23 UTC (permalink / raw) On Apr 22, 10:08 pm, Elias Salomão Helou Neto <eshn...@gmail.com> wrote: > On Apr 22, 6:21 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > > > I think that all significant paradigms are already stated. All languages we > > are talking about are equivalent in terms of Turing completeness. Paradigms > > are of course finer than that, but still I believe that there is nothing > > significantly new left. All these agent-, aspect-, cloud-, extreme-, > > whatever stuff was known and used before 1980. > > I must mention that it is always like that, people tend to believe > that every paradigm is already around until someone comes up with a > "new" one. But it may pretty well be the case that you're right and > they're all already stated, I guess there is just no way to know. > > > Not every man or woman can program. I doubt that programming should be > > taught to people specializing on other majors. Sorry guys, programming is > > not a modern lingua franca. > > Surely you're right. But still I have to teach my students... > > > Nevertheless, future professional programmers should never be exposed to C > > as the first language. It is like teaching physics in the school. Pupils > > first learn the physics of XIX century. When they made 3/4, they are told: > > guys, that was wrong! Here is how it goes! Programmers must learn concepts > > and techniques which C cannot illustrate. What C can illustrate is how not > > to program. > > When it comes to physics, the main reason to teach classical > mechanical is that it is actually a good approximation to modern > theories and the math is far more simple. Nobody will say "guys, that > was wrong!" because that is not wrong, it just must be used within its > valid limits. Rockets reached the moon based on computations that used > classical Newtonian mechanics. > > It is quite different with programming languages, as C is actually > harder than Pascal, which is a great tool for teaching programming. > > Only for the record, my current students are not supposed to become > professional programmers, but physicists. Not that it actually > matters, since those who should become professionals are exposed to C > as a first programming language as well in here. > > > C is poor for teaching because it takes too much noise to illustrate basic > > programming concepts like array, string, result of a function etc. It is > > full of silly limitations, which programmers must learn to circumvent, > > before they get at the core ideas. In the end they learn only these tricks > > and think that programming is about that, lacking understanding of software > > engineering as a whole. > > C is terrible for teaching, but it is not up to me to decide which > language to teach in those introductory classes. > > Elias. Just out of curiosity, why physicists should learn C? Isn't FORTRAN much better choice for them? ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 15:23 ` George P. @ 2011-04-23 17:28 ` Nasser M. Abbasi 2011-04-23 17:52 ` Dmitry A. Kazakov 0 siblings, 1 reply; 124+ messages in thread From: Nasser M. Abbasi @ 2011-04-23 17:28 UTC (permalink / raw) On 4/23/2011 8:23 AM, George P. wrote: > Just out of curiosity, why physicists should learn C? Isn't FORTRAN > much better choice for them? > Yes and No. First, there are really two types of physics courses: computational physics, where the emphasis is on solving physics problems computationally, and there are the classical physics courses, where the emphasis is on solving physics problems analytically. Some courses have a combination of both. For STUDENTS, Fortran is not a good choice for many of the physics courses, other than the ones with more of the computational aspect. Look at any physics dept. these days, hardly anyone is using Fortran any more for teaching. Also, Fortran does not have plotting ability build-in, so if a student solves a differential equation using Fortran and wants to plot the solution, then how to do it? Then have to go learn a new system, maybe gnuplot, learn how to save the data correctly from the Fortran program, etc... Most student have hard time just learning how to open a file, never mind all the rest. Ada would have been a good choice for computational physics, but it also have the same problem when it comes to visualization. That is why, for teaching physics, better to use a packaged system, which makes it easy for students to use, and they can concentrate on the physics, not on the nitty gritty of 'coding'. For courses with more analytical physics, Mathematica/Maple/Sage type systems are better, since they allow symbolic computation, and for the more computational physics courses, other alternative are available, such as Matlab/Ocatve etc..might be a good choice also. The point is to learn physics with least waste of time in the implementation part of the solution of the physics problem. But any one of the above is better than C. --Nasser ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 17:28 ` Nasser M. Abbasi @ 2011-04-23 17:52 ` Dmitry A. Kazakov 2011-04-23 18:11 ` Nasser M. Abbasi 2011-04-23 20:47 ` George P. 0 siblings, 2 replies; 124+ messages in thread From: Dmitry A. Kazakov @ 2011-04-23 17:52 UTC (permalink / raw) On Sat, 23 Apr 2011 10:28:24 -0700, Nasser M. Abbasi wrote: > Also, Fortran does not have plotting ability build-in, so if a > student solves a differential equation using Fortran and wants to > plot the solution, then how to do it? If I correctly remember grafor (Graphical FORTRAN?) was the first ever plotting library. Not that I am advocating FORTRAN, of course... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 17:52 ` Dmitry A. Kazakov @ 2011-04-23 18:11 ` Nasser M. Abbasi 2011-04-23 20:47 ` George P. 1 sibling, 0 replies; 124+ messages in thread From: Nasser M. Abbasi @ 2011-04-23 18:11 UTC (permalink / raw) On 4/23/2011 10:52 AM, Dmitry A. Kazakov wrote: > On Sat, 23 Apr 2011 10:28:24 -0700, Nasser M. Abbasi wrote: > >> Also, Fortran does not have plotting ability build-in, so if a >> student solves a differential equation using Fortran and wants to >> plot the solution, then how to do it? > > If I correctly remember grafor (Graphical FORTRAN?) was the first ever > plotting library. > > Not that I am advocating FORTRAN, of course... (:-)) > I never heard of the above. I collect list of all plotting libraries for Fortran, and that one is not on my list, will add it. Here is the current list I have now (added your reference) 1. PGPLOT 2. PLPLOT 3. PSPLOT 4. DISLIN 5. F90GL 6. GINO 7. grafor (per this post) But whatever it is, it will have the same problem as all the others: it will not be available on the student computer at school, since it is not part of the system. A student can't just go download something from the net, build it, etc.. since this is not allowed to do at school computers. It is really better for students and the teacher to use one known and fully packaged system, which has easy to use graphics, build-in math functions, debugger, editor etc.. all from one source. --Nasser ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 17:52 ` Dmitry A. Kazakov 2011-04-23 18:11 ` Nasser M. Abbasi @ 2011-04-23 20:47 ` George P. 2011-04-24 11:36 ` Peter C. Chapin 1 sibling, 1 reply; 124+ messages in thread From: George P. @ 2011-04-23 20:47 UTC (permalink / raw) On Apr 23, 1:52 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Sat, 23 Apr 2011 10:28:24 -0700, Nasser M. Abbasi wrote: > > Also, Fortran does not have plotting ability build-in, so if a > > student solves a differential equation using Fortran and wants to > > plot the solution, then how to do it? > > If I correctly remember grafor (Graphical FORTRAN?) was the first ever > plotting library. > > Not that I am advocating FORTRAN, of course... (:-)) > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de There were few, and there was always Open-GL. Last time I checked on FORTRAN in 2002-3, it was pretty decent language for the purpose. Nothing like FORTRAN IV I started on. And it also was fast (Compaq/DEC). Surprisingly, while it went through series of dramatic transitions (f90 to f08), it seems that F community is not obsessed with backward compatibility as much as C community. Compilers are able compile and link to old legacy code but for those who writes software there is a new format. Anyone knows how widely it is still being used and what is demographics of it? G. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 20:47 ` George P. @ 2011-04-24 11:36 ` Peter C. Chapin 2011-04-25 11:43 ` Paul Colin Gloster 0 siblings, 1 reply; 124+ messages in thread From: Peter C. Chapin @ 2011-04-24 11:36 UTC (permalink / raw) On Sat, 23 Apr 2011 13:47:51 -0700 (PDT), "George P." <george.priv@gmail.com> wrote: >Surprisingly, while it went through series of dramatic transitions >(f90 to f08), it seems that F community is not obsessed with backward >compatibility as much as C community. Compilers are able compile and >link to old legacy code but for those who writes software there is a >new format. > >Anyone knows how widely it is still being used and what is >demographics of it? Fortran is definitely still being used. I have at times lurked on comp.lang.fortran and it is at least as active as this group (I think more active). And yes, starting with Fortran 90 the language was utterly transformed and is now reasonably modern. I believe the latest version (Fortran 2008) is even object oriented. My impression is that Fortran is still primarly used in its traditional area of numeric computation where C is considered an upstart language. In fact in a head-to-head comparison between C and Fortran it is common for a Fortran program to outperform an equivalent C program. I've explored this effect myself with a toy program that does Gaussian elmination. Thus people interested in maximum numeric performance are drawn to Fortran. Ada could also be a contender in this application area but Fortran's array operators are so nice and modern Fortran compilers are so mature that the language is hard to beat when it comes to numerical applications. In any case, don't joke about Fortran as if it's some kind of dinosaur. It will just make the people in the Fortran community roll their eyes in disgust... or amusement. :) Peter ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-24 11:36 ` Peter C. Chapin @ 2011-04-25 11:43 ` Paul Colin Gloster 0 siblings, 0 replies; 124+ messages in thread From: Paul Colin Gloster @ 2011-04-25 11:43 UTC (permalink / raw) Peter C. Chapin <PChapin@vtc.vsc.edu> sent on April 24th, 2011: |---------------------------------------------------------------------------| |"On Sat, 23 Apr 2011 13:47:51 -0700 (PDT), "George P." | |<george.priv@gmail.com> wrote: | | | |>Surprisingly, while it went through series of dramatic transitions | |>(f90 to f08), it seems that F community is not obsessed with backward | |>compatibility as much as C community. Compilers are able compile and | |>link to old legacy code but for those who writes software there is a | |>new format. | |> | |>Anyone knows how widely it is still being used and what is | |>demographics of it? | | | |Fortran is definitely still being used. I have at times lurked on | |comp.lang.fortran and it is at least as active as this group (I think more | |active). And yes, starting with Fortran 90 the language was utterly | |transformed and is now reasonably modern. I believe the latest version | |(Fortran 2008) is even object oriented." | |---------------------------------------------------------------------------| It was almost decided for the upcoming SPEC CPUv6 that the only languages allowed would be Fortran; C; and C++. Fortunately, I successfully argued that Ada should be allowed, and I mentioned SofCheck AdaMagic. |---------------------------------------------------------------------------| |"My impression is that Fortran is still primarly used in its traditional | |area of numeric computation where C is considered an upstart language. In | |fact in a head-to-head comparison between C and Fortran it is common for a | |Fortran program to outperform an equivalent C program. I've explored this | |effect myself with a toy program that does Gaussian elmination. Thus people| |interested in maximum numeric performance are drawn to Fortran." | |---------------------------------------------------------------------------| VHDL would outperform Fortran. |---------------------------------------------------------------------------| |"Ada could also be a contender in this application area but Fortran's array| |operators are so nice and modern Fortran compilers are so mature that the | |language is hard to beat when it comes to numerical applications. | | | |In any case, don't joke about Fortran as if it's some kind of dinosaur. It | |will just make the people in the Fortran community roll their eyes in | |disgust... or amusement. :) | | | |Peter" | |---------------------------------------------------------------------------| You could educate this ignoramus: "Dr." David Sinclair of Dublin City so-called University: WWW.computing.DCU.Ie/~davids/ In the academic year 1999-2000 he tried to convince me that the only reason someone still used FORTRAN was because of legacy code, and that all new number-crunching code should be in Java! ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 2:08 ` Elias Salomão Helou Neto 2011-04-23 7:23 ` Dmitry A. Kazakov 2011-04-23 15:23 ` George P. @ 2011-04-23 16:56 ` Nasser M. Abbasi 2011-04-23 18:45 ` Elias Salomão Helou Neto 2 siblings, 1 reply; 124+ messages in thread From: Nasser M. Abbasi @ 2011-04-23 16:56 UTC (permalink / raw) On 4/22/2011 7:08 PM, Elias Salom�o Helou Neto wrote: > > Only for the record, my current students are not supposed to become > professional programmers, but physicists. For physics programming, there are much better systems than C. C makes one think more about 'coding' than about the problem itself, which is what one should be thinking about, instead of pointers and casting problems. I suggest the following alternatives as better for physics students: 1. Mathematica: symbolic and numerical and graphics all integrated. 2. Matlab: Simple to program, but less symbolic, but good for computational physics. 3. Maple: Similar to Mathematica, but Mathematica is based on functional programming, Maple is more procedural. 4. Many other open/free alternatives to the above: Octave, Sage, Maxima, etc.. I think C is the worst language to choose to teach students programming in physics, or any other subject, other than operating systems and drivers may be. > > C is terrible for teaching, but it is not up to me to decide which > language to teach in those introductory classes. > > Elias. But you are the teacher, so ofcourse it is up to you. If it is not up the teacher to choose the language to teach with, then you are teaching at the wrong university. This is like saying it is not up to the doctor to decide which medicine should be given to the sick person. regards, --Nasser ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-23 16:56 ` Nasser M. Abbasi @ 2011-04-23 18:45 ` Elias Salomão Helou Neto 0 siblings, 0 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-23 18:45 UTC (permalink / raw) > But you are the teacher, so ofcourse it is up to you. If > it is not up the teacher to choose the language to teach with, > then you are teaching at the wrong university. No, it is not up to me. I'd rather be teaching Matlab (Octave actually), but the course's description clearly stated C and other disciplines will require this knowledge later. Th university I teach is USP, the most prestigious in Latin America. It is the wrong one in the sense that it is not mine, so I can't take all decisions about the courses I teach. > This is like saying it is not up to the doctor to decide which > medicine should be given to the sick person. Not quite, they will be required to know C in later courses and if I don't teach them, who will? Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-22 6:16 ` Elias Salomão Helou Neto 2011-04-22 9:21 ` Dmitry A. Kazakov @ 2011-04-22 12:15 ` J-P. Rosen 2011-04-22 14:56 ` Niklas Holsti 1 sibling, 1 reply; 124+ messages in thread From: J-P. Rosen @ 2011-04-22 12:15 UTC (permalink / raw) Le 22/04/2011 08:16, Elias Salom�o Helou Neto a �crit : > Yep. That's a major problem. No matter how much I try to teach people > to think before coding, they won't do so. But I don't think that Ada > makes it any better, does it? No, it just makes it more likely that inconsistent design will produce code that does not compile. > Of course this is a rather good justification for Ada to be more > widely adopted. As I've said elsewhere on this thread, Ada's premises > are far more realistic than C's ones. But it does not make C a lame > language. > C is not a lame language, because it fulfills its intended purpose: a portable assembly language. The trouble is if you take it for anything else. My view of the difference between C and Ada is as follows: C is the best language to program a computer; Ada is the best language to develop a software application. (please don't quote me on the first half without the second one!) C is simply unbearable to people who are used to thinking at a higher level. (Says someone who programmed in an earlier life at a much lower level than anybody does nowadays - in binary, directly on the keys of a control panel). ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-22 12:15 ` J-P. Rosen @ 2011-04-22 14:56 ` Niklas Holsti 0 siblings, 0 replies; 124+ messages in thread From: Niklas Holsti @ 2011-04-22 14:56 UTC (permalink / raw) J-P. Rosen wrote: > Le 22/04/2011 08:16, Elias Salom�o Helou Neto a �crit : >> Yep. That's a major problem. No matter how much I try to teach people >> to think before coding, they won't do so. But I don't think that Ada >> makes it any better, does it? > No, I disagree with J-P. Even if Ada programmers may be as likely as C programmers to start typing ("coding") before thinking, I believe that Ada programmers are much more likely to start by typing things that are on the design level, such as package declarations, type declarations, and subprogram declarations, because these things are so much better supported and therefore easier to use in Ada than in C. Thus, the initial Ada "coding" is really "designing". A programmer can of course create a C program in the same way, with type declarations in header files etc., but the traditional C culture does not guide programmers in this direction. > it just makes it more likely that inconsistent design will produce > code that does not compile. I entirely agree with that. >> Of course this is a rather good justification for Ada to be more >> widely adopted. As I've said elsewhere on this thread, Ada's premises >> are far more realistic than C's ones. But it does not make C a lame >> language. >> > C is not a lame language, because it fulfills its intended purpose: a > portable assembly language. In my view C is not even good as a portable assembly language. The least I would expect from an assembly language is full control over the machine, at least over the abstracted machine that the language shows you. But in C, very basic things such as the behaviour on overflow of signed integer operations is undefined. Only recently has the language even defined integer types with known sizes. I think C was originally an attempt to get some of the benefits of a high-level language (portability being one of them) with the same performance and code size as assembly language. In the circumstances of the first C implementations, the language designers and compiler developers were satisfied with a hybrid language that has some high-level flavour but is mired in a swamp of low-level, yet undefined and unportable semantics. Perhaps this was the best that they could do, within their resources, but unfortunately C became popular and standardized in this inadequate form. I think of C as a Model-T Ford. It worked, and still works, but good grief... to claim that it is the ideal car boggles my mind. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 16:19 ` Elias Salomão Helou Neto 2011-04-21 17:36 ` Dmitry A. Kazakov @ 2011-04-21 23:29 ` Randy Brukardt 2011-04-22 6:29 ` Elias Salomão Helou Neto 2011-04-25 11:22 ` Paul Colin Gloster 2 siblings, 1 reply; 124+ messages in thread From: Randy Brukardt @ 2011-04-21 23:29 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 5778 bytes --] "Elias Salom�o Helou Neto" <eshneto@gmail.com> wrote in message news:4b5748dc-60fa-4cec-a317-054626e9a1ca@d19g2000prh.googlegroups.com... >> We're not talking about C specifically, we're talking about "a new >> language". > > New to the programmer or to the world? If it is the former, I still > recommend a book. A textbook will take you from the basics to the more > advanced features of the language. This is the way to learn. By > skipping the first steps people simply won't know the most basic > stuff, such as C's type promotions. > > Instead, people like to program by "trial and error". Which will > rarely, if ever, work. I don't think anyone was advocating "trial-and-error". But there are lots of ways to learn something beyond reading a textbook. (I've rarely done that specifically.) ... >> These days, I hardly expect anyone to expect requiring a "book" to do >> anything. Even counting "e-books" as "books", there are a lot of >> information >> sources which have nothing to do with "books". It was a lot harder to >> understand back in 1981, yet it still happened then (and even then there >> were a lot of information sources having nothing to do with books - >> papers, >> magazine articles, seminars, lectures, computer-aided-instruction). > > I still do not recommend any of those as means for a beginner to learn > a language: papers are not for beginners; magazine articles are too > vague or too specific; seminars are usually too short to be of any use > for beginners and they are, decause of being short, focused on a too > narrow or too vague subject; lectures are good, but good lecturers > will likely indicate a bibliography, which will include textbooks if > it is intended to beginners. Perhaps computer-aided-instruction, but I > haven't seen it in use, so I do not recommend it. > > Remember, I am a professor. I do lecture and present seminars. And no, > seminars won't teach you how to program. Neither will the lectures, > unless followed by laboratory classes and homeworks, which should be > done alongside a good book on the subject. Honestly, I do not like > students taking notes of my lectures, they should be paying attention > and latter they should use the recommended book as a reference. Unless > I've explicitly stated otherwise. I suspected that, and that is your bias here. For the most part, I don't agree with the need for formal training. It's useful for those with no programming training at all, but for those that have significant programming experience, picking up a new language does not require that level of imersion. ... >> And I doubt I would *buy* a textbook these days; pretty much everything >> one >> needs is on-line (and often not in the form of a book!). > > Even though there is plenty information on the internet, books are > still worth buying, I am sure of that. You can't (legally) find the > really good textbooks on-line neither you can find anything comparable > to those textbooks. Good information still has its price. > > As a test, find me a replacement for "C++ Primer" on-line. Dunno anything about C++, but at least two of the best Ada books are available free on-line (English's "Ada 95: The Craft of Object-Oriented Programming" [for new programmers] and Riehle's "Ada Distilled" [for experienced programmers new to Ada]). I've probably forgotten some. The Ada Programming Wikibook is also a good resource, especially to answer questions. Perhaps the C++ market is different because there is a lot more money to be made, but I would doubt it. There are good Ada books that you can only buy, of course, but unless you are doing a professional project, I recommend starting with the free resources. If it turns out that Ada is not for you, you are only out time. ... >> Maybe *you* have to fight it. I happen to think that a language that is >> unnecessarily different than what a typical programmer would expect is >> dangerous. (And yes, Ada suffers from this in a few places as well -- and >> those things are also dangerous.) > > Ops. I think you're wrong here. Programming languages _must_ be > different from each other, otherwise there would not be reason for so > many to exist. And some new, useful, paradigms appear that can't be > natural to any programmer simply because it did not exist before its > invention! I'm unconvinced that most programming languages even need to exist. Most programming languages exist because someone thought that they could do it better. And hardly any of them were right. :-) Ada has a different history than that (although one could argue the same thing). I don't see the point of using a polyglot of programming languages that all do essentially the same thing. One of the problems is that everyone makes incremental differences in their programming languages, which just makes them different without making them much better. This is the same problem that I have with the way Microsoft changes everything around in each new version of Windows, without any obvious improvement in functionality (it is just different, and thus requires relearning everything you already know). For a new programming language (or OS) to be worthwhile, it needs to embody a significant paradyme shift (such as functional or transactional programming for a programming language, or a touch GUI, as in iOS/Android). Otherwise, we might as well be using Windows 2000 (it worked perfectly fine, thank you). A programming language that brings something wildly new to the table might be worthwhile, but piles of languages all the same just waste time. (You can probably tell that I support/use interfacing to C and other languages by practical necessity, and definitely not by choice!) Randy. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 23:29 ` Randy Brukardt @ 2011-04-22 6:29 ` Elias Salomão Helou Neto 0 siblings, 0 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-22 6:29 UTC (permalink / raw) On Apr 21, 8:29 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > I suspected that, and that is your bias here. For the most part, I don't > agree with the need for formal training. It's useful for those with no > programming training at all, but for those that have significant programming > experience, picking up a new language does not require that level of > imersion. C does. People must understand it. That's what I've been trying to explain. > Dunno anything about C++, but at least two of the best Ada books are > available free on-line (English's "Ada 95: The Craft of Object-Oriented > Programming" [for new programmers] and Riehle's "Ada Distilled" [for > experienced programmers new to Ada]). I've probably forgotten some. The Ada > Programming Wikibook is also a good resource, especially to answer > questions. Great, thank you for pointing me those! But they're still books :-) Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 16:19 ` Elias Salomão Helou Neto 2011-04-21 17:36 ` Dmitry A. Kazakov 2011-04-21 23:29 ` Randy Brukardt @ 2011-04-25 11:22 ` Paul Colin Gloster 2 siblings, 0 replies; 124+ messages in thread From: Paul Colin Gloster @ 2011-04-25 11:22 UTC (permalink / raw) [-- Attachment #1: Type: TEXT/PLAIN, Size: 1592 bytes --] Elias Salomão Helou Neto <eshneto@gmail.com> sent on April 21st, 2011: |---------------------------------------------------------------------| |"[..] | | | |[..] | |[..] Honestly, I do not like | |students taking notes of my lectures, they should be paying attention| |[..]" | |---------------------------------------------------------------------| Who writes once reads twice. |---------------------------------------------------------------------| |"[..] | | | |Ops. I think you're wrong here. Programming languages _must_ be | |different from each other, otherwise there would not be reason for so| |many to exist. And some new, useful, paradigms appear that can't be | |natural to any programmer simply because it did not exist before its | |invention! | | | |[..]" | |---------------------------------------------------------------------| Some languages must be different from each other, but there are unnecessarily many languages. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 23:26 ` Gautier write-only 2011-04-17 23:43 ` Nasser M. Abbasi @ 2011-04-18 19:13 ` Elias Salomão Helou Neto 1 sibling, 0 replies; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-18 19:13 UTC (permalink / raw) On Apr 17, 8:26 pm, Gautier write-only <gautier_niou...@hotmail.com> wrote: > On 17 avr, 21:19, Elias Salomão Helou Neto <eshn...@gmail.com> wrote: > > > All reasonable men will try to learn the language before programming. > > Waw! Then you won't meet many reasonable people in companies (or > perhaps only among those who never program)... That's exactly what I meant. Because reasonable people are expensive. Elias. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-17 19:19 ` Elias Salomão Helou Neto 2011-04-17 23:26 ` Gautier write-only @ 2011-04-20 5:11 ` J-P. Rosen 2011-04-20 15:45 ` KK6GM ` (2 more replies) 1 sibling, 3 replies; 124+ messages in thread From: J-P. Rosen @ 2011-04-20 5:11 UTC (permalink / raw) Le 17/04/2011 21:19, Elias Salom�o Helou Neto a �crit : > All reasonable men will try to learn the language before programming. > The mentioned behavior is the one C is supposed to have, whether you > like it or not. It one of the first thing I teach in my C classes: > type promotions in expression. They may be dumb, or may not, I will > not argue on that. But being reasonable is knowing the tool before > trying to use it. > I really wonder why there are barriers on balconies. All reasonable people know that being too close to the edge of the balcony is dangerous. Here is a quote from one of the first books on C, written by K&R: "C was designed under the assumption that the programmer is someone reasonable who knows what he is doing". Here is a quote from the introduction to the Ada LRM: "Ada was designed with consideration for programming as a human activity" I let as a philosophy homework that these two starting point led to completely different languages. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Adalog a d�m�nag� / Adalog has moved: 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-20 5:11 ` J-P. Rosen @ 2011-04-20 15:45 ` KK6GM 2011-04-20 19:04 ` Vinzent Hoefler 2011-04-21 14:18 ` Elias Salomão Helou Neto 2 siblings, 0 replies; 124+ messages in thread From: KK6GM @ 2011-04-20 15:45 UTC (permalink / raw) On Apr 19, 10:11 pm, "J-P. Rosen" <ro...@adalog.fr> wrote: > Le 17/04/2011 21:19, Elias Salom o Helou Neto a crit : > > > All reasonable men will try to learn the language before programming. > > The mentioned behavior is the one C is supposed to have, whether you > > like it or not. It one of the first thing I teach in my C classes: > > type promotions in expression. They may be dumb, or may not, I will > > not argue on that. But being reasonable is knowing the tool before > > trying to use it. > > I really wonder why there are barriers on balconies. All reasonable > people know that being too close to the edge of the balcony is dangerous. > > Here is a quote from one of the first books on C, written by K&R: > "C was designed under the assumption that the programmer is someone > reasonable who knows what he is doing". > > Here is a quote from the introduction to the Ada LRM: > "Ada was designed with consideration for programming as a human activity" > > I let as a philosophy homework that these two starting point led to > completely different languages. A simple extrapolation of a 2002 study puts the worldwide cost of buggy software at about $350 billion today. 1/3 of that cost is incurred by developers, 2/3 by end users. I want to know who these reasonable developers are who are OK with losing $120 billion per year using "popular" languages when all the data points to languages that could reduce that figure dramatically. And I'd like to know what their customers would think (the customers who are losing $240 billion a year) if they knew that they were being sold buggy software even though there were proven languages that could reduce that loss dramatically. So, by what standard is the use of C "reasonable"? ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-20 5:11 ` J-P. Rosen 2011-04-20 15:45 ` KK6GM @ 2011-04-20 19:04 ` Vinzent Hoefler 2011-04-20 21:09 ` Georg Bauhaus 2011-04-21 14:18 ` Elias Salomão Helou Neto 2 siblings, 1 reply; 124+ messages in thread From: Vinzent Hoefler @ 2011-04-20 19:04 UTC (permalink / raw) J-P. Rosen wrote: > Here is a quote from one of the first books on C, written by K&R: > "C was designed under the assumption that the programmer is someone > reasonable who knows what he is doing". Or simply: <http://www.open-std.org/jtc1/sc22/wg14/www/charter>: |Some of the facets of the spirit of C can be summarized in phrases like |(a) Trust the programmer. |(b) Don't prevent the programmer from doing what needs to be done. |(c) Keep the language small and simple. |(d) Provide only one way to do an operation. |(e) Make it fast, even if it is not guaranteed to be portable. Now the question remains who is more reasonable: The one using a language that prevents him from making silly mistakes - or the one assuming he does not even make those mistakes in the first place. Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-20 19:04 ` Vinzent Hoefler @ 2011-04-20 21:09 ` Georg Bauhaus 2011-04-20 22:52 ` Vinzent Hoefler 0 siblings, 1 reply; 124+ messages in thread From: Georg Bauhaus @ 2011-04-20 21:09 UTC (permalink / raw) On 4/20/11 9:04 PM, Vinzent Hoefler wrote: > <http://www.open-std.org/jtc1/sc22/wg14/www/charter>: > > |Some of the facets of the spirit of C can be summarized in phrases like > |(a) Trust the programmer. > |(b) Don't prevent the programmer from doing what needs to be done. > |(c) Keep the language small and simple. > |(d) Provide only one way to do an operation. > |(e) Make it fast, even if it is not guaranteed to be portable. Not much different from what is true about Ada. (a) (Like Haskell,) Ada trusts the programmer to be explicit, e.g. instantiating Unchecked_Conversion. Normally, though, Ada doesn't trust us when we want to pass addresses of local objects up the call chain. But it is possible. (b) Ada seems to make it a little difficult to get pointer arithmetic from Interfaces.C.Pointers to omit null tests. But otherwise... (c) The C standard is about the same size as Ada's, isn't it? C is simple? (d) Are there two ways to do an operation in Ada? (e) Some Ada programs are fast and still guaranteed to be portable. That's true of some C programs as well. Ada programs might need unchecked conversions and representation clauses to make a program non-portable. Although, an Ada program need not be non-portable even though we let the *compiler* choose efficient the representation on a target machine: type Roman is ('M', 'D', 'C', 'L', 'V', 'I', 'X'); for Roman'Size use Integer'Size; function To_Integer is new Unchecked_Conversion(Roman, Integer); Now To_Integer(X) + N; will produce the "byte operation [that] is more efficient on the target machine" iff the compiler uses efficient byte operations for Integer. Or this, type S is new String; for S'Component_Size use Integer'Size; So I guess C's (e) is working around the fact that C's choices would not allow the programmer to say what needs to be done? ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-20 21:09 ` Georg Bauhaus @ 2011-04-20 22:52 ` Vinzent Hoefler 0 siblings, 0 replies; 124+ messages in thread From: Vinzent Hoefler @ 2011-04-20 22:52 UTC (permalink / raw) Georg Bauhaus wrote: > On 4/20/11 9:04 PM, Vinzent Hoefler wrote: > >> <http://www.open-std.org/jtc1/sc22/wg14/www/charter>: >> >> |Some of the facets of the spirit of C can be summarized in phrases like >> |(a) Trust the programmer. >> |(b) Don't prevent the programmer from doing what needs to be done. >> |(c) Keep the language small and simple. >> |(d) Provide only one way to do an operation. >> |(e) Make it fast, even if it is not guaranteed to be portable. > > Not much different from what is true about Ada. I am quite sure, that the meaning of "trust the programmer" is completely different here. More along the lines of "if in doubt, the programmer takes precedence". Also for the "prevention". Ada doesn't prevent you from doing bad things, but at least it makes it hard for you - and visible for others. > (c) The C standard is about the same size as Ada's, isn't it? > C is simple? It has less pages at least: Just checked, my copy of the C99 PDF has 554 pages, the ARM05 has 791 pages. But considering that the ARM is much wordier than its C counterpart... > (d) Are there two ways to do an operation in Ada? Less so than in C. > (e) Some Ada programs are fast and still guaranteed to be portable. > That's true of some C programs as well. Ada programs might need unchecked > conversions and representation clauses to make a program non-portable. There are easier ways to make it non-portable. Using Integer and assuming 'Size of 32, for instance, just like someone would in C when using "int". > So I guess C's (e) is working around the fact that C's choices > would not allow the programmer to say what needs to be done? Like the lack of being able to define the Endianess of bit-records? That's what the charter says: |3. C code can be non-portable. Although it strove to give programmers the |opportunity to write truly portable programs, the Committee did not want to |force programmers into writing portably, to preclude the use of C as a |``high-level assembler;'' the ability to write machine-specific code is one |of the strengths of C. So, their understanding of "what needs to be done" seems more like "forgot the syntax of my assembler, lemme use C instead". ;) Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-20 5:11 ` J-P. Rosen 2011-04-20 15:45 ` KK6GM 2011-04-20 19:04 ` Vinzent Hoefler @ 2011-04-21 14:18 ` Elias Salomão Helou Neto 2011-04-21 16:22 ` Vinzent Hoefler 2 siblings, 1 reply; 124+ messages in thread From: Elias Salomão Helou Neto @ 2011-04-21 14:18 UTC (permalink / raw) On Apr 20, 2:11 am, "J-P. Rosen" <ro...@adalog.fr> wrote: > Le 17/04/2011 21:19, Elias Salom o Helou Neto a crit : > > > All reasonable men will try to learn the language before programming. > > The mentioned behavior is the one C is supposed to have, whether you > > like it or not. It one of the first thing I teach in my C classes: > > type promotions in expression. They may be dumb, or may not, I will > > not argue on that. But being reasonable is knowing the tool before > > trying to use it. > > I really wonder why there are barriers on balconies. All reasonable > people know that being too close to the edge of the balcony is dangerous. What about kids? C is not out there to be used by kids, as barriers on balconies are mostly because of that. Furthermore, there are always those who have acrophobia.. > Here is a quote from one of the first books on C, written by K&R: > "C was designed under the assumption that the programmer is someone > reasonable who knows what he is doing". > > Here is a quote from the introduction to the Ada LRM: > "Ada was designed with consideration for programming as a human activity" > > I let as a philosophy homework that these two starting point led to > completely different languages. Interestingly, just like I said, C "pretends" people are reasonable, while Ada does not. The second approach is far nearer the truth, as we all can see. ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 14:18 ` Elias Salomão Helou Neto @ 2011-04-21 16:22 ` Vinzent Hoefler 2011-04-21 19:25 ` John B. Matthews 0 siblings, 1 reply; 124+ messages in thread From: Vinzent Hoefler @ 2011-04-21 16:22 UTC (permalink / raw) Elias Salomão Helou Neto wrote: > Interestingly, just like I said, C "pretends" people are reasonable, > while Ada does not. The second approach is far nearer the truth, as we > all can see. One of my favorite quotes I read somewhere (Bruce Powell Douglas, I think): " C treats you like a consent adult. Pascal treats you like a naughty child. Ada treats you like a criminal. " This also explains the different popularity of those languages. ;) Still, when it comes to safety-critical, I'd rather be treated like a criminal by a compiler than by a judge. :-> Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-21 16:22 ` Vinzent Hoefler @ 2011-04-21 19:25 ` John B. Matthews 0 siblings, 0 replies; 124+ messages in thread From: John B. Matthews @ 2011-04-21 19:25 UTC (permalink / raw) In article <op.vuaqfkwhlzeukk@jellix.jlfencey.com>, "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote: > Elias Salomão Helou Neto wrote: > > > Interestingly, just like I said, C "pretends" people are > > reasonable, while Ada does not. The second approach is far nearer > > the truth, as we all can see. > > One of my favorite quotes I read somewhere (Bruce Powell Douglas, I > think): > > " C treats you like a consent adult. Pascal treats you like a naughty > child. Ada treats you like a criminal. " > > This also explains the different popularity of those languages. ;) > Still, when it comes to safety-critical, I'd rather be treated like a > criminal by a compiler than by a judge. :-> Inexplicably, others seem to resent it: <https://groups.google.com/d/topic/rec.humor.funny.reruns/bo5KznjUtXo> I think I may have "Ada tendencies." :-) -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews> ^ permalink raw reply [flat|nested] 124+ messages in thread
* Re: Fun with C 2011-04-16 17:02 Fun with C George P. ` (2 preceding siblings ...) 2011-04-17 19:19 ` Elias Salomão Helou Neto @ 2011-04-23 23:07 ` Gerd 3 siblings, 0 replies; 124+ messages in thread From: Gerd @ 2011-04-23 23:07 UTC (permalink / raw) On 16 Apr., 19:02, "George P." <george.p...@gmail.com> wrote: > Spend few days chasing bug in embedded C project which can drilled > down to this. Consider the following program, and all reasonable men > will expect the result to be negative. Not in C, and it is not a > compiler bug :-( > > And offcorse none of the three comilers I cheched did not bother to > issue a warning at least.. > > #include <stdio.h> > > int main() > { > unsigned n = 128; > int i = -2048; > int r; > > r = i / n; > > printf("R = %d\n", r); > > return 0; > > > > }- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Try to run a MISRA checker. ^ permalink raw reply [flat|nested] 124+ messages in thread
end of thread, other threads:[~2011-05-20 16:04 UTC | newest] Thread overview: 124+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-04-16 17:02 Fun with C George P. 2011-04-16 20:04 ` Nasser M. Abbasi 2011-04-16 21:12 ` Ludovic Brenta 2011-04-16 21:42 ` jimmaureenrogers 2011-04-17 7:17 ` Georg Bauhaus 2011-04-17 8:29 ` Martin 2011-04-17 18:19 ` George P. 2011-04-17 8:40 ` Georg Bauhaus 2011-04-18 1:04 ` Peter C. Chapin 2011-04-18 2:14 ` George P. 2011-04-16 22:03 ` George P. 2011-04-17 6:26 ` KK6GM 2011-04-17 6:59 ` Georg Bauhaus 2011-04-17 16:15 ` KK6GM 2011-04-17 19:35 ` Elias Salomão Helou Neto 2011-04-17 20:18 ` KK6GM 2011-04-18 19:47 ` Elias Salomão Helou Neto 2011-04-18 22:11 ` Peter C. Chapin 2011-04-17 22:26 ` Georg Bauhaus 2011-04-18 19:12 ` Elias Salomão Helou Neto 2011-04-18 20:56 ` KK6GM 2011-04-18 21:01 ` Georg Bauhaus 2011-04-18 21:20 ` Nasser M. Abbasi 2011-04-19 2:43 ` George P. 2011-04-19 18:05 ` Vinzent Hoefler 2011-04-19 19:34 ` George P. 2011-04-19 20:08 ` Georg Bauhaus 2011-04-19 1:10 ` Elias Salomão Helou Neto 2011-04-19 14:28 ` Georg Bauhaus 2011-04-19 17:40 ` Jeffrey Carter 2011-04-21 14:52 ` Elias Salomão Helou Neto 2011-04-21 18:58 ` Georg Bauhaus 2011-04-21 19:27 ` Hyman Rosen 2011-04-28 5:13 ` David Thompson 2011-04-28 13:41 ` Hyman Rosen 2011-05-05 8:39 ` David Thompson 2011-04-25 11:06 ` Paul Colin Gloster 2011-04-25 11:00 ` Georg Bauhaus 2011-04-25 12:12 ` Martin 2011-04-25 18:39 ` Paul Colin Gloster 2011-05-08 23:41 ` wilso 2011-05-20 10:41 ` Yannick Duchêne (Hibou57) 2011-05-20 16:04 ` Yannick Duchêne (Hibou57) 2011-04-18 0:12 ` George P. 2011-04-18 19:24 ` Elias Salomão Helou Neto 2011-04-19 1:22 ` George P. 2011-04-19 2:06 ` Elias Salomão Helou Neto 2011-04-19 2:37 ` Bill Findlay 2011-04-19 3:00 ` George P. 2011-04-17 19:19 ` Elias Salomão Helou Neto 2011-04-17 23:26 ` Gautier write-only 2011-04-17 23:43 ` Nasser M. Abbasi 2011-04-18 19:16 ` Elias Salomão Helou Neto 2011-04-18 23:10 ` Randy Brukardt 2011-04-19 1:36 ` Elias Salomão Helou Neto 2011-04-20 23:14 ` Randy Brukardt 2011-04-21 16:19 ` Elias Salomão Helou Neto 2011-04-21 17:36 ` Dmitry A. Kazakov 2011-04-21 17:43 ` Hyman Rosen 2011-04-21 19:44 ` Dmitry A. Kazakov 2011-04-22 6:16 ` Elias Salomão Helou Neto 2011-04-22 9:21 ` Dmitry A. Kazakov 2011-04-22 13:18 ` Hyman Rosen 2011-04-22 15:17 ` Dmitry A. Kazakov 2011-04-23 2:08 ` Elias Salomão Helou Neto 2011-04-23 7:23 ` Dmitry A. Kazakov 2011-04-23 9:42 ` Georg Bauhaus 2011-04-23 10:23 ` Dmitry A. Kazakov 2011-04-23 18:37 ` Elias Salomão Helou Neto 2011-04-23 21:36 ` Dmitry A. Kazakov 2011-04-24 11:27 ` Peter C. Chapin 2011-04-24 13:53 ` Dmitry A. Kazakov 2011-04-24 19:07 ` Nasser M. Abbasi 2011-04-24 19:46 ` Dmitry A. Kazakov 2011-04-24 21:20 ` Nasser M. Abbasi 2011-04-24 22:33 ` Elias Salomão Helou Neto 2011-04-25 7:09 ` Dmitry A. Kazakov 2011-04-25 20:46 ` Maciej Sobczak 2011-04-25 21:19 ` George P. 2011-04-26 6:18 ` Dmitry A. Kazakov 2011-04-26 6:58 ` Nasser M. Abbasi 2011-04-26 8:39 ` Dmitry A. Kazakov 2011-04-26 20:57 ` Maciej Sobczak 2011-04-27 8:00 ` Dmitry A. Kazakov 2011-04-27 8:19 ` Georg Bauhaus 2011-04-27 9:32 ` Dmitry A. Kazakov 2011-04-28 7:02 ` Maciej Sobczak 2011-04-28 7:41 ` Dmitry A. Kazakov 2011-04-28 10:24 ` Peter C. Chapin 2011-04-28 13:56 ` Dmitry A. Kazakov 2011-05-03 1:19 ` Nasser M. Abbasi 2011-05-03 6:05 ` J-P. Rosen 2011-05-03 6:15 ` Ludovic Brenta 2011-05-03 7:43 ` Dmitry A. Kazakov 2011-05-03 15:34 ` Bill Findlay 2011-05-03 7:53 ` Georg Bauhaus 2011-05-03 9:29 ` Simon Wright 2011-04-24 22:23 ` Elias Salomão Helou Neto 2011-04-25 7:10 ` Dmitry A. Kazakov 2011-04-24 20:37 ` Georg Bauhaus 2011-04-23 15:23 ` George P. 2011-04-23 17:28 ` Nasser M. Abbasi 2011-04-23 17:52 ` Dmitry A. Kazakov 2011-04-23 18:11 ` Nasser M. Abbasi 2011-04-23 20:47 ` George P. 2011-04-24 11:36 ` Peter C. Chapin 2011-04-25 11:43 ` Paul Colin Gloster 2011-04-23 16:56 ` Nasser M. Abbasi 2011-04-23 18:45 ` Elias Salomão Helou Neto 2011-04-22 12:15 ` J-P. Rosen 2011-04-22 14:56 ` Niklas Holsti 2011-04-21 23:29 ` Randy Brukardt 2011-04-22 6:29 ` Elias Salomão Helou Neto 2011-04-25 11:22 ` Paul Colin Gloster 2011-04-18 19:13 ` Elias Salomão Helou Neto 2011-04-20 5:11 ` J-P. Rosen 2011-04-20 15:45 ` KK6GM 2011-04-20 19:04 ` Vinzent Hoefler 2011-04-20 21:09 ` Georg Bauhaus 2011-04-20 22:52 ` Vinzent Hoefler 2011-04-21 14:18 ` Elias Salomão Helou Neto 2011-04-21 16:22 ` Vinzent Hoefler 2011-04-21 19:25 ` John B. Matthews 2011-04-23 23:07 ` Gerd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox