This is where the beauty/simplicity of some programming languages, namely, intepreted languages (e.g., Python), comes in: if a bad line of code never gets executed, then the program itself will run fine. In other words, if the line is never called in the program, then you'll not know that the functionality that that line presented was bad. In this case, the analogy breaks down a bit - and also shows why certain languages are easier to learn than others (e.g., Python vs. C++).

This is true, however there are languages which allow for more programming errors than others.

I just mentioned C as one possible example.

The goal should be to have programming languages that reduce programming errors, not that make it easier to shot yourself.

Of course this is only a small step towards better software, as whole system design also plays a big role.

This feels like an excuse to me. I’ve worked on a lot of rather simple web apps that all more or less do the same stuff. A few of them have managed to have delightfully simple codebases, most of them haven’t. There’s no reason that couldn’t be true for all of them. You usually end up having at least some complexity. But small complexity trade offs don’t necessarily require you to undermine the simplicity of the entire system.

I completely agree with this. The best code is code you don't have to read because the structure of the code makes navigation easy and functional boundaries obvious. A language that doesn't provide strong support for declaring functional boundaries results in code that is much harder to read because you have to comprehend a lot more of it to know what's going on.

I used to think that way. But it only took me half a decade of professional development (and reading/discussing in circles like HN) to see that it's a fallacy. A programming language cannot be perfect because it's made for humans, who are not perfect (and runs on computers, which arguably are not perfect).

Accepting the fact that there's no singular, perfect way to express a given idea has been freeing, actually. I used to constantly chase the dragon, getting hung up on refactoring and refactoring and refactoring, trying to attain that perfect description. I still get caught up in it sometimes. A little bit of that spirit makes for better code. But you have to be able to pull yourself away.

This was, in the grand scheme of things, likely offset by the hours of frustration most of the students went through while debugging their parser which did not work perfectly the first time.

It's more important that a function looks good, than that it actually works?

I'm sorry, but that sounds stupid. A computer is a functioning machine first.

If it worked from the start, it wouldn't need to be fixed later.

You can always study someone's work to figure out how it works. There's no point studying a system that doesn't.

The key to writing type-less code is making it so simple that you could cry. Avoid being clever at all costs. However, it's almost the exact opposite when you have a nice compiler checking everything, you can be mighty clever and know that it will work.

I'm lucky in that we can solve a problem in a myriad of languages, depending on if it needs to be "realtime", or can be precomputed. There are some types of problems I'd rather solve in Scala, and others, Python or PHP. It just depends.

And the terrifying thing about language is that we can still strive to be precise and yet (perhaps even unknowingly) be wildly misunderstood...perhaps malevolently. I've heard someone describe programming as telling a very precise story to a very stupid human. However, I think it would be better to describe a compiler as a more humble listener. One who is willing to say "I'm sorry, you just told me to multiply a string, and I think I'm misunderstanding you." Thinking of compiler errors as an expression of humility can explain the comfort one finds in a stronger type system.

It is the same comfort one finds by not speaking publicly on twitter but speaking to a person who has the charity to say "huh? I think you just said this thing that sounds wildly offensive, and I think I'm misunderstanding you."

Not really. It's quite unusual to see a serious formal approach.

I'm working through a book that uses C++. Every few pages I find undefined behaviour (struct punning, illegal use of memset to zero-out objects, etc) and needless usage of non-standard compiler-specific language features.

This is the well it works on my machine mindset used widely in programming, even in books written by highly qualified people.

> Those proofs are typically far from understandable or rigorous.

I'm not sure what kind of thing you're thinking of here. Can you give an example?

Then you need more creativity. :)

Nuances make it possible to express extremely complicated (yet often used) concepts in a very concise manner that is still extremely clear. See for example Python Decorators [1].

Very rigid languages take less effort in learning, but at the same time can require the developer to spend a lot more time and effort expressing certain things. See Java.

[1] http://simeonfranklin.com/blog/2012/jul/1/python-decorators-... (Only 12, imagine that!)

> The only resolution is for us as professionals to use our judgement.

Or the third option: create the language with the simplest implementation of all necessary complexity.

