A lot of programming is an end in itself.
The programming I do for work is not. It needs to meet deadlines, and match expectations.
But I have dozens of projects sitting around that exist just for the sake of existing, or for some goal that is more about "because I think it'd be aesthetically pleasing" than because it's practical. Many people do. Sometimes it is an exploration of code for the sake of code. Sometimes it is an exploration of the effects of code.
Some of them might become practical one day. Then they'll cease to be as fun as they are now. I just spent most of the night wrangling a garbage collector for my ahead-of-time Ruby compiler for example - first time I've been able to spend serious time on it for a couple of years. The entire project is very much "because I can" and "because it pleases me" than for practical reasons; I make choices I wouldn't make if I needed to get something working within constraints. I make choices that actively cause more effort.
But conversely a lot of practical code has a feeling of art as well, in that there is the straight-forward way of doing it, the way everyone is used to, and then there is that way of doing it that blows your mind by showing possibilities you had not even imagined. Examples of that to me would be TCCBOOT [0]. The story of TCC itself is art to me - the original obfuscated version was 2048 byes of source. But to then take that, and turn it into something very little more and make it compile an OS during boot was not a practical goal, and not driven by utility - it was a mindbending demonstration of the possibility of producing a compiler that could compile a kernel from source and be competitive with loading a pre-compiled binary, and the beauty of what you can achieve with that simplicity. Nobody uses it. That's not the point.
The point is a lot of who saw it went on to think differently about how dynamic systems can be.
Massalin's Synthesis kernel [10] stands out to me as another example that for me crosses the boundaries and is both outstanding engineering and art in challenging the ideas of how systems could be built in ways that make me look at it just as much because of the beauty of it as because of the practical ideas. (The main thing it brought was the idea of making the kernel adapt to its clients by generating custom code for system calls; to me it is art because it turned the idea of a kernel as something static on its head; and conceptually we're still just scraping the very surface of dynamic code generation in kernels that Massalin's thesis started playing with). There are many works like that, where the specific implementations are irrelevant - nobody uses the Synthesis kernel - but where the ideas are as important as any expressed in more overt or "intentional" art.
> Furthermore, there are clearly-defined constraints: you cannot smith an axe and call it a sword, just as you cannot write a web scraper and call it a raytracing engine.
You might just find someone do that just to spite you. Just like someone wrote a paper on translating images of paint splatters into Perl [1] for the sake of it.
In fact someone has been there, done that, already, sort of [2] - not ray-tracing, but an art installation that downloaded random 3d models with a scraper and combined them.
Specific tasks and projects have constraints. Outside of that people make what they want, often for no particular reason, or for reasons that in retrospect look totally idiotic.
> Art does not have this limitation. Art does not have this limitation. In any art medium, you can imagine creating a horribly mangled artifact, like a canvas smeared with random colors, or a piece of discordant music, or a violently disorienting video game -- and yet these would still be considered art. But a program full of syntax errors is like a cracked sword without a hilt: useless. Art cannot be useless.
Software is full of horribly mangled artefacts that are considered valuable for the sake of it. The IOCCC [3] is a prime example, but so many projects I admire are projects that have all kinds of fatal or less fatal flaws but have something about them that is more art than craft. The entire history of esoteric languages [4] for example is about communicating ideas rather than making something useful. Sometimes they are mocking other languages - like INTERCAL, with it's wordy syntax drawing parallels to COBOL and FORTRAN, and it's reverse goto (come from) making regular goto's seem trivial - sometimes they are an exploration of minimalism, like Brainfuck, sometimes they are an exploration of what is possible - in Befunge control flow changes the direction source code is read in.
Whole categories of software has more to do with the aesthetics or other textual aspects of the program than utility - quines, obfuscated programs and golfing springs to mind.
Often the crossover is very direct: Whole genres of art are intimately tied with programming: Chiptunes are both closely tied to the hardware of the platforms they originated from, but many subsets are also intrinsically linked to a history where musical scores where expressed using custom players where musicians where often also the person to code the player. Rob Hubbard [5] is a famous example of a musician whose music was expressed as code (it was driven by data, but most of his C64 tracks are data for a single, specific iteration of his player code, so having "score" is insufficient; the score is incomplete without the code).
Many of his tracks stand out not just because of the musical qualities, but because they represented code as art. E.g. the Monthy on the Run theme [6] was renowned because of the technical challenge of getting that close to sounds of a string instrument on something as crazily basic as the C64 SID chip. I like the tune, but the masterpiece of art in that work is figuring out how to do that with patterns as simple as this: [7]. Another classic example would be his music for International Karate [8] which is a track I still love that is less impressive in terms of code (because the track demands less), but that still demonstrates an impressive mastery off both.
From the same era we also see graphics expressed as code to a greater and greater extent: The exploration of computational graphics became more and more important, but also the exploitation of the capabilities of the available systems to make graphics that was linked intimately to code. E.g. the various "FLI" modes on the C64 [9], or even just plain demos, where the code was part of the artwork: the systems could not display the art without the co-mingled code.
[0] https://bellard.org/tcc/tccboot.html and https://bellard.org/otcc/
[1] https://www.reddit.com/r/programming/comments/b9fqwj/93_of_p...
[2] http://www.customarttools.com/blog/2016/2/26/fmdelivery
[3] https://ioccc.org/
[4] https://esolangs.org/wiki/Esoteric_programming_language
[5] https://www.c64-wiki.com/wiki/Rob_Hubbard
[6] https://www.youtube.com/watch?v=4EcgruWlXnQ
[7] https://www.youtube.com/watch?v=YIA_0cvS2gQ
[8] https://www.youtube.com/watch?v=dvmSpZWW45k
[9]http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm
[10] http://www.scs.stanford.edu/nyu/04fa/sched/readings/synthesi...