"Knowing" a language

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

mountaingoat
Posts: 80
Joined: Wed Aug 01, 2007 6:01 am UTC

"Knowing" a language

Postby mountaingoat » Mon Dec 29, 2008 4:19 am UTC

What constitutes "knowing" a programming language?

For example, I know most of Java, but certainly not all of it.
Would knowing the basics of the language (conditional statements, loops, data structures, etc.) be sufficient? Or would you have to know more advanced features (JavaBeans, Sockets)?

I'm guessing that it's really a case by case basis... where knowing the basics and how to read the language would be just being "familiar" with the language, rather than being "comfortable" or "knowing" it.

In the context of jobs, I guess it would just be best to ask exactly how much you're required to know, correct?

User avatar
Qoppa
Posts: 694
Joined: Sat Nov 24, 2007 9:32 pm UTC
Location: Yes.

Re: "Knowing" a language

Postby Qoppa » Mon Dec 29, 2008 4:27 am UTC

Some languages are so vast that it's impossible to 'know' the language entirely. Take C++ for example. In addition to the basic syntax and concepts, there's the entire STL, Win32, DirectX, OpenGL, Boost library, Winsock, etc. to know as well. I don't think it's humanly possible for a person to become 100% confident writing good code in all of those without having to look stuff up all the time. I'd say you know a language when you know all the concepts, syntax, and are capable of doing what you want in the language, provided it's not an incredibly specific task (what constitutes an incredibly specific task will obviously vary from language to language). You should know how to use the features of the language correctly, not just know their syntax. Knowing how to make a class is pretty useless if you don't know when to create one, and possibly more importantly, when not to create one.

Code: Select all

_=0,w=-1,(*t)(int,int);a()??<char*p="[gd\
~/d~/\\b\x7F\177l*~/~djal{x}h!\005h";(++w
<033)?(putchar((*t)(w??(p:>,w?_:0XD)),a()
):0;%>O(x,l)??<_='['/7;{return!(x%(_-11))
?x??'l:x^(1+ ++l);}??>main(){t=&O;w=a();}

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: "Knowing" a language

Postby 0xBADFEED » Mon Dec 29, 2008 4:51 am UTC

I think to answer this question you first have to answer the question:

"Is knowing the language separate from knowing the standard library?"

I wouldn't say someone knows C++ if they don't know the STL pretty well. I wouldn't say someone knows Java unless they know a decent amount of the standard library (java.io, java.util, etc.). But then how much knowledge of the standard library is necessary to claim that you "know" it?

A rough minimal checklist for claiming that you know a language might include the following:

[Without referring to the manual]

1) Can write most common control structures
2) Can do most common I/O operations
3) Know the major standard data structures offered by the standard library/language

I would say those 3 things are the absolute minimum for even thinking about claiming that you "know" a language. And they should suffice for doing general programming tasks you might be asked in an interview, for instance, you could do pretty much all the project euler problems with that knowledge.

User avatar
TheAmazingRando
Posts: 2308
Joined: Thu Jan 03, 2008 9:58 am UTC
Location: San Diego, CA

Re: "Knowing" a language

Postby TheAmazingRando » Mon Dec 29, 2008 5:34 am UTC

I would say you "know" a language if you know the syntax, style, effective use, and common idioms. Basically, if you enough to be able to code in it efficiently, and how to look up for yourself anything you don't know by heart. For example, I "know" Java. I know the standard coding style of Java, I understand OOP. I don't know, off the top of my head, all of the functions in java.lang.String, but I know how to look that up in a few seconds, and how to use that information once I find it.

User avatar
Berengal
Superabacus Mystic of the First Rank
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway
Contact:

Re: "Knowing" a language

Postby Berengal » Mon Dec 29, 2008 5:43 am UTC

I have a more bare-minimum definition. To know a language, you need to know all of its syntax and all of its semantics but nothing else. This is slightly different from knowing how to program in a language, which requires some knowledge of common idioms, the provided stl etc. as previously mentioned. It's quite possible to know one but not the other. Although you usually need to know most of the syntax and semantics to be able to program, it's quite possible to go years programming java without knowing the enhanced for syntax.
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

