Self-taught C

[James Kuyper]

On 02/08/2012 11:42 AM, Jorgen Grahn wrote:
....

{{Unix bigot mode|
Unix in general makes it easier to write programs which are small and
have a simple interface, yet are useful. I haven't tried it, but I
imagine the threshold is much higher on Windows.}}

If you haven't tried doing it on Windows yet, what is it you're
comparing Unix against when you say it's "easier"? I know there's things
other than Unix and Windows, but the significance of your statement
would be easier to evaluate if we knew what you were comparing Unix with.

 

[Nick Keighley]

[...]

[...] get graphics working as fast as you
can. It's harder now than it was to get a simple character-based
raster that can be used for moving space invaders round the screen.

It's still easy on Unix, where you have the curses library.

{{Unix bigot mode|
Unix in general makes it easier to write programs which are small and
have a simple interface, yet are useful. I haven't tried it, but I
imagine the threshold is much higher on Windows.}}

simple filters that work in Unix work fine in windows. You may even be
able to run the same code.

Nowadays simple GUI/graphics stuff is probably about evens. But when
it was X-Window verses Win32 I humbly submit Windows was streets
ahead!

 

[Nick Keighley]

Nick Keighley wrote:

[best way to learn C- beginner programmer]

I would also add participating in public forums dedicated to the
programming language, such as comp.lang.c, and also forums dedicated to >specific platforms, such as comp.unix.programmer.  Getting our hands
dirty may be the best learning experience that we can have, but being
exposed to the experiences that others had/are having will also
contributes greatly to our own progress.

good point. by this time I know what a program should look like so
even in a new language. I want my programs to work (lots of tests) and
exhibit a certain... spareness- no repeated code, no wodges of boiler
plate, no pages of woffle, each component should do one thing well.
Oh, and it should be idiomatic as well (you can write FORTRAN in any
language).

Plus, when we stumble on a problem we might benefit from having a
community willing to help us out on it.  Conversely, we may help others> with their problems, and in the process learn a bit more from it.

In short, we may do all our learning alone, but being a part of a
community dedicated to a specific subject also helps a lot.

yes, this group, C++, scheme, Microsoft, Unix have all helped me lots.
Oddly I've never really used a perl newgroups. Which might explain my
perl!

 

[Nick Keighley]

  Reading C books (including the C specification), Reading
  books on software engineering (not C specific),

reading about the design of other stuff. I'm in a minority here I
know...

Reading and
  porting code (e.g., C code from other systems to the Amiga
  or from other languages to C), writing C code, talking with
  friends about C, Reading the C source code of a computer
  game while playing it to find the tricks (how to play and
  win), and giving C classes (my next C class starts this
  thursday [the day after tomorrow] in Berlin; it's a real
  C class [not a C++ class]).

 

[Nick Keighley]

.....and of course, in the interest of "teaching", you are going to
omit what those "necessary" omissions might be and why.

Balderdash!

you shouldn't teach things that are actually wrong. It takes ages
(sometimes never) for people to shake off things like "pointers are
faster than arrays"

 

[Malcolm McLean]

Nowadays simple GUI/graphics stuff is probably about evens. But when
it was X-Window verses Win32 I humbly submit Windows was streets
ahead!

X is fundamentally misdesigned, because the idea is that the "client",
which means sever, sends a stream of bytes over a network to the "X
sever", which means client. However virtually no systems work like
that, and in fact it's hard to get interactivity if the client is
remote. But that consideration dominates the interface.
Then it's stupidly hard to get up a wondow because you've got to mess
about with defining colormaps.

I did try to solve these problems with BabyX, which was going to be a
simple interface to X. But I never finished it, and there were some
difficulties. It worked on one system, but not when I tried it on
another.

 

[Rui Maciel]

X is fundamentally misdesigned, because the idea is that the "client",
which means sever, sends a stream of bytes over a network to the "X
sever", which means client. However virtually no systems work like
that, and in fact it's hard to get interactivity if the client is
remote.

