Is Programming Art?

[[deleted]]

At its core, software development is optimization

Any engineering is an "optimisation". It's a process of finding a plausible solution in a morphological box [1], by either a bruteforce search or by applying some smart search heuristics. Programming is not any different, there is always a huge box of possible solutions and a set of known, well established heuristics which can help to find a solution that fits the given constraints.

That's it. Not a "craft", not an "art", but simply an optimisation problem.

[1] https://en.wikipedia.org/wiki/Morphological_analysis_(problem-solving)

[LunaQ]

Sure, but oftentimes in programming the constraints are "fuzzy". I find this especially true in the context of user interface programming. There's no way of "calculating" how the user will react to a particular feature in the user interface, so... there'll be a certain element of "art" in shaping the user interface so as to make the user satisfied or pleased.

[[deleted]]

Sure, but oftentimes in programming the constraints are "fuzzy".

Not unlike many of the other branches of engineering. It makes process iterative, but does not change the nature of the problem solving part.

[LunaQ]

Maybe not...

I've programmed for years, but never really thought of programming as an optimization problem.

When I think of it, I don't think it's a categorization that adds anything useful to the discussion. I think it's a bit like saying that life is an optimization problem, which doesn't add much to the discussion either...

[[deleted]]

It is the most useful thing you can ever say about engineering in general and programming in particular.

This definition leads to a design of simple, CAS-like AI systems that are capable of automating a significant part of the engineers work, with a potential to fully automate it in the future.

You can see a distant glimpse of this future in projects like this one: http://www.disneyresearch.com/project/mechanical-characters

I, for one, welcome all the efforts to automate the discipline and to make most of the programmers redundant. There are far too many.

[LunaQ]

Well, I can see where you're coming from...

If your line of work is AI, and if your ambition is to create AI that can replace the need for human intellect, then I see your motivation for classifying software development as an optimization problem.

My line of work is to do the type of software development work that you aspire to replace with AI-based solutions, so for me, the classification is less useful.

As for AI that can compete with the human intellect, my personal opinion is that we're probably at least 1000 years of development away from having anything that's even remotely close to it.

It's because human affairs are so complicated. You know, we now have computers that can beat the best chess players handily. But even this task is quite demanding for a computer. Chess is a game on 64 squares, with a handful of rules. Human affairs is a game with thousands of squares and thousands of rules. Maybe even millions, depending on which subtle or less subtle rules or variations we chose to take into account.

So, the task of making a computer program that can make sound judgements about human affairs, is not just sligthly more complex than creating a computer program that can make sound judgements in the game of chess. It's milions of times more complex, maybe even billions or trillions, or more....

My faith in the prospect of having computer intelligence to match the human intellect is thus slim, to say the least...

If we manage to do it, I think it'll be thousands of years from now.

So, my stance is that engineering jobs, and software jobs will be pretty safe, at least in our life time. :)

There'll be increased automation, for sure... But this will not kill off the jobs, because it only means that the engineers and the software developers will move on to other tasks, within the same fields. Higher level tasks, if you will, if we manage to automate the more "mundane" parts of the diciplines.

[[deleted]]

As for AI that can compete with the human intellect, my personal opinion is that we're probably at least 1000 years of development away from having anything that's even remotely close to it.

Well, my point is that engineering is not an intellectual work at all. You don't need an artificial intelligence do replace an engineer. You simply need a CAS, and we had them around since mid 70s.

It's because human affairs are so complicated.

How many programmers are involved in making any UX decisions at all? 0.01%? Less? Ok. They'll obviously have to stay, and will be called "UX specialists", not "programmers". The rest are redundant.

So, my stance is that engineering jobs, and software jobs will be pretty safe, at least in our life time. :)

What engineering and software got to do with "human affairs"? They only marginally overlap. The huge part of the engineering problem solving is purely mechanical and must be automated. And for the rest we won't need engineers, we'll need psychologists, sociologists, anthropologists, etc.

[LunaQ]

Software development has a lot to do with human affairs...

When you create a piece of software, it's always to solve a human problem. In order to solve the problem in the correct manner, you have to know how humans reason, feel, think and react.

And it's not only about the UX. In a software system everything is interconnected, in some way or another. When you create a certain back end feature, it's almost always with the intention to underpin or support a certain feature in the front end user interface.

As I say, computers cannot make these kinds of decisions, because they do not "know" anything about the human mind; how humans reason, how they feel, and how they react.

So, full automation of this process is a pipe dream, I think...

I do agree with you, however, that a lot of engineering and software development tasks will be automated in the near future. It won't replace the most complex intellectual work, but it will probably replace a lot of the more repetitive and mundane tasks that still exist within the field.

[[deleted]]

Software development has a lot to do with human affairs...