User avatar
headprogrammingczar
Posts: 3072
Joined: Mon Oct 22, 2007 5:28 pm UTC
Location: Beaming you up

Re: "Knowing" a language

Postby headprogrammingczar » Mon Dec 29, 2008 2:29 pm UTC

So you are saying they just need to know enough of the syntax for their code to be Turing Complete?

My definition of "knowing" a language is sufficient knowledge of syntax (in Java, that means pretty much all of it except for switch, which is just an optimized if-else-if ladder), as well as how to quickly look up secondary library information. You don't have to actually know any of the library, but if you use any particular code enough, you will end up memorizing it anyway.
<quintopia> You're not crazy. you're the goddamn headprogrammingspock!
<Weeks> You're the goddamn headprogrammingspock!
<Cheese> I love you

User avatar
Berengal
Superabacus Mystic of the First Rank
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway
Contact:

Re: "Knowing" a language

Postby Berengal » Mon Dec 29, 2008 3:16 pm UTC

headprogrammingczar wrote:So you are saying they just need to know enough of the syntax for their code to be Turing Complete?

No, I'm saying they need to know all of the syntax and the corresponding semantics. Usually you only need a comparatively very small subset of the language to make it turing complete, and not all languages are turing complete anyway.
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

User avatar
sparkyb
Posts: 1091
Joined: Thu Sep 06, 2007 7:30 pm UTC
Location: Camberville proper!
Contact:

Re: "Knowing" a language

Postby sparkyb » Mon Dec 29, 2008 5:24 pm UTC

I think you know a language when you are comfortable working in it. I have different design patterns in different languages and I think that part of knowing a language is having a style for yourself for working in that language. You shouldn't have to think too hard about how you'd want to do basic tasks. This should require a familiarity with basic stuff like IO and data structures. I wouldn't say you need to know STL to say you know C++, but pretty much any task is going to call for some kind of list structure and if it's not std::vector then it should at least be some alternative.

Knowing a language is entirely separate from knowing about certain topics/techniques such as threading, sockets, GUIs, etc. But also, you can know languages and you can know topics, without necessarily knowing how to use those topics in every language you know (you know the topic so long as you know it in some language).

deathspiral
Posts: 4
Joined: Mon Dec 29, 2008 4:21 pm UTC

Re: "Knowing" a language

Postby deathspiral » Mon Dec 29, 2008 5:51 pm UTC

You need to know enough that the code you write looks like the code produced by a practitioner with several years of experience. Languages have a lot of idioms - using these idioms is almost as important as being technically correct.

The Pragmatic Programmer has a section on this (or perhaps it was one of the XP books...) - the idea is that your code should be indistinguishable from the code your team members write. This allows all of you to edit any code in the system without messing with the flow.

My C code (a language I haven't done serious development in in almost a decade) simply looks WRONG in comparison to an experienced C developers. It compiles and does all the right things, but it's not nearly as succinct and maintainable. Considering the fact that fully half my time is spent looking at and fixing code that other people have written, the ability to use common idioms is very important to me.

an example:

if (a==1)

versus

if (1==a)

both are correct, but the second is preferable to a C developer since it prevents mis-assignment.

There are hundreds of these small quirks in every language that experienced developers gradually learn and use. In my mind, you don't "know" a language until you implicityly understand why all of these small things are used.

The definitive test for Java: If you can make it through "Java Puzzlers" by Josh Bloch you, almost by definition, know the language. :)

User avatar
You, sir, name?
Posts: 6983
Joined: Sun Apr 22, 2007 10:07 am UTC
Location: Chako Paul City
Contact:

Re: "Knowing" a language

Postby You, sir, name? » Tue Dec 30, 2008 1:38 am UTC

I'd say you know a language when you no longer need references to write nontrivial programs in it (with the exception of stuff like writing a compiler for the language in the language, since no mortal can be expected to know language specifications of even smaller languages like C verbatim).
I edit my posts a lot and sometimes the words wrong order words appear in sentences get messed up.

User avatar
r1chard
Posts: 281
Joined: Thu Dec 06, 2007 2:17 am UTC
Location: Melbourne, AU
Contact:

