Programming cage match: Languages or Discipline?

>On Sep 1, 2006, at 1:43 PM, Mike wrote:
> Programming languages are not the solution to bad software.
>
> Good programming *practice* is.

"You can write Fortran programs in any language."

Which means, you can write bad programs in any language, no matter how hard the language tries to prevent it.

--
David

At 10:16 AM -0700 9/5/06, Geoff.Odhner wrote:
>I agree with one point that good programming practice is the key to
>good software, but your conclusion is too simplistic. Good,
>appropriate programming languages are quite helpful as well, and a
>well educated programmer is flexible enough to adapt without great
>difficulty to new languages, since he/she is educated in
>* programming* rather than just *programming languages*. There are
>reasons for having languages specialized for particular situations
>or tasks. One does not use C or C++ where one uses AJAX for good
>reason. C/C++ are best implemented as compiled languages, and the
>tasks that AJAX is adapted for requires interpreted scripting. I'm
>not saying that JavaScript (as used by AJAX) is really the ideal
>scripting language for that task, since we know it has some serious
>security issues, but it is adapted to the task. Flex (and its
>predecessor lex) is a valuable aid to generating C/C++ code for
>parsing, and when confronted by a complex parsing task it's an
>excellent choice. The fact that you could write the C/C++ code
>yourself doesn't mean that you could write it as fast or as well as
>you could with flex. You could write it better if you really know
>the theory well, of course, but it could take you much longer.

And of course you are ignoring the time it takes to learn all of
those. In the time it took me to learn JavaScript, lex, flex, and
AJAX, I could have written 3 products in C/C++. Then when I learn
those there will be 4 news ones to learn next month and I will never
get any code written because I will be spending all my time with my
head in books.

The original vision behind the Macintosh was simplicity, not
complexity. Making computers simple and easy to use is what success
in modern software is all about - not reverting back to the stone
ages of command line UNIX. No wonder so many IT companies are
dropping like flies today. There seems to be this pervasive myth that
complex is somehow better.

>It's clear that you haven't worked on the kind of projects that I've
>worked on which have required bringing together many different tools
>and languages to accomplish diverse tasks.

I hear this a lot too. The end result in my experience is usually a
cobbled together product that uses too many technologies and thus is
subject to breaking in the future. Not to mention that scripting
languages are slow at runtime because they are interpreted. As for
what "the right kind of project" is. I pray that I never have to work
on such a project where I need to string together 20 different junk
technologies to make it work. Does the name Rube Goldberg ring a bell?

Simplicity. Beauty. That is what Macintosh is all about. If you want
to over-engineer things as most software developers do, then keep at
it. We will be sure to see more "Why is software so bad?" cover
stories in Wired Magazine.

I certainly appreciate the flexibility of C and C++, but if I limited
myself to them I would be doing myself and my employers a great
disservice. My productivity depends on choosing an appropriate tool
for a given task, and sometimes building a tool for a task, with its
very own language specific to that task.

Like I said: over-engineering. After all, why use an existing
language to write something when you can write your own to do it!

>Sometimes such a tool can be reused for a similar task on another
>similar project, and sometimes it's just a one-time language for a
>one-time task. That's not because I'm "churning out crap" as you
>suggest, but because I'm finding the most efficient and robust way
>to get a particular project done.

And spending lots of time doing so when the solution has already been
available for 30+ years.

Sure, C is thirty-some years old, but Python is 16, Perl is 19, Java is around 16, ObjC is 20-25, Ruby is 11-13, and even Haskell (does anyone outside academia really use Haskell?) is 7 years old; C++ is only 23. These have all been around for a long time, and are hardly being "churned out". Have you *used* these languages? I've developed commercial software applications in C, C++, Java, Perl, and Python, and each language has its strengths (and, of course, weaknesses).

Without getting into details, some of these languages (Python, for example), make programming better, by supporting good programming practice. I would have more confidence in an application implemented in Python by a good programmer than one implemented in C/C++ by an equally good programmer.

I think C/C++ are the perfect programming languages.

There is no perfect programming language; the right programming language depends on the task. C/C++ is a great hammer, but not every programming task is a nail. Carpentry is an art, too.

On 2.9.2006, space aliens observed lists573 saying:

My 14 years of experience in the software industry tell me that all the problems in software are due to programmer laziness, sloppiness, cutting corners because of deadlines instead of working longer hours to make sure the code is right.

You didn't say what you were working *as*. I'm a software engineer (which basically means I do planning, architecture and writing code). Asking programmers to work longer hours is just about the most stupid thing you could possibly do, and maybe even one of the main sources of bad applications.

Most programmers will probably get at most 4 hours of productivity (i.e. time spent writing actual working code - Joel Spolsky of Fog Creek Software estimates that he gets about "two or three hours a day of productive coding" [1]) out of themselves each day. If you make them work longer, they will write code alright - but code which they will have to fix, remove or refactor the next day. Or, worse, code which will not be fixed, removed or refactored and which will subsequently lead to major problems further down the road.

