
What I Expect From a Programming Language - jpro
http://eiffelroom.org/node/653
======
PuerkitoBio
Interestingly, these qualities all apply to Go:

\- easier to read than write : it has been said a lot that go (esp. its error
handling) was somewhat verbose, though very readable.

\- Not tricking the programmer : this one is a bit subjective, go does use the
equal sign as assign operator, but the required braces for if-else, gofmt tool
and strict compiler help in not tricking you.

\- one way to do things : go (its community) is very actively promoting the
_idiomatic_ way of doing things. Also consider, no while/do loops, only for.

\- as much static typing as possible : maybe not as much as rust, but yeah,
very static typing (array length is part of the type, for example)

\- no warnings : exactly that! Unused variables and imports are errors.

\- coding conventions part of the language : the gofmt tool does that. Don't
publish code that is not gofmt'ed!

~~~
chimeracoder
I read the article and then came to the comments looking to make this exact
point.

Gofmt is my favorite example of why coding conventions can, and _should_ be
part of the language.

------
tikhonj
I think "one way to do it" Java and Python philosophy is overrated. Sure, when
it's presented that way, it sounds great! Why wouldn't we want one way to do
things?

I like to think about it differently: instead of trying to coerce my problem
to fit the language, I want to mold my language to fit the problem. It's
easier to think about the problem in its own terms--the terms of its domain--
than in those terms filtered through a "one-size-fits-all" language design.

I want code that is declarative and closely reflects its underlying logic. And
this means there will be more than one way to do things--while many problems
are similar mechanically, their actual meaning is vastly different.

So there really _is_ a benefit to having more than one way to do things: you
can choose a way that's appropriate for the problem you're solving. Of course,
this puts a bit of trust into programmers to have good taste: while it allows
you to write far _better_ code than a one-size-fits-all language, it also
allows you to write far _worse_ code. I personally think this is a worthy
compromise.

Another interesting thing I've found is that having more than one way to do
things naturally emerges when you have a distinct set of powerful primitives.
This is most evident in math: for any given problem, there are often _a ton_
of different ways to arrive at the same solution. Each of these ways emerges
naturally from the fundamental building blocks of math.

Coincidentally, these different ways of looking at the same thing are not only
natural but actively useful: they give you different perspectives on the same
idea. An example I recently encountered was with lattices. There are two
different ways to define a lattice--one in terms of partial orders and one in
terms of algebras. The former gives you an intuition on the structure of a
lattice; in a sense, it tells you what a lattice "looks like". The latter
makes it easy to see relationships between lattices and other algebraic
structures: for example, Boolean algebras are just a special kind of lattice.
You can then even combine the two and start thinking about Boolean algebras in
terms of orders.

So to me, having multiple different but equivalent ways to do things is both
useful and natural, especially if these different ways emerge naturally. I
much prefer this approach to something more prescriptive and monolithic, where
the language designer has tried to guess exactly what and how I will be doing
and explicitly provided a way to do it.

~~~
fleitz
Sure there are corner cases such as lattices where having more than one way of
expressing a problem is beneficial, I think what the op is getting at are
things like:

if/else vs. the ternary operator in C. Blocks/Procs/Lambdas in Ruby. etc.

The concepts are so close that the language might as well pick one way of
doing it and just do that. I don't need 18 kinds of for/for-
in/while/do/do/while loops each broken in it's own way, I need one that works.

For myself in the above cases I'd make if/else an expression, and get rid of
blocks/procs.

Most of what is in today's languages shouldn't be spec'd as part of the
language, but rather provided by the standard library. What is the point of
async/await in C# but not monads? It does not empower programmers, it
subjugates them to the will of Anders, these tasks are blessed, these are not.

~~~
charliesome
Even if you made if/else an expression, the ternary is still useful for
brevity.

Compare:

    
    
      foo(a ? b : c)
    

Versus:

    
    
      foo(if a then b else c end)
    

Which do you think reads more clearly?

~~~
ori_b
The slightly less terse:

    
    
         if(a)
            foo(b)
          else
            foo(c)