Re: "Knowing" a language

Postby r1chard » Tue Dec 30, 2008 1:51 am UTC

In a former life I was on the panel for interviews for a Perl job. I used to ask them how they'd rate themselves out of 10 in terms of Perl competency. In my opinion there's no more than 10 people in the world who should be allowed to rate themselves above an 8 (Larry, Damien, Audrey, ... ok, maybe not 10?) Anyone claiming to be above a 6 would be shown a relatively simple but incorrect expression and asked to explain why it was wrong. None had the correct answer.

Yeah, I was probably being a bit mean, but I was bitter having signed up for Python development and being lumped with Perl + Java for 18 months ;)

Seriously, it was a simple expression. Couldn't tell you what it was today though. Had something to do with an obscure paren rule though IIRC.

User avatar
sparkyb
Posts: 1091
Joined: Thu Sep 06, 2007 7:30 pm UTC
Location: Camberville proper!
Contact:

Re: "Knowing" a language

Postby sparkyb » Tue Dec 30, 2008 5:11 am UTC

You, sir, name? wrote:I'd say you know a language when you no longer need references to write nontrivial programs in it (with the exception of stuff like writing a compiler for the language in the language, since no mortal can be expected to know language specifications of even smaller languages like C verbatim).


I think you're being a little harsh. I would count myself as an expert Python programmer and I still go to the library reference all the time. It's not necessary for me to memorize every function, all their parameters (and their order), and all their semantics as long as I know where to go look when I need to know.

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Re: "Knowing" a language

Postby yy2bggggs » Tue Dec 30, 2008 6:00 am UTC

Image

User avatar
Area Man
Posts: 256
Joined: Thu Dec 25, 2008 8:08 pm UTC
Location: Local

Re: "Knowing" a language

Postby Area Man » Tue Dec 30, 2008 8:44 am UTC

I would agree with many of the comments above. In my experience, I would add that being able to read code written by someone else, poor and advanced code, and be able to follow it (as in seeing the logic flow, not the statements) would indicate how well you "know" a language. This would include being able to spot errors.

What that means is that you would have to know the different (more advanced) features/quirks of a language, not just control flow, and so on.
For instance (and I have seen this too often), if you can write some code in c/c++ but you can't use pointers, or references(c++), or pointers to arrays, or pointers to arrays of pointers, pointers to functions, etc., and how to properly get what you want out of each, then you don't know c/c++. Java would have similar issues, say with passing references by value; each language has its color.

I would conclude then that knowing a language comes down to a separate list of things to know for each language.
(e.g. Does one know C++ if one knows not of templates?)
Bisquick boxes are a dead medium.

Carnildo
Posts: 2023
Joined: Fri Jul 18, 2008 8:43 am UTC

Re: "Knowing" a language

Postby Carnildo » Tue Dec 30, 2008 10:22 am UTC

Area Man wrote:I would agree with many of the comments above. In my experience, I would add that being able to read code written by someone else, poor and advanced code, and be able to follow it (as in seeing the logic flow, not the statements) would indicate how well you "know" a language. This would include being able to spot errors.


I'd say this is true only for code that's meant to be read. Code such as what you find in IOCCC entries or in write-only languages needs to be studied, not read.

User avatar
Marz
Posts: 156
Joined: Mon Dec 10, 2007 9:13 pm UTC
Location: UK
Contact:

Re: "Knowing" a language

Postby Marz » Tue Dec 30, 2008 12:26 pm UTC

deathspiral wrote:an example:

if (a==1)

versus

if (1==a)

both are correct, but the second is preferable to a C developer since it prevents mis-assignment.

I would disagree. In order to prevent mis-assignment, use "==", not "=" - very simple. It is logical for the test to be "(a==1)", as the variable being tested is a, not 1. You want to know the value of a, and test whether it is 1; you are not checking whether the value of 1 is equal to a - you know what 1 is; it's constant. Besides, if you're assigning, you're doing it wrong anyway.

User avatar
Berengal
Superabacus Mystic of the First Rank
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway
Contact:

Re: "Knowing" a language

