Page 1 of 1

Is Brevity the Soul of Wit? - A Programmer's Perspective

Posted: Tue Dec 05, 2017 1:05 pm
by hankinsohl
Browsing the problem answer posts, it seems to me that Project Euler is far more mathematically oriented than programming oriented; brevity is beautiful and is reflected in many wonderful posts.

At the same time, production code in actual service often runs hard up against "beauty" - programming teammates will often be less talented than PE posters - even if you happen to work for an excellent company such as Microsoft/Amazon/Google/etc.

In a real-world environment, where code maintenance is essential, brevity must be sacrificed for clarity.

Too - the question of security - bounds checks, parameter verification, etc. - such checks are (IMO) rightly absent from most PE solution posts - but in production code - at least in debug builds - and certainly in code facing unchecked input - such checks are mandatory. Choice of programming language may lessen a lot of the security concerns of course.

And clarity too may be sacrificed - often elegant PE solutions are presented without a single comment - leaving the reader to work out what's happening.
An anecdote -

I once wrote a clever bit of code and checked it into production. I then went on vacation.

When I returned, I noticed that my code had been changed - not only that - an error had been introduced into my previously error-free code.

Who was at fault? Me, or the errant code "correctors"?

I think I was mostly at fault - a simple comment in my code would have headed off "correction" by my teammates. I was fully aware that my code wasn't straight forward when I checked it in - nonetheless it was brief, and elegant.
So, is PE mostly a mathematical site? or a programming site?

I think it's mostly mathematical for reasons outlined above.

What do you think?

Re: Is Brevity the Sole of Wit? - A Programmer's Perspective

Posted: Tue Dec 05, 2017 1:25 pm
by hk
It's the interplay of math and programming that makes Project Euler interesting for most of its participants.
So it's neither mostly mathematical nor mostly programming.
But mostly both of the two.

Re: Is Brevity the Sole of Wit? - A Programmer's Perspective

Posted: Tue Dec 05, 2017 1:40 pm
by hankinsohl
Thanks hk.

Out of curiosity, is your background mostly mathematical or programming or a mixture of both?

My father was a PhD mathematician. I grew up loving math and science and early on in high school took a programming class which I loved.

My career took me into neither field - chemical engineering by degree I nonetheless did no chemical engineering work - but engineering in general instead.

My personal love of computers and programming led me to purchase one of the first Amiga computers as soon as they came out. A little later on I developed a disassembler for the Amiga (DSM) and sold roughly 1000 copies of the program commercially.

Later on in my career, I switched from engineering to programming - most recently having worked for Microsoft.

So my take on PE problems/solutions is from the background of a professional programmer with interest in math.

Re: Is Brevity the Sole of Wit? - A Programmer's Perspective

Posted: Tue Dec 05, 2017 1:45 pm
by hk
One more comment:
I think that "programming" and "software development and maintenance" are quite different things.
People working in the IT-sector are often unjustfiable thinking that "software development and maintenance" is the same as "programming".

(Btw, I'm not answering any questions about myself in public)

Re: Is Brevity the Sole of Wit? - A Programmer's Perspective

Posted: Tue Dec 05, 2017 5:31 pm
by traxex
Best practices are heuristics. Part of being a good programmer is understanding why they exist, what benefits and costs they have, and recognizing when they're not useful.

If a piece of code doesn't need to be maintained, spending time making it maintainable is a waste. If it doesn't need to be understood by other people, there's no need to make it understandable. Being able to write a run-once-and-forget program very quickly is a skill and does not preclude one from also being able to develop "serious" software. Some programmers have a very narrow view and believe that a 200-line program with a github repository, file, semantic versioning, unit tests and continuous integration is always Better with a capital B than a one-line shell script that does the same thing.

For me, Project Euler and problem solving is a way to escape all the baggage of developing software at work and make programming fun again.

I would agree that Project Euler is more mathematical than algorithmic, compared to competitive programming sites. There are some algorithmic problems here, notably a bunch of dynamic programming in pre-200 problems, but overall they are the exception.

Re: Is Brevity the Soul of Wit? - A Programmer's Perspective

Posted: Tue Jun 12, 2018 12:28 pm
by Kenya_A
I tried an approach to problem 55 where I tried to build up a 'language' of programs so that I could, in one line, calculate my actual result, using the terms which I had previously defined, and defined in such a way as to encapsulate all the methodology required to solve the problem.
I ended up with a file 167 lines long, which is one of my longest yet. I am new to programming; I learnt racket in class. From what I read online, re both Paul Graham and the course materials for the class I took, lisp programming, and maybe functional programming in general, is about building the tools you want to solve the problem at hand, like form scratch. Also, I've seen many one liners as a result of much coding 'back-ground-work', where - and this was specifically encouraged and I appreciate the beauty of it - looking at the function one writes as the actual answer to the problem, all the components spell themselves out as the obvious elements of the exact calculation a problem presents. That was cool to see. So I tried it. Maybe went somewhat overboard - I commented this in my posted solution.
Specifically, though, some of the length is from following the formula of having a contract, and then a purpose, then the program definition, and then tests, for every program. Supposedly this makes us better programs - type specification in the contract does make you more mindful as you type or work out the actual program, and for me can clear up some bugs, conceptually, about what the function entails. I would like to have put the tests in a separate module, to make the solution cleaner. Some of the rules for good programming though, are for other situations. I was doing this in Typed Racket to remember how to program in general, for a blog, but project euler solutions are not a blog, and the code can be terser and not as maintainable/ not maintainable at all, just understandable to either you, and you only, or also a reader. And whether the reader is supposed to figure it out for themselves or find it obvious is another thing.
Specifically, maybe I like using, 'next' time, some more built-in functions and collapse more calculations into single functions and/or lines.
That is also probably easier in something other than racket?
I could have taken a different approach entirely, by trying to make the program shorter, and I wonder what that feels like. This time was an experiment in creating a 'language', and the end result is verbosity - everything in moderation perhaps, but I think this approach is more generalizable to big problems, and that I might like to continue it - being 'fine' and 'thorough' when programming something conceptually difficult and maybe it will pay off then, compared to other approaches. Wheras right now it was deifnitely overkill, in that it took a fucking day-and-a-half to finish *two* operations - a palindrome tester and a function to hen find if a number is lychrel. It took me that long because I broke it down into subtasks and programmed all of those, and had errors (put in the tests after coding chunks because the chunks were really one whole to me, being related, but subsequently had to find errors that were not obviously located).
Brevity is the soul of wit - I have not yet tried that approach and wonder what it will be, in general, and/or would be, in racket. A one-liner in C , or in Racket, is also cool.