[1]<http://www.joelonsoftware.com/articles/fog0000000339.html>

I agree that bad languages aren't the main source of bad code. Languages can do a lot of things to help improve code (and this is a hotly-debated topic, so I'd rather not give examples), but mainly, it comes down to training.

I guess that most programmer have never had extensive formal training. That means they never had to learn things like proper planning or design patterns. Design patterns are "best-practice" solutions to known problems in software engineering. If you don't learn them, you're bound to invent your own solution to these known problems, which are bound to be worse than the "best-practice" solutions. In that regard, lazy programmers are actually the best programmers because they don't invent new stuff. They use what works.

Programming is often described as a creative task. It is, but there's just as much cold science involved (after all, it's "engineering"). You need to learn your theory if you want to be a good programmer. The language you end up using doesn't have a whole lot of influence on the quality of your code, and new, better languages can't magically turn a bad programmer into a good one.

Again, this is not to say that new programming languages can't help. For example, the switch from procedural to object-oriented programming made it possible to write applications which were not thought possible before. However, even here: It's a concept, not a language. You can write object-oriented code in plain C. Newer languages like Java help, but a good programmer can write good object-oriented code in C, and a bad programmer can write bad object-oriented code in Java (although bad programmers writing code in C++ clearly do create a bigger mess than bad programmers writing code in Java :-).

At 10:16 AM -0700 9/5/06, Hamilton Richards wrote:
>lists573, who signs his contribution "Mike", paints a vivid
>explanation of why so much software is so lousy, but his brush is a
>little too broad. It's true that many programming languages are mere
>repackagings of the features of their predecessors, and the
>proliferation of essentially equivalent languages has led many
>people to dismiss all discussion of languages' relative merits as
>quasi-religious "language wars". Nevertheless, Mike's extrapolation
>from "many" to "all" is a step too far.
>
>Of course no programming language can solve problems caused by
>programmers' laziness or sloppiness, or by bad management.
>Nevertheless, all other things being equal, with a better
>programming language a programmer can create higher-quality software
>in less time. And there are programming languages whose superiority
>has been demonstrated in the development of real-world industrial
>software.

But the problem is we don't live in an "all things being equal
world". There are too many variations in programmer discipline. You
can take a lousy programmer and give him a great langauge and he is
still going to produce junk software. People spend endless hours
studying languages and theory-of-the-week but almost no one spends
time thinking about the importance of meticulousness and solid
structure in programs. As is usually the case people just want to do
the bare minimum now and then wonder why it's unmaintainable later.

>Mike's rant, "Java, Objective-C, Perl, Python, Jython, Haskel, Ajax,
>Flex, Ruby, Ruby on Rails -- there's no end to the crap people are
>churning out" indicates that he has heard of one such language,
>though the misspelling of its name (it's "Haskell" with two l's)
>suggests that his familiarity with it is less than intimate. Haskell
>(www.haskell.org) is one of a family of so-called functional
>programming languages, one of whose best-known close cousins is Lisp.

I could care less about HaskeLL. I wouldn't spend time learning any
of these junk langauges if I had to. I'd change professions first
because as soon as I invested time in learning them, everyone would
decide they were obsolete and ask me to learn 3 new ones next month.
No thanks. I used C/C++ from 1989 to 2002 without a single problem or
need to learn another language. Now I'm suddenly supposed to learn 3
new ones a year. Fine for a college student maybe but as a
professional programmer, I don't have that kind of time. I never
learned Lisp either, nor do I want to. Don't need it.

>A functional language whose superiority has been demonstrated
>industrially is Erlang. It was used by Ericsson Telecom in the
>development of the AXD 301 ATM Switch, the flagship in Ericsson's
>line of datacom products. A retrospective analysis [1] indicates
>that using Erlang increased programmer productivity by a factor
>between four and ten:
>
>[quote] Comparisons between Ericsson-internal development projects
>indicate similar line/hour productivity, including all phases of
>software development, rather independently of which language
>(Erlang, PLEX, C, C++ or Java) was used. What differentiates the
>different languages then becomes source code volume.

I think you are mistaking PR for 'research'.

>Some concrete comparisons of source code volume have been made, as
>applications written in C++ have been rewritten in Erlang, resulting
>in a ten-fold reduction in the number of lines of uncommented source
>code. Other comparisons have indicated a fourfold reduction. A
>reasonable conclusion is that productivity increases by the same
>factor, given the same line/hour programmer productivity.
>
>When measuring product quality in number of reported errors per 1000
>lines of source code, the same relationship seems to exist: similar
>error density, but given the difference in code volume, roughly 4-10
>times fewer errors in Erlang-based products.

