

Do we really need another programming language? - paulgb
http://paulbutler.org/archives/do-we-really-need-another-programming-language/

======
RiderOfGiraffes

      > ... until programming languages reach the
      > expressiveness of written English, I’ll keep
      > welcoming them.
    

English is so inherently ambiguous that you are really asking about legally
expanded, lawyerese, and not English. And that's going to be several times
longer than the source code.

I agree there's space for improving languages, I believe Google's new "Go"
probably isn't that big a step, but I think asking for the "expressiveness of
English" is dangerous nonsense.

~~~
paulgb
Thanks. You're right; when I did the experiment myself (once with a Haskell
program, once with a C++ one), the results definitely looked like lawyerese.
Surprisingly, though, they were still shorter than the program. Maybe that
just means I'm a bad Haskell/C++ coder, but I don't think that's all of it.

One point that I may not have properly gotten across is that I'm not
suggesting that programming languages should approach English in form. I was
just trying to establish English as a lower bound for the amount of
information required to communicate an idea. (It's not even a lower bound,
since English is fairly redundant, but it's an upper bound on the lower bound
if you know what I mean)

If I said "until programming languages reach the information density of
written English", do you think that would make more sense?

~~~
RiderOfGiraffes
I don't have time to write an essay about this now, and I'm not sure I'd be
the right person to do so anyway, but here are some thoughts I believe to be
relevant.

Real Information Theory, as opposed to Data Transmission Theory, has to take
into account the receiver. The transmitter has to have a model of the
receiver, and then devise the data that will transform the receiver according
to the intent of the transmitter.

For example, if you're a mathematician and I talk about the topological space
obtained by gluing the edge of a mobious strip to the edge of a disk being the
same topological space obtained by identifying antipodal points of S^2, you'll
know what I mean. If not, I have to explain further.

Similarly, a computer program can start with a top level description of your
intent, and a competent programmer can then complete the steps.

But a computer is not a programmer. When you describe your algorithm in
sufficient detail for a programmer, you haven't given enough information for
someone who isn't a programmer. A non-programmer will look at what you've
written and then say "How do I do that?" Thus you need further instructions.

So you might say "We sort this vector of numbers by picking one at random,
scanning down the vector to separate into those that are smaller, equal and
larger, then recurse." and a sufficiently skilled programmer who's never met
the Quicksort can now implement it.

But there are details missing.

You programs should (perhaps) be arranged so that the main routine is
sufficient for a very skilled programmer to complete. Each routine called then
is sufficient for a slightly less skilled programmer to complete, and recurse.

The problem is that the terminating case is the computer, and not a
programmer, or even a person. Thus the terminating case is a long way down.

Perhaps there is a language design that will bring the terminating case
higher.

~~~
paulgb
That's true, but it seems these are practical limitations, not theoretical
ones.

The nice thing about the terminating case being a computer, though, is that
it's a moving target (Moore's law, etc.). At the extreme case, a compiler
could model every molecule in a human brain and use the simulated intelligence
to convert the description into a language that it can compile.

I would be crazy to expect that any time soon, but I think it shows that in
theory we can do better than existing programming languages do.

By the way, I re-worded the last sentence to "as long as programming languages
are less expressive than written English, I'll keep welcoming them.", because
I don't think it's inevitable that programming languages can become as
expressive as natural languages. I do think that as long as they aren't, we
can do better.

~~~
lolcraft
In my opinion expressiveness doesn't exist objectively. With that motivation
for language design (achieving the expressiveness of English), I'm afraid
you're running to a self-centered opinion; it is expressive only for those who
have learned it since childs. The hierarchy of programming languages derives
from the fact that expanding those languages is a lot of work (reimplementing
the parser), in comparison with a natural one (metaphors, or neologisms).
That's why, I think, a more general language (LISP, Smalltalk) is better. They
don't give you expressiveness, which is only given by semantics, but at least
they don't narrow those semantics. In comparison, English is a very ambiguous
language which seems more expressive because it's semantics are huge. Which
leads to the problem that, even if you built an artificial brain, you'd have
to teach that brain ontology. Ultimately, the problem's root is not found
within programming languages, but is an inertia to extend those which exist.

------
daeken
There will always be a need for better programming languages, with the current
situation making new languages more important than ever. We have computers we
can't completely utilize at the moment and they're becoming more parallelized
(and thus more difficult to work with, using current tools) by the second.