~~~
qu4z-2
My only complaint with that version is that foo() is repeated now. It's not
clear at a glance that you're definitely calling foo, and only deciding which
argument to pass. (Well, in this simple case it's quite obvious, but...)

~~~
zackelan
If that's really a concern:

    
    
        if (a):
            arg = b
        else:
            arg = c
        foo(arg)
    

In my experience, trying to optimize for brevity at the expense of clarity is
almost always a bad idea.

~~~
tomlu
I like this - idiomatic, brief and clear:

    
    
        arg = a and b or c
        foo(arg)

~~~
capisce
Personally I don't really see what's unclear about foo(a ? b : c)

In fact, I'd say your "trick" with using boolean operators on non-booleans
that way is less readable.

~~~
tomlu
I don't think there is anything at all unclear about (a ? b : c). I use it all
the time when programming in C and its derivatives.

The (a and b or c) idiom is used in Lua, Ruby and Python (in descending order
of idiomaticness). Since the person I was responding to seemed to be using
syntax reminiscent of these languages, I thought I'd offer up this expression
form as an alternative to resorting to statements.

------
pcwalton
Making unused variables and code formatting issues into errors was considered
and rejected for Rust. The reason is that much of debugging consists of
commenting out pieces of code and rebuilding. Often this results in variables
becoming unused and formatting becoming messed up. I've worked with systems
that threw errors here (FxCop), and it was terribly inconvenient in practice.

I think the optimum is just a loud set of warnings, a community expectation
that all code be warning-free, and a pretty printer included with the language
to get the ecosystem to standardize on a style.

------
jfb
tl;dr: OP likes Eiffel.

A perfectly reasonable post, but not a very interesting one. I could probably
write something similar:

    
    
      - homoiconicity
      - tail-call elimination
      - s-expressions
    

Can you tell what my first language was?

~~~
unimpressive
Scheme?

~~~
kenjackson
Nope. Must be XML.

~~~
jfb
XML used to be a very easy way for my coworkers to get a rise out of me.
Thankfully, I haven't had to think about it since I left Apple.

------
zem
it's interesting how his entire _class_ of expectations is different from
mine. my focus is mostly on what facilities for abstraction and safety the
language gives me; i hold that if you have powerful enough abstraction
facilities to factor out boilerplate, your code can be made to be way more
readable than the "only one way to do it" class of languages, and if you have
safety features built into the language (static typing, abstract datatypes,
contracts, linear types) it will be _forced_ to be more reliable.

------
darrencauthon
He wrote: "As much static checking as possible: Static checking is good. Did
you ever write a larger piece of code in one go, compiled it and it produced
tons of errors? All these error would still be there, if you would not have
static checking. You err much more than you think."

I think _he_ errors much more than he really thinks. If errors are what he's
truly trying to avoid, he'd be more focused on unit testing and TDD than
passing syntax.

Descriptions like his make me wonder how many static typing proponents have
actually spent any legitimate amount coding in a dynamic language for a
production application. It seems all scary to code applications without a big
IDE, but I promise that it's possible and a lot of people make it work.

~~~
slurry
Java developer: "How can you code without an IDE?"

non-Java developers: "How can you code in fucking Java?"

~~~
eropple
I write Java in Vim on occasion.

I think I'm broken.

------
aidenn0
I think this is off base with regards to warnings. Warnings are the sign of a
language that has been widely used. There is something that is now known to be
bad (i.e. error prone), but previously was not known to be bad.

If you make it an error you break lots and lots of code. If you totally ignore
it, you allow more preventable bugs to be introduced. Thus the warning is
born.

------
ced
I don't understand how he can want static checking, but no warnings. "x is
declared but never used" has saved me so many times. Maybe he's used to
languages where warnings cannot be locally disabled? In Common Lisp I can
(declare (ignore x)) to "shut up the compiler", and it works really well.

~~~
michaelfairley
He wants "x is declared but never used" to be an error that halts compilation.
Go's philosophy on this[1] is "if it's worth complaining about, it's worth
fixing in the code."

1:
[http://golang.org/doc/go_faq.html#unused_variables_and_impor...](http://golang.org/doc/go_faq.html#unused_variables_and_imports)

------
msutherl
Programs should be easy to write and easy to read

Formatting should delineate structure wherever useful

Syntactical noise should be avoided

Should provide powerful tools for expressing ideas succinctly

Static checking should be available but not required

Should provide a rich set of built-in tools

Should support runtime program manipulation

------
bo1024
I agree with most of the post, but this:

> _Programs have to be easier to read than write_

I think is impossible.

~~~
webreac
It was one the main motto of Ada. Ada is very easy to read (to be honest, it
is less true since Ada95) but when I do not use it during a long time, I
forget how to write in Ada.