These 'studies' are almost always flawed. The alleged increase could
have been due to programmer discipline, personality, or other
factors. If this is such a great langauge then I am sure we will see
C/C++ go away and this will replace it. Besides, most companies don't
want to re-write working code. That's a huge cost. Just ask Apple.
Carbon came into being precisely for this reason.
>
>While AXD 301 consists of programs written in C, C++ and Java as
>well as Erlang, and each language is used where it fits best,
>practically all the complex work is done in Erlang. This is usually
>decided by the designers themselves -- many of our most skilled C
>programmers prefer Erlang for complex tasks, and consider it the
>obvious choice for anything that involves concurrency or
>distribution. [/quote]

Like I said, I don't want to invest the time. C/C++ does everything I
need and I can make up for typical source code problems using
discipline, meticulousness, and making sure the code is carefully
crafted instead of being slapped together. Any benefits gained by
spending time learning a new language seem to be minimal compared to
the time wasted not programming in a language I am intimately
familiar with.

>My own programming experience includes substantial work in the
>conventional languages Fortran, Modula-2, and C++, as well as
>Haskell and a few other functional languages. It's fair to say that
>functional programming requires a very different mind-set, but once
>you've made the "jump", programming in conventional languages feels
>like doing arithmetic in Roman numerals.
>
>Why do conventional languages persist in the face of demonstrably
>superior alternatives? Some say that functional languages are hard
>to learn, but the Ericsson retrospective says otherwise:
>
>[quote] Finally, we have seen that programmers -- even those with no
>previous exposure to functional languages -- learn Erlang quickly,
>and become productive within a matter of weeks. [/quote]
>
>A more substantial obstacle is that even "a matter of weeks"
>constitutes a substantial investment, either for an individual or
>for a group, especially when project deadlines are pressing. Another
>is that without organizational support, many programmers are
>naturally loath to forsake their hard-won expertise in conventional
>programming for a fresh start in an unfamiliar --and to them
>unproven-- technology.

There is no way in hell I believe this. It may take 2-3 weeks to
learn a language, but it will take at least 2-3 entire projects to
master it and if I want perfect code then I want to use a language
that I have mastery of. Like I said, 1-2 years' investment just isn't
worth it for me.

Mike wrote:

> In 14 years of writing commerical software I've never needed anything
> other than C/C++. I just don't see the need for all this other stuff.

C has been a throwback to the Middle Age for the entire software
industry. Almost every time you need to install a security patch from
Apple or Microsoft it's because of the lack of appropriate security
features in C and its descendants. Missing basic features like proper
bounds checking (which makes exploits possible) and strong typing in the
core language is a kind of criminal negligence which in other industries
what have lead to massive lawsuits. The only excuse for its users was
the lack of memory and processor speed in the 70s plus the availability
  of C compilers. But in the 80s other, compared to C relatively safe,
languages like Pascal were also widespread. It's an unfortunate accident
of history that C has become the dominant language.

Another point: C and C++ are way too low level languages to take
advantage of today's hardware. It's smarter to spend development time
making the application fullfil its business requirements and to create a
userfriendly interface. Current Java and .NET virtual machines make it
possible to run modern languages much faster than C/C++ programs because
  they include much more knowledge about current hardware and can make
more assumptions about the software which runs on it, i.e. on-the-fly
optimization due to it's monitoring of the usage.

People touting C look the same to me as doctors not having updated their
  knowledge for 20 years.

Mike wrote:

> I could care less about HaskeLL. I wouldn't spend time learning any
> of these junk langauges if I had to. I'd change professions first
> because as soon as I invested time in learning them, everyone would
> decide they were obsolete and ask me to learn 3 new ones next month.

It's not about learning a specific language, it's about the concepts and
ideas they represent. Learning a different language widens your
horizon.

> Now I'm suddenly supposed to learn 3 new ones a year.

Not "now". It has always been this way.

On 06 Sep 2006, at 14:47 , Mike wrote:
> At 10:16 AM -0700 9/5/06, Tony Meyer wrote:
> Java never delivered on its promise of "Write once, run anywhere"

Oh, I think it did. It was Microsoft that bastardized Java, not
Sun. I've had plenty of java apps written "for" linux that I've run
on my Mac without any issue.

> As for the others, like I said. Learning curve. I have yet to see
> any of them deliver any benefits that I don't get in C/C++. And
> interpreted scripting languages are slow compared to compiled
> binaries. Plus there is always the chance someone will hack your
> script, or the inumberable versions of the Perl interpreter or
> Python, or whatever will be out of date and then your script won't
> run. Compiled binaries suffer none of these problems.

Well, I know python can be compiled, and I'm fairly certain perl can
be as well. Don't know about php or ruby, but I wouldn't be at all
surprised. All of these can be used within Xcode<1>, alongside Obj-C
and Applescript.

> In 14 years of writing commerical software I've never needed
> anything other than C/C++. I just don't see the need for all this
> other stuff.