If I'm not mistaken, the X window system was developed with remote clients
in mind and in a time where remote clients were the norm. So, with that in
mind, I don't agree that X was fundamentally misdesigned.

Fast-forward 30 years, nowadays we have clients sending and receiving
streams of bytes over a network to/from a server in order to provide a
graphical user interface, but instead of the X window system we have the
world wide web. So, although it's a slightly different abstraction level,
it's essentially the same thing.

But on the same abstraction level there is the Wayland display server
protocol, and it appears their developers haven't moved away from the same
type of design adopted for X.

But that consideration dominates the interface.
Then it's stupidly hard to get up a wondow because you've got to mess
about with defining colormaps.

Maybe a better way to put it is that, since then, things got to be a whole
lot simpler. The technical limitations at the time didn't made it possible
to get away with some tricks that are employed today. After all, a
considerable number of GUI toolkits which are widely used today basically
provide an abstraction layer over X, and they work quite well.



Rui Maciel

 

[Nick Keighley]

If I'm not mistaken, the X window system was developed with remote clients
in mind and in a time where remote clients were the norm.  So, with that in
mind, I don't agree that X was fundamentally misdesigned.

Fast-forward 30 years, nowadays we have clients sending and receiving
streams of bytes over a network to/from a server in order to provide a
graphical user interface, but instead of the X window system we have the
world wide web.  So, although it's a slightly different abstraction level,
it's essentially the same thing.

But on the same abstraction level there is the Wayland display server
protocol, and it appears their developers haven't moved away from the same
type of design adopted for X.


Maybe a better way to put it is that, since then, things got to be a whole
lot simpler.  The technical limitations at the time didn't made it possible
to get away with some tricks that are employed today.  After all, a
considerable number of GUI toolkits which are widely used today basically
provide an abstraction layer over X, and they work quite well.

that's why I said they were about evens. You program in some
abstraction and tweak it for particular implementations. probably not
good enough for serious games but for a learner ok.

 

[Malcolm McLean]

If I'm not mistaken, the X window system was developed with remote clients
in mind and in a time where remote clients were the norm.  So, with that in
mind, I don't agree that X was fundamentally misdesigned.

Fast-forward 30 years, nowadays we have clients sending and receiving
streams of bytes over a network to/from a server in order to provide a
graphical user interface, but instead of the X window system we have the
world wide web.  So, although it's a slightly different abstraction level,
it's essentially the same thing.

The problem is that the messages were wrong. In X the server sends a
message "A key was pressed" and the client has to send back a mesage
"please draw the letter X in such and such a font in that window". So
of course the poor user would hammer the key again, then get a row of
xes, then press delete several times, delete the lot, then tap the x
key once, deliberately and smartly, and go for a coffee until he could
type in the next character.
With the web interface the server says "put up an edit box". The
client then allows the user to enter text. It then tells the server
"the user has finished putting text into the boxes you told me to put
up, and here's what he wrote".

 

[Ben Pfaff]

The problem is that the messages were wrong. In X the server sends a
message "A key was pressed" and the client has to send back a mesage
"please draw the letter X in such and such a font in that window". So
of course the poor user would hammer the key again, then get a row of
xes, then press delete several times, delete the lot, then tap the x
key once, deliberately and smartly, and go for a coffee until he could
type in the next character.

I've seen people do that, but I've never understood why. If
you're going to type "xerxes", type "xerxes". Don't type "x" and
wait for it to appear, then type "e" and wait for it for appear.
It's a great way to waste your own time.

 

[Patrick Scheible]

I've seen people do that, but I've never understood why. If
you're going to type "xerxes", type "xerxes". Don't type "x" and
wait for it to appear, then type "e" and wait for it for appear.
It's a great way to waste your own time.

Not everyone can touch-type.

-- Patrick

 

[James Kuyper]

Not everyone can touch-type.

If you can't touch-type, writing code must be a real pain. Writing
documentation must be even worse. You have my sympathies!