Despite the progress that's been made, computing is still a very young field
and there's a whole lot of room to grow. We need better languages, better
compiler technology, better kernels, better paradigms for handling tasks
(processes and threads don't cut it), and above all else, we need new ideas.

If people aren't experimenting with new ideas, we won't move forward. While
most of the implementations (literal implementations or specific language
designs) will fail, the good ideas will carry on and support the next
generation. We should all welcome innovation in this space, even if we don't
like what's being created.

~~~
Freebytes
Yes, we should continue producing programming languages, but the danger with a
programming language from Google is that they have such a reputation that
other programming languages that might be superior could be overlooked in
favor of the trendy option.

~~~
raganwald
I'm going to take the optimistic view here. Sure, Google has muscle. But so
did IBM, and where is PL/I today?

~~~
jacquesm
There is a PL/I plug in for eclipse and there are people working on a
compiler, I wouldn't count it out just yet.

------
Zak
_Now compare your description to the program’s source code. The source code is
almost certainly several times longer, less intuitive, and less descriptive._

I tried this with a short Lisp program a few years ago and found it to be
false. I may have been too detailed in my descriptions with the English
version, but I don't think so. Evolved[0] languages for human communication
are notoriously imprecise.

The "plain English" translation of a legal document will be much shorter than
the original as well. Such language isn't used in legal documents because
lawyers can and will argue over the interpretation. To make programming like
everyday English, the runtime would have to sort out the ambiguities. I think
that would require human-like AI.

Given human-like AI, much of what we do as programmers could be done by the AI
instead. A non-programmer could simply ask the AI to create the program or
provide certain kinds of output. Even in a situation like that, I suspect
there would still be a demand for human programmers who could more precisely
communicate their intentions to computers, if only for the purpose of creating
better AIs[1].

[0]That means pretty much any language people actually speak. I'm not sure if
it's true for designed languages like Esperanto.

[1]It might be a good idea to restrict AIs from certain kinds of self-
modification or from creating new AIs. I think we've all seen that movie.

------
st-keller
Of course we need a new programming language - but i don't think we need GO.
Here's my personal whishlist: * Concurrency as default (i don't want to
express explicitly which parts of my porogram can run in parallel). * I want
my programs to be able to run backwards natively (not that kind that MS pseudo
backwards-debugging feature crap). i personally call this feature an "entropy-
shield" * a really pure functional language (not that "pure functional"
languages that allow and than try to monad away "non-functional functions"
Such a language has to be completely time-agnostic - that means it will never
"run" a program. But - as always - nobody will know what i'm taking about ;-)

~~~
stcredzero
About 90% of the time in the better Smalltalk implementations, you can tell
the debugger to forget the last few stack frames, or jump back to the "start"
of the current one. Nearly unfettered replay-ability is almost as good as
stepping backwards.

~~~
st-keller
I agree - If you're focused on debugging. But there's much more to that.
"Running backwards" is not "replay". Running backwards a clock-program will
result in hands turning anti-clockwise. Not mentioned the possibilities you
can do, if program-speed can be set beetween 100% and -100%. I think most
people think about that as they do with nearly every true innovation: "What
schould that be good for?"

------
dkersten
I think we do. As PG says, programming languages are not born equal.

Different languages have different strengths and weaknesses. Some are
particularly good at number crunching, others make working with text easy.
Some provide rich, powerful type systems, others go for minimalism. Some
languages are designed to enforce OO, others build on list/stack/tree data
structures. Some go for functional purity, others are based on logic proving,
others still are based on the flow of data instead of the application of
functions. Some languages promote stacked hierarchial components, others
promote flat hierarchies instead.

Until we find that sweet spot, where all these different features are combined
in a powerful, expressive, yet simple way, we will need to continue
experimenting with new programming languages. As we gain experience in writing
different kinds of software and solving different kinds of problems, we can
model programming languages around these tasks to simplify them and build
abstractions upon them.

Personally, I don't think our search for the ultimate language will end until
we can find a nice balance between imperative and dataflow programming
languages, since they seem to be the two most fundamentally different
paradigms, yet some problems are better expressed in one and others in the
other. (Eg, imperative is very good at expressing purely mathematical concepts
as well as imposing order on computation, while dataflow is great at highly
concurrent processing - until we can merge the two, I believe we will always
have problems)

So yes, we do need more programming languages. Hopefully some day someone will
create a multi-paradigm langauge which manages to gracefully balance the
various pros and cons. Unfortunately, I think it could be a long while yet,
before an _ultimate_ language is created.

------
dmoney
Writing a program is maybe 10% what you want it to do, and 90% telling the
computer how to do it. So I think the question of when we won't need another
programming language can be answered as: when the default programming language
of the day has libraries and/or syntax that grow to include every "how" that's
been done before. This way you only have to specify the "what" unless you're
doing something nobody's figured out how to do.

So I guess my idea of the limit programming language/environment would be that
it's automatic (or at least trivially easy) to make 90% of every new program
into a gem, and then automatic/trivial to find the gem that does exactly what
you need, as well as to debug it. (maybe rubygems are already this good, i
haven't looked into them).

------
freakwit
The question of "Do we really need another programming language?" is one that
comes up time and time again. The answer is often one of the following:

* No - We have languages that are turing-complete so new languages have no benefit.

* Yes - New languages can take trends that make their way into other languages in the form of libraries and built them directly into the language, making the source code cleaner.

* Yes - New hardware (cf. multi-processors) enables new features which can't be exploited by older languages.

* No - New languages segment the population, meaning we keep re-inventing the wheel by writing the same libraries over and over again.

------
stcredzero
Definition of a "Gentleman Computer Scientist":

    
    
        A man who knows how to write a new programming language 
        But then doesn't!
    

Definitions applying to the female gender left to other posters.

------
joezydeco
What about looking at the situation from Google's point of view?

You need your engineering staff to use a language like Python instead of C or
C++ for multiple reasons. C's too dangerous and C++ is too slow and full of
traps. But Python doesn't compile efficiently into native code (forget Swallow
for now).

My hunch is that Google will move their internal staff to coding in this
language for newer projects, and not really care who else out there is using
it.

------
asciilifeform
> Do we really need another programming language?

Certainly.

Just not another 1970s abomination which firmly traps programmers into the
compile-pray-debug cycle.

~~~
9oliYQjP
I swear, someone at Google could fart and somebody would write a press release
about it.

------
wendroid
Adapt or die