Well, I'd much rather talk to a mysql data base and a web page using
php, myself. I wouldn't dream of trying it in C/C++

<1> Depending on just how badly you want to

--
Why live in the world when you can live in your head?

On Sep 6, 2006, at 4:47 PM, Mike wrote:
>> It's clear that you haven't worked on the kind of projects that I've
>> worked on which have required bringing together many different tools
>> and languages to accomplish diverse tasks.
>
> I hear this a lot too. The end result in my experience is usually a
> cobbled together product that uses too many technologies and thus is
> subject to breaking in the future. Not to mention that scripting
> languages are slow at runtime because they are interpreted. As for
> what "the right kind of project" is. I pray that I never have to work
> on such a project where I need to string together 20 different junk
> technologies to make it work. Does the name Rube Goldberg ring a bell?

Absolutely! Every project can be done with one simple program, I'm
sure. It's the best way to approach a project where you have tens of
megabytes of structured text which needs to be broken down into
dozens of component parts, have many of those component parts sorted,
cross-indexed, and related to a half dozen outside databases before
being brought back together into a compressed form and combined with
the cross-compiled code that will retrieve it on a dedicated
platform. The people who designed UNIX with pipes and generic
utilities that could address separate parts of such a job must have
been dreaming when they thought it made more sense breaking such a
job into manageable pieces and automating those related tasks using
shell scripts and makefiles. [End sarcasm]

I have brought many commercial projects to completion using such a
complex approach. I, too, hope you never have to work on such a
complex project, because you clearly don't have the aptitude for it.
It requires serious programming skill, not just the ability to learn
one or two programming languages which you are then afraid to stray
away from. The sad thing is that you don't know the difference.

As for scripting being slow, *of course* it's slow. That's why one
generally only uses it for either a wrapper for a program which is
widely distributed, or for a task which is rarely run, such as in a
build system, or a data preparation system.

There are different rules one must learn to practice good programming
hygiene when scripting as compared with writing C or C++ code. If
one isn't really aware of how to use the scripting tools, it is easy
to write disastrous scripts, but well written scripts are valuable
tools. Of course treating your tools with the attitude that they're
junk predisposes you to misusing them, since you start out with the
bias that they aren't worth learning to use correctly. So please,
stick to your C/C++.

Geoff
.

On or about 9/6/06 1:47 PM, thus spake "Mike" <listsmichael-amorose.com>:

> Claiming that new programming languages haven't improved upon older languages
> is wrong.

Actually I'm not sure that anything in a programming language can be "new"
any more (unless we somehow progress beyond the line-by-line text-based
programming that has dominated since compilers were invented). What a new
programming language can do is steal effectively and eclecticly from other
languages. One of the things I like most about Ruby is that it steals all my
favorite features from all the other languages I know. It's as if the author
of the language had been asking himself, "What lessons can we learn from our
experience with these other languages? What was good about them, and what
was bad about them?" - and had gotten the right answer in every case.

> Thinking that new programming languages can magically turn bad
> programmers into good ones is just as wrong.

But to deny that a programming language has a character is just as wrong
too. Certain programming languages do lend themselves to, and encourage, a
certain style of programming, and if that's a style that you like and are
productive in, you'll feel such a language to be attractive, and rightly so.
Similarly, it is possible that I might find a language you like to be
downright repulsive (and from the evidence so far, I do). m.

--
matt neuburg, phd = matttidbits.com, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide - Second Edition!
http://www.amazon.com/gp/product/0596102119
Take Control of Word 2004, Tiger, and more -
http://www.takecontrolbooks.com/tiger-customizing.html
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/

In the midst of Mike's rants are some really valuable words: "the
importance of meticulousness and solid structure in programs." They
fit very well with something I've often said about myself: God gave
me a proofreader's eye for detail and a generalist's eye for the big
picture, and I depend equally on both when working with a computer.
To put it another way, if you don't have the self discipline to get
all of the details exactly right, you can't possibly build a
structure that's both solid enough to hold up under the pressure of
thousands of users hammering on it and flexible enough to be revised
easily as those users' needs change.

At the same time, I have to disagree with Mike's prescription for a
single-language working environment. Obviously it has been a Good
Thing for him, and I'm sure it works well for some other people, too.
But to borrow mathematical terminology, it's adequate but not
sufficient. Let me explain with a story.

I was fortunate, many years ago, to be introduced to computers via
the FORTRAN language. I say "fortunate" because learning that
language taught me to apply the rules of logic to the construction of
problem-solving algorithms (procedures) that could be "understood" by
a computer, but at a high level which didn't require me to understand
the details of the computer's operation. The already-available
libraries of mathematical subroutines likewise contributed to viewing
the process at a high level.

