Erik Naggum wrote: > a serious programmer who does not know what to expect from his compiler is a > contradiction in terms. I don't think _any_ programmer who has not actually > read and actually understood the specification of his language, or at least > the parts thereof that he uses, should be allowed to write code for other > people than himself unless it occurs under very close supervision by someone > who does know the specification.
I think this is a valid. For languages in which I have more experience, I have a better day-to-day knowledge of the relevant specifications. For example: any C work will keep strictly to the current ISO and POSIX standards.
But how do you become a serious programmer? This is something I would hope to become one day. But I do not have anybody to tutor or supervise me and I do not have access to the ANSI cl specification.
> of course, this is predicated on the desire to see programming as a > professional discipline on par with law, medicine, auditing, etc,
I agree with this. This is an important thing that should happen.
Anyway back to the point I was trying to make was: if something is being implemented to do something that is explicitly not defined in the standard, why not tell me that is what you are doing? Even if I had read and though that I understood the specification of the language, there are still grey areas that are subject to interpretation.
This raises the point about what is the "value of a variable?" This is clearly subject to interpretation (bringing back the sound of a tree falling in the forest) and it would help if there was a bit more carping.
William Deakin <wi...@pindar.com> writes: > But how do you become a serious programmer? This is something I > would hope to become one day. But I do not have anybody to tutor or > supervise me and I do not have access to the ANSI cl specification.
For nearly all intents and purposes (besides legal ones), the HyperSpec is indeed a faithful representation of the ANSI CL specification (since it is a mechanical translation of the source code for the printed ANSI CL specification). Since the HyperSpec is available freely, it is much easier to get access to the meat of the ANSI CL specification for CL. It is also more readable than nearly any other standard I've come across, and more useful for daily work, too. In the words of Jerry Pournelle: Highly Recommended!
-- Pierre Mai <p...@acm.org> PGP and GPG keys at your nearest Keyserver "One smaller motivation which, in part, stems from altruism is Microsoft- bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
* William Deakin | But how do you become a serious programmer? This is something I would | hope to become one day. But I do not have anybody to tutor or supervise | me and I do not have access to the ANSI cl specification.
| Even if I had read and though that I understood the specification of the | language, there are still grey areas that are subject to interpretation.
there always will be in any specification useful to intelligent people. if intelligent people can't disagree on what something means, it isn't worth writing down. (now, somebody disagree on this, please. ;)
| This raises the point about what is the "value of a variable?" This is | clearly subject to interpretation (bringing back the sound of a tree | falling in the forest) and it would help if there was a bit more carping.
even if it were worded differently, someone might decide to carp more than others, as CMUCL does, and people would find it difficult to ignore a warning, such as when they disagreed about the exact condition under which something is unspecified or even argue that it is underspecified.
I believe in conforming to standards, but as a baseline, not as the end. conformance means you can trust something to be the way the specification says it should be, but it doesn't make sense to ask the specification a question like "what does it mean to do something that doesn't have fully specified behavior?". the proper answer is "why do you want to do that?".
note also that when the specification doesn't say anything at all, it does in fact say "all that we say nothing about has unspecified behavior" and it equally invalid to use a specification to prove a point outside of exactly what it says.
to answer your first question: you become a serious programmer by going through a stage where you are fully aware of the degree to which you know the specification, meaning both the explicit and the tacit specification of your language and of your problem. "hey, it works most of the time" is the very antithesis of a serious programmer, and certain languages can only support code like that. over time, you get a good gut feeling for the failure mode of your assumptions, and when you can trust that you are unlikely to make grossly invalid assumptions, the dangers that people run into in the absence of that trust vanish in a puff of standardization: it's the kind of trust you buy from somebody who claims to be conformant. non-conformance is about violating this sense of trust.
certain languages support serious programmers, and others don't. e.g., I don't think it is at all possible to become a serious programmer using Visual Basic or Perl. if you think hard about what Perl code will do on the borders of the known input space, your head will explode. if you write Perl code to handle input problems gracefully, your programs will become gargantuan: the normal failure mode is to terminate with no idea how far into the process you got or how much of an incomplete task was actually performed. in my view, serious programmers don't deal with tools that _force_ them to hope everything works.
#:Erik -- save the children: just say NO to sex with pro-lifers
"Pierre R. Mai" wrote: > In the words of Jerry Pournelle: Highly Recommended!
Thank you for your recommendation. It is something that I currently use and find very,very useful. My problem is that in my hasty and confused state I did not read the small print on the Common Lisp HyperSpec (tm) first page. As it says 'While the paper version remains the official standard, we think that as a matter of practice you'll find the Common Lisp HyperSpec much easier to navigate and use than its paper alternative. While the paper version remains the official standard, we think that as a matter of practice you'll find the Common Lisp HyperSpec much easier to navigate and use than its paper alternative.'
As I said in my reply to Pierre Mai, I need to RTFM. Thank you also for your kindness.
> ...if intelligent people can't disagree on what something means, it isn't > worth writing down...
I, of course, must now disagree with this. ;)
> even if it were worded differently, someone might decide to carp more than > others ... and people would find it difficult to ignore a warning, such as > when they disagreed about the exact condition under which something is > unspecified or even argue that it is underspecified.
Sure.
The things that helps me when I'm in a bind with a C program is the gcc compiler and lint. Both of which produce copious warnings or carps. I then either fix or ignore these warning, but then am aware of that I have decided to ignore somethings. caviat programmatici. (apologies to Vassil Nikolov).
> I believe in conforming to standards, but as a baseline, not as the end.
'Rules are for the guidance of wise men and the obediance of fools.' I am currently in the fool camp.
[...elided an excellent statement about serious programmers...]
> certain languages support serious programmers, and others don't. e.g., I > don't think it is at all possible to become a serious programmer using Visual > Basic or Perl.
However, I would argue that you can do some useful things using these languages. If you are so inclined.
> if you think hard about what Perl code will do on the borders of the known > input space, your head will explode.
BANG ;)
> if you write Perl code to handle input problems gracefully, your programs will > become gargantuan
To do that is not to use perl in the way in which it is intended (IMHO).
William Deakin <wi...@pindar.com> writes: > > certain languages support serious programmers, and others don't. > > e.g., I don't think it is at all possible to become a serious > > programmer using Visual Basic or Perl.
> However, I would argue that you can do some useful things using > these languages. If you are so inclined.
You can do some pretty useful things with band-aid or tape, in a fix. Yet no-one in his/her right mind makes band-aid or tape an integral part of the design of new products. ;)
> > if you write Perl code to handle input problems gracefully, your > > programs will become gargantuan
> To do that is not to use perl in the way in which it is intended (IMHO).
A very true statement. See the intended uses for band-aid and tape. Given this, the large use of Perl in our industry should be quite telling: Either we are constantly in a fix, or out of our minds. It seems to me that we are quite often both, and as long as we continue this, we will only create more trouble to fix. ;)
Regs, Pierre.
-- Pierre Mai <p...@acm.org> PGP and GPG keys at your nearest Keyserver "One smaller motivation which, in part, stems from altruism is Microsoft- bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
"Pierre R. Mai" wrote: > You can do some pretty useful things with band-aid or tape, in a fix. Yet > no-one in his/her right mind makes band-aid or tape an integral part of the > design of new products. ;)
Agreed. Though it is quite useful if you have a cut finger or want to send a parcel in the post ;)
[...] > the desire to see programming as a > professional discipline on par with law, medicine, auditing, etc [...]
I notice that this list does not include anything like electrical or civil engineering (i.e. disciplines that are based on some science,^1 e.g. physics), and I wonder if this was deliberate or just to keep the list short. __________ ^1 I believe that medicine is an art; it may become a science one day, but is not one yet. I know others may disagree, and I don't think I am going to argue about it.
* Vassil Nikolov <v...@einet.bg> | I notice that this list does not include anything like electrical or | civil engineering (i.e. disciplines that are based on some science,^1 | e.g. physics), and I wonder if this was deliberate or just to keep the | list short.
the underlying science of a discipline doesn't dictate how professional practitioners will or can be, and it isn't even relevant. a scientific attitude is orthogonal with the profession, too. I'm purposely leaving such disciplines out because I don't think programming is anywhere close to the hard engineering disciplines nor that it ever will be, and I don't want to open up for the impression that I believe in even more staticity¹ when I want to argue dynamism and dealing with people professionally.
the similarity between engineering disciplines and programming lies in how they deal with legal and communal requirements, ever changing user requirements, sharing knowledge among practitioners, standardization, etc, not in the underlying scientificity¹. therefore, it is better to use professions where the potential for confusion is much more limited.
| ^1 I believe that medicine is an art; it may become a science one day, | but is not one yet. I know others may disagree, and I don't think I am | going to argue about it.
I believe medicine is a science and programming an art because I know both of them well, not just programming.
#:Erik ------- ¹ if these aren't words today, they will be in the future. -- save the children: just say NO to sex with pro-lifers
On 25 Aug 1999 11:05:59 +0000, Erik Naggum <e...@naggum.no> wrote:
> want to open up for the impression that I believe in even more staticity¹ [...] > etc, not in the underlying scientificity¹. therefore, it is better to [...] > ¹ if these aren't words today, they will be in the future.
Italian already has both words: "staticita`" and "scientificita`".
