Weblogs Forum - Are Programmers People? And If So, What to Do About It?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Are Programmers People? And If So, What to Do About It?

44 replies on 3 pages. Most recent reply: Aug 9, 2006 12:53 AM by Vincent O'Sullivan

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 44 replies on 3 pages [ « | 1 2 3 ]

Ken Arnold

Posts: 27
Nickname: arnold
Registered: Apr, 2003

Re: Are Programmers People? And If So, What to Do About It?

Posted: Apr 17, 2003 7:34 AM

> I think you are missing an important human factor, but I
> don't think I can express what it is clearly.

I hate it when that happens. Maybe my response can help you express it in reaction.

> The thing that makes me think you're missing one (or
> perhaps more than one) is that I can clearly and
> successfully apply all six of your human factors to coding
> for a Turing machine.

If I were forced to actually code to a Turning Machine, I would be unhappy largely because the level of expression is very far below my level of abstraction. One of the human factors rules (one that Apple has taken most seriously) is that you should give the user the tools to directly manipulate what they want to manipulate. So you grab the file that you want to move and drop it in the folder you want it to live in. Very little at the Turing Machine instruction level is at the level I want to manipulate to solve my problems.

Ken

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Are Programmers People? And If So, What to Do About It?

Posted: Apr 17, 2003 5:34 PM

> (Whoops! Forgot to do a Preview and mismatched my
> formatting tags. I've been petitioning Bill for a
> "delete my last post" feature, to no avail.)
>
Measure twice. Cut once.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Are Programmers People? And If So, What to Do About It?

Posted: Apr 17, 2003 6:57 PM

Tell me about it, Mr. Spam King. ;-)

Not my real name

Posts: 2
Nickname: zamphir
Registered: Apr, 2003

Re: Are Programmers People? And If So, What to Do About It?

Posted: Apr 19, 2003 10:10 AM

If I were forced to actually code to a Turning Machine, I would be unhappy largely because the level of expression is very far below my level of abstraction.

Well, obviously, forcing someone to use a particular language (with the clear implication that 'forcing' means 'against their will') is going to cause them to be unhappy, regardless of whether or not the language is well suited for the tasks at hand.

One of the human factors rules (one that Apple has taken most seriously) is that you should give the user the tools to directly manipulate what they want to manipulate.

This seems to imply 'more than one way to do it'. Why should I have to use the '+' sign to indicate string concatenation? Or set union? These are similar things, aren't they? So they should be done similarly? Or does using different characters to represent the same operation count as 'similarly'?

Even more importantly, should I really have to master more than one programming language in order to solve problems in more than one problem-set? Should I have to use Scheme if I want to work with problems that are best expressed functionally, and Java if I want to solve problems that are best expressed with objects? If the answer to that is no, then again, 'more than one way to do it'.

So you grab the file that you want to move and drop it in the folder you want it to live in.
And now I want to move the file to an FTP server, or send it to someone by email, or pass it to a process for manipulation. Drag and drop can definately (and has been) extended to cover these concepts, but where does it start to break down? Are these things really the same, or different problem sets? Do they need different sets of tools? I think it depends on who you ask, and whether it's really me (cause I know a lot about FTP and Email, and they're really different) that's trying to move the file, or if it's you or my wife or my mother or anyone else. Which again seems to lead to 'more than one way to do it'.

Very little at the Turing Machine instruction level is at the level I want to manipulate to solve my problems.
I agree. But the Turing Machine instruction set has exactly one way to do things, there are no dangerous operations, everything is explicit, the default behavior is always the right thing to do, and etc... So, for working at that level of abstraction, it's a successful language by your criteria.

You haven't made a point about working at the right level to solve the problem at hand, I think.

Almost all (to hedge my bets) modern languages are designed around a certain philosophy and set of design principles of some kind or another. One of the tenets of the Java design was 'make it easy for C programmers to learn', as I understand it. This lead to keeping the fall through behavior of the case statement. One of the tenets of the Perl philosophy has always been 'More than one way to do it'. This leads to diverse dialects of what counts as the same 'language'.

This set of philosophys and design principles is what you're really discussing. You want to encourage language designers to include human factors into the picture. But I think human factors are a lot more situational and cultural than you are portraying them as. Also, I think that human factors were a consideration in almost all modern language designs. Not all of the ones you're advocating, and sometimes ones you disagree with.