Having learned FORTRAN, I was then taught SPS (a form of assembler)
and machine language, in order to appreciate how the steps of a
FORTRAN program were actually carried out, and what the capabilities
and limitations of the underlying hardware were. Immediately I
recognized that while assembler language was critically important for
writing things like FORTRAN compilers and various "utility" programs
(there wasn't yet such a thing as an "operating system"), high-level
languages like FORTRAN offered the best opportunities for real
productivity. (If I'd been in the business world rather than the
scientific world, I might have adopted COBOL instead.)

This view was reinforced in my first full-time paid job. For part of
the time, I was using Univac's FORTRAN V ("five") to write lots of
applications that used meteorological data. (FV had such a good
compiler that even the best assembler programmer could only optimize
its output by 2 percent or so. Many of Univac's nifty extensions to
the then-standard FORTRAN IV language were later incorporated into
the international standard FORTRAN 77.) The rest of the time, I was
helping to design and build (in assembler language) the first
real-time operating system to provide the foundation for collecting,
processing and distributing military weather information in a 24/7
operation. Clearly this was a situation of "use the right tool for
the job."

After many years of other jobs and other languages (or variations), I
was hired into my last and best job on the basis of my knowledge of
an excellent but undeservedly obscure language named REXX. However,
after starting work, I discovered that only about 5 percent of the
existing code which I had to maintain was in REXX, with the remainder
being in a dialect of a mainframe language that I'd only encountered
once before, and never really used. Not a problem! Years earlier,
I'd adopted the slogan, "The day I stop learning is the day I start
dying, and I'm not ready for that yet." I dived into the available
documentation, and within two weeks was making significant
improvements to that code base. A couple of years later, I wrote a
long comparative analysis of these two languages. Both of them were
used for scripting a mainframe tool named AF/Operator (which was my
responsibility), and I showed how each had both strong and weak
points, so that neither could do the entire job well. The software
supplier liked this analysis so well that it was published as an
article in the company news magazine for customers of that product!

Sometimes the requirements of a job allow it to be accomplished with
a single tool. More often, a job requires the use of multiple tools,
each of which is best at certain tasks. Much as I admire the person
who can use one tool with great skill, I have more admiration for the
person who carries a well-stocked toolbox and knows just which tool
to use for each task.

Carl Scott Zimmerman
csz_stl swbell.net

On Sep 7, 2006, at 3:22 PM, Geoffrey Odhner wrote:

> I have brought many commercial projects to completion using such a
> complex approach. I, too, hope you never have to work on such a
> complex project, because you clearly don't have the aptitude for it.
> It requires serious programming skill, not just the ability to learn
> one or two programming languages which you are then afraid to stray
> away from. The sad thing is that you don't know the difference.

Paul Graham (I think) uses an argument that runs something like this.

First, we have to accept that some languages are more powerful or
more expressive than others -- not that they can make the computer do
anything that the other language can't, but that they allow
programmers to get work done more efficiently. For instance, file
handling in Perl has fewer fiddly bits than file handling in C, which
in turn has fewer fiddly bits than file handling in assembly: not
that you can't get fine-grained access, but that the higher-level
languages are built so that routine tasks are very simple to perform.

Now, he uses the example of Blub, a hypothetical language which has
more expressive power than some languages but less expressive power
than others. Someone who's familiar with Blub can look at less
powerful languages and conclude that they're less powerful, because
they're missing some feature that Blub has; but when he looks at more
powerful languages, they don't seem more powerful, they just seem
weird. (Consider a BASIC programmer trying to deal with recursive
subroutines, or a C programmer trying to deal with object orientation
and polymorphism, or lexical closures.) Until the programmer becomes
familiar with those languages and understands the features, he can't
see the point of them.

Our vocabulary of concepts and techniques is limited by our language.

> As for scripting being slow, *of course* it's slow. That's why one
> generally only uses it for either a wrapper for a program which is
> widely distributed, or for a task which is rarely run, such as in a
> build system, or a data preparation system.

And the dichotomy between "scripting" and "compiled" language is
mostly illusory anyway, and is an implementation detail. Perl, for
instance, (and I think Python and Ruby as well) is compiled to
bytecode at run-time and then the compiled version is executed. If
you're building a large system in Perl, there are a few simple ways
to make it persistent.

There's also a substantial tradeoff in developer time: I use Perl
for a lot of the things I used C for before I used Perl, because Perl
makes a lot of things easier than C. I don't need to worry about
memory management anymore, or array bounds checking; this comes at a
cost of some performance, but it's a worthwhile trade -- at the rate
I bill for consulting, a memory leak bug or two will buy you a new
Mac mini.

Charlton



--
Charlton Wilbur
cwilburchromatico.net

On 7.9.2006, space aliens observed lists573 saying:
>I never studied formal CS nor design patterns. This is another theory
>of the week.

I think the discussion about lazyness versus hard languages won't lead
anywhere (I'm sure Joel Spolsky, who designed Excel Basic amongst other
things, is happy to know that you think he's a "below-average
programmer"), but I just want to point out that design patterns are
everything *but* "another theory of the week."

Books on design patterns have appeared since the late 80s - basically,
they started appearing when C++ and object orientation became more
wide-spread. A design pattern is "a general repeatable solution to a
commonly-occurring problem in software design," as defined by wikipedia
[1]. You should check it out sometime. It might help you avoid searching
solutions to problems which smarter minds have already solved :-)

[1]<http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29>

One more thing: I don't really understand how you can advocate
"simplicity" and "beauty" and then claim that "C/C++ are the perfect
programming languages." There is no "perfect programming language," and
if there were, it wouldn't look like C++. Different languages are suited
for different problems. Not every problem is best solved in C/C++. There
are even quite a lot of problems which can't be solved using C/C++ at
all (try writing an application which can be downloaded from a server
and run in a browser :-).

I once attended a lecture held by Bjarne Stroustrup (the "inventor" of
C++). I don't really know what the subject of the lecture was, but it
turns out Stroustrup had searched the Internet for problems which
supposedly weren't solvable in C++. He then proceded to explain to us
how to solve these supposedly unsolvable problems in C++. I learned
something during that lecture, but it wasn't what Stroustrup intended:
If you try to create a language which solves every problem and supports
every esoteric programming practise, you end up with a language which
can't really solve *anything* all too well :-)

The most beautiful solution to a problem uses the language which fits
*the* problem, not the language which fits *all* problems.


>Theories have no place in real-world practical programming
>I wouldn't spend time learning any of these junk langauges if I had to

Are you serious? Programming is *based* on theories. And aren't you at
least a bit curious about programming languages other than C and C++?
Don't you think that learning, say, Ruby might even teach you a thing or
two about programming in C?

lucas

It does seem that I ignited a firestorm, albeit with a lot of help. Some
things have not changed in the past 35 years, and arguments over PLs are
among those.

In the late 1970s I attended a POPL conference at which David Parnas took
part in a panel discussion. As part of that, he presented a 2-page paper on
his new programming language BLOWHARD. (I still have the paper copy
somewhere, and it has apparently been printed in his collected works, but I
can't find the actual paper online.) BLOWHARD had no core features -- just
a null statement I think -- and everything else was done via extensions. Of
course, at that time extensibility was the fad.

I keep hearing "you can write bad code in any language". It's true, but
it's not the whole truth. David Shayer wrote:

>"You can write Fortran programs in any language."

but Charlton Wilbur wrote:

>Our vocabulary of concepts and techniques is limited by our language.

which is perhaps more to the point. Or as Edsgar Dijkstra famously put it,

"The tools we use have a profound (and devious!) influence on our thinking
habits, and, therefore, on our thinking abilities."

(http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html, which
contains plenty to both inspire and offend anyone in the programming biz.)

Of course Dijkstra's comment, as with so much that he wrote, applies far
beyond the sphere in which it was written. If you read it quickly and
haven't seen it before, I recommending pondering it a bit before proceeding.

I have to comment additionally on David Shayer's remark above. The
implication -- that use of the language in question implies bad code -- is
a fair criticism of FORTRAN (the standards up to 1978), but is not a fair
criticism of Fortran (the 1990 standard and beyond, and the language David
referenced). One of the ironies is that as Fortran (previously FORTRAN)
evolved into a good programming language, it was gradually forgotten
(though it's still used in some important application areas). This is
perhaps the best example arguing that infatuation with the new, in
preference to fixing the old, has been at least a major sidetracking force
in PL evolution.

In any case, it doesn't really matter how good the programming languages
AVAILABLE are. What matters most to most programmers is the strength of the
programming languages he or she actually encounters in everyday work.
Studies 30+ years ago showed that on the average, code is read ten times. I
don't know of any later studies, but I have no reason to believe that the
ratio has changed. This implies that on the average, a programmer is vastly
more affected by OTHERS' choices of PLs than his/her own choice. This
implication is due not only to the direct (a programmer spends time reading
other programmers' code) but also the indirect (programmers interact, and
so are not fully independent when it comes to promulgating new ideas, or
even old ideas).

Plus, concepts in programming are very much a social phenomenon. If the
languages used for 90%+ of the code being written lack a given concept,
then that concept just won't gain traction in the programming community.
Dominance does matter even in the conceptual realm. As Hamilton Richards wrote:

>So far, however, functional programming has been even less successful in
>the marketplace than our beloved Macintosh

and until FP gets a conceptual hold, it doesn't stand a chance of any
realistic large scale trial.

Finally, just to comment on a common misconception in an otherwise
excellent posting: Nils Kassube wrote:

>Missing basic features like proper bounds checking [...] The only excuse
>for its [omission] was the lack of memory and processor speed in the 70s

The only problem with this viewpoint is that the Burroughs B6700, from
around 1970, did have bounds checking which prevented the kinds of exploits
we see rampant today -- and it didn't suffer in speed. The key is not raw
speed but CPU design: in particular ISA design which allows the bounds
checking to proceed in parallel with other computation. PL developers in
the 1970s were in this sense restricted not by CPU speed but by the fact
that they were designing languages to run on a CPU which had been designed
with no input from software designers. And 35 years later, the dominant ISA
design has achieved its status because -- all together now -- everybody was
using it, so everybody else used it too.

Edward
Art works by Melynda Reid: http://paleo.org

> Try telling a musician or painter to crank out one work of art
> after another on a fixed schedule.

Try telling a musician to only use an acoustic piano, because that is
the perfect keyboard and anything that came after it is just
"fluff" (No Rhodes? No Wurly? No Moog? No way!!) Try telling a
painter to only use a simple brush, because that is the perfect
painter's tool and any other "color application method" that came
after it is just "fluff." Try telling an electronics engineer to keep
using tubes, because that is the perfect electronics component and
anything that came after it (transistors, microprocessors, ASICs,
FPAs...) is just "fluff."

These limitations won't stop artists or engineers from producing
_some_thing, but the results will be far, _very_ far, from what would
be possible if you'd provide them the freedom to choose the tools
themselves. And that also applies to programming languages.


> Learning curve. I have yet to see any of them deliver any benefits
> that I don't get in C/C++.

The learning curve of a language is an interesting aspect, indeed.

Let's assume someone wants to build a pre-press automation workflow.
AppleScript is a great language for this: it's easy to learn, has
little coding overhead (despite being on the verbose end of things),
is rather beginner-friendly by not requiring a compilation cycle to
see the results of the program, and it is amazingly powerful for
hooking up several apps into one workflow. Should a coder learn the
ins-n-outs of constructors, destructors, pointers, etc. just because
C/C++ is presumably "the" perfect language, or wouldn't sticking with
AppleScript be the smarter choice?

Thing is: learning curve is not about having to learn a new language
everytime one is published; it's about learning the most appropriate
language for your needs in the first place.


> People who cannot focus on a task for more than 4 hours are
> mentally lazy and undisciplined. I have been writing code 12 hours
> a day since 1993.

Come on, 'fess up: it's you Bill! Now that you're dropping out from
Microsoft, you're bored like hell and trolling on a Mac-related
mailing list is just the thing to help you get through a long day,
right?! ;-D

Seriously, though, Your remark reminds me of uni professors who
lecture for 1.5 hours straight. Never mind that research has
conclusively shown that, on average, the ability to concentrate drops
significantly after about 45..50 minutes of knowledge work.
"Professors didn't put in any breaks in _my_ time, so why should I?!"

Finally, it's interesting to note that, as a software _engineer_, you
don't seem to differentiate between quantity and quality. Why bother
with how many hours a programmer actually spends on writing code each
day, if the resulting software product is finished on time (assuming
a _reasonable_ project schedule, that is) and is of high quality?

Oh, one more thing: you may find Tom DeMarco's book "Slack" quite an
interesting read...


GreetinX,

Jochen.


--
A Polytrope's Musings <http://www.polytropia.com/musings>
Polytropic Flickr Pix <http://www.flickr.com/photos/polytropia>
Thoughts on Macintosh <http://www.oreillynet.com/pub/au/2663>

OK, I guess I'm stuck with chiming in in this thread.

My all-time favorite language was Prograph. The one program I still
run in Classic was written by me in Prograph, in the pre-PowerPC
days. It has come forward until sometime in the relatively near
future, when I'll no longer have a way to run Classic (the G4 it runs
on here goes back to 2001). (My published articles were about
Prograph, as it happens.)

I only run that program after a rain (it is a rainfall recorder).
(There were incarnations of it in Pascal using MacApp, in Forth, and
in Smalltalk along the way, but each was short lived--the Pascal/
MacApp variant was the shortest lived: I never got its user interface
done, but inserted new data using AppleScript.) The incarnations had
one thing in common: they all were taught to import and export the
data as plain text (comma-separated-values) files.

I wrote in Comit (a text processing system created at MIT about the
same time as LISP). There are very good reasons why LISP survived
and Comit did not. I'm likely the only person on the list who has
run Comit programs hands-on on an IBM 704. ;-) (I also believe I'm
the only person on the list who has refereed a basketball game with
Vannevar Bush as partner.) (I very much doubt that "our" game is
mentioned in the Wikipedia article below; it was an MIT faculty-
student game. Van worked the mid court--I covered the two endlines:
I was in better shape then than now.)

<http://en.wikipedia.org/wiki/Vannevar_Bush>

   --John ("Van" is not name-dropping: Dr. Bush was "Van" to
everyone, faculty and student alike, by the time I met him)

On Fri, 8 Sep 2006, Edward Reid wrote:

> [...] but Charlton Wilbur wrote:
>
> > Our vocabulary of concepts and techniques is limited by our
> > language.
>
> which is perhaps more to the point. Or as Edsgar Dijkstra famously put
> it,
>
> "The tools we use have a profound (and devious!) influence on our
> thinking habits, and, therefore, on our thinking abilities."
>
> (http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html,
> which contains plenty to both inspire and offend anyone in the
> programming biz.)

It isn't exactly a new idea. Squint at these comments just so and you
end up with the Sapir-Whorf hypothesis:

    In linguistics, the Sapir-Whorf hypothesis (SWH) states that there
    is a systematic relationship between the grammatical categories of
    the language a person speaks and how that person both understands
    the world and behaves in it.

http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis

It's true in linguistics, it's true in programming, heck it's even true
among musicians: the more ways you learn how to express yourself (in
languages, instruments, etc), the more expressive you can be.

This idea that C is the only language any programmer needs is utter
nonsense, on the same level of thinking as "all them furriners should
just speak English."

The Wikipedia article is also worth reading, if only for quotes such as:

    The position that language anchors thought (thinking is shabdanA or
    'languaging') was argued cogently by Bhartrihari (6th c.AD) and was
    the subject of centuries of debate in the Indian linguistic
    tradition. Related notions in the West, such as the axiom that
    language has controlling effects upon thought, can be traced to
    Wilhelm von Humboldt's essay "Uber das vergleichende Sprachstudium"
    (On the comparative study of languages), and the notion has been
    largely assimilated into Western thought. Karl Kerenyi began his
    1976 English language translation of Dionysus with this passage:

      "The interdependence of thought and speech makes it clear that
      languages are not so much a means of expressing truth that has
      already been established, but are a means of discovering truth
      that was previously unknown. Their diversity is a diversity not
      of sounds and signs but of ways of looking at the world."

Et cetera.


--
Chris Devers

On 09 Sep 2006, at 13:23 , Chris Devers wrote:
> In linguistics, the Sapir-Whorf hypothesis (SWH) states that there
> is a systematic relationship between the grammatical categories of
> the language a person speaks and how that person both understands
> the world and behaves in it.

I like how George Orwell put in in his novel 1984:

"It was intended that when Newspeak had been adopted once and for all
and Oldspeak forgotten, a heretical thought...should be literally
unthinkable, at least so far as thought is dependent on words."

--
I want to get hurt!

I'm not even a programmer (beyond hobby-level dabbling), but I had to laugh at parts of this page.

"...there's no end to the crap people are churning out... programmers think they can be the next Bill Gates by inventing the next programming language."

First, a message to any programmer who's churning out crap and wants to be the next Bill Gates:

Well done!

Next:

"What a total waste of time. They could be inventing ... products people want instead."

Last I looked, the software market is flooded with more products – great ones included – than you and I can use in a lifetime. A dozen lifetimes. Programmers aren't creating software products? That's the most bizarre statement I've ever heard from a "programmer".

And from someone else, lists573:

"In Japan standard work weeks are 80 hours, not 40 - for everyone. American programmers have become totally lazy and sloppy."

Where did that nonsense come from? In Japan – my home – work weeks are 40 hours. Plenty of variety in that, sure, but statistics show pretty similar annual worker hours for Americans and Japanese. If you want to find someone working 80 hours a week, your best bet is to first talk to programmers in American IT startups. (But don't be surprised to hear a reply of "Only 80 hours? I wish...")

Then again: American, Japanese, East Minestronean... Programming is performed by individuals. What the heck do passports have to do with this anyway?

(My first post on TidBITS. Back to real commentators – )

My views overlap with Mike's (list573) in two areas. First, programmer discipline is often overlooked as a professional requirement. It is however a crucial trait that programmers need to maintain intellectual control over what they are doing. Second, a huge number of programming languages as well as technical tools are being produced quickly. Industry often favors the adoption of young and hyped up technologies, and fails to recognize the value of seasoned expertise. Expertise which can only come from a tool that professionals have had time to master.

However, I strongly disagree with his inclusion of Haskell in this list of "crap" as he calls it. I am certainly not trying to sell Haskell, or claim that he needs to use something besides C/C++ if that is what he is comfortable using. Hamilton Richards already made a case for Haskell's adoption, but I want to focus on his more subtle point. The ability to produce a language like Haskell took decades of research. This effort was not trivial, and did not come from a fad.

This has been a long standing effort. It is a contribution by some great minds. Statements referring to this work as "junk" or as a "language-of-the-week" are negative and obtuse. Further to suggest its invention was in the interest of being "the next Bill Gates" isn't credible. I have never heard of a programmer becoming rich solely because they contributed to Haskell.

I hope that Mike (list573), even though he made some valid statements, will recant his views regarding this remarkable contribution.