Postby Berengal » Tue Dec 30, 2008 2:56 pm UTC

Marz wrote:I would disagree. In order to prevent mis-assignment, use "==", not "=" - very simple.

Yes, that's how to prevent against mis-assignment, but how do you protect against typos that cause mis-assignment? They're going to happen, and you're not going to catch them all.
Don't say it's less clear either. Adopting <value>==<var> for equality testing and <var>=<value> for assignment only makes it clearer what's going on if it's consistent.
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

User avatar
Marz
Posts: 156
Joined: Mon Dec 10, 2007 9:13 pm UTC
Location: UK
Contact:

Re: "Knowing" a language

Postby Marz » Tue Dec 30, 2008 6:37 pm UTC

No, see, they won't happen, if you take pride in your work. If you write a mis-assignment, your code is wrong, and should be corrected. If you leave it that way, your code will always be flawed. The best way to fix an error is not to ensure that it is silent, but to make it detectable, so that you may correct it.

HenryGifford
Posts: 152
Joined: Mon Nov 03, 2008 2:01 am UTC

Re: "Knowing" a language

Postby HenryGifford » Tue Dec 30, 2008 7:17 pm UTC

I think to know a language you should be able to teach someone the language and get them relatively good at it.

User avatar
Berengal
Superabacus Mystic of the First Rank
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway
Contact:

Re: "Knowing" a language

Postby Berengal » Tue Dec 30, 2008 7:26 pm UTC

That post made no sense at all, Marz.
Marz wrote:No, see, they won't happen, if you take pride in your work.
Yes, they will.
Marz wrote:If you write a mis-assignment, your code is wrong, and should be corrected.
To correct it you must first detect it. That's not guarranteed, and this kind of error can be subtle.
Marz wrote:If you leave it that way, your code will always be flawed. The best way to fix an error is not to ensure that it is silent, but to make it detectable, so that you may correct it.
1=a is a syntax error, which probably is as far from a silent error as you can get as not only the compiler, but even syntax highlighting might barf at it. a=1 in a test isn't neccessarily an error, and is at best a warning at compile time which, if turned on, will also warn about all your other legitimate uses of assignments in test.

HenryGifford wrote:I think to know a language you should be able to teach someone the language and get them relatively good at it.

Being a good teacher shouldn't be a requirement for knowing a language. I see where you're coming from though.
Last edited by Berengal on Tue Dec 30, 2008 7:27 pm UTC, edited 1 time in total.
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: "Knowing" a language

Postby 0xBADFEED » Tue Dec 30, 2008 7:27 pm UTC

HenryGifford wrote:I think to know a language you should be able to teach someone the language and get them relatively good at it.


This makes no sense to me.

Being proficient in a language and being able to teach it are completely different skills. I can be a great programmer in language X and a horrible teacher. But by your definition I don't know language X because I'm a horrible teacher. Also, now my ability to "know" language X depends on someone else's ability to learn language X.

I do think a requirement for knowing a language includes being able to talk about it intelligently and at some reasonable level of depth, if that's what you're trying to get at.

Berengal wrote:if turned on, will also warn about all your other legitimate uses of assignments in test


Most of the people who argue for the '1 == a ' form would probably also argue that there is no such thing as a legitimate use of assignment in a test.

User avatar
Area Man
Posts: 256
Joined: Thu Dec 25, 2008 8:08 pm UTC
Location: Local

Re: "Knowing" a language

Postby Area Man » Tue Dec 30, 2008 9:38 pm UTC

Carnildo: I think we can safely rule ioccc entries as outliers, as the people who wrote the program would have trouble coming back to it after a short time :). Also, r1chard already pointed out that it's hard to be an expert in languages which have a large core of built-in tricky libriaries (i.e. write-only) languages.

0xBADFEED wrote:Most of the people who argue for the '1 == a ' form would probably also argue that there is no such thing as a legitimate use of assignment in a test.


Assignment in test may be bad form in other code, but is a basic feature of c/++.
Copying a c string:

Code: Select all

while( *p++ = *q++ );

Simple. Straightforward. Straight from Stroustrup. Alliteration.
Bisquick boxes are a dead medium.

