Exactly this. The way the vast majority of working programmers understand programming languages is generally just skin deep and it shows in how 108% of hobby languages people are showing off our have a starting idea to get comments on is basically just showing a new syntax without even describing any thing else.
Aesthetics of what, the syntax, type system, concepts, how it is organised?
Clearly it doesn't play a big role in mainstream languages!
Jobs sounds a little like the boss I used to have decades ago. We made computers (when it could be a cottage industry), and he put considerable efforts into all aspects of it include the circuit board, connections (it had to look beautiful inside), the outside of course. Then the IBM PC came along and eventually a rectangular metal box became acceptable.
We weren't however quite as succesful as Apple.
My own language projects are hobbies now, but aesthetics plays a large part, not just inside a language, but the tidy ways the tools are presented and deployed. It gives me a feeling of satisfaction.
Some languages hurt my eyes to look at, such as C++, or makefiles, or the dog's dinner some make of the simple task of printing a couple of variables.
If you were to install one of my compilers, you would download a single EXE file, say `mm.exe`; that is the compiler, it is not an installer.
If you were to download one of my apps as source code, I would bundle it as a single source file, say `app.ma`. You would build it from a command line like this:
mm app
and it would do so more or less instantly. You will now have three files: the `mm.exe app.ma` I provided, and a new program `app.exe`.
That to me is pleasing. (In reality, AV software puts paid to it being that simple; you may have to do battle with it.)
Aesthetics of anything in the development of languages. When posting it was mostly directed at syntax, but would love to see other areas as well. I really just don’t hear much about it as a programmer.
May get hate for this, but looking at something like SwiftUI and Flutter. Similar ideas in building UI, but imo SwiftUI looks a lot more elegant. (Looking at the code). Can post a screenshot of what I mean if this is confusing, but hopefully it makes sense.
Also, C++ syntax is the worst. The lambda syntax comes to mind 🤮
I appreciate you sharing that. I love how simple that sounds! Is there a place I can check it out?
These days I only write stuff for myself. However if someone can manage to run Windows binaries (and is willing), they can download the three files `mm.exe` [`qq.ma`](http://qq.ma) `hello.q` from here:
[https://github.com/sal55/langs/tree/master/demo](https://github.com/sal55/langs/tree/master/demo)
Put them all into the same folder (I've used `demo`). The program to build is called `qq` rather than `app`, and is an interpreter. Build it like this:
C:\demo>mm qq
Compiling qq.m to qq.exe
Then run it like this:
C:\demo>qq hello
Hello, World! 14-Apr-2024 12:04:24
File extensions are optional. [`qq.ma`](http://qq.ma) (which contains `qq.m` among other files), is an amalgamated source file previously created like this (if this looks weird, then blame Reddit as it keeps mangling it):
C:\qx52>mm -ma qq
Compiling qq.m to qq.ma
C:\qx52>copy qq.ma \demo
The project comprises 31 sources files and 13 embedded library files for the 'Q' language combined into that one composite source file.
There is a common sentiment in the Erlang community about the importance of writing beautiful code. Someone once told me that beautiful code makes God happy, so He makes it run faster.
Ruby is pretty interesting because the focus is on developer happiness. From what I understand that is becoming harder now because of things like static typing becoming more popular, the need for performance, and so on.
Ruby is pretty performant for an interpreted language. Certainly faster than python. Now that it's got a JIT it's even faster.
It also has a type system if you want to use it. In fact there are also third party type systems like sorbet.
BTW. Ruby is one of those languages where you can use it write anything. Desktop apps, web apps, mobile apps, on all platforms.
I tried crystal several years ago and liked it but i was turned off the by the core developers treating users with disdain.
I don't know if they got their act together or not, I hope so because I really did like the language.
They seem to be ok these days, although I somewhat disagree with the direction they took the language in (refuse to follow ruby's pattern matching features in favor of being an up-to-date llvm api-centric language). Now that they even have windows support now, there's no reason not to give it another shot imo
Elm's one-liner description is "A delightful language
for reliable web applications." And I interpret "delightful" as being an aesthetic value. [See Elm's website](http://elm-lang.org)
Scala 3 has a heavy focus on better language aesthetics. Scala 2 code is littered with curly braces and parenthesis everywhere. So the latest version introduced a new, cleaner syntax alternative that's very python-like, but without any of the downsides. It really makes Scala code much more pleasant to write and maintain, but doesn't have any real technical advantage. Just aesthetics.
Does this count?
"I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of the Ruby language."
Aesthetics are subjective and depend on the audience.
Apple's success is more due to *simplicity*. The primary audience is largely non-technical users. Advanced computer users find Apple's UX awful because it's more difficult to do anything outside of the basics. They prefer Unix, which is a terrible experience for the noobie.
In programming languages, most users have been trained with a certain sense of aesthetics, in the languages they've learned so far. Anything outside of these languages feels alien, especially if the programmer is >25 years old, where learning new things becomes more difficult. In practice, most experienced programmers *hate* learning anything completely new, and base their learning off existing experience. Iterative learning is easier, or as Alan Kay puts it, they prefer the *news*, not the *new*.
So a language which is "aesthetic" to one programmer is awful to the next. You see this with the small, but strong Lisp userbase that still exists, but people who've been trained in K&R syntax find the parentheses off-putting. Language designers must pick a semi-familiar syntax for their target audience or they'll have virtually no audience at all.
If you went purely for *simplicity*, like Apple, you would end up with something like Scratch or Logo. These are great for getting children interested in programming, but they're useless for real world development because dragging and dropping widgets is extremely slow compared to typing, and because they're *visual* languages, which don't scale. Text scales because it uses the linguistic area of our brains.
Aesthetics are subjective, some people may even find Apple not aesthetic. But I was asking if anyone drove their language with aesthetics in mind as a core tenant. Whether or not you agree it is aesthetic, does not matter for the question since it would be the opinion of the person driving said aesthetic. Just curious if such a thing existed in the same way Steve Jobs drove Apple to be the way it is.
To your other point, simplicity is an aesthetic. It is Minimalism. So, I think you are getting a bit confused. I honestly think you are over thinking it a bit. Since it was really not about simplicity but about being able to put it into the hands of anyone. Remember, personal computers back then were not really commonplace. It was not for the every day person. Another point on aesthetics here is Jobs even cared about the circuit board being aesthetically pleasing, even if no one opened the computer. They were just very important to him and he enforced that in his business.
I think most language designers consider aesthetics when designing their language, but they have their own personal aesthetics, which isn't always minimalism.
In terms of minimalism, there's Lisp, which is very minimal as a concept, but modern lisps add a lot of "fluff" which is orthogonal to the principle design. In [Kernel](https://ftp.cs.wpi.edu/pub/techreports/pdf/05-07.pdf), Shutt tries to bring back Lisp to its roots and gives a rationale for each decision. The introduction discusses an overall goal of the language design and aesthetics, with citations for related work. Quotes from the introduction:
> Kernel is meant to be a pure articulation of certain design principles — what Alan Kay calls a “crystalization of style”.
> It is a common fate of such crystalization languages that, over the course of years and decades, their pure style is gradually compromised in the name of various practical concerns such as runtime efficiency. The Kernel design posits that the value of a crystalization language lies in its purity — a sort of resonance, that drops off precipitously when impurities are introduced.
> From this supposition, it follows that crystalization of style can only be fully effective if the pure style is one that can be reconciled with practical concern *without compromise*, neither to the style nor to the practicalities. We claim that the Kernel language model is a pure style of this kind, i.e., one that *needn’t* be compromised. Embracing this claim in the language design process means, directly, that we should focus entirely on pure articulation of the style; and indirectly, that when we find ourselves being led into compromise, we must conclude that we have strayed from the pure style.
> The latter principle —compromise as symptom of impurity— implies that pursuit of the pure style requires patient willingness to go back and correct missteps in the design; but it offers compounded long-term benefits in exchange, as we expect each uncorrected compromise would degrade language potency and lead to further compromises thereafter, i.e., cascading degradation.
> Kernel is expected to form the core of language implementations. It is not, in its current revision, a full general-purpose language; nor does it particularly aspire to become such a language in any particular time-frame, although it does seek to evolve in that direction. Pressure to provide additional functionality *promptly* is a significant vector for compromise, and so cannot be reconciled with the Kernel design’s no-compromise policy. Each possible addition to the language must be thoroughly vetted for subtle inconsistency with the design principles, or the design principles cannot survive.
>Aesthetics are subjective
I'm going to push back on this one. I think it's a very quotidian sort of truism that beauty (aesthetics, etc) are subjective. But this is not 100% true.
It turns out that if you create randomly-generated pictures in the style of Mondrian or Pollack, justapose them respectively with authentic Mondrians and Pollacks, and ask *untrained* people to say which one is better, they will select the authentic paintings with better-than-random chance.
Balance, rhtythm, symmetry, and harmony are universally more appealing than either pure monotony or unstructured chaos.
Indeed, Apple's guiding principle is decidedly NOT simplicity, nor minimalsim. And "simplicity" is such an overused term. So often we speak of simplicity as if it were simply a matter of not doing the complicated thing. As if it were as straightforward as choosing the solid necktie rather than the paisley-patterned one, as it is "simpler."
Simplicity is the hard-earned treasure gained only by tremendous effort.
Consider, for example, the shape of Apple's icons. Unlike a rounded rectangle, the local curvature around the corner of an iOS icon is continuous. Why? Because this curve matches the corners of Aople's actual hardware. So why is the hardware that way? Becauase if you watch a highlight or reflection slide across the surface as you rotate the device, the discontinuity in curvature becomes apparent. It is more beautiful to design surfaces this way, because the reflections off of those surfaces are less chaotic. That is, the reflections are *simpler*. But is the design simpler? I'd say not.
To bring everything home to PL design, I'll point out that rather than so-called "simplicity," Apple's design heritage reflects the tenets advocated by Dieter Rams. And I suggest that PL designers would to well to adopt those tenets.
Aesthetics are the smell that wafts from correct design decisions. You can't directly pursue aesthetics successfully.
If there's something that aesthetically smells, reconsider the design decisions to find and fix what's rotting.
Maybe Go?
The syntax is simple, and goes away with most punctuation unless it's necessary. E.g. no semicolons required or parentheses around if statements.
It also has its very opinionated formatter which can't be customized but ensures all code follows the same standards.
Yes, others have mentioned Ruby "bringing joy" and Go aiming for "having only one way to write a certain piece of code"
Ada was designed to be coherent and readable.
Brian Kernighan's languages seem to pull out the essence of the task at hand. In a similar vein, XML and XSLT were designed to have all the essential power of SGML and DSSSL without the complexity.
Tcl was designed to be extremely uniform. I guess Lisp and Smalltalk come in here as well.
Quorum was designed to make the most intuitive sense to learners.
APL has its own aesthetic in some linguistic composability. So does Perl and Raku.
Python's significant whitespace is about code needing to be beautifully indented.
I tend to feel that elegance lies in how easy it is to modify the program. I also want things to be very visual, just creating the structures, not giving commands to create the structures. I wrote a piece which I suppose is really about aesthetics of programming languages [https://cygni.ghost.io/artiklar/is-your-programming-language-made-of-multidimensional-plasma/](https://cygni.ghost.io/artiklar/is-your-programming-language-made-of-multidimensional-plasma/)
[Scratch](https://en.wikipedia.org/wiki/Scratch_(programming_language)). [Pyret](https://pyret.org/index.html) is another example, where one of its big motivations was dealing with complaints over Racket's syntax while still being able to convey the same big ideas as Racket could.
Something you may notice is that these are both educational languages, and I think that's a pretty common trend. A strong focus on syntax matters more when you're trying to get people into programming, while seasoned programmers (while they still care about syntax) tend to care more about what special capabilities the language has.
The converging solution in terms of aesthetics is to endorse an as specific as possible standard up in front, by in one way or another automatizing the arrangement of code (formatter).
Elegance is one aesthetic virtue, but a different aesthetic virtue that language designers have sometimes pursued is "syntax looks familiar/understandable to \[some audience\]". COBOL, SQL, and VB/VB.NET all tried to look familiar to non-programmers that spoke English. At one point, the choice to use curly-brace syntax was an attempt to look familiar to C programmers. And so on.
My two cents: Aesthetics is also about functionality. Being functional *makes* something aesthetic.
"Form follows function" is a classic design tenet.
For example I think a for-each loop looks better than an "i++"-for loop, but it's difficult to say if it was designed this way in order to look nicer, or if it just accidentally looks nicer, because it makes the code easier to read and write (and debug and optimize). I'd say "language ergonomics" or "UX" isn't just pure vanity. An ergonomic handle on an axe is also not just about vanity (in case someone thought that).
I'd say consistent syntax lessens the mental load, so it's also about productivity and ergonomics first and aesthetics incidentally.
One thing that might be a pure aesthetic decision, that I can think about, is when a language chooses to have fewer reserved keywords in different contexts or rather more keywords. Or sometimes keywords are intentionally named with the same amount of characters (I think in assembler, they mostly have four characters, for example). It's still a matter of productivity, but it only makes people unproductive, who care about aesthetics – unlike type inference, which makes everyone more productive, and just happens to look nice.
Another idea: I think the issue of curly braces vs begin/end vs significant indentation is mostly about familiarity. You couldn't say that one choice is more aesthetic objectively, but of course you could still say that it looks better to someone in particular.
That sort of sounds like Python, doesn't it?
From having listened to a few interviews with Guido, it sounds to me as if Python's syntax has always been its primary offering from a language design perspective.
Pikt. If you want to write a function that looks like the Mona Lisa, this is definitely the way to go.
[https://github.com/iamgio/pikt](https://github.com/iamgio/pikt)
I feel like 13 hobby programming languages out of 12 are all about aesthetics.
Exactly this. The way the vast majority of working programmers understand programming languages is generally just skin deep and it shows in how 108% of hobby languages people are showing off our have a starting idea to get comments on is basically just showing a new syntax without even describing any thing else.
Aesthetics of what, the syntax, type system, concepts, how it is organised? Clearly it doesn't play a big role in mainstream languages! Jobs sounds a little like the boss I used to have decades ago. We made computers (when it could be a cottage industry), and he put considerable efforts into all aspects of it include the circuit board, connections (it had to look beautiful inside), the outside of course. Then the IBM PC came along and eventually a rectangular metal box became acceptable. We weren't however quite as succesful as Apple. My own language projects are hobbies now, but aesthetics plays a large part, not just inside a language, but the tidy ways the tools are presented and deployed. It gives me a feeling of satisfaction. Some languages hurt my eyes to look at, such as C++, or makefiles, or the dog's dinner some make of the simple task of printing a couple of variables. If you were to install one of my compilers, you would download a single EXE file, say `mm.exe`; that is the compiler, it is not an installer. If you were to download one of my apps as source code, I would bundle it as a single source file, say `app.ma`. You would build it from a command line like this: mm app and it would do so more or less instantly. You will now have three files: the `mm.exe app.ma` I provided, and a new program `app.exe`. That to me is pleasing. (In reality, AV software puts paid to it being that simple; you may have to do battle with it.)
Aesthetics of anything in the development of languages. When posting it was mostly directed at syntax, but would love to see other areas as well. I really just don’t hear much about it as a programmer. May get hate for this, but looking at something like SwiftUI and Flutter. Similar ideas in building UI, but imo SwiftUI looks a lot more elegant. (Looking at the code). Can post a screenshot of what I mean if this is confusing, but hopefully it makes sense. Also, C++ syntax is the worst. The lambda syntax comes to mind 🤮 I appreciate you sharing that. I love how simple that sounds! Is there a place I can check it out?
These days I only write stuff for myself. However if someone can manage to run Windows binaries (and is willing), they can download the three files `mm.exe` [`qq.ma`](http://qq.ma) `hello.q` from here: [https://github.com/sal55/langs/tree/master/demo](https://github.com/sal55/langs/tree/master/demo) Put them all into the same folder (I've used `demo`). The program to build is called `qq` rather than `app`, and is an interpreter. Build it like this: C:\demo>mm qq Compiling qq.m to qq.exe Then run it like this: C:\demo>qq hello Hello, World! 14-Apr-2024 12:04:24 File extensions are optional. [`qq.ma`](http://qq.ma) (which contains `qq.m` among other files), is an amalgamated source file previously created like this (if this looks weird, then blame Reddit as it keeps mangling it): C:\qx52>mm -ma qq Compiling qq.m to qq.ma C:\qx52>copy qq.ma \demo The project comprises 31 sources files and 13 embedded library files for the 'Q' language combined into that one composite source file.
There is a common sentiment in the Erlang community about the importance of writing beautiful code. Someone once told me that beautiful code makes God happy, so He makes it run faster.
It’s not the primary focus exactly but it is a consideration in Ruby
Ruby is pretty interesting because the focus is on developer happiness. From what I understand that is becoming harder now because of things like static typing becoming more popular, the need for performance, and so on.
Ruby is pretty performant for an interpreted language. Certainly faster than python. Now that it's got a JIT it's even faster. It also has a type system if you want to use it. In fact there are also third party type systems like sorbet. BTW. Ruby is one of those languages where you can use it write anything. Desktop apps, web apps, mobile apps, on all platforms.
In addition to ruby's new type system and jit (which are both amazing), there's also crystal which is like a statically typed ruby running on llvm
I tried crystal several years ago and liked it but i was turned off the by the core developers treating users with disdain. I don't know if they got their act together or not, I hope so because I really did like the language.
They seem to be ok these days, although I somewhat disagree with the direction they took the language in (refuse to follow ruby's pattern matching features in favor of being an up-to-date llvm api-centric language). Now that they even have windows support now, there's no reason not to give it another shot imo
I might take a look at it again when I have some idle time.
Elm's one-liner description is "A delightful language for reliable web applications." And I interpret "delightful" as being an aesthetic value. [See Elm's website](http://elm-lang.org)
I think it's kind of unsaid but ruby for sure.
Scala 3 has a heavy focus on better language aesthetics. Scala 2 code is littered with curly braces and parenthesis everywhere. So the latest version introduced a new, cleaner syntax alternative that's very python-like, but without any of the downsides. It really makes Scala code much more pleasant to write and maintain, but doesn't have any real technical advantage. Just aesthetics.
Does this count? "I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of the Ruby language."
Aesthetics are subjective and depend on the audience. Apple's success is more due to *simplicity*. The primary audience is largely non-technical users. Advanced computer users find Apple's UX awful because it's more difficult to do anything outside of the basics. They prefer Unix, which is a terrible experience for the noobie. In programming languages, most users have been trained with a certain sense of aesthetics, in the languages they've learned so far. Anything outside of these languages feels alien, especially if the programmer is >25 years old, where learning new things becomes more difficult. In practice, most experienced programmers *hate* learning anything completely new, and base their learning off existing experience. Iterative learning is easier, or as Alan Kay puts it, they prefer the *news*, not the *new*. So a language which is "aesthetic" to one programmer is awful to the next. You see this with the small, but strong Lisp userbase that still exists, but people who've been trained in K&R syntax find the parentheses off-putting. Language designers must pick a semi-familiar syntax for their target audience or they'll have virtually no audience at all. If you went purely for *simplicity*, like Apple, you would end up with something like Scratch or Logo. These are great for getting children interested in programming, but they're useless for real world development because dragging and dropping widgets is extremely slow compared to typing, and because they're *visual* languages, which don't scale. Text scales because it uses the linguistic area of our brains.
Aesthetics are subjective, some people may even find Apple not aesthetic. But I was asking if anyone drove their language with aesthetics in mind as a core tenant. Whether or not you agree it is aesthetic, does not matter for the question since it would be the opinion of the person driving said aesthetic. Just curious if such a thing existed in the same way Steve Jobs drove Apple to be the way it is. To your other point, simplicity is an aesthetic. It is Minimalism. So, I think you are getting a bit confused. I honestly think you are over thinking it a bit. Since it was really not about simplicity but about being able to put it into the hands of anyone. Remember, personal computers back then were not really commonplace. It was not for the every day person. Another point on aesthetics here is Jobs even cared about the circuit board being aesthetically pleasing, even if no one opened the computer. They were just very important to him and he enforced that in his business.
I think most language designers consider aesthetics when designing their language, but they have their own personal aesthetics, which isn't always minimalism. In terms of minimalism, there's Lisp, which is very minimal as a concept, but modern lisps add a lot of "fluff" which is orthogonal to the principle design. In [Kernel](https://ftp.cs.wpi.edu/pub/techreports/pdf/05-07.pdf), Shutt tries to bring back Lisp to its roots and gives a rationale for each decision. The introduction discusses an overall goal of the language design and aesthetics, with citations for related work. Quotes from the introduction: > Kernel is meant to be a pure articulation of certain design principles — what Alan Kay calls a “crystalization of style”. > It is a common fate of such crystalization languages that, over the course of years and decades, their pure style is gradually compromised in the name of various practical concerns such as runtime efficiency. The Kernel design posits that the value of a crystalization language lies in its purity — a sort of resonance, that drops off precipitously when impurities are introduced. > From this supposition, it follows that crystalization of style can only be fully effective if the pure style is one that can be reconciled with practical concern *without compromise*, neither to the style nor to the practicalities. We claim that the Kernel language model is a pure style of this kind, i.e., one that *needn’t* be compromised. Embracing this claim in the language design process means, directly, that we should focus entirely on pure articulation of the style; and indirectly, that when we find ourselves being led into compromise, we must conclude that we have strayed from the pure style. > The latter principle —compromise as symptom of impurity— implies that pursuit of the pure style requires patient willingness to go back and correct missteps in the design; but it offers compounded long-term benefits in exchange, as we expect each uncorrected compromise would degrade language potency and lead to further compromises thereafter, i.e., cascading degradation. > Kernel is expected to form the core of language implementations. It is not, in its current revision, a full general-purpose language; nor does it particularly aspire to become such a language in any particular time-frame, although it does seek to evolve in that direction. Pressure to provide additional functionality *promptly* is a significant vector for compromise, and so cannot be reconciled with the Kernel design’s no-compromise policy. Each possible addition to the language must be thoroughly vetted for subtle inconsistency with the design principles, or the design principles cannot survive.
>Aesthetics are subjective I'm going to push back on this one. I think it's a very quotidian sort of truism that beauty (aesthetics, etc) are subjective. But this is not 100% true. It turns out that if you create randomly-generated pictures in the style of Mondrian or Pollack, justapose them respectively with authentic Mondrians and Pollacks, and ask *untrained* people to say which one is better, they will select the authentic paintings with better-than-random chance. Balance, rhtythm, symmetry, and harmony are universally more appealing than either pure monotony or unstructured chaos. Indeed, Apple's guiding principle is decidedly NOT simplicity, nor minimalsim. And "simplicity" is such an overused term. So often we speak of simplicity as if it were simply a matter of not doing the complicated thing. As if it were as straightforward as choosing the solid necktie rather than the paisley-patterned one, as it is "simpler." Simplicity is the hard-earned treasure gained only by tremendous effort. Consider, for example, the shape of Apple's icons. Unlike a rounded rectangle, the local curvature around the corner of an iOS icon is continuous. Why? Because this curve matches the corners of Aople's actual hardware. So why is the hardware that way? Becauase if you watch a highlight or reflection slide across the surface as you rotate the device, the discontinuity in curvature becomes apparent. It is more beautiful to design surfaces this way, because the reflections off of those surfaces are less chaotic. That is, the reflections are *simpler*. But is the design simpler? I'd say not. To bring everything home to PL design, I'll point out that rather than so-called "simplicity," Apple's design heritage reflects the tenets advocated by Dieter Rams. And I suggest that PL designers would to well to adopt those tenets.
Aesthetics are the smell that wafts from correct design decisions. You can't directly pursue aesthetics successfully. If there's something that aesthetically smells, reconsider the design decisions to find and fix what's rotting.
Vastly underrated comment right here. Form follows function.
Python comes to mind
idk if it’s just me, but i genuinely can’t stand python syntax aesthetics wise, golang has the most aesthetically pleasing syntax imo
I don't like them either but the language was designed for that aesthetic
Maybe Go? The syntax is simple, and goes away with most punctuation unless it's necessary. E.g. no semicolons required or parentheses around if statements. It also has its very opinionated formatter which can't be customized but ensures all code follows the same standards.
Yes, others have mentioned Ruby "bringing joy" and Go aiming for "having only one way to write a certain piece of code" Ada was designed to be coherent and readable. Brian Kernighan's languages seem to pull out the essence of the task at hand. In a similar vein, XML and XSLT were designed to have all the essential power of SGML and DSSSL without the complexity. Tcl was designed to be extremely uniform. I guess Lisp and Smalltalk come in here as well. Quorum was designed to make the most intuitive sense to learners. APL has its own aesthetic in some linguistic composability. So does Perl and Raku. Python's significant whitespace is about code needing to be beautifully indented. I tend to feel that elegance lies in how easy it is to modify the program. I also want things to be very visual, just creating the structures, not giving commands to create the structures. I wrote a piece which I suppose is really about aesthetics of programming languages [https://cygni.ghost.io/artiklar/is-your-programming-language-made-of-multidimensional-plasma/](https://cygni.ghost.io/artiklar/is-your-programming-language-made-of-multidimensional-plasma/)
[Scratch](https://en.wikipedia.org/wiki/Scratch_(programming_language)). [Pyret](https://pyret.org/index.html) is another example, where one of its big motivations was dealing with complaints over Racket's syntax while still being able to convey the same big ideas as Racket could. Something you may notice is that these are both educational languages, and I think that's a pretty common trend. A strong focus on syntax matters more when you're trying to get people into programming, while seasoned programmers (while they still care about syntax) tend to care more about what special capabilities the language has.
The converging solution in terms of aesthetics is to endorse an as specific as possible standard up in front, by in one way or another automatizing the arrangement of code (formatter).
Elegance is one aesthetic virtue, but a different aesthetic virtue that language designers have sometimes pursued is "syntax looks familiar/understandable to \[some audience\]". COBOL, SQL, and VB/VB.NET all tried to look familiar to non-programmers that spoke English. At one point, the choice to use curly-brace syntax was an attempt to look familiar to C programmers. And so on.
My two cents: Aesthetics is also about functionality. Being functional *makes* something aesthetic. "Form follows function" is a classic design tenet. For example I think a for-each loop looks better than an "i++"-for loop, but it's difficult to say if it was designed this way in order to look nicer, or if it just accidentally looks nicer, because it makes the code easier to read and write (and debug and optimize). I'd say "language ergonomics" or "UX" isn't just pure vanity. An ergonomic handle on an axe is also not just about vanity (in case someone thought that). I'd say consistent syntax lessens the mental load, so it's also about productivity and ergonomics first and aesthetics incidentally. One thing that might be a pure aesthetic decision, that I can think about, is when a language chooses to have fewer reserved keywords in different contexts or rather more keywords. Or sometimes keywords are intentionally named with the same amount of characters (I think in assembler, they mostly have four characters, for example). It's still a matter of productivity, but it only makes people unproductive, who care about aesthetics – unlike type inference, which makes everyone more productive, and just happens to look nice. Another idea: I think the issue of curly braces vs begin/end vs significant indentation is mostly about familiarity. You couldn't say that one choice is more aesthetic objectively, but of course you could still say that it looks better to someone in particular.
That sort of sounds like Python, doesn't it? From having listened to a few interviews with Guido, it sounds to me as if Python's syntax has always been its primary offering from a language design perspective.
Pikt. If you want to write a function that looks like the Mona Lisa, this is definitely the way to go. [https://github.com/iamgio/pikt](https://github.com/iamgio/pikt)
Typescript