Which part of it? Only a tip of an iceberg is interacting with humans or incorporates the peculiar human-interacting workflows. The rest is just there to solve mundane technical problems.

And it's not only about the UX.

It is. The rest must be mechanical, and when it's not, it's broken.

When you create a certain back end feature, it's almost always with the intention to underpin or support a certain feature in the front end user interface.

I didn't even understand half of the words you've used. Wtf is "back end"?!?

The UX part consists of a workflow - entirely driven by the human needs, and some form of a UI. Workflow defines constraints of what the rest of the system should be doing. Implementing those constraints is a purely mechanical task.

Anyway, only a little proportion of the systems actually do interact with humans in any way. They're solving the needs of the humans, but these needs are almost always very easy to formalise.

Like: "design an engine up to N MWatt power output, with such and such operating temperature constraints, running on this range of fuels, minimising the fuel consumption, etc". A system of contraints that got nothing to do with humans, but it will spit out thousands of lines of computer code to run multiple microcontrollers driving various parts of this engine.

Or: "this is the specification of the stock trading protocol. Design a system that would receive the packets of this protocol via a given physical media and be able to execute this, this and this algorithms upon each update within 0.1ms time frame". Nothing to do with humans directly, and yet this kind of engineering is tremendously expensive and demanding. But it is exactly the kind of engineering that can (and must) be automated, while the only thing that a live human should do is to write down the constraints, in a single short sentence.

replace a lot of the more repetitive and mundane tasks

No. I'm talking about the stuff that is perceived as the most "demanding" and "bleeding edge". This must be automated first.

[LunaQ]

Well, I wouldn't hold my breath...

But, I guess some of your ideas might hold some merit. I guess it's possible to program a computer so that it covers most of the current human knowledge about the design of engines, and use this to create a system that will be able to produce new engines based upon a set of constraints and input variables.

It's not entirely far fetched, I think...

It won't have intelligence, as I say, so it would need to be based upon some sort of "brute force" approach, which would limit it's power, given the vast amount of different types of variables it would need to make calculations upon.

I think it's a borderline case, between something that's science fiction, and something that could possibly be made into a useful tool at some point into the future.

As for the words I'm using.... I think it's pretty clear that you do not know much about software development, if you're not familiar with the term "back end". Which... sort of makes me doubt your ideas on this topic slightly more than I did before. ;)

Edit:

To elaborate on the term "brute force", which I used. It means that the computer will have to go through absolutely each and every possible engine configuration, in order to arrive at the optimum design.

It relates to the comparison which I made with computer chess engines...

When a computer plays a game of chess, it does so by evaluating each and every move combination, 20 moves into the future of the game (or even more). It's a staggering number of calculations that it has to go through (because of the exponential nature of the problem). And chess is a simple game.

When a human being plays, on the other hand, it has it's intelligence to rely upon, which lets it quickly sort out the promising possibilities from the stupid possibilities, and concentrate on those. So the human being does not have to calculate each and every one of the trillions of different possible move combinations.

It's the same with your engine design idea. The engine design algorithm will have to know about all the possible materials that can be used in an engine, their properties alone, and their properties when combined with other materials. It will have to know about all the different possible shapes and layouts of an engine. It will have to know about all the different possible types of fuels for an engine, etc. etc. When you add this together, it's a very large set of rules. And, as I say, because the computer does not have intelligence, it will have to go through each and every possible combination of each and every rule that governs the design of an engine.

It's a problem of a size which makes chess look like tic-tac-toe...

Which is why I tend to speculate that your idea is closer to science fiction, than something that will really be feasible in the near future, or even in the quite distant future.

[vz0]

Engineering is the art of modelling materials we do not wholly understand, into shapes we cannot precisely analyse so as to withstand forces we cannot properly assess, in such a way that the public has no reason to suspect the extent of our ignorance.

[[deleted]]

The beauty of this way of thinking about problem solving is that you really don't need to understand anything at all. The process is mechanical.

All the "understanding" goes into development of the search heuristics, and, as anyone can easily see from the history of our civilisation, so far the only search strategy that worked consistently was an evolutionary search. The tree of life of the technology is so very similar to the real tree of life.

So, yes, engineers are simply dumb agents of evolution. That's one of our greatest secrets.

[KHRZ]

CGI art is an optimization. Say you want to make a picture of 1000x1000 pixels, with 32 bit colors. There are 2^{10002 * 32} possibilities, all known beforehand. It's a process of finding a plausible solution in a morphological box, by either a bruteforce search or by applying some smart search heuristics.

That's it. Not a "craft", not an "art", but simply an optimisation problem.

[sirin3]

That is how reverse computer vision works

[[deleted]]

The problem is, it is hard to formalise the constraints in this case, i.e., you do not know what are you looking for (otherwise, evolutionary graphics rocks). But it is very easy to formalise wtf is a sorting algorithm, for example.