Rysto
Posts: 1460
Joined: Wed Mar 21, 2007 4:07 am UTC

Re: "Knowing" a language

Postby Rysto » Tue Dec 30, 2008 9:52 pm UTC

Area Man wrote:Simple. Straightforward. Straight from Stroustrup.

Three lies for the price of one!

HenryGifford
Posts: 152
Joined: Mon Nov 03, 2008 2:01 am UTC

Re: "Knowing" a language

Postby HenryGifford » Tue Dec 30, 2008 9:58 pm UTC

0xBADFEED wrote:This makes no sense to me.

Being proficient in a language and being able to teach it are completely different skills. I can be a great programmer in language X and a horrible teacher. But by your definition I don't know language X because I'm a horrible teacher. Also, now my ability to "know" language X depends on someone else's ability to learn language X.

I do think a requirement for knowing a language includes being able to talk about it intelligently and at some reasonable level of depth, if that's what you're trying to get at.

Yeah, that's true.
I don't know what I was talking about.. I guess I meant you should be able to understand the basics of the language well enough that you could tell someone, not necessarily well, what they do, and how to use them.

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: "Knowing" a language

Postby 0xBADFEED » Tue Dec 30, 2008 9:59 pm UTC

Area Man wrote:Carnildo: I think we can safely rule ioccc entries as outliers, as the people who wrote the program would have trouble coming back to it after a short time :). Also, r1chard already pointed out that it's hard to be an expert in languages which have a large core of built-in tricky libriaries (i.e. write-only) languages.

0xBADFEED wrote:Most of the people who argue for the '1 == a ' form would probably also argue that there is no such thing as a legitimate use of assignment in a test.


Assignment in test may be bad form in other code, but is a basic feature of c/++.
Copying a c string:

Code: Select all

while( *p++ = *q++ );

Simple. Straightforward. Straight from Stroustrup. Alliteration.


I personally don't have a problem with assignment in a test. But there are people who do.

Code: Select all

while( *p++ = *q++ );


They would probably also have a problem with this snippet.

Apart from the fact that it uses assignment in a test, it also relies on the tricky semantics of '++' prefix versus postfix. They would argue that this same loop could be expanded to around 3 lines instead of one and its intent and functionality would be much clearer. I know this type of programming can be par-for-the-course in C and C++.

People who prefer the '1 == a' form of comparison generally favor a very defensive style of coding that strives to make intent as explicit as possible in an effort to eliminate the possibility of ambiguities and the mental bookkeeping that comes with tricky/clever code (e.g. the loop above).

When I say "ambiguity" I mean subtle differences between the intent of the code and the functionality of the code.
Last edited by 0xBADFEED on Wed Dec 31, 2008 5:21 pm UTC, edited 1 time in total.

User avatar
Area Man
Posts: 256
Joined: Thu Dec 25, 2008 8:08 pm UTC
Location: Local

Re: "Knowing" a language

Postby Area Man » Tue Dec 30, 2008 10:34 pm UTC

Rysto wrote:
Area Man wrote:Simple. Straightforward. Straight from Stroustrup.

Three lies for the price of one!

Them is fightin' words, sir.

See: The C++ Programming Language Chapter 6.2.5.

0xBADFEED wrote:I personally don't have a problem with assignment in a test. But there are people who do.
[...]
Apart from the fact that it uses assignment in a test, it also relies on the tricky semantics of '++' prefix versus postfix. This same loop could be expanded to around 3 lines instead of one and its intent and functionality would be much clearer. I know this type of programming can be par-for-the-course in C and C++.


Calling ++prefix or postfix++ "tricky semantics" is a sure sign of not knowing C basics, and would therefore make it on The List for C|++. (I'm not saying that you don't know it)
These people which you speak of are probably the same ones who in the late 90s - early 2000s thought it would be a good idea to do code reviews with managers who knew nothing about programming, therefore chose programming languages which a "non-technical" person could read, instead of a language which helps solve the problem.
Bisquick boxes are a dead medium.

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: "Knowing" a language

