In article ,
Neil Cerutti wrote:
>On 2013-12-17, Steven D'Aprano
> wrote:
>> I would really like to see good quality statistics about bugs
>> per program written in different languages. I expect that, for
>> all we like to make fun of COBOL, it probably has few bugs per
>> unit-of-useful-work-don
In article <20131216213225.2006b30246e3a08ee241a...@gmx.net>,
Wolfgang Keller wrote:
>> > And ever after that experience, I avoided all languages that were
>> > even remotely similar to C, such as C++, Java, C#, Javascript, PHP
>> > etc.
>>
>> I think that's disappointing, for two reasons. First
On Thu, 19 Dec 2013 19:38:51 -0500, Roy Smith wrote:
> Does anybody ever use D? I looked at it a few years ago. It seemed
> like a very good concept. Sort of C++, with the worst of the crap torn
> out. If nothing else, with the preprocessor torn out :-)
>
> Did it ever go anywhere?
Apparently
On 12/20/13 6:58 PM, Dennis Lee Bieber wrote:
On 20 Dec 2013 02:16:05 GMT, Steven D'Aprano
declaimed the following:
2) Even for kernel developers, I believe that systems languages should be
safe by default. You ought to have to explicitly disable (say) bounds
checking in critical sections of
On Thu, 19 Dec 2013 19:38:51 -0500, Roy Smith wrote:
> In article <52b328f7$0$6512$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> Correct. The *great deal of trouble* part is important. Things which
>> are the responsibility of the language and compiler in (say) Java, D,
>>
On Fri, 20 Dec 2013 00:38:51 -, Roy Smith wrote:
I disagree entirely (but respectfully). If you want to get down to the
hardware where you can fiddle bits, you want as little getting between
you and the silicon as possible. Every time you add a safety feature,
you put another layer of *st
In article <52b328f7$0$6512$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> Correct. The *great deal of trouble* part is important. Things which are
> the responsibility of the language and compiler in (say) Java, D, Rust,
> Go, etc. are the responsibility of the programmer with
In article <52b365b6$0$6512$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
[some stuff]
> where Unix went, so did C;
[some more stuff]
What he said.
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, 19 Dec 2013 04:50:54 +, Mark Lawrence wrote:
> If C is such a crap language, what does it says for the thousands of
> languages that never got anywhere? Or did C simply have a far larger
> sales and marketing budget? :)
The sociology of computer languages is a fascinating topic. Like
On Fri, Dec 20, 2013 at 7:42 AM, Gregory Ewing
wrote:
> A piece of code such as
>
>for (i = 0; i < numThings; i++)
> total[i] += things[i];
>
> is NOT improved by rewriting it as
>
>for (theLoopIndex = 0; theLoopIndex < numThings; theLoopIndex++)
> total[theLoopIndex] += things
Wolfgang Keller wrote:
In fact, thinking of it, a really good language should imho *require*
verbosity (how about a *minimum* length - or maybe even a
dictionary-based sanity check - for identifiers?), since that already
keeps all those lazy morons away who think that "shortcuts are cool".
No,
On Fri, Dec 20, 2013 at 5:40 AM, Neil Cerutti wrote:
> And another thing: How many other languages have their very own
> calling convention?
Pascal does (sometimes called the Win32 convention).
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On 2013-12-19, Chris Angelico wrote:
> On Fri, Dec 20, 2013 at 4:12 AM, Steven D'Aprano
> wrote:
>> But why is so much non-performance critical code written in C?
>> Why so many user-space applications?
>
> Very good question! I don't have an answer. There are a few
> "maybe-answers", but they mos
On Fri, Dec 20, 2013 at 4:12 AM, Steven D'Aprano
wrote:
> But why is so much non-performance critical code written in C? Why so
> many user-space applications?
Very good question! I don't have an answer. There are a few
"maybe-answers", but they mostly come down to "programmer didn't know
of a vi
> On Thursday, December 19, 2013 9:46:26 AM UTC+5:30, Roy Smith wrote:
> > rusi wrote:
> > > Soon the foo has to split into foo1.c and foo2.c. And suddenly you need
> > > to
> > > understand:
> > > 1. Separate compilation
> > > 2. Make (which is separate from 'separate compilation')
> > > 3. H
On Fri, Dec 20, 2013 at 4:06 AM, Steven D'Aprano
wrote:
> Should some implementation decide to compile that away as dead
> code, it would be perfectly allowed to. (Well, assuming that it
> determined first that locals() actually was the built-in and not some
> substitute, either by static analysis
On Wed, 18 Dec 2013 17:15:30 +, Mark Lawrence wrote:
> On 18/12/2013 08:18, Steven D'Aprano wrote:
>>
>> The C99 standard lists 191 different kinds of undefined behavior,
>> including what happens when there is an unmatched ' or " on a line of
>> source code.
>>
>> No compile-time error, no ru
On Wed, 18 Dec 2013 17:33:49 -0500, Terry Reedy wrote:
> On 12/18/2013 3:18 AM, Steven D'Aprano wrote:
>
>> We don't know what locals()['spam'] = 42 will do inside a function,
>
> I am mystified that you would write this.
Context is everything. locals() doesn't just return any old dictionary.
On Fri, Dec 20, 2013 at 3:20 AM, Steven D'Aprano
wrote:
> On Wed, 18 Dec 2013 19:51:26 +1100, Chris Angelico wrote:
>
>> On Wed, Dec 18, 2013 at 7:18 PM, Steven D'Aprano
>> wrote:
>>> You want to know why programs written in C are so often full of
>>> security holes? One reason is "undefined beha
On Wed, 18 Dec 2013 19:51:26 +1100, Chris Angelico wrote:
> On Wed, Dec 18, 2013 at 7:18 PM, Steven D'Aprano
> wrote:
>> You want to know why programs written in C are so often full of
>> security holes? One reason is "undefined behaviour". The C language
>> doesn't give a damn about writing *cor
On Wed, 18 Dec 2013 07:23:54 -0800, Ethan Furman wrote:
> On 12/18/2013 12:18 AM, Steven D'Aprano wrote:
>> And yes, I'm being pedantic.
>
> No, you're being an ass.
My my, it doesn't take much of a challenge to the Holy Church Of C to
bring out the personal attacks.
--
Steven
--
https://m
> > I've never heard C syntax reviled quite so intensely. What syntax
> > do you like, out of curiosity?
>
> Pascal, Python, if written by someone who uses semantic identifiers
> and avoids to use C(++)/Java-isms. I've seen Eiffel as well (without
> understanding it) and it didn't look ridiculous
> I find it frustrating that Pythonistas shy away from regex as much as
> they do.
I find regular expression syntax frustrating. >;->
As long as I have the choice, I still prefer syntax like e.g.
VerbalExpressions. That's made for actual humans like me.
Sincerely,
Wolfgang
--
https://mail.pyt
On Thu, 19 Dec 2013 19:41:00 +1300, Gregory Ewing
wrote:
But it's not above inferring a dereferencing
operation when you call a function via a
pointer. If f is a pointer to a function,
then
f(a)
is equivalent to
(*f)(a)
If the compiler can do that for function calls,
ther
Roy Smith wrote:
I suspect what you mean is, "There are some things that don't make sense
until you understand computer architecture".
An example of that kind of thing from a different
perspective: I learned Z80 assembly language by first
learning Z80 *machine* language (my homebrew computer
di
Dave Angel wrote:
C is a glorified macro assembler. So the -> operator is not analogous
to the dot operator, it's Syntactic sugar:
p-> a. Is really
(*p).a
But it's not above inferring a dereferencing
operation when you call a function via a
pointer. If f is a pointer to a function,
then
Roy Smith於 2013年12月19日星期四UTC+8下午12時16分26秒寫道：
> In article <07c6e6a3-c5f4-4846-9551-434bdaba8...@googlegroups.com>,
>
> rusi wrote:
>
>
>
> > Soon the foo has to split into foo1.c and foo2.c. And suddenly you need to
>
> > understand:
>
> >
>
> > 1. Separate compilation
>
> > 2. Make (wh
In article ,
Gregory Ewing wrote:
> Roy Smith wrote:
> > even
> > if you've got all the signatures of foo() in front of you, it can
> > sometimes be hard to figure out which one the compiler will pick.
>
> And conversely, sometimes the compiler will have a hard
> time figuring out which one y
Roy Smith wrote:
even
if you've got all the signatures of foo() in front of you, it can
sometimes be hard to figure out which one the compiler will pick.
And conversely, sometimes the compiler will have a hard
time figuring out which one you want it to pick!
I had an experience in Java recent
On 19/12/2013 05:09, rusi wrote:
On Thursday, December 19, 2013 10:20:54 AM UTC+5:30, Mark Lawrence wrote:
On 19/12/2013 04:29, rusi wrote:
On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote:
On Tue, 17 Dec 2013 15:51:44 -, Wolfgang Keller wrote:
The only issue for me
On Thursday, December 19, 2013 10:20:54 AM UTC+5:30, Mark Lawrence wrote:
> On 19/12/2013 04:29, rusi wrote:
> > On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote:
> >> On Tue, 17 Dec 2013 15:51:44 -, Wolfgang Keller wrote:
> >>> The only issue for me was to figure out how
On 19/12/2013 04:29, rusi wrote:
On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote:
On Tue, 17 Dec 2013 15:51:44 -, Wolfgang Keller wrote:
The only issue for me was to figure out how to do in C what I already
knew in Pascal. And I had to waste a *lot* more time and ment
On Thursday, December 19, 2013 9:46:26 AM UTC+5:30, Roy Smith wrote:
> rusi wrote:
> > Soon the foo has to split into foo1.c and foo2.c. And suddenly you need to
> > understand:
> > 1. Separate compilation
> > 2. Make (which is separate from 'separate compilation')
> > 3. Header files and libra
On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote:
> On Tue, 17 Dec 2013 15:51:44 -, Wolfgang Keller wrote:
> > The only issue for me was to figure out how to do in C what I already
> > knew in Pascal. And I had to waste a *lot* more time and mental effort
> > to mess with
On Thu, Dec 19, 2013 at 3:16 PM, Roy Smith wrote:
> It's pretty common here to have people ask questions about how import
> works. How altering sys.path effects import. Why is import not finding
> my module? You quickly get into things like virtualenv, and now you've
> got modules coming from y
In article <07c6e6a3-c5f4-4846-9551-434bdaba8...@googlegroups.com>,
rusi wrote:
> Soon the foo has to split into foo1.c and foo2.c. And suddenly you need to
> understand:
>
> 1. Separate compilation
> 2. Make (which is separate from 'separate compilation')
> 3. Header files and libraries and t
On Thursday, December 19, 2013 7:10:53 AM UTC+5:30, Roy Smith wrote:
> Grant Edwards wrote:
> > I've always felt that there are features in C that don't make a lot of
> > sense until you've actually implemented a compiler -- at which point
> > it becomes a lot more obvious why some thing are done
On 19/12/2013 01:49, Roy Smith wrote:
In article ,
Mark Lawrence wrote:
I've never contemplated writing a compiler, let alone actually written
one. It's like the comments along the lines of "you can't call yourself
a programmer until you've mastered regular expressions".
Who makes comment
In article ,
Grant Edwards wrote:
> On 2013-12-18, Chris Angelico wrote:
>
> > Well, okay. In C you can't have Foo.foo().
>
> If "Foo" is a structure with a field named "foo" that is a pointer to
> a function, then you can indeed "have" Foo.foo().
Sigh. This has gone off in a direction I ne
In article ,
Mark Lawrence wrote:
> I've never contemplated writing a compiler, let alone actually written
> one. It's like the comments along the lines of "you can't call yourself
> a programmer until you've mastered regular expressions".
Who makes comments like that? As far as I can tell,
In article ,
Grant Edwards wrote:
> On 2013-12-18, Roy Smith wrote:
> > In article ,
> > Grant Edwards wrote:
> >
> >> Ideally, you should also have written at least one functioning
> >> compiler before learning C as well.
> >
> > Why? I've never written a compiler. I've written plenty of
On Thu, Dec 19, 2013 at 11:49 AM, Rhodri James wrote:
> It's sounds like you made, and are carrying on making, one of the classic
> mistakes of software engineering
Never get into a flame war in Asia, and never go up against a C
programmer when segfaults are on the line!
ChrisA
--
https://mail.
On Tue, 17 Dec 2013 15:51:44 -, Wolfgang Keller
wrote:
The only issue for me was to figure out how to do in C what I already
knew in Pascal. And I had to waste a *lot* more time and mental effort
to mess with that language than it took for me to learn *both* the
basics of programming per
On 18 December 2013 22:33, Terry Reedy wrote:
> On 12/18/2013 3:18 AM, Steven D'Aprano wrote:
>
>> We don't know what locals()['spam'] = 42 will do inside a function,
>
> I am mystified that you would write this. Locals() will "Update and return a
> dictionary representing the current local symbol
On Wed, 18 Dec 2013 14:55:10 -, Chris Angelico
wrote:
On Wed, Dec 18, 2013 at 11:53 PM, Dave Angel wrote:
Funny you should say that in the middle of a discussion about
lifetime. In
C, when you do the -> thing, you're now in a different struct with a
potentially different lifetime. I
On 12/18/2013 3:18 AM, Steven D'Aprano wrote:
We don't know what locals()['spam'] = 42 will do inside a function,
I am mystified that you would write this. Locals() will "Update and
return a dictionary representing the current local symbol table." The
only thing unspecified is the relation b
On Thu, 19 Dec 2013 01:55:10 +1100, Chris Angelico
wrote:
Sure, but you can figure out whether p is a local struct or a local
pointer to some other struct by looking at its declaration. Do you
also need to look at every usage of it?
C is a glorified macro assembler. So the -> operator is not
On 18/12/2013 18:05, Grant Edwards wrote:
On 2013-12-18, Roy Smith wrote:
In article ,
Grant Edwards wrote:
Ideally, you should also have written at least one functioning
compiler before learning C as well.
Why? I've never written a compiler. I've written plenty of C. I don't
see how
On 18/12/2013 18:00, Grant Edwards wrote:
On 2013-12-18, Chris Angelico wrote:
Well, okay. In C you can't have Foo.foo().
If "Foo" is a structure with a field named "foo" that is a pointer to
a function, then you can indeed "have" Foo.foo().
Complete fooey :)
--
My fellow Pythonistas, as
On 2013-12-18, Roy Smith wrote:
> In article ,
> Grant Edwards wrote:
>
>> Ideally, you should also have written at least one functioning
>> compiler before learning C as well.
>
> Why? I've never written a compiler. I've written plenty of C. I don't
> see how my lack of compiler writing ex
On 2013-12-18, Chris Angelico wrote:
> Well, okay. In C you can't have Foo.foo().
If "Foo" is a structure with a field named "foo" that is a pointer to
a function, then you can indeed "have" Foo.foo().
--
Grant Edwards grant.b.edwardsYow! It's OKAY -- I'm an
On 18/12/2013 08:18, Steven D'Aprano wrote:
The C99 standard lists 191 different kinds of undefined behavior,
including what happens when there is an unmatched ' or " on a line of
source code.
No compile-time error, no run-time error, just blindingly fast and
correct (according to the standard)
On Wednesday, December 18, 2013 8:53:54 PM UTC+5:30, Ethan Furman wrote:
> On 12/18/2013 12:18 AM, Steven D'Aprano wrote:
> > On Tue, 17 Dec 2013 22:49:43 -0500, Paul Smith wrote:
> >> On Wed, 2013-12-18 at 01:33 +, Steven D'Aprano wrote:
> >>> On 12/17/2013 04:32 PM, Roy Smith wrote:
> Yo
On 12/18/2013 12:18 AM, Steven D'Aprano wrote:
On Tue, 17 Dec 2013 22:49:43 -0500, Paul Smith wrote:
On Wed, 2013-12-18 at 01:33 +, Steven D'Aprano wrote:
On 12/17/2013 04:32 PM, Roy Smith wrote:
You never have to wonder what the
lifetime of an object is,
Since C isn't object oriented,
On 2013-12-18, Chris Angelico wrote:
> On Wed, Dec 18, 2013 at 11:53 PM, Dave Angel wrote:
>> Funny you should say that in the middle of a discussion about
>> lifetime. In C, when you do the -> thing, you're now in a
>> different struct with a potentially different lifetime. If p
>> is a local,
On Wed, Dec 18, 2013 at 11:53 PM, Dave Angel wrote:
> Funny you should say that in the middle of a discussion about lifetime. In
> C, when you do the -> thing, you're now in a different struct with a
> potentially different lifetime. If p is a local, with auto lifetime, then
> so is p.x
>
> So
On 18 Dec 2013 08:22:58 GMT, Steven D'Aprano
wrote:
On Wed, 18 Dec 2013 13:11:58 +1100, Chris Angelico wrote:
> The one differentiation that I don't like is between the . and ->
> operators. The distinction feels like syntactic salt. There's no
context
> when both are valid, save in C++ where
On 18 December 2013 09:18, rusi wrote:
>> (BTW is there any reason that the document is repeated twice in the same
>> pdf?)
>
> Thanks for the heads-up -- some pdf generation issues I guess
>
> Is it ok now?
Yes. Also it definitely reads better without the twocolumn format.
Oscar
--
https://m
On Tuesday, December 17, 2013 4:42:07 PM UTC+5:30, Oscar Benjamin wrote:
> On 17 December 2013 00:39, rusi wrote:
> > I had a paper some years ago on why C is a horrible language *to teach with*
> > http://www.the-magus.in/Publications/chor.pdf
> Thanks for this Rusi, I just read it and it describ
On Wed, Dec 18, 2013 at 7:18 PM, Steven D'Aprano wrote:
> You want to know why programs written in C are so often full of security
> holes? One reason is "undefined behaviour". The C language doesn't give a
> damn about writing *correct* code, it only cares about writing
> *efficient* code. Conseq
On Wed, Dec 18, 2013 at 7:22 PM, Steven D'Aprano wrote:
>> Well, okay. In C you can't have Foo.foo().
>
> Hah, well according to Paul Smith's example code you can. So either:
>
>
> - it's possible to be an experienced C programmer and still have
> fundamental gaps in your knowledge about basic con
On Wed, 18 Dec 2013 13:11:58 +1100, Chris Angelico wrote:
> On Wed, Dec 18, 2013 at 12:33 PM, Steven D'Aprano
> wrote:
>> On Tue, 17 Dec 2013 19:32:20 -0500, Roy Smith wrote:
>>
>>> There's very few mysteries in C.
>>
>> Apart from "What the hell does this piece of code actually do?". It's
>> no
On Tue, 17 Dec 2013 22:49:43 -0500, Paul Smith wrote:
> On Wed, 2013-12-18 at 01:33 +, Steven D'Aprano wrote:
>> And "What does 'implementation-specific undefined behaviour' actually
>> mean in practice?", another common question when dealing with C.
>
> Only asked by people who haven't had i
On Wed, 18 Dec 2013 01:33:03 +, Steven D'Aprano wrote:
>> or just what operation "x + y" is
>> actually going to perform.
>
>
> With no operator overloading, that one at least is correct.
Actually, I stand corrected. I was completely mistaken about that. The C
operation x + y is undefined
On Wed, 2013-12-18 at 01:33 +, Steven D'Aprano wrote:
> And "What does 'implementation-specific undefined behaviour' actually
> mean in practice?", another common question when dealing with C.
Only asked by people who haven't had it explained. There's "undefined
behavior", and there's "imple
On Wed, Dec 18, 2013 at 2:12 PM, Devin Jeanpierre
wrote:
>> Wrong. A pointer is a scalar value, usually some kind of integer, and
>> its lifetime is the same as any other scalar.
>
> The duration of a pointer's validity is far more interesting, and that
> is why it is the primary meaning of the te
On Tue, Dec 17, 2013 at 7:01 PM, Chris Angelico wrote:
> On Wed, Dec 18, 2013 at 1:33 PM, Devin Jeanpierre
> wrote:
>> Yes you do. Lifetimes are hard, because you need to malloc a lot, and
>> there is no defined lifetime for pointers -- they could last for just
>> the lifetime of a stack frame, o
On Wed, Dec 18, 2013 at 1:33 PM, Devin Jeanpierre
wrote:
> On Tue, Dec 17, 2013 at 4:32 PM, Roy Smith wrote:
>> There's very few mysteries in C. You never have to wonder what the
>> lifetime of an object is
>
> Yes you do. Lifetimes are hard, because you need to malloc a lot, and
> there is no d
On Tue, Dec 17, 2013 at 4:32 PM, Roy Smith wrote:
> There's very few mysteries in C. You never have to wonder what the
> lifetime of an object is
Yes you do. Lifetimes are hard, because you need to malloc a lot, and
there is no defined lifetime for pointers -- they could last for just
the lifeti
On Wed, Dec 18, 2013 at 12:33 PM, Steven D'Aprano wrote:
> On Tue, 17 Dec 2013 19:32:20 -0500, Roy Smith wrote:
>
>> There's very few mysteries in C.
>
> Apart from "What the hell does this piece of code actually do?". It's no
> coincidence that C, and Perl which borrows a lot of syntax from C, ar
On Tue, 17 Dec 2013 19:32:20 -0500, Roy Smith wrote:
> There's very few mysteries in C.
Apart from "What the hell does this piece of code actually do?". It's no
coincidence that C, and Perl which borrows a lot of syntax from C, are
the two champion languages for writing obfuscated code.
And "W
In article ,
Grant Edwards wrote:
> Ideally, you should also have written at least one functioning
> compiler before learning C as well.
Why? I've never written a compiler. I've written plenty of C. I don't
see how my lack of compiler writing experience has hindered my ability
to write C.
In article <20131217165144.39bf9ba1cd4e4f27a9689...@gmx.net>,
Wolfgang Keller wrote:
> C is just a kafkaesque mess invented by a sadistic pervert who must
> have regularly consumed illegal substances for breakfast.
Don't be absurd. C is a perfectly good language for the kinds of things
it's
On Tue, Dec 17, 2013 at 1:20 PM, Chris Angelico wrote:
> On Wed, Dec 18, 2013 at 5:03 AM, rusi wrote:
> > On Tuesday, December 17, 2013 8:21:39 PM UTC+5:30, Neil Cerutti wrote:
> >> I can't think of a reference, but I to recall that
> >> bugs-per-line-of-code is nearly constant; it is not langua
On 2013-12-17, Mark Lawrence wrote:
> On 17/12/2013 16:59, Grant Edwards wrote:
>>
>> I've always thought C was a great language for low-level, bare-metal,
>> embedded stuff -- but teaching it to first or second year computer
>> science students is just insane. C has a certain minimalist
>> ortho
On Tuesday 17 December 2013 12:23:28 Cousin Stanley did opine:
> >> Rick Johnson wrote:
> >> Dovetails are nothing more than sadistic nostalgia --
> >> they give old men a "chubby" and young men a nightmare.
> >
> > There is nothing more satisfying than cutting a set of dovetails by
> > hand a
On Wed, Dec 18, 2013 at 5:03 AM, rusi wrote:
> On Tuesday, December 17, 2013 8:21:39 PM UTC+5:30, Neil Cerutti wrote:
>> I can't think of a reference, but I to recall that
>> bugs-per-line-of-code is nearly constant; it is not language
>> dependent. So, unscientifically, the more work you can get
On Tuesday, December 17, 2013 8:21:39 PM UTC+5:30, Neil Cerutti wrote:
> On 2013-12-17, Steven D'Aprano wrote:
> > I would really like to see good quality statistics about bugs
> > per program written in different languages. I expect that, for
> > all we like to make fun of COBOL, it probably has f
On 17/12/2013 16:59, Grant Edwards wrote:
I've always thought C was a great language for low-level, bare-metal,
embedded stuff -- but teaching it to first or second year computer
science students is just insane. C has a certain minimalist
orthogonality that I have always found pleasing. [Peopl
On 17/12/2013 17:18, Larry Martell wrote:
On Tue, Dec 17, 2013 at 11:59 AM, Grant Edwards wrote:
On 2013-12-17, Wolfgang Keller wrote:
I was also taught C as an undergrad but having already learned Java, C
and C++ before arriving at University I found the C course very easy
so my own experie
On Tue, Dec 17, 2013 at 11:59 AM, Grant Edwards wrote:
> On 2013-12-17, Wolfgang Keller wrote:
>
>>> I was also taught C as an undergrad but having already learned Java, C
>>> and C++ before arriving at University I found the C course very easy
>>> so my own experience is not representative. Many
On 17 December 2013 15:51, Wolfgang Keller wrote:
>>
>> I was also taught C as an undergrad but having already learned Java, C
>> and C++ before arriving at University I found the C course very easy
>> so my own experience is not representative. Many of the other students
>> at that time found the
On 2013-12-17, Wolfgang Keller wrote:
>> I was also taught C as an undergrad but having already learned Java, C
>> and C++ before arriving at University I found the C course very easy
>> so my own experience is not representative. Many of the other students
>> at that time found the course too ha
On Tuesday, December 17, 2013 9:51:07 PM UTC+5:30, larry@gmail.com wrote:
> On Tue, Dec 17, 2013 at 10:35 AM, Mark Lawrence wrote:
> > I was in charge of the team at work that had to make all code Y2K compliant.
> > I discovered the one bug that to my knowledge slipped through the net. Four
>
On Tue, Dec 17, 2013 at 10:35 AM, Mark Lawrence wrote:
> I was in charge of the team at work that had to make all code Y2K compliant.
> I discovered the one bug that to my knowledge slipped through the net. Four
> years later back at the same place on contract I fixed the fix!!!
>From around 199
> I was also taught C as an undergrad but having already learned Java, C
> and C++ before arriving at University I found the C course very easy
> so my own experience is not representative. Many of the other students
> at that time found the course too hard and just cheated on all the
> assignments
On 17/12/2013 15:24, Steven D'Aprano wrote:
On Tue, 17 Dec 2013 09:54:41 -0500, Roy Smith wrote:
In article ,
Neil Cerutti wrote:
On 2013-12-17, Steven D'Aprano
wrote:
I would really like to see good quality statistics about bugs per
program written in different languages. I expect that,
On Tue, 17 Dec 2013 09:54:41 -0500, Roy Smith wrote:
> In article ,
> Neil Cerutti wrote:
>
>> On 2013-12-17, Steven D'Aprano
>> wrote:
>> > I would really like to see good quality statistics about bugs per
>> > program written in different languages. I expect that, for all we
>> > like to mak
> > It's not just the abysmally appalling, hideously horrifying syntax.
> > At about everything about C is just *not* "made for human beings"
> > imho.
>
> I've never heard C syntax reviled quite so intensely. What syntax do
> you like, out of curiosity?
Pascal, Python, if written by someone wh
On 17/12/2013 14:54, Roy Smith wrote:
In article ,
Neil Cerutti wrote:
On 2013-12-17, Steven D'Aprano
wrote:
I would really like to see good quality statistics about bugs
per program written in different languages. I expect that, for
all we like to make fun of COBOL, it probably has few bu
In article ,
Neil Cerutti wrote:
> On 2013-12-17, Steven D'Aprano
> wrote:
> > I would really like to see good quality statistics about bugs
> > per program written in different languages. I expect that, for
> > all we like to make fun of COBOL, it probably has few bugs per
> > unit-of-useful-w
On 2013-12-17, Steven D'Aprano
wrote:
> I would really like to see good quality statistics about bugs
> per program written in different languages. I expect that, for
> all we like to make fun of COBOL, it probably has few bugs per
> unit-of-useful-work-done than the equivalent written in C.
I ca
Rick Johnson wrote:
Dovetails are nothing more than sadistic nostalgia --
they give old men a "chubby" and young men a nightmare.
There is nothing more satisfying than cutting a set of dovetails by hand
and having them glide together like silk, the first time you test-fit
them, with no da
On Tue, Dec 17, 2013 at 10:12 PM, Oscar Benjamin
wrote:
> I was also taught C as an undergrad but having already learned Java, C
> and C++ before arriving at University I found the C course very easy
> so my own experience is not representative. Many of the other students
> at that time found the
On Tue, 17 Dec 2013 11:12:07 +, Oscar Benjamin wrote:
> These types of problems are compounded by the fact that the current C
> course uses automated marking so a program that produces the correct
> output gets full marks even if it is terribly written and the student
> entirely misses the poi
On 17 December 2013 00:39, rusi wrote:
> On Tuesday, December 17, 2013 5:58:12 AM UTC+5:30, Ned Batchelder wrote:
>> On 12/16/13 3:32 PM, Wolfgang Keller wrote:
>> >>> And ever after that experience, I avoided all languages that were
>> >>> even remotely similar to C, such as C++, Java, C#, Javasc
On Monday 16 December 2013 20:30:47 Mark Lawrence did opine:
> On 17/12/2013 01:06, Roy Smith wrote:
> > In article ,
> >
> > Rick Johnson wrote:
> >>Dovetails are nothing more than sadistic nostalgia --
> >>they give old men a "chubby" and young men a nightmare.
> >
> > There is noth
On Monday, December 16, 2013 8:33:11 PM UTC-6, Steven D'Aprano wrote:
> Of course, this is very hard to measure: different languages require
> different amounts of code to get something useful done. Different
> languages get used for different things -- there are no operating system
> kernels writ
On Mon, 16 Dec 2013 19:26:37 -0800, Rick Johnson wrote:
> **As a side note, you might want to be aware that ethylene glycol,
> whilst quite poisonous, tastes sweet. That fact may seem
> inconsequential until your beloved pet drinks leaking coolant water,
> quickly goes blind, and d
On Monday, December 9, 2013 2:53:30 PM UTC-6, bob gailer wrote:
> Taking the opposite perspective from Gene: I think Python
> is great as an intro to computing and programming. Give a
> student a tool with which he can be productive quickly.
> and with minimal effort. Understanding the real machine
1 - 100 of 211 matches
Mail list logo