I hope this is as coherent as it seems to be right now.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Are Programmers People? And If So, What to Do About It?

Posted: Apr 20, 2003 7:43 AM

> Tell me about it, Mr. Spam King. ;-)

Good point. (For those who don't know what Matt is talking about, I accidentally sent out false unsubscribe messages to subscribers of my newsletter last week.)

I noticed one of the other mailman commands has like a preview option, where it will tell you what it would do if you execute the command (minus the preview argument), but not do it. remove_members doesn't have that preview option. Seems like a nice option, but even if it had it, I might not have used it.

David Govoni

Posts: 2
Nickname: davidg
Registered: Apr, 2003

Re: Are Programmers People? And If So, What to Do About It?

Posted: Apr 29, 2003 11:39 AM

> <p>I first started to think about this when writing a
> paper on C++. In the first (and only) draft, I declared
> that a programming language is a user interface to the
> language's abstract programming model. I was surprised to
> discover that this view was not common, although it was
> easy to sell. It was easy to sell because most people

What about 'smaller' and less popular languages that force you to think with the abstract programming model.

I'm getting deeper into the Zen of Forth. After a while thinking in Forth (not just stacks, but in the mode of the Forth machine underneath) makes wonderful sense. I'm using the tool (Forth) with an understanding of its abstraction (the model implemented underneath) and I can extend it at will.

Also I would go farther and say it isn't just programming lanugages that implement an abstract model that, when understood, makes it more powerful. Most applications and tools fit in this mode.

When I teach an application I try and explain what the app will do and what the user has to do to help it (and vice versa). Understanding the model really does help.

Steve Holden

Posts: 42
Nickname: holdenweb
Registered: Apr, 2003

Re: Are Programmers People? And If So, What to Do About It?

Posted: Apr 30, 2003 5:53 AM

I'm getting deeper into the Zen of Forth. Is it possible, do you think, that you have developed a set of mental analogies (homomorphisms) that allow you to perceive certain problem-domain situations in terms of analogical *implementation language* structures? That's what a good development model can do. As you later point out, it's the extensibility wot does it.

Since you mention Zen, let's analogise the language as a hammer and the problem as a nail. I suspect that your increasing familiarity of Forth, and possibly your increasing perception of your existing code base as a vocabulary, is simply allowing you to perceive the nailness of all things, or (if you're lucky) simply all things problem-related.

I'm using the tool ...with an understanding of its abstraction ... and I can extend it at will is good when the tool is extensible, or at least flexible enough to build extensible structures. Ultimately though some people just never get the "extensibility" thing at all and just continue to write simple repetitive programs that make them happy.

Being more of a carpenter than a construction engineer myself, I might observe that the most satisfying projects are the ones that flower slowly but without stress, improving their descriptive power slowly. The most important feature of "best practice" development technologies over the years has been the emphasis on decoupling the programming task from management stress, and avoiding having rabid dot-commers screaming in your face because they want to be RICH in twenty seconds and it's YOUR FAULT the SOFTWARE isn't READY. Sorry, I have these flashbacks now and again.

Facility with language is one way to reduce programming stress, appropriate choice of language for the problem domain being another. (Many) people are unwilling to let their essential humanity enter a debate like this to the extent of ignoring even the most obvious truths. Such as: for any small problem, it's easier to use a language you already know. Therefore, unless a language is *really* easy to learn, the opportunity cost of using it requires a significant new problem, and no amount of evangelism is going to persuade PHP programmers to learn Perl so they can write their ten-line scripts as six-line scripts. This doesn't stop flamewars erupting between proponents of "competing" languages. One more thing: don't try thinking in Forth (or any other programming language) to describe the humanities, either: some tasks just aren't programmable.

I'm sorry, but the whole premise of this topic is banal in the extreme. If "programmers are people" is a "radical notion", gimme a break. I'd rather be coding the cryptography algorithm for the doors to the dungeons of hell than stuck in a world where the existence and utility of people was any kind of "radical notion".

David Govoni

Posts: 2
Nickname: davidg
Registered: Apr, 2003

Finding the language

Posted: Apr 30, 2003 9:09 AM

Is it possible, do you think, that you have developed a set of mental analogies (homomorphisms) that allow you to perceive certain problem-domain situations in terms of analogical "implementation language" structures?

