systems programming versus application programming

[Roedy Green]

Heh. I was *born* in 1971 )

I was born in 1948. That was a very fortunate time from the point of
view of getting to see the explosive growth of computers. I got my
first computer job in 1964.

From my perch of watching so much change, evolution seems to be
stalling.

1. XML is a terrible mistake. The intent is good, but the execution
idiotic. It is a giant exercise in obfuscation by camouflaging the
data in a sea of distraction.

2. Pure server side is a dead end. We need to get decent client-side
data entry/validation/presentation to complement it.

3. Nobody seems to grasp the huge maintenance penalty they are paying
for verbosity. Everyone seems to equate brevity with APL cryptics. The
only way humans can write more substantially complex programs is to
make program do more per line. Humans can only read and be familiar
with so much material. This means giving up the medieval monkish
desire to control every filigree of the illuminated manuscript in
perfect custom detail. We have to hand over tasks like layouts to
intelligent agents. We have to redesign our languages so that you can
hide the plumbing behind the paneling. Everything is so exposed and
in the way.

 

[Liz]

I love it when you 'talk dirty', Liz.. ;-)

*SMILE*

 

[Liz]

I was born in 1948. That was a very fortunate time from the point of
view of getting to see the explosive growth of computers. I got my
first computer job in 1964.

From my perch of watching so much change, evolution seems to be
stalling.

1. XML is a terrible mistake. The intent is good, but the execution
idiotic. It is a giant exercise in obfuscation by camouflaging the
data in a sea of distraction.

Just wait till the binary version starts to take off.

 

[Peter Ashford]

I was born in 1948. That was a very fortunate time from the point of
view of getting to see the explosive growth of computers. I got my
first computer job in 1964.

From my perch of watching so much change, evolution seems to be
stalling.

1. XML is a terrible mistake. The intent is good, but the execution
idiotic. It is a giant exercise in obfuscation by camouflaging the
data in a sea of distraction.

I agree. I've found XML useful when I want a heirarchical file format
without having to roll my own, but mostly a PITA for everything else. I
worked for a company doing openGL gfx for TV broadcast - our viewer
program picked up data from a text file and rendered it - took about an
hour to write the parser. Switching to XML bloated the system to
parsing several related documents, adding XML parsing libraries and
adding several days to the project. Utter waste of time.

2. Pure server side is a dead end. We need to get decent client-side
data entry/validation/presentation to complement it.

Agreed, but then I'm writing a Java game in OpenGL, so I would say that ;o)

3. Nobody seems to grasp the huge maintenance penalty they are paying
for verbosity. Everyone seems to equate brevity with APL cryptics. The
only way humans can write more substantially complex programs is to
make program do more per line. Humans can only read and be familiar
with so much material. This means giving up the medieval monkish
desire to control every filigree of the illuminated manuscript in
perfect custom detail. We have to hand over tasks like layouts to
intelligent agents. We have to redesign our languages so that you can
hide the plumbing behind the paneling. Everything is so exposed and
in the way.

Simplicity is the main reason I like Java and the main reason I don't
like C++.

 

[Liz]

I agree. I've found XML useful when I want a heirarchical file format
without having to roll my own, but mostly a PITA for everything else. I
worked for a company doing openGL gfx for TV broadcast - our viewer
program picked up data from a text file and rendered it - took about an
hour to write the parser. Switching to XML bloated the system to
parsing several related documents, adding XML parsing libraries and
adding several days to the project. Utter waste of time.


Agreed, but then I'm writing a Java game in OpenGL, so I would say that

;o)

[ot] I got a dell laptop about 10-11 months ago that is supposed to have
some
hardware support for OpenGL, but I don't know what to do to take advantage
of it, any suggestions? I found a site that had an evaluation tool that I
ran and apparently the hardware support is there, but I can't remember
what exactly.

 

[Roedy Green]

I wish everyone had some exposure to Forth. Forth is not the way to
go, but it shows you what could be possible. It is a language to let
you experiment with your dreams. People who have not experienced
Forth are a bit like those expounding on sexual pleasure who have
tried nothing more exotic than a backrub.

People who spend their entire lives in the Algol family (Fortran, C,
C++, Java) have such impoverished views of how things could be. It is
like a president who never traveled outside his own country.

 

[John]

2. Pure server side is a dead end. We need to get decent client-side
data entry/validation/presentation to complement it.

I agree with this, but it's an unpopular viewpoint. Do you have any
resources (articles, papers etc) that discuss/show this?

 

[Roedy Green]

I agree with this, but it's an unpopular viewpoint. Do you have any
resources (articles, papers etc) that discuss/show this?

I had an article published in October 1986 in Byte magazine where I
argue for this and describe my Abundance computer language. See
http://mindprod.com/article.html

