phao

> In short: just because many people manage to use Java does not mean it is in any sense optimal or even good.

Nobody is saying the contrary. I suggested him one of the many options he has (from which I mentioned 2), which is using java. And said that using java is better than going around looking for why people bash java. Which happens to be true.

Consider how he would choose a better language though.

It's surprising how cumbersome it may get to write a simple loop in a more "elaborate" language.

> Also, I think the oft-repeated "right tool for the right job" bromide about programming languages is deeply flawed. Programming languages overlap far more than most tools--they are all general-purpose programming languages, after all. The difference between a hammer and a screwdriver is far greater than even the difference between Java and Haskell. Choosing a programming language is more like choosing the best power drill--they overlap almost completely and can do the same jobs. It's quite plausible that some are almost always better than others, but that you could ultimately do the job with either. It will just be more difficult with one than the other.

There is more to choosing a language than "the language". Here are some reasons why he may wanna use java:

1) He has books about java, but not about anything else.

2) His co-workers use java.

3) He needs to work with the JVM.

4) He really wants to use java.

5) He has a bunch of minor reasons to use java.

6) Libraries, Libraries, Libraries.

7) Development tools.

8) Good implementations.

9) There is a standard for the language.

10) There is a huge community around the language.

11) He doesns't really have a choice. His boss wants him to use java.

12) He's in academia and most people in his institute uses java.

(there are more!)

The "right tool for the job" sure is true. And very much true. It is complicated to select it though. That's why I didn't try to tell him HOW to select that tool. I really think he'll be better off with java if he saw java is good enough (another point is that a "known good enough" is usually better than a "unknown perfect").

We choose "a language" but rarely because of "the language". As you said yourself, a lot of times, these languages are general purpose languages and overlap a lot.

Have you ever noticed that a lot of the languages used today are really tied up to their implementations/running systems? C and UNIX, Java and JVM, C# and CLR, Python and CPython, PHP, Ruby, Objective-C (this one is a really good example), JavaScript, etc. This was true in the past too, think of delphi, vb6 and windows, lisp and the lisp machines, fortran and cobol and the IBM systems.

A lot of what was "language design" in the past, is libraries and implementation design today. Choosing a language is more than looking at "the language", its syntax, semantics, idioms, patterns, etc.

Some other important stuff. Like building a GUI is important, communicating over a network, accessing files, dealing with the data base, doing graphics programming. You can either use, for example, c# and have lots of these from .Net CLR with little effort, or pick OCaml, for example, and have it, but having to do a lot of work that you'd not have to do in c#. Even if you port OCaml to run on the CLR, it's unlikely to be as much CLR friendly than C#.

But, also, there are "local" reasons to choosing a language. These are stuff you or I don't know because it's specific to him or his group of people.

> You should be learning something new all the time, and programming languages are some of the most important things to learn in CS--they affect not only what you write but how you think. So strive to find the best one you can rather than settling for something that works--in this day and age, expecting your language to be somewhat usable is too low a bar to set.

Learning new stuff is good advice, generally. But programming languages are one of the most irrelevant things in CS. In the long run, they are irrelevant.

"We" already teach/learn a lot of programming concepts and techniques without specific programming languages, but with concepts shared by a class of programming languages (as you even said it, lots of them overlap). Concepts and techniques that, in the past, were highly specific of particular programming languages.

Languages get obsolete. Those which remain do so usually because of practical matters (like C, or Java, or C++).

The idea, sometimes new, a programming language may bring is important though. The language itself is not. For example, closures are really catching on now, but it was invented much in the past, and first implemented in languages that people do not use much (I guess it was scheme, but I am not asserting it)

And, so I can end this reply...

I'm sorry for arrogance, but you should not lose the ability to separate interesting from the practical, which I got the impression you cannot do very well. Some things are both (I guess haskell is one of these), but it's not usually the case.

What some people (fortunately, it doesn't seem that it's most of them) don't understand is that lots of programming do not require the sort of elaborate constructs and idioms that, for example, scheme allows you to use. I once talked to a guy who did lots of "business" software. I mentioned scheme to him. Told him lots of cool stuff about recursion, clojures and macros, told him a little about lambda calculus; showing how you could do it in scheme. And he told me "It's cool, but it's also like people don't know what is useful anymore.". Well, that got me thinking back then.

You can argue all you want if he's right or not; if the software he writes is difficult or not, but it's not that he didn't see the advantage of those things. But turns out that most repetitions do not require and are not good with recursion (they just loop over a collection or a range of values; a for+iterators or numbers would usually do), most functions do not return other functions (not that you couldn't do it that way, but it's usually the case that your program is simpler if you don't), and minimalism is not really that much convenient in writing software for $$ (many people seem to reach this conclusion). Lots of applications are still single threaded, and runs in only one process. Immutability is a lot more interesting in theory than in practice for a large class of programs. Static typing still catches a lot of problems, and people usually do not bother that much about having to write down the types. Beautiful techniques for managing large programs are very interesting ... for large programs. It turns out that lots of programs are not that large. And the list goes on and on.

There is a hate against Java, also against C#, C++, PHP (which I hate), C, and pretty much any other mainstream language.

Notice, though, that competent people have done great jobs using these languages. So you have some choices. Two of them are: wonder why people bash Java or go do something useful with it. I suggest you do the second.

The key to using programming languages is in trying to use the one which will help you the most, or get in your way the least. Sort of "the right tool for the job". Idk what jobs java is good at. If you found out that it's good for your project, then use it.

Take a look a this article: http://prog21.dadgum.com/143.html

One major problem, which I think is related to this you're saying is that C is used as if it was a beginner's language, but it isn't.

C was made so that it could be simply compiled to assembly. Also important, it had high portability "in mind". The mix of these two design goals is that compilers could exist for many platforms. And not just that, it's a language that was made also so that a large part of the UNIX operating system could be re-written in.