Well.. there's 2 parts to the answer.

First, have I developed a set of mental analogies? Yes. But not just from Forth. I've developed them from every programming language I've used and tried to wrap my mind around. I don't look at problems as Forth problems or C problems or Pascal problems. I try to look at them as problems that have to be abstracted onto the computer and then look for the most suitable mental analogy (and approach) from my repetoire.

Not that I'm always good at picking the best or most efficient. I usually end up picking the one that's the simplest for me to understand and implement. I just try to have a larger array of techniques at my disposal than one language might limit me to. (Not everything is a string, but in M or REXX it makes somethings really simple).

Secondly, Forth is one of the few languages where, once I get comfortable with it, I haven't found an analogy I couldn't implement. Do I want an ordered data store ala M? No problem. Do I want simple basic structures ala Pascal? No problem. Do I want OOP with a certain style? Not a problem. Do you want to treat all your data as tables ala xBase? Go ahead.

I suspect that your increasing familiarity of Forth, and possibly your increasing perception of your existing code base as a vocabulary, is simply allowing you to perceive the nailness of all things...

Funny you should use that word... vocabulary. Unlike so many other languages where you apply the language to your task Forth is different. In most languages you apply the vocabulary to the task and piece together the steps into a document. Programming may be the technical equivalent of writing literature in a given language. (Literate programming aside).

In Forth commands are words. They are kept in lists or vocabularies. You decide what words you need to solve the problem (or a subset of the problem) and you create the words.

You then use those newly created words to build the next higher abstraction... and repeat until you get to your goal. The application.

The hardest part is that building the lower words means 'doing Forth'. Working with the stack and working with fundementals. But very quickly you are into the domain (and vocabulary) of the problem and not Forth.

I thought finding names for variables was tricky but finding the right names for my Forth words makes all the difference in building the higher levels of the application.

To get back to the Zen of it. Its not just the nailness. Not only in Forth but in all the languages it helps to see the 'nailness' and the 'hammerisms' and blend the two together to make one vocabulary. Build a language and a problem that use the same descriptive names and the solution may just drop out of the blue.

That's why programmers try and reword the problem to match the vocabulary their language gives them. Most languages don't make it easy to also change the language to match the problem.

Cees de Groot

Posts: 16
Nickname: cdegroot
Registered: May, 2003

Re: Are Programmers People? And If So, What to Do About It?

Posted: May 10, 2003 4:59 AM

You're mostly right, but as a Smalltalk programmer I have to disagree on two points:

1. Smalltalk has a strange syntax. Well, from where I stand, Java has a strange syntax. And Chinese as well.

2. Smalltalk's demise is due to its strange syntax. That's absolutely untrue - Smalltalk's demise is due to the arrogance and bad dealings of the Smalltalk vendors in the '80s. Now the dust has settled, and Smalltalk's use seems to be on the rise again.

As far as human factors go, Smalltalk was created with exactly that in mind - namely as a user interface to the programming language's model for kids. Alan Kay basically holds the position that if kids can't use it, it is useless for grown-ups. If kids *can* use it, it might still be useless for grown-ups, because kids easier cross 'paradigm chasms' than adults (reword 'move 1 forward; turn 5 degrees left' from a logo-like environment into differential equations).

I think that an in-depth analysis of your human-factors checklist will show that Smalltalk and some of the languages it helped inspire (Python and probably even more so Ruby) fare quite well.

On the other hand, I think it's about time we leave the concept that code must be expressible in plain ASCII and editable with vi or Emacs. A rich, GUI based interface to the programming language model (which these days would probably be expressed as some object structure marshallable in XML) beyond Javadoc and syntax highlighting will help more than inventing yet more ASCII-based languages. Again, Smalltalk leads the way - code is usually represented as live objects, and 'filing out' to ASCII leaves something useful for version control, but not for Emacs editing. However, the 'method body' is still pure ASCII, but voices are rising to leave that as well (so you can add all sort of hyperlinks, cross-references, fontifying, etcetera).

Ken Arnold

Posts: 27
Nickname: arnold
Registered: Apr, 2003

Re: Are Programmers People? And If So, What to Do About It?

Posted: May 12, 2003 8:21 AM

Howdy, Cees -- hope things are going well.