However, it seems to me that you can still write "xerxes" using
hunt-and-peck without having to wait for the first 'x' to display. The
only difference I see is that with hunt-and-peck you're more likely to
still be hunting for the 'e' when the 'x' finally shows up. I've often
touch-typed an entire paragraph while waiting for the first character of
that paragraph to display on screen.

 

[Joe keane]

If you're going to type "xerxes", type "xerxes".

I'm used to using a VT100 against a less-than-crisp machine.
But sometimes when people see me do that, they are all 'whoa' like it's
some kind of wizard skill.

 

[Stephen Sprunk]

I'm used to using a VT100 against a less-than-crisp machine.
But sometimes when people see me do that, they are all 'whoa' like it's
some kind of wizard skill.

I learned touch-typing long ago since I was able to outpace my modem
when chatting on bulletin boards, though that only lasted a few years.

Today, I can often outpace my phone's on-screen keyboard with just my
thumbs, which amazes friends. I don't see what's so difficult about it,
especially if you're looking at the keyboard while typing like most
hunt-and-peckers do.

S

 

[Stephen Sprunk]

The problem is that the messages were wrong. In X the server sends a
message "A key was pressed" and the client has to send back a mesage
"please draw the letter X in such and such a font in that window". So
of course the poor user would hammer the key again, then get a row of
xes, then press delete several times, delete the lot, then tap the x
key once, deliberately and smartly, and go for a coffee until he could
type in the next character.
With the web interface the server says "put up an edit box". The
client then allows the user to enter text. It then tells the server
"the user has finished putting text into the boxes you told me to put
up, and here's what he wrote".

Yes, the Web was the new "green screen" application.

However, the cycle of reincarnation continued to turn and now many
poorly-written AJAX applications need a round-trip (or several) to the
server before they'll update the page...

The "problem" with X was/is really that people tried to use it over
networks that simply didn't have the bandwidth to support what they were
trying to do. Like any interactive application, once the network starts
buffering and/or dropping packets, performance goes to heck.

S

 

[Patrick Scheible]

If you can't touch-type, writing code must be a real pain. Writing
documentation must be even worse. You have my sympathies!

Your sympathies are misplaced. I touch-type. But people who aren't
sure if they typed correctly understandably wait for the echo.

-- Patrick

 

[Ben Pfaff]

Not everyone can touch-type.

If you are typing, but not touch-typing, then you are looking at
the keyboard, so you should have no uncertainty about what you
have typed.

 

[James Kuyper]

Your sympathies are misplaced. I touch-type. But people who aren't
sure if they typed correctly understandably wait for the echo.

Sure, but hunt-and-peck typists have just hunted for the character, they
shouldn't be uncertain about whether they hit the right one. Such
uncertainty is more common among inexperienced touch typists, who can't
see what they're doing, than it is with either expert touch typists or
hunt-and-peck typists.

 

[Kaz Kylheku]

X is fundamentally misdesigned, because the idea is that the "client",
which means sever,

Blast from the past! I haven't heard this bullshit in some 20 years.

 

[Kaz Kylheku]

The problem is that the messages were wrong. In X the server sends a
message "A key was pressed" and the client has to send back a mesage
"please draw the letter X in such and such a font in that window". So
of course the poor user would hammer the key again, then get a row of
xes, then press delete several times, delete the lot, then tap the x
key once, deliberately and smartly, and go for a coffee until he could
type in the next character.

I sat in a lab full of X window terminals at university and don't remember
any of these problems.

X does require a fairly low latency connection to the server in order
to be useful.

With the web interface the server says "put up an edit box". The
client then allows the user to enter text. It then tells the server
"the user has finished putting text into the boxes you told me to put
up, and here's what he wrote".

But this basically brings you back to a command line interface. You can't
compare a window system with detailed mouse and keyboard events to form
submission (which requires some kind of GUI underneath it). That is completely
moronic.

If form submission were enough, we wouldn't have Javascript for developing
"desktop-like" apps (which don't even come close, usually). Javascript can
render the browser unresponsive, and is a gaping security hole.

I use the NoScript FireFox extension to explicitly allow Javascript
on a site-by-site basis.