C as first language?

Depending on the task. I'd divide programming tasks into four general categories.

1) trivial bit shuffling functions. Functions like strlen(), or even like sprint(), which
any programmer ought to be able to write if he puts in enough effort.

2) Non-trivial bit shuffling functions. E.g. an attack on the travelling salesman problem,
which you could approach in several ways, and it's not obvious which will be best.

3) low-level IO functions. These are often difficult to write, but it's a different type of
difficulty. The challenge is in understanding how the hardware is reacting and
synchronising with it in the right way.

4) Glue code. This is often called "business logic". The rules are complex and have to
be right, but there's no fundamental algorithmic complexity in them. it's case of
having an appropriate library of the other functions, and calling them at the right time.


The type of design you need varies depending on the task.

 

It's some way off being perfect. (I'm working on a compiler which is now
targeting native code rather then C source; there is considerable extra
freedom in doing things that either C can't express, or doesn't allow, or
would generally moan about for no good reason.)

What does that correspond to in C; function pointers?

I think of C as being used to implement something better! Or rather, higher
level.

If you look at any general algorithm, then in any dynamic language, you can
almost implement directly as expressed. Not so in C, not if it lacks support
for certain features (strings and lists for example, or containers of mixed
types).

 

Both B and BCPL have those things, and yet C was designed precisely
because of what B lacked, so to make your statement true, you need to
include some more stuff.

In what terms do people who don't know C think in when they think of an
algorithm? Was Euclid thinking "in C terms" when he devised his famous
GCD algorithm?

 

Maybe. I tried to be exhaustive, but I might have missed something important.
Obviously not essential, B was presumably usable, but not as nice as C.

Obviously Euclid didn't have a C compiler.

The algorithm is

Start with a pair of positive integers, a and b.
while the two integers are unequal
set a to the minimum of a and b
set b to the absolute difference between a and b
repeat
The answer is the value.

That maps pretty well to C thinking, you've got a while loop in there, and comparison operators.
Also a and b are variables you keep track of, not parameters. I can't read Greek so I
can't read Euclid's original text, and in my summary the fact that a is corrupted by the
first step is glossed over - Euclid may or may not have done that, it's a normal thing to
do when describing an algorithm in natural rather than formal language.

So yes, we're thinking of it in C terms - while loops, comparisons, a sub-function which takes
the minimum. Not in pure assembler terms, where you might only have x, y and a registers
and not be able to devote one to a and one to b. Not in object-oriented terms where a
and b are anything that supports the < and - operators. Not in Lisp terms whereby each
step is a recursive call to the previous one. C terms are the natural ones that most people
use when thinking about algorithms.

Obviously since I've been a C programmer for so long I no longer have an objective view of
the matter. But I programmed for about ten years before learning C, and I felt that very
shortly after learning the language.

 

Which one, a or b? (I tried it and it didn't seem to work, ending up with
both zero).

I don't know why you think these basic arithmetical ops are the exclusive
domain of C; most languages will have them too!

So, for example, I can write code in one of my languages to calculate the
GCD (using a different algorithm from yours) of 31415926534676736647 and
438478473847834834784748 (answer 7). Trying it in C however didn't work
(overflow in constant).

More likely they think in terms of pseudo-code. Such code doesn't have
annoying details such as data types and limits to worry about or to specify
(and it tends to have less punctuation).

A lot of pseudo code will *not* translate to functioning C without a lot of
work. With some languages, however, it can almost be directly transcribed.

Of course nothing stops you using C *syntax* to write pseudo-code in, but
actually running the result is another matter unless it's known to be within
the language's capabilities.

 

C's got an issue with machine precision. An int means "an integer, as long
as you are sensible", not "the largest integer that can be represented
on your 100TB hard drive".
It's seldom much of a problem.

 

(snip, someone wrote)

I like the analogy that someone else posted, about manual or automatic
transmissions. For a new driver to also have to learn how to shift at
the same time, isn't easy. Now, presumably 100 years ago that is what
they did, but cars have improved since then.

Java intentionally (more than C++) has many features from C.
It also requires bounds checking on arrays, and for casts on
objects that aren't appropriate. Java requires casts on narrowing
conversions, which helps avoid some strange mistakes that can
easily trap C programmers.

The "objects late" teaching style uses static methods for much
of the teaching and practice, and so is more C like.

If one was interested, there is a JOS project, to work on an OS
in Java. As well as I know, it is going pretty slow, though.

-- glen

 

For what you want to do, it's a fair choice. Python will also be useful.

Otherwise I'd say learn C++ first and get C for free!

 

.

C++ is /intentionally/ a superset of C. Java has curly brackets, but
what else? [0]

To me that sounds as an argument /against/ using Java to learn C. You
/will/ need to learn to handle those aspects of C, and postponing that
learning seems risky.

Hell, I wouldn't even recommend using C++ to learn C -- and I really
prefer C++ to C.

/Jorgen

[0] Here I must admit here I haven't used Java for 16 years or so.
They might have added pointers, manual heap management and
call-by-value while I wasn't looking.

 

(snip, I wrote)