I suppose we could argue this around till the cows come home (I don't have any, but maybe you do -- otherwise it will be a long talk).

In my experience, there were two standard complaints I heard from people who tried to switch (or get others to switch) from C++ to Smalltalk: the speed and the syntax. The speed issue is really just How Things Were, and no longer really an issue in most cases. But the syntax certainly was off-putting. You will find, I believe, that almost every procedural language still left standing has an Algol-derived syntax. Whether this is appeals to an inbred human tendency or simply to what people have come to expect is rather irrelevant: Try putting the hot water tap on the right-hand side of the faucet sometime, or using a screw that turns the other way, and you will discover the power of expectations.

(Okay, "procedural": To some, "procedural" is an intrinsically anti-OO term, but to me, OO languages are all about associating the right combination of procedure and state in order to process a message. So "procedural" is the term I use to contrast the family of Algol, Ada, C, C++, Smalltalk, Basic, Pascal, Java, Perl, C, sh, FORTRAN, etc., with list-based languages, functional languages, visual languages, stack languages, query languages, etc. If you know a better term, tell me, but that's what I mean here. All these terms are necessarily loose, but I hope you get what I mean.)

Consider


[i < 10]
   whileTrue: [Transcript show: i printString.  i := i + 1]

The syntax is clearly consistent -- everything is a message sent to the thing that precedes it ("[i < 10]" is a block that is sent the "whileTrue:" message), but it is sort of head-twistingly backwards from the expected "while (i < 10) ...", even though this syntax works just fine for "Transcript show: ..." (IMHO, anyway). Why do people expect "while ..."? I don't think that's very relevant here, my experience is that this is unnatural and offputting.

My strongest exposure to this was when the GOF patterns book came out, which had C++ and Smalltalk in it. The number of people around me who were puzzling out the Smalltalk and being explicitly unhappy about it was pretty high.

Stroustroup got this one right: C was very popular and widespread, and he ran with it. To say Smalltalk got this "wrong" would be rather unfair, as it predated the clarity of this market positioning effect, but it certainly ended up on the wrong side of this line.

Python is largely Algol-like, in fact, C-like. I haven't used Ruby at all, and I don't know what its "market share" is, so I don't know how relevant it is to the point.

Now, how much this has to do with the demise (such as it is) of Smalltalk is a matter of opinion. I just have this programmer-centric view that if programmers had fallen in love with Smalltalk, someone would have satisfied that demand, as has happened with any number of other languages with bad vendor histories (FORTRAN, Lisp, C++ -- hell, even Java has been provided by multiple vendors.) Programmers can write compilers and interpreters, so they would have written their own (as they have) and people would have used those ones instead of the maddened vendors'. That this did not happen seems like fairly strong evidence that it was something else in the way, at least in addition to that problem. Speed was certainly one of those things, but my opinion was that the oddness of the syntax to the mass of programmers was major factor.

And too bad. There is a lot to like in Smalltalk.

As for text vs. non-text languages, I will be more convinced when I see one that is a significant improvement over text-based ones. Clearly for some tasks, graphical interfaces are better, but for flow control especially I have yet to see a graphical-based editing system that was not visually inefficient and unscalable. Maybe I just gave up looking after living with a few and deciding that there was an intrinsic mismatch beyond the small scale, so maybe you'll point me at something worth looking at. It would be a nice surprise.

Carl Manaster

Posts: 24
Nickname: cmanaster
Registered: Jun, 2003

Re: Are Programmers People? And If So, What to Do About It?

Posted: Jun 3, 2003 8:33 AM

A nice notion, and a nice post. Steven Pemberton, creator of ABC, one of Python's precursors, has a related article at

http://www.acm.org/sigchi/bulletin/1997.3/views.html

Mike Sanford

Posts: 1
Nickname: unixpgmr
Registered: Aug, 2006

Re: Are Programmers People? And If So, What to Do About It?

Posted: Aug 6, 2006 11:12 AM

First of all, let me say that I agree with most of Ken's points. However, I take exception to his use of C++ as language of choice to make his points. I have been in the industry for some 16 years. I have done application programming, API design, and kernel development. I mention this so that you will know where I am coming from.

Since C++ retains all of C's syntax, we need to look at C first to understand some of Ken's issue with C++ and why I have issues with Ken's use of C++ in his examples.

The original intention of C was as a systems language. As such, C is well designed for its job. With the right compiler, it produces very small and fast code - as it should. It allows the experienced programmer to advantage of its design to make good use of resources. C violates most of Ken's human factors because items like garbage collection have a tendency to hinder efficient operation of code in a sytems's evironment. Operating Systems require tight coding and exceptional execution speed and garbage collection would hinder that requirement.

Also, we need to look at the history of C's development. C was never intended to become a wide spread langauge. So comparing C to a language that was designed to be wide spread is unfair. Why C became so popular as an application language, I am not sure. It really should never be used as an application language for most of the reasons that Ken states. C++ is no better. C++ is just a morphing of C to include some principles of object oriented programming. In my opinion, it should have never been done since object oriented design is clearly an application design method. Like I said before, C is a systems language and most system developers will tell you that while object oriented programming is great, it does not belong at the systems level.

I understand Ken's desire to use C++ because it is so populular. However, I think examples from other languages would have emphasized the points more clearly.

All in all, a good article on the issues that language designers need to take into consideration. However, when looking at a language for possible use, remember: All languages have their purposes and no one language serves all purposes. Should a language be chosen that is not suited for the intended purpose of the program, it is not the language's fault.

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: Are Programmers People? And If So, What to Do About It?

Posted: Aug 7, 2006 2:48 AM

I don't agree with #4 ("Dangerous things should be impossible, or where necessary, clearly labeled as dangerous."). Dangerous things should be possible! If you make everything that could be dangerous impossible, you get Java. Is redefining a method at runtime dangerous? Is eval() dangerous? If you make these things impossible you're assuming that programmers are stupid. I think that everything that's possible should be possible. A program should be able to rewrite its own code if that's possible (and if this doesn't make other things harder to do). A language designer shouldn't be afraid and think that programmers will abuse this feature. Someone might need it, and others can ignore it.

Continuations for example. They confusing, but very helpful for web applications. Inner classes: why can't you modify outer variables?

Java assumes that I'm stupid. Therefore I choose another language.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Are Programmers People? And If So, What to Do About It?

Posted: Aug 8, 2006 7:24 AM

> > <p>I first started to think about this when writing a
> > paper on C++. In the first (and only) draft, I declared
> > that a programming language is a user interface to the
> > language's abstract programming model. I was surprised
> to
> > discover that this view was not common, although it was
> > easy to sell. It was easy to sell because most people
>
> What about 'smaller' and less popular languages that force
> you to think with the abstract programming model.
>
> I'm getting deeper into the Zen of Forth. After a while
> thinking in Forth (not just stacks, but in the mode of the
> Forth machine underneath) makes wonderful sense. I'm using
> the tool (Forth) with an understanding of its abstraction
> (the model implemented underneath) and I can extend it at
> will.
>
> Also I would go farther and say it isn't just programming
> lanugages that implement an abstract model that, when
> understood, makes it more powerful. Most applications and
> tools fit in this mode.

I want to emphasize that the “user interface” is only half of the picture. The other half is the semantics or internal model of how the language operates. My guess is that languages with a consistent internal model like Forth, Scheme or even a Turing machine should be easier to understand than many of the mainstream languages. Unfortunately they work on a too low of abstraction level to be really useful for other than low-level programs or basic algorithms. But if a good and complete user interface (read API) could be build on top of those models we should have a language that is really “user friendly”.

I particularly found the two papers at this page thought provoking:
http://www.cs.mdx.ac.uk/research/PhDArea/saeed/

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Are Programmers People? And If So, What to Do About It?

Posted: Aug 9, 2006 12:53 AM

> Java assumes that I'm stupid. Therefore I choose another
> language.

Choosing a language based its supposed macho qualities is (at best) curious.

Java doesn't assume that you're stupid, it assumes that it's worth studying the mistakes commonly made by C and C++ programmers, learning from those mistakes and incorporating them into the language in such a way as to make them history. Time spent avoiding common and preventable pitfalls is time wasted when those pitfalls need not even exist.

Yes, there is a case to be made in language design, that in eliminating the worst problems you also eliminate the best opportunities. But in practice (in my opinion) better final applications are the result if only because the two sides of the equation don't balance out. A stunningly fast, succinct, recherché piece of code with an obscure memory leak doesn't equate to a piece of ploddingly average code that delivers.

Flat View: This topic has 44 replies on 3 pages [ « | 1 2 3 ]

Previous Topic

Next Topic