As some additional, although you can interpret C, that's not how it's usually used. In teaching/learning, people use optimizing (professional) compilers such as GCC. Which leads to a much non-interactive environment.

Put these 2 design goals together and you're bound to realize a language which is not beginner friendly because lots of things are there, or not, for reasons (a) to help the compiler writers; (b) due to portability on some machine of the 70's or 80's; and (c) of being a language for OS development. Add this with the fact that the tools around the language are not so interactice, you get something really beginner unfriendly.

C is not simple to learn, to use or to get good at. Compilers take advantage of what was put in the standard in very bizarre ways. Which means that if your code is wrong, even a little bit, it's likely that you get bugs, terrible ones. The optimizing compilers (good for professional use; bad for leaning) are usually the ones which will lead to the strangests bugs. Again, not beginner friendly.

It's often that people think they're good at C, and that they write portable C code: they usually are not and don't. C is very good at deceiving people.

Unfortunately, C is not a language that you can just pick and start solving your problem right away. Many more ordinary statements can fail for non-obvious reasons, which is not so common in other languages.

I am not implying that you don't know all this. I am though, implying that you should take this into consideration when you talk about learning C, and beginner programmers approaching C, and even beginners in C from other languages.

There are good books which are not difficult, and do not let go of preciseness, like K&R2.

This Chris Torek guy has a bunch of articles. Series called "C for smarties". It's __very__ good.

http://web.torek.net/torek/c/

The link is in there in the wiki somewhere, but I think it's worth placing it separately.

The wiki mentions some names in the Usenet page. Google these names.

Sorry. I don't know why I didn't do it.

http://www.iso-9899.info/

This is that wiki page I mentioned. It has links to all sorts of places. All articles I was talking about, I found in there.

It has an articles page:

http://www.iso-9899.info/wiki/C_gotchas

And it has some recommendations on many things, including other artigles.

http://www.iso-9899.info/wiki/Usenet

Check out the "Additional materials part":

http://www.iso-9899.info/wiki/Main_Page#Additional_materials

Anyway, wander a little bit in that page. The books recommendations are great, even though they recommend Deitel & Deitel C book, which is not bad, but it's sort of shallow.

Thanks!

Very few people have reasons to use C. As far as I know, must people do not want to use C. Those who want or have reason to, should go in depth. If you're trying to avoid going deep on the subject, then, forgive my intrusion, maybe you should be focusing on something else.

Some languages you can use by just learning a little bit here and there, supperficially. C is not one of these.

Honestly, why don't you re-iterate the known tutorials about these things? Make a blog post saying "here are these old C tutorials, which are amazing; and some people seem to have forgotten these things" and post them. Lots of comp.lang.c posts are interest Chris Torek's stuff are interesting. If you go to the ##c channel, at irc.freenode.com, they have a wiki link on the topic. That wiki has links to many tutorials. Re-iterate these things. And, please, recommend people using something other than C =)

C assumes some sort of object space addressable to the byte (each object is composed of one or more bytes -- no such a thing as a 0 bytes object in C). It's the memory pretty much. Afaik, what is an address is not defined as part of the language. I guess people should use the knowledge they got from their "how computers work" classes =D. A pointer holds an address. I think that's as deep as you can get with this as clarifying goes.

You can though, say, to help learners that the address of an object is a value which can be used to indirectly access the object. You could say that it's a value that you can keep with you, to access the object later, indirectly.

And, as any language that I am aware of. Things are usually defined abstractly (in terms of what you want to be true about them). C is not different. You won't find concrete definitions (things may look concretely defined, but they're not). As far as we're concerned, addresses are these things that

- the address-of operator returns

- is help by pointers

- can be indirected

- ...

It could be represented as a character string for all we know.

Minor points:

- & is called the "address of" operator, and saying "The & is the reference operator and is used to reference a memory address" sounds just strange.

- In C, a reference is just a way to indirecty access an object, which means that a pointer is a reference. The C language doesn't define references like C++ does (as another name for an object). In C, references are much informal (the conceptual definition is used; as in a means to access something else).

I am going to be honest with you, I read the beginning. Found it strange, then looked at the topics. Saw you had a "pointers and arrays" section. Read it (it's the part where people get confused more). You seem to make the same mistakes. I didn't read the rest.

These are not minor problems, IMO.

Here is a quote from the pointers and arrays section:

"Imagine an array variable like a pointer that cannot be changed that holds the memory address of the first element of the array it points to. Even though the array variable holds a memory address, you cannot assign a pointer variable to an array variable, even if the pointer variable actually points to the same or a different array. You also cannot assign one array variable to another."

Arrays are not pointers. And they don't hold memory addresses. An array is a continuous block of memory holding as many objects as you specified, all of the same type. You should explain "value context" and "object context" and tell people that when an array name is used in a value context, the value you get is a pointer to its first element. This is not due to "arrays are pointers" or "arrays hold pointers". Arrays are not pointers; and they only hold pointers if the element type is of a pointer type (however, in this case, the pointer(s) is(are) its element(s)).

You should explain what it means "arrays values are pointers to their first elements", and focus on "value". If you take the sizeof operator or the address of operator, they operate on object context (not on value context), then you will "reveal" the "true nature" of the array.

To really be able to explain pointers, you should explain other things first. Which is very hard to do in a small blog post. I suggest you make a series of posts; and try to make then correct, w/o getting bogged down with definitions of C terminology (which idk how to avoid). Terminology such as lvalue, rvalue, name, value context, object context, value of something, object, identifier (in C, identifiers and names are 2 different terms), and some others.

Out of curiosity... Can I ask you why you're posting about C?

Yet another broken C pointers guide out there to confuse people.