Hacker News Reader

Comment by igouy | Hacker News Reader

Perhaps "to serve the creative spirit" of the coder is not what most software development should be about?

Literally almost every piece of consumer facing software is created using languages or frameworks that derive from Smalltalk-esque principles (OOP, MVP, IDEs, etc...).

And the creative spirit is what brings innovation. Tons of what's obvious now wasn't obvious when someone created it.

Xerox PARC has certainly been influential: "The Alto software included four different programming environments: BCPL, Mesa, Smalltalk, and Lisp."

https://computerhistory.org/blog/xerox-alto-source-code/

https://computerhistory.org/blog/the-deep-history-of-your-ap...

"Even if you’re designing for professional programmers, in the end your programming language is basically a user-interface design. You will get much better results regardless of what you’re trying to do if you think of it as a user-interface design." -Alan Kay

https://www.doc.ic.ac.uk/~susan/475/AlanKay.html

Let's take that to be true, as-before — Perhaps "to serve the creative spirit" of the coder is not what most software development should be about.

Perhaps most software development should be about effectiveness or reliability or …

In the words of Christopher Alexander, the programmer is the true inhabiter of the program. Since we can expect the world in which the program should function will change, so should the program.

It is the programmer that has to figure out, often with experiments, what changes to the program work best.

Therefore it makes no sense to me to focus on anything but serving the programmer.

The better the experience is for the programmer, the more users will say "y'know what? This doesn't quite do what I want, I wonder how I change that" and presto, they're a programmer now.

We would never have had Hypercard if it weren't for Smalltalk and Alan Kay, and we've never had a platform as good as Hypercard since. That's a crying shame.

Who does the programmer "serve" ?

Perhaps we need to get rid of this artificial distinction between users and programmers.

Precisely. Every barrier in place between using a system and programming it serves to elevate the decisions of its designers over those of its users. The greatest power of computers is their ability to be reshaped to meet whatever need the user has, but we mostly lock that power away from them.

There's a subsection of people who are very well served by that. And it has already been happening. SQL, Python, HTML/CSS/JS are all things that people use who are not primarily programmers. Applications like Unity, Excel, some Adobe stuff also blur the line here.

But let's not forget that there are a ton of people (many more than the above) who are constantly overwhelmed by computers even though they only use very few features. There's people who can't use ATMs and smartphones. Most computer users only ever use the most common applications (browsers, music/video players etc).

Perhaps users want to use apps without needing to program apps?

Perhaps some want to play in a garden without needing to dig and plant and weed and…

I think you shouldn't need to program if you don't want to understand the problem domain.

Do you think someone should need to program if they want to understand the problem domain?

Speaking for myself, I’ve never found a better way to understand something new.

Perhaps a way to understand abstract categories.

> Multics Emacs proved to be a great success—programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

~ https://www.gnu.org/gnu/rms-lisp.html

think i've seen the term 'operator' used in this context?

I sort of get where this comes from: the product should serve the users. But thinking of dev tools as the product for devs (the users in this context) is useful.

Devs code better products if they enjoy using the tools.

> Devs code better products if they enjoy using the tools.

Is there any evidence for that claim?

A guitar's design shouldn't be at least enjoyable enough to make the guitarist a better player?

I don't think we've been talking about guitars.

Only if you missed the part that this technology tries to capture "the spirit" of the creative side of the coder which is an universal, hence my analogy with making "the coder feel like a rockstar".

I asked "Is there any evidence for" the claim that "Devs code better products if they enjoy using the tools."

So far nothing has been offered.

Absolutely! Software development is all about making money, and I think this in general is at odds with creativity (different goals, methods, practices, whatnot). However, I also think that there is large group of people who does not code for money, but to make art, have fun, or express themself, and "to serve the creative spirit" is exactly what they need.

Software development is also about making things work for other people.

I agree that "most software development" is not about serving the creative spirit of the coder, but it'd be a shame to lose that! And if in some way we could have our cake and eat it (i.e. enjoy the creative process of coding for most software) sounds like a win-win to me! Idealistic, but one can dream ;)

Isn't software a form of literacy? Why should not be about? I'm not understanding yet your line of reasoning.

Reply on news.ycombinator.com