λ - programming

I think it really depends what you're doing. For me the beauty is important, it's the reason I'm here. That computers are basically the most useful thing ever is fringe next to that, but I can understand that some guy just hacking out his paycheck doesn't give a fuarrrk.

I think it's more important here than it is in mathematics but only because of the sideline benefits. In mathematics a proof is a proof and any one is, in practice, as good as another. Beautiful programs generally run faster and have less bugs.

>Very few courses or books talk about beauty
That's as it should be. Such beauty cannot really be taught, nor studied or codified. Let the books and courses teach the mechanics of things, from the right students the beauty will come regardless.

>>11820
I feel like I could be a really good mathematician if I actually studied maths to any real level. I often think about ways of proving and solving things only to find out that it has been proven in the way I was thinking about it just carried out logically further than I am able to.

>>11825
Then you should study to see if you'll be.The more great minds in mathematics the better

I think it does. Your code expreses the most with the least, your functions do the right things and don't jnterfere with each other, and it is easier to read and mantain because it doesn't get overly complex. You avoid spaghettification and subsequent patchwork, your code is done in such a way that it's easier to actually change in it's inherent design.
But why do 't books teach that? Well, some do. But most of them only care avout giving you the syntax and the details of how it works, and a lot of them come, honestly, from rather inexperienced programmers. They aim to get you coding, and very few take you to this other, somewhat vague area where you write beautiful code. Thinking Forth, The Pragmatic Programmer, and perhaps SICP are some such books

>>11820
It's all a matter of opinion.

There are people, who believe that good code is code, which does what it's supposed to do.
For them, programming skill often boils down to being able to make things work, the faster the better.

On the other hand, there also are people who care about the aesthetics of their code.
Sometimes even more so than being quick to finish it.
Those people will often value abstraction and concepts touching into mathematics.

This split can even be seen in language design.
There's languages, that are great for getting something up and running as quickly as possible, like Go or python.
There also are languages, that enable programmers to define and compose abstractions, like the lisp- or ML-families.

>>11823
>In mathematics a proof is a proof and any one is, in practice, as good as another.
Not true. Proofs evolve as the mathematics built around and on top of them moves forward. Being able to understand a result with proofs from multiple viewpoints is a part of the beauty of mathematics. Being able to prove results with techniques from seemingly unrelated fields is one of the defining features of 20th century mathematics.

>>11841
>to prove results with techniques from seemingly unrelated fields
Iktf there is a proof on the infinitude of primes using concepts from topology.
It's kinda useless but I'm sure anyone can appreciate the ingenuity of it

>>11841
I stand corrected.

>>11829
Except it isn't all a matter of opinion. Considering the quantified nature of programming languages. There are a variety of metrics to measure how effective a certain program is.

You can benchmark it's efficiency.
You can measure how well it deals with dynamically allocated memory.
You can even measure how terse your statements are (which is more aesthetic an issue than performance based).
Or how well you've threaded it.

Needless to say, there's a performance dimension that /does/ determine how well a program was written. And to say it's all based on opinion... well it isn't.

>>11829
>It's all a matter of opinion.
Are you saying that all code is just as good as any other code or are you saying nothing at all? The first case isn't true, and the second is a thought terminating cliche. It doesn't provide any information; it just ends any discussion on the topic.

Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity.

— David Gelernter

>>11856
Performance Measurements don't make one program better than another,
as it is a Metric which depends on the Machine that the generated code is executed on/generated for.
There is a world outside of RISC/CISC. (sadly it only exists in our minds currently)

>Considering the quantified nature of programming languages.
What are talking about?

>>11857
>Are you saying that all code is just as good as any other code or are you saying nothing at all?
No, I'm merely saying that beauty lies in the eyes of the beholder.
I personaly am part of the second group described.
Aesthetics are what make programming fun for me and I'll try to steer clear of "ugly" languages and problems.

>The first case isn't true, and the second is a thought terminating cliche.
All programmers I've met so far fit one of those two groups.
Sure, you could make a finer grained definition, but this one is good enough for me.

>It doesn't provide any information; it just ends any discussion on the topic.
But that's how reality unfortunately works.
Every discussion to define good vs bad and beautiful vs ugly will boil down to a matter of opinion and view.
Believing you can come up, or even have come up, with a definitive answer to such a question is just wrong and will lead to fruitless religious wars.

>>11862
>Every discussion to define good vs bad and beautiful vs ugly will boil down to a matter of opinion and view.
Please stop with the sophistry. Nobody needs another "everything is subjective :P" argument. I can write objectively bad code.

>>11901
>I can write objectively bad code.
Yeah, I definetly agree with you on that.

There are the basic requirements, of course, it should do what it's supposed to do and run reasonably fast.
Apart from those kinds of things, I don't think you can define any global standards for code.

>>11823
>Beautiful programs generally run faster
An argument against this would be the use of recursion. Recursion could be considered as beautiful, but generally it fills up the stack and causes more function calls. But surely modern optimization algorithms can circumvent this.

>>11901
>Nobody needs another "everything is subjective :P" argument. I can write objectively bad code.

But that's what you get when you start talking about taste and beauty when we don't even define what's beautiful and what's ugly code.

As said earlier, we can objectively measure the efficiency of a given program but apparently that doesn't make it "beautiful"; a program could be fast but hard to extend, modify or even understand.

To me, I prefer to think somewhat as >>11828. In my opinion, good code:

1. Is written in such a manner that can easily communicate intent without relying too much on comments.
2. Is designed to easily allow for potential changes using appropriate abstractions; too little and you get a rigid program, too much and you get enterprise fizzbuzz.
3. Makes use of the features of the language/framework in which is written.
4. Last, and not least, it takes into account the capabilities of the executing environment and adapts accordingly.

...I think I'm just parroting CC2 at this point, maybe I'll read it again someday.

>>11910
with tail recursion you don't really need to take up more memory than a single function call would take and that's a pretty old technique.

>>11820
I think Forth is beautiful.
http://merlintec.com/download/color.html

I also think Lisp is beautiful.

They both have simple compilers, but Lisps depend on complicated optimizations or dedicated hardware to achieve efficiency whereas Forth compilers generally perform no optimizations and let the programmer fold constants and whatnot manually.

Assembler languages and the assemblers themselves can also be beautiful in many ways, such as their simplicity or the ways they allow their programs to be written more easily and with less hassle through macros and other means.

I think it is hard or impossible to write beautiful and great programs in many common languages, like Python or Java.

It is not enough that the program functions. The program also needs to be beautiful and efficient, preferably written in a way that is still efficient even with less optimizing compilers. One Lisp example is binding references temporarily instead of relying on the compiler to recognize that you are constantly using the same reference through introspection or other means.

A great programmer understands that programming itself should be programmed and that itself programmed and so an ad infinitum.

Beauty in programming for me is being able to control complexity and making your program readable.

>>11914
Tail recursion often forces you to write less beautiful code, though.

>>11922
The colorForth website was down when I posted earlier, but now I can show this:
http://www.colorforth.com/ide.html

Just look at the simplicity of this driver. Look at how simple and to-the-point the comments are.

This is beautiful code. This is simple code. This is readable and modifiable code.

This is correct code.

>>11939
not true. Just put everything you need to iterate through in a list and you're ready to go.

>>11954
that lets you turn iteration into (tail) recursion, but for sufficiently intricate recursion, the only way to make it tail recursive or iterative is to effectively implement your own call stack on the heap.