Postby 0xBADFEED » Tue Dec 30, 2008 11:21 pm UTC

Area Man wrote:Calling ++prefix or postfix++ "tricky semantics" is a sure sign of not knowing C basics, and would therefore make it on The List for C|++. (I'm not saying that you don't know it)
These people which you speak of are probably the same ones who in the late 90s - early 2000s thought it would be a good idea to do code reviews with managers who knew nothing about programming, therefore chose programming languages which a "non-technical" person could read, instead of a language which helps solve the problem.


I'm not debating the validity of this view one way or the other, merely asserting that there are people that hold this view. And, depending on who you talk to it could be considered good or bad style. My personal preference is somewhere in the middle and debating what is or isn't good C/C++ style is going to derail this thread.

I'm only pointing out that the "accepted" idioms of some languages can be very hard to nail down. This is especially true in C and C++; one person's idiom can be another person's no-no.

User avatar
TheAmazingRando
Posts: 2308
Joined: Thu Jan 03, 2008 9:58 am UTC
Location: San Diego, CA

Re: "Knowing" a language

Postby TheAmazingRando » Wed Dec 31, 2008 12:57 am UTC

If you know C/++,

Code: Select all

while( *p++ = *q++ );

is pretty self-evident. It could be written more clearly, perhaps, but it isn't obscure unless you don't know the language well, especially compared to some of the hacks people write. *p++ is a pretty crucial low-level programming idiom, and if you don't understand what it does, I wouldn't say you "know" C/++.

The strength of the language is in its low-level manipulation, and clever hacks are an inseparable part of its heritage. If you don't understand pointer wizardry, you don't know the language.

Rysto
Posts: 1460
Joined: Wed Mar 21, 2007 4:07 am UTC

Re: "Knowing" a language

Postby Rysto » Wed Dec 31, 2008 1:31 am UTC

I'd argue that line of code does way too many things in one line. I know what it does because I've seen it before. But someone who's never seen it before, no matter how well they know the language, will have to spend time puzzling it out. Programming, no matter what the Perl zealots may say, is not about writing a solution in as few lines as possible. It's about solving problems in an efficient, maintainable way. And writing code with three side effects in an expression, that depends on a non-obvious order of operations(where non-obvious means "knowledge of mathematics gives you no hint one way or the other what the order is"), that has a loop with an empty body and and a tricky terminating condition, is not maintainable code in my book.

User avatar
hotaru
Posts: 1045
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: "Knowing" a language

Postby hotaru » Wed Dec 31, 2008 1:39 am UTC

Rysto wrote:I'd argue that line of code does way too many things in one line. I know what it does because I've seen it before. But someone who's never seen it before, no matter how well they know the language, will have to spend time puzzling it out. Programming, no matter what the Perl zealots may say, is not about writing a solution in as few lines as possible. It's about solving problems in an efficient, maintainable way. And writing code with three side effects in an expression, that depends on a non-obvious order of operations(where non-obvious means "knowledge of mathematics gives you no hint one way or the other what the order is"), that has a loop with an empty body and and a tricky terminating condition, is not maintainable code in my book.

you don't know c.

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

User avatar
Berengal
Superabacus Mystic of the First Rank
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway
Contact:

Re: "Knowing" a language

Postby Berengal » Wed Dec 31, 2008 2:10 am UTC

Rysto wrote:I'd argue that line of code does way too many things in one line. I know what it does because I've seen it before. But someone who's never seen it before, no matter how well they know the language, will have to spend time puzzling it out.

I figured it out in less than a minute the first time I saw it, and i barely knew what a pointer was at the time. It was the third day ever I had programmed, all of it in Java, and everything I knew about the computer architecture I had gotten from the one page in my beginners java book that explained the basics. I happened upon it quite randomly on the internet, and the following conversation between me and my brother took place within the mentioned minute: "Is that an assignment in a while? Can I do that?", "Yeah", "And what's that star thingy?", "Pointer dereferencing in this case.", "So.... it's copying a string?"
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

User avatar
Xeio
Friends, Faidites, Countrymen
Posts: 5101
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

Re: "Knowing" a language