I think for me, it was the C++ overload of << and >> that discouraged
me. Yes that is a small thing, but it was enough. Java makes fewer
changes to the operators and the way they are used. (I disagree
with the Java overload of +, but I can get used to it.)

If you haven't looked lately, you might look at a relatively
new addition, System.out.format(). Very interesting for C
programmers!

And those driving manual transmissions will need to learn to shift
gears, but if you have never touched a car before, and especially
never tried steering, consider the first time you are partway
around a curve and the instructor asks you to shift gears.

It has changed a lot in 16 years. Java is always call by value,
pretty much in the same way that C is. Primitive types are
always passed by value, and objects are always processed through
reference variables, which are passed by value.

-- glen

 

If you know C or C++, you get that instantly. All objects go on the
heap and are accessed via a pointer to them.
However it can be confusing to people new to programming.

 

It sounds as the same system that Python uses ... I'm familiar with
/that/ one, and it's IMHO very different from C's. If that's pretty
much like C, then I cannot think of a language which isn't!

/Jorgen

 

Of the languages I'm familiar with, all of the following are, IMO,
substantially more different from C than Java is,

APL
COBOL
RPG II
SQL
Haskell

 

"Learn a bunch of reasonable and useful languages" is good advice.
And Python is a fine language. Popular, too.

There are lots of C things you don't want to learn if you're learning
C++, though. I wouldn't recommend a "two for the price of one"
strategy, especially since there are too many people writing C in C++
already.

I /would/ recommend skipping C and going straight to C++, while still
being able to use the same set of C libraries and tools ... but that
would be rude considering this is comp.lang.c.

(Also I tend to get paid for writing C code, but not C++.)

/Jorgen

 

I don't know how things are done elsewhere, but all of my clients who
produce "embedded" (some are Linux based) C products use Python for
their acceptance and production test systems. I'm guessing this is a
pretty popular combination. On the OS front, I'm not sure about Linux,
but Solaris derived systems use a lot of Python.

Write your unit tests in C++!

 

Types. B is typeless, C has types. They not included in your list of
"all you really need" so it's for you to say if you really need them
i.e. that you missed something important, or, alternatively, that C has
*more* than you need.

In Euclid, the procedure is presented twice to determine two separate
things. What you've written is the abstraction of the common part into
a single procedure. Euclid never did that (it was presumably not
important to him; he surely knew that there was something important in
common between the two). Furthermore, you have taken his wording of
"measures" (remainders) and lengths and turned it into a notation of
variables and loops. That all comes from you.

Someone familiar with, say, Haskell would have written this algorithm in
a different pseudo-code.

I think you agree with me. I said:

"the trick is to think in terms of programs that map into C"

That's exactly what you are doing. You've abstracted the algorithm from
one form (the rather ill-specified wording in the original) but you've
been careful to do that in a way that maps to into C. People with other
perspectives will see it differently.

Are you looking at proposition I or II? Proposition II (the GCD one)
starts (and I too must rely on translation):

Let AB and CD be the two given numbers not relatively prime.

I don't see that in your algorithm. Could it be that you (or th editor
of your edition) abstracted
something out that was not there in the original?

Who's "we"? You and Euclid? I don't see how you can say that. If you
are trying to be inclusive, let me quote Samuel Goldwyn: include me out.

But you are avoiding the main question: if what you say is true, how do
people who don't know C, or, if you are backing down form that, a C-like
language, think about algorithms? How did Church think about his
effective procedures? Not in terms of C or anything like it, that's for
sure.

 

In Java, the type of an object can be retrieved by
.getClass(). This object type cannot be modified by any
means, not even by a cast operator. It is immutable.

What you might have in mind are reference expressions.
The type of those can be set by a cast indeed.

This is similar to C++11, where IIRC

constexpr int i{ 1.1 };

gives an error: narrowing!

The main-method of Java is static. So, unless one finds a
way to circumvent this main method in teaching, one is
forced to start with a static method declaration for the
hello-world program. Common utility methods, like »abs« or
»max« are static too.

Yes. But to the common programmer who is not using the NDK,
Android appears to be a kind of Java OS, because Java is its
default programming language.

 

Java had pointers from the start. (That is, »pointers« in
the sense of the JLS - not in the sense of N1570, of course.)

The JLS 1 from 1996-08 already said:

»The reference values (often just references)
are pointers to these objects«

All of these words have /different/ meanings in Java and in C:
»object«, »variable«, »pointer«. What Java defines as a
»variable« is what C calls an »object«, for example.

The JLS 1 starts with this quotation:

»"When I use a word," Humpty Dumpty said,
in rather a scornful tone, "it means just what I
choose it to mean - neither more nor less."
"The question is," said Alice, "whether you
can make words mean so many different things."
"The question is," said Humpty Dumpty,
"which is to be master - that's all."

- Lewis Carroll, Through the Looking Glass«.

 

An algorithm expresses the solution to a problem with the
elements of a given language, whatever language this is.

 

According to Malcolm, that language is always "C". Ben is just pointing
out that this is a problematic assertion if it's intended to apply to
people who never learned "C". It's almost as problematic to apply it to
people who don't particular like "C".