Unfortunately, famously, tragically, perfect languages attempted so far are examples of what not to do. The best ones are wonderfully unique examples of what not to do!

I know because I have created more than several.

Yes.

A good language makes the correct thing the easy thing.

Aside from the 1000 line function (sheesh), this is a failure of the IDE, not of the practice. We have computers that can inline these functions so you could see the code in a big 1000 line thunk if you would like, but only a LISP IDE gives you inlining afaik.

> “Good code is simple” doesn’t actually say anything.

That's a bold claim and I will assert it is wholly incorrect. Good Code is simple and simple code is VERBOSE

> whether that translates to “simple” code depends on the programmers.

That is incorrect. It largely depends on the language abstractions. When the abstractions are familiar, it goes from incomprehensible (literally) to familiar. Code cannot seem simple if you do not have the familiarity with the abstractions used.

> Should we strive to satisfy the Shakespeare for Dummies demographic

Yes.

> Programmers seem to believe in a realm of beautiful, readable, easy-to-maintain code that they haven’t seen or worked with yet

Lots of programmers believe it because they have seen it. I have. It was embedded in hard-to-maintain code, but it was there.

Elegant code does not necessarily mean readily understandable code (or "readable" code). For example, some Haskell programmers like writing extremely elegant code -- so elegant that you can base a whole new (elegant) branch of mathematics on it -- yet it is no more readable than, say, many early BASIC programs.

But why pick on Haskell? I've never seen Microsoft Word's code, but let's imagine it were the paragon of OOP design. Then, I'd like to add a feature similar to the spellchecker, that tests whether consecutive sentences rhyme. Now, I could probably find the spell-checking code rather easily, only to learn that it is attached to the main program via the most beautifully intricate plugin system -- with lifecycle management, runtime loading and unloading and whatnot -- that it takes me a few days only to learn that bit.

The point is that software is complicated, and very non-standardized. Code readability rests only in part on its structure, and a lot on how many "advanced" language features are used, the number of libraries used and their familiarity. You'll probably find "terrible" code that uses a couple of popular, mature libraries, that you're familiar with, much easier to understand than the most "elegant" polyglot codebase (written in both Python and Haskell, because, you know, the best tools were picked for each job) that makes use of 10 of the newest, shiniest libraries you've read a lot about on HN and always wanted to learn but never had the time to.

Programming languages follow rules and programmers should follow the rules. Just because mistake is common doesn’t mean the language should incorporate it into its functioning. That makes inconsistent behavior and is a pain in the long run because instead of learning and following logic, programmers have to guess what’s a common enough error that the language compensates. And over time the language drifts and is hard to work with.

It seems easier to me to just suck it up and learn the right way to do things in a language.

Programmers make it all the time too, or at least something very similar. See all those people who are on the endless quest for the "perfect" language, which usually means one which allows for writing the shortest code, sometimes at a very high cognitive cost for very little payoff. No, I really don't want to do a massive amount of mental backflips just to save a few characters, thanks.

This, exactly. It’s worth contrasting this with Python, which has a reputation for being simple but is actually extremely complex - but it is easy (at least for small programs).

However, I can’t help thinking that the two shouldn’t be in opposition. IMO it should be possible for a language to be both simple and easy to use.

There's some dose of truth to this, but the statement requires further elaboration to illustrate the complete picture. Programmers understand informally and intuitively what to avoid, yet we make serious mistakes when writing code anyway, because we are all stuck at the prerigorous[0] stage of understanding programming languages. Unfortunately, so long as our languages don't have a formal semantics, there is no way to reach the rigorous stage, let alone the postrigorous stage. (There is no path connecting the prerigorous and postrigorous stages that doesn't pass through the rigorous stage.)

[0] https://terrytao.wordpress.com/career-advice/there%E2%80%99s... .

> Seems to me like safe languages is the real solution to this

Safe languages are one solution, perhaps the most useful one in the vast majority of cases. However, legitimate use cases for unsafe languages do exist, and we need workable solutions for those cases. That being said, I don't think an informal English document could be such a solution.