Postby Xeio » Wed Dec 31, 2008 3:53 am UTC

hotaru wrote:
Rysto wrote:I'd argue that line of code does way too many things in one line. I know what it does because I've seen it before. But someone who's never seen it before, no matter how well they know the language, will have to spend time puzzling it out. Programming, no matter what the Perl zealots may say, is not about writing a solution in as few lines as possible. It's about solving problems in an efficient, maintainable way. And writing code with three side effects in an expression, that depends on a non-obvious order of operations(where non-obvious means "knowledge of mathematics gives you no hint one way or the other what the order is"), that has a loop with an empty body and and a tricky terminating condition, is not maintainable code in my book.
you don't know c.
No idea if he does or not, but he has some good points. Granted, it's fairly readable, and a pretty common idiom, but if it wasn't, then deciphering it may be a pain, especially if you aren't 100% sure of the order of the * and ++ operators. Granted, if you are including knowing idioms of a language, then obviously this is one of them (a somewhat important one, and probably order of operators, but that's something I always use parenthesis to fix, I can't stand looking stuff like that up).

User avatar
Marz
Posts: 156
Joined: Mon Dec 10, 2007 9:13 pm UTC
Location: UK
Contact:

Re: "Knowing" a language

Postby Marz » Wed Dec 31, 2008 9:29 am UTC

Berengal wrote:That post made no sense at all, Marz.

I'm talking about how you should always strive toward elegant code; you should ensure that your code is correct, rather than praying that an error won't make a bug. It is always better to make any error of any kind fail loudly, rather than exist invisibly. Besides, a simple regex search would find any errors of this type - if you take pride in your work, you will ensure that they do not exist. I know I've never left any such errors in my code.

User avatar
Area Man
Posts: 256
Joined: Thu Dec 25, 2008 8:08 pm UTC
Location: Local

Re: "Knowing" a language

Postby Area Man » Wed Dec 31, 2008 9:59 am UTC

Xeio wrote:
hotaru wrote:
Rysto wrote:I'd argue that line of code does way too many things in one line. I know what it does because I've seen it before. But someone who's never seen it before, no matter how well they know the language, will have to spend time puzzling it out. Programming, no matter what the Perl zealots may say, is not about writing a solution in as few lines as possible. It's about solving problems in an efficient, maintainable way. And writing code with three side effects in an expression, that depends on a non-obvious order of operations(where non-obvious means "knowledge of mathematics gives you no hint one way or the other what the order is"), that has a loop with an empty body and and a tricky terminating condition, is not maintainable code in my book.
you don't know c.
No idea if he does or not, but he has some good points. Granted, it's fairly readable, and a pretty common idiom, but if it wasn't, then deciphering it may be a pain, especially if you aren't 100% sure of the order of the * and ++ operators. Granted, if you are including knowing idioms of a language, then obviously this is one of them (a somewhat important one, and probably order of operators, but that's something I always use parenthesis to fix, I can't stand looking stuff like that up).

I didn't think the example was that controversial as it is from the C++ intro book by the guy who created the language. So, if you haven't seen a line like this before, wgaff if you understand it.
I don't expect COBOL programmers to write code in a way for me to understand; they should write what is natural for them.

As I pointed out before, when you write code you're writing it for future maintainers who do know the language, unless it's your first highschool programming excercise. Dereferencing, incrementing, 0 as false, cstrings are all _very_ basic concepts in C, not even requiring any standard #includes.

Rewriting this into many lines would improve nothing, as you still have to understand all of the basics.

Anyway, comments are an important part of coding too, and a brief explanation (just like the one I originally wrote) would suffice.
You're not trying to make it terse, you're uncluttering a simple loop to make the whole program more comprehensible. Sure, you could write a whole program on two lines in C, but knowing whitespace and formatting conventions is part of knowing the language.
Bisquick boxes are a dead medium.

User avatar
Berengal
Superabacus Mystic of the First Rank
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway
Contact:

Re: "Knowing" a language

Postby Berengal » Wed Dec 31, 2008 11:50 am UTC

Marz wrote:
Berengal wrote:That post made no sense at all, Marz.