Many of these ideas could be brought forward to Java.

Back then I argued for class libraries that come built-in with the
language. It was considered a fruitcake idea at the time. Now it is
self-evident.

Some of the ideas include self-labeling fields, smart fields that know
their own type (e.g. Swedish phone number), how to do data entry and
validation, bounds, how to issue prompts and error messages, how to
display, how to convert to internal form, how to store in a database,
etc.

Layouts now exist in Java, but they could go a lot further in giving
the layout manager discretion.

Abundance works with jaunting to handle validation. You just pepper
your code with asserts, and the system handles making the user back up
and change the data to keep the asserts happy and generating the error
messages and warnings. There are no explicit loops to send him back.


The apps I do to this day in Abundance are far easier for
technopeasants to use than Java server side apps and they are orders
of magnitude easier to write.

 

[Liz]

I had an article published in October 1986 in Byte magazine where I
argue for this and describe my Abundance computer language. See
http://mindprod.com/article.html

I won a programming contest for PC Magazine a few years back.

Original name for C++ was "c with classes." I used the original
compiler. (I was at bell labs at the time.)

 

[Tim Ward]

I was trying to show this booting ritual is NOT that ancient.

I was doing it in 1964 on the 7044, in 1968 with LGP-30, and later
with the PDP-8. Circa 1977 the Apple ][ came with the BIOS in ROM and
very rapidly the practice died out.

On the Data General Nova, IIRC, the boot rom cost extra - most people bought
it, but not my then current employer :-(

 

[George Neuner]

I was told that people who do systems level programming are better
programmers than people who write applications.

Having done both and worked with people on both sides of the fence, I
would say that the average system (and/or embedded) programmer tends
to be more meticulous than the average application programmer and
tends to produce better code.

While I don't think either programming group can claim "better" skills
in general, I do think there are profound differences in culture and
attitude which affect the quality of the finished product.

System programmers, in general, write code that must be of sufficient
quality and reliability that applications can be written to depend on
it's services. Application programmers, in general, write code that
must be of sufficient quality and reliability to achieve the projected
market penetration. The difference between those levels of quality
and reliability can be and frequently is orders of magnitude.

My perspective is that they require different skills sets. One of the views
is that systems programmers don't require too much object-oriented
design skills than applications programmers.

I don't know where you got these idea's ... perhaps from some very
antiquated sources. OOD is just as relevant to system design as to
application design.

An object oriented design may not be realised using object oriented
programming. This is not a contradiction - design is a different
level of abstraction than implementation and is frequently done using
different methods and tools. Decent tools may not be available for
programming on the target platform - this doesn't prevent the designer
from using OOD methods. The architect designs the building with a CAD
program, the steel worker implements the building with a welding
torch.

In contrast to programming, system *design* typically requires much
greater skill than application design because "systems" typically have
many more requirements to satisfy - one of which may be to execute ill
behaved user applications without crashing ... in addition to whatever
else it does. You can think of system design as application design
practiced at the Grand Master's level.

George

 

[Roedy Green]

Original name for C++ was "c with classes." I used the original
compiler. (I was at bell labs at the time.)

You hung out with Bjarne Stroustrup? I had an very embarrassing
encounter with him. He showed on BIX (the Byte Information Exchange)
one day, the predecessor to newsgroups we used in the days of X.25
packet nets.

We were having a discussion about the quality of C++ documentation,
and I was rather critical. It did not dawn on me that my debating
opponent was the author of C++ and the texts I was trashing. He seemed
to take this all very personally.

Oops.

I did not like him at all and he certainly did not like me. Then I
read his Design and Evolution of C++ which explained the political
struggles he went through to try to keep C++ from being too
bailingwire. Ever since I have been much more sympathetic to him.

I did manage to mend fences with him a bit with a hymn of praise to
his brilliance in designing vtbls, the structures under the hood that
let C++ handle multiple inheritance and virtual functions. This was a
brilliant invention I don't think many people appreciate because they
saw only the elegant result, and spent no time themselves trying to
solve the problem. This was the heart of C++.

 

[Roedy Green]

I don't know where you got these idea's ... perhaps from some very
antiquated sources. OOD is just as relevant to system design as to
application design.

Perhaps what he heard was that device drivers and other low level
coding is often not OO.

 

[Liz]

You hung out with Bjarne Stroustrup? I had an very embarrassing
encounter with him. He showed on BIX (the Byte Information Exchange)
one day, the predecessor to newsgroups we used in the days of X.25
packet nets.

We were having a discussion about the quality of C++ documentation,
and I was rather critical. It did not dawn on me that my debating
opponent was the author of C++ and the texts I was trashing. He seemed
to take this all very personally.

Oops.

I did not like him at all and he certainly did not like me. Then I
read his Design and Evolution of C++ which explained the political
struggles he went through to try to keep C++ from being too
bailingwire. Ever since I have been much more sympathetic to him.

I did manage to mend fences with him a bit with a hymn of praise to
his brilliance in designing vtbls, the structures under the hood that
let C++ handle multiple inheritance and virtual functions. This was a
brilliant invention I don't think many people appreciate because they
saw only the elegant result, and spent no time themselves trying to
solve the problem. This was the heart of C++.

Back in the day he would start a lecture with something like
"C++ is a strongly hyped language."

Dave Korn is a cool guy too, he had UNIX (SVR4 of course)
running on top of win nt 4.0 maybe 8-10 years ago.

And (VERY early in the game)
he had some software that ran on a lan of Sun boxes.
It had very small resource and status tables for all the
machines in each of the machines. Then you could type in any
SVR4 command preceeded by some keyword I can't remember and
it would find the best machine to run it on based on these
two tables. The job would be shipped there, run there, and
results would be returned. You could even run nmake and it
would send different pieces of the job to different machines
for parallel processing.

There were several "famous" guys that did a lot that most
folks never heard about other than the one or two things
that made them famous.

 

[Scott Ellsworth]

Having done both and worked with people on both sides of the fence, I
would say that the average system (and/or embedded) programmer tends
to be more meticulous than the average application programmer and
tends to produce better code.

I have worked with both as well, and have a different view.

I have found that there are two groups of programmers lumped together as
"Application programmers". The programmers often called "business
developers" tend to be people who have written relatively few programs
previously. Further, they tend to be focussed on a problem domain, and
not on quality of implementation. Ask, and they often describe
themselves as a broker, a trader, a scientist, or a doctor, rather than
a programmer, even if the programming task they are working on has taken
a lot of their time for quite a while.. Their applications rarely
scale, and they are rarely concerned with becoming better at the craft.
Not all business developers are this way, of course, as many decide that
they enjoy programming tasks, and thus want to do them better, but it
does describe a great many of them.

A rather different group is writing re-usable applications, generating
frameworks or libraries, and in general concerning themselves with good
design. They may not all agree on what the principles of good design
are, but they are aware of what it means to them, and how to bring it
about. Further, they tend to improve over the course of every
programming project. Often, they have had a few courses in programming
theory, and have read a bit about design.

Embedded programmers are often concerned about resource usage at an
earlier stage, but the second category of application developers also
are aware of the issue. Put another way, the rigor used by the best of
the application programmers is similar to the rigor used by the best of
the systems programmers. There are differences in culture and outlook
that determine when they apply their metrics, profiles, and
optimizations, but at the end of the day, the tools of the best of the
breed programmers in either group seem to be isomorphic to each other.

Scott

 

[George Neuner]

the rigor used by the best of the application programmers is similar to
the rigor used by the best of the systems programmers. There are
differences in culture and outlook that determine when they apply their
metrics, profiles, and optimizations, but at the end of the day, the tools
of the best of the breed programmers in either group seem to be
isomorphic to each other.

I completely agree ... but the original question wasn't just about
best of breed. In my opinion, having system programming experience
makes for a better programmer at any level of competence.

System programming teaches the pitfalls of cooperative and/or separate
development and integration in ways that application programming does
not. It requires understanding that software components don't always
play nice together and that groups of components can have very complex
and sometimes very subtle interactions. System programmers learn
defensive programming more quickly because they are forced to
recognize and *prevent* integration problems in and with their own
code. Because they deal with other peoples' code much more
frequently, they learn more quickly to recognize symptoms and diagnose
compatability problems. These are important skills which will carry
over into all of their future work and I contend that system
programming teaches them quicker and in more definitive ways than
application programming.

I also don't think formal education (or lack thereof) has anything to
do with being a good programmer - rather I think it requires a person
with an engineering mind and repressed control issues

[ In case you are wondering now, I have a master degree in computer
science (in OS theory and design), completed course work for a degree
in database theory and completed most of the course work for a degree
in language theory. I've worked for over 10 years in an OEM contract
design house doing wierd projects like: device firmware; an embedded
operating system; a virtual machine, compiler and development
framework; a medical imaging system; several machine vision quality
control applications; a factory automation system and a distributed
sensor information system. I have 4 applications that are FDA
validated for production use and a number that are tested 4-nines
reliable. The medical imaging system I helped design is slated for
clinical diagnostic use but the contracting company has not yet
applied for FDA validation.

Not bragging here - I'm sure there many people reading this have
bested anything or everything that I've done. Just illustrating that
my perceptions are colored by education and years of work that has
been system and/or reliability oriented. ]

George