I'm talking about how you should always strive toward elegant code; you should ensure that your code is correct, rather than praying that an error won't make a bug. It is always better to make any error of any kind fail loudly, rather than exist invisibly. Besides, a simple regex search would find any errors of this type - if you take pride in your work, you will ensure that they do not exist. I know I've never left any such errors in my code.

I'm pretty sure you must've misread something then. You objected to using "1==a" instead of "a==1" in tests, and then I argued that the former would be better because unlike "a==1", "1==a" typoed would become "1=a", which is a compiler error no matter what compiler flags you use. "a=1" is never a compiler error, and is only a warning if you turn that warning on (which also warns about legitimate uses that aren't a program error). Therefore, "1==a" is better than "a==1" in tests for the very reasons you state: If you make a typo, the first will fail instantly while the other will compile just fine.
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

User avatar
Emu*
Posts: 689
Joined: Mon Apr 28, 2008 9:47 am UTC
Location: Cardiff, UK
Contact:

Re: "Knowing" a language

Postby Emu* » Wed Dec 31, 2008 12:15 pm UTC

I haven't done low-C for a few years, but is

Code: Select all

*p++


equivalent to

Code: Select all

(*p)++

(Increment the variable stored at p)

or

Code: Select all

*(p++)

(inc the pointer, then access it)

or even

Code: Select all

*p;p++

access p, then inc it, seeing as we're in postfix...
Cosmologicon wrote:Emu* implemented a naive east-first strategy and ran it for an hour, producing results that rivaled many sophisticated strategies, visiting 614 cells. For this, Emu* is awarded Best Deterministic Algorithm!

User avatar
Marz
Posts: 156
Joined: Mon Dec 10, 2007 9:13 pm UTC
Location: UK
Contact:

Re: "Knowing" a language

Postby Marz » Wed Dec 31, 2008 12:46 pm UTC

Berengal wrote:You objected to using "1==a" instead of "a==1" in tests, and then I argued that the former would be better because unlike "a==1", "1==a" typoed would become "1=a", which is a compiler error no matter what compiler flags you use.

Note:
Marz wrote:It is logical for the test to be "(a==1)", as the variable being tested is a, not 1. You want to know the value of a, and test whether it is 1; you are not checking whether the value of 1 is equal to a - you know what 1 is; it's constant.

The bit you seem to have focused on was a sentence-long afterthought.
Anyway, far from on topic.

User avatar
Berengal
Superabacus Mystic of the First Rank
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway
Contact:

Re: "Knowing" a language

Postby Berengal » Wed Dec 31, 2008 1:06 pm UTC

I'm focusing on "a==1" being prone to typos causing silent errors whereas "1==a" isn't, and thus is better to use. I'm sorry, but you're wrong on the internet, and I can't let that happen.
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

Rysto
Posts: 1460
Joined: Wed Mar 21, 2007 4:07 am UTC

Re: "Knowing" a language

Postby Rysto » Wed Dec 31, 2008 2:05 pm UTC

hotaru wrote:you don't know c.

:roll: :roll: :roll:

Actually, I happen to be a C programmer by profession. I stand by what I said: it does too many things in one line.

And as for the people calling it a "common C idiom", what, you people actually use that in your code? As opposed to strcpy?

User avatar
sparkyb
Posts: 1091
Joined: Thu Sep 06, 2007 7:30 pm UTC
Location: Camberville proper!
Contact:

Re: "Knowing" a language

Postby sparkyb » Wed Dec 31, 2008 3:04 pm UTC

Emu* wrote:

Code: Select all

*(p++)


Technically this code is equivalent to *p++, however (p++) doesn't return what you think it does. It returns a copy of the value of p before it was increment, not the result of the increment operation. It is pretty counter-intuitive as compared to ++p which increments p and returns the new value. ++p is exactly the same as p+=1 (well, with primitive types without overloaded operators), but p++ is like nothing else I can think of. So the behavior of it is more like the one you wrote as *p;p++. But this is an important thing to know in C and can be very handy. It is only a shame that p++ has become very popular when ++p is really more appropriate most of the time except when you really want that funky behavior, as in *p++


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 10 guests