

Sylph: the programming language I want - alixmartineau
http://eev.ee/blog/2015/02/28/sylph-the-programming-language-i-want/

======
deckiedan
A lot of syntax / spacing / etc. problems would go away if we stopped using
completely plain text as the medium for programming languages. Or rather, if
we extended plain text, or got our editors to understand the languages a bit
more thoroughly than just highlighting keywords and giving us autocompletion
or whatever. This has been explored a bit by michaelw and others
([http://www.foldr.org/~michaelw/emacs/](http://www.foldr.org/~michaelw/emacs/))
for lisp.

Imagine a syntax aware editor which could display code from a language using
the syntax or style of another. (This might only work from a single base
language, there are too many "odd" features in languages which couldn't
translate universally).

So, since I like python, it could be displayed PEP8 style. Someone else could
see it with LISP braces everywhere. Another could have it with 2 spaces and
'end' keywords, or {curlybraced;} (in K&R style, or whatever you like).

~~~
TheOtherHobbes
This was tried. It was called APL.

[http://en.wikipedia.org/wiki/APL_%28programming_language%29](http://en.wikipedia.org/wiki/APL_%28programming_language%29)

It was very, very clever.

It was so clever hardly anyone understood it, and it's (mostly) forgotten.

Having said that - I kind of agree. It seems like most languages are attempts
to:

1\. Create a human-readable text-based representation of symbolic logic.

2\. Chunk the symbolic logic in (hopefully) useful ways.

3\. Cross-correlate symbolic levels, so at one extreme you have actual bytes
in physical memory, at the other you have arbitrarily complex symbolic data
structures.

4\. Build simple error checking into the language so it's impossible to write
obvious nonsense. (This includes, but isn't limited to, all type systems.)

5\. Constrain the operations that are possible for similar reasons. ('State'
etc.)

This is all more or less taken for granted. I'm not sure it should be.
Basically it's a bottom-up approach to language design - reduce operations to
binary algebra, add constraints.

But top-down languages like Prolog and (kind of...) Erlang try to do
interesting, powerful, things, and have at least a few features that Just
Work.

So I think the top-down approach is underexplored. There's a sweet spot
between top-down simplicity, expressiveness with minimal cognitive load, and
processing efficiency.

It's unlikely current syntax conventions are close to it.

I think most people know that languages are different points on various trade-
off scales, so there will never be one single best language.

But more variety might not be a bad thing.

~~~
101914
Interesting that you use the past tense. I am using such a language in the
present. And it is working just fine. I have no need for Python but so many
people are seemingly trying to coax me to use it. Such is the case for most of
the verbose languages.

I do not understand all the constant discourse about languages. Personally I
prefer to choose something simple and small, and stick to it. To increase
convenience when working with these terse languages, I write code generators.

To me, it is not the language that matters (except as below), it is the
programs that the author chooses to write and how those programs perform.

It is probably my own selective bias but I find that the smaller programs
written in relatively terse languages tend to be of higher quality. When I see
a verbose language used to write a program, I am reluctant to use the program.
But I would never suggest that someone else make the same decisions. I believe
one should think for herself.

There is not so much discussion about the terse languages I use. I am inclined
to think this is a good thing. Then I can focus on the choice of the programs
the author chooses to write instead of her choice of language.

~~~
woah
What are these terse languages you speak of?

~~~
srpeck
APL, J ([http://www.jsoftware.com/](http://www.jsoftware.com/)), k
([http://kparc.com/k.txt](http://kparc.com/k.txt)).

www.reddit.com/r/apljk/

------
brudgers
This reminds me of reading a typical zoning ordinance: more an historical sack
of bandaid reactions to specific but unrelated past problems than a positive
program generating a bounded creative domain. Addressing gripes is not
evaluating tradeoffs.

Successful languages start with a clear idea of what problem they want to
solve, creating coherency at a high level. Values are ranked and might be nice
is distinguished from what is held dear. The starting point is identifiable
and the passion positive. Saying "the ending point is not here," isn't enough.

~~~
falcolas
It actually reminds me of a first draft mind dump. From here, some aggressive
refactoring could turn this into a very nice language specification.

Brain-dumps are valuable for discussion and as a first step. From there, we
just need to follow our normal programming routines: Write, refactor, test,
repeat.

~~~
brudgers
I hated sounding negative on the article. It represents a lot of admirable
effort. My point is that the effort is not directed in a particularly
constructive direction in regard to creating a new programming language.

There's a clear goal when writing a language that is both a floor wax and a
desert topping. On the other hand, all writing a language with the goal of
being neither floor wax nor desert topping just gets us a floor topping and a
dessert wax. There's no problem solved. Griping isn't brainstorming.

Brainstorming is structured. Productive brainstorming is constrained by
reality. By which I mean that brainstorming about something like type
inference acknowledges that type inference is subject to the Halting problem
and that dynamic typing as in Python does not entail type inference.

Starting with Assembly, all higher level programming languages are DSL's over
machine code. _Things I hate_ is not a domain that leads to insight or a
coherent minimum language. Python's core was addressing pedagogical problems
such as beginners learning to format code well. Google's Closure compiler
addresses the problem of JavaScript performance. Rust is intended to address
client server programming. For each there is something that can be measured
objectively and improved.

Don't misunderstand me, there's nothing wrong with writing a programming
language as a learning exercise or to scratch one's own itch or solve the
world's problems. But it is an engineering design exercise not a poem. The
facts of computation make it so.

~~~
ulisesrmzroche
Brainstorming is not a structured exercise, it's a bunch of people throwing
ideas. How productive it was is not measured by constraints.

~~~
brudgers
One of the structural features of brainstorming is the prohibition on
criticism.

Etc.

~~~
ulisesrmzroche
Etc, what?

You mean that structural features like prohibition of criticism in
brainstorming leads to limited and unimaginative ideas, which is the point of
brainstorming in the first place, and that no one agrees on what the the
structural features of brainstorming actually are in the first place?

In any case, I don't understand your writing very well because it doesn't show
a lot of clarity, but if you really wanna keep up a debate, I don't mind.

------
one-more-minute
For some of the stuff about types and optimisation in particular, you should
check out Julia's type system [0]. First-class types, avoiding inheritance,
optional type restrictions, and (albeit early) support for static checking
[1], it's all there.

It'd be worth taking a look at things like its macros as well – I actually
think Julia hits on a lot of the points in this post really well, though of
course no language is perfect.

[0]
[http://docs.julialang.org/en/latest/manual/types/](http://docs.julialang.org/en/latest/manual/types/)
[1]
[https://github.com/astrieanna/TypeCheck.jl](https://github.com/astrieanna/TypeCheck.jl)

Minor nitpick:

> Tut, tut. That should really be a set! It’s much faster, O(1).

Structures like sets have a lower _complexity_ but higher constants (i.e. the
overhead of hashing the value etc). When you have a small number of values, a
straight linear search over an array will often be faster (which is why it's
useful to have the explicit choice).

------
okasaki
>If your language has braces, then you are indenting for the sake of humans
(because humans are good at noticing alignment and edges), and bracing for the
sake of computers. That’s double the effort for something as mundane as where
a block ends. If they get out of sync, then your code naturally breaks in a
way that’s very difficult for you to detect.

No, I use braces for the computer, and the computer automatically and
unambiguously indents it for me.

If anything the wasted effort happens in whitespace significant languages like
Haskell and Python where the computer can't tell what you want and you have to
cycle through all sensible indentations (for every line!)

~~~
seanmcdirmid
The computer is really quite proficient at inferring block structure from
indentation, and if you use a modern editor this structure is manipulated
rather effortlessly.

The main problem with indent oriented languages is that not everyone is or
wants to use a modern editor. Then there are LISPers who think braces
everywhere are a swell idea.

~~~
geocar
> The computer is really quite proficient at inferring block structure from
> indentation, and if you use a modern editor this structure is manipulated
> rather effortlessly.

Nonsense.

Try pasting a block of Python into Hacker News and you get something that
starts off like this:

import os import random def do_something(x): if x: fd = os.open(x)

and only gets worse. A language with braces/semicolons has no such problem; it
is _easier to communicate with others_ , and the absolute value of being able
to communicate with others when starting a new language is exceptional.

~~~
vertex-four
> A language with braces/semicolons has no such problem; it is easier to
> communicate with others

If someone posts more than two lines of practically any curly-brace language
as one line, it's illegible. Yes, you can pull it into an editor and fix it
automatically, but it's a _huge_ waste of time that is best fixed by simply
posting the code properly in the first place.

~~~
geocar
> any curly-brace language as one line, it's illegible.

 _You_ might not be able to read it, but others can, so it is _by definition_
not illegible.

"Indention language", on the other hand, has actually lost its meaning and
_therefore_ is illegible.

> it's a huge waste of time that is best fixed by simply posting the code
> properly in the first place

Helping others is never a _waste_ of time, but telling people thy are too
stupid to ask for help _correctly_ is cruel.

~~~
vertex-four
> Helping others is never a waste of time, but telling people thy are too
> stupid to ask for help correctly is cruel.

Asking others politely to help you help them is not cruel in any way. If you
allow a community to become a place where people can ask questions without
putting _any_ effort at all in themselves, you end up with all the people who
can actually help leaving, and your community being full of people who will
only ever put in the bare minimum of effort.

~~~
geocar
"Help you help them" however is only necessary in the python example because
data is lost. The indention doesn't _mean anything_ to C programmers, and thus
I need no help from them to help them.

~~~
vertex-four
> The indention doesn't mean anything to C programmers

So you could read and debug a 5000-line program written all on one line
without reformatting it?

~~~
geocar
What does "5000 lines all on one line" mean?

If it fits on a page I don't have trouble reading it. Line breaks tend to make
it harder to fit on a page and not easier.

Example:

[http://www.nsl.com/papers/origins.htm](http://www.nsl.com/papers/origins.htm)

~~~
vertex-four
You can honestly read and understand that as-is? And adding line breaks and
proper indentation would make it absolutely no easier? Impressive. I don't
think there's many C programmers who have that ability.

~~~
geocar
Yes I can read this, and adding line breaks would not make it easier.

In fact I think it would make it worse.

This has come up before, if you're interested:

* [https://news.ycombinator.com/item?id=8476189](https://news.ycombinator.com/item?id=8476189)

* [https://news.ycombinator.com/item?id=8476702](https://news.ycombinator.com/item?id=8476702)

It is also something I set out to learn how to do because I saw someone else
do it: If someone produces smaller and faster code than me, then I should want
to learn from it.

When working with others, I will often extemporise my code for their sake. I
sometimes make mistakes when doing this, but sometimes making friends is more
important than fast and correct programs.

------
zak_mc_kracken
> it’s sometimes asked why len in Python is a function, rather than a method.
> The answer is that of course it is a method, called __len__. The real answer
> is that Python pointedly and deliberately does not reserve any method

That's some comical post rationalization.

The reason why len is a function is because it was in Python before Python
started receiving OO features.

As a result, Python is a crazy hodge podge of imperative, OO and functional
semantics where you never know if you should be calling `o.foo()` or `foo(o)`
unless you've been writing Python since the late 90s.

~~~
sanderjd
I really like the approach of allowing either kind of call, with the "dot"
style mere convenience over the function style. Rust has that sort of thing:

    
    
        let v = &vec![1u32,2,3];
        println!("{}", v.len());
        println!("{}", Vec::len(v));

~~~
kibwen
In general this feature is sometimes called "Universal Function Call Syntax"
(UFCS), though interestingly Rust does it exactly the opposite of most other
languages with this feature. In Rust, defining a method lets you use it as a
free function; in C# and D, defining a free function lets you use it as a
method.

------
bsder
This bothered me a lot:

> I seem to have a knack for trying to write things in Rust that rely on
> intertangled references and mutability: first a game, then a UI library…

First of all, a UI library is _EXACTLY_ the kind of thing I want you running
through Rust and having a long, drawn out fight over mutability. Every UI we
currently have absolutely _sucks_ in a multi-threaded context. I want the
compiler to make you think long and hard that maybe, just maybe your ideas
about how to architect a GUI library are very broken and that you have to
restart from a clean slate.

As for a game, do you _really_ have that much mutable state, or are you just
conditioned to use mutable state by default? Games _do_ have lots of mutable
state, but games also have lots of bugs due to multi-threading that being
forced to analyze mutable state exposes.

------
pnathan
This is a great bag of "Hum, these things irritate me, let's do better".
Couple critiques come to mind:

\- too Rust/Python focused - the author needs more rounding of PL experience.
I would suggest spending some more time with Haskell/ML and then some time
with Common Lisp/Scheme. Reread the Programing Languages survey textbooks from
college.

\- not really enough familiarity with the theoretical side of PL. A metric ton
of work has been done in academia, some of the listed problems have been
solved, and at the worst, will give the author a nice way to go to sleep at
night. This kind of relates to the previous point.

The concept of _Locality_ I think is an important one and a real take-away
from this essay. You want to be able to ensure that your code is meaningful
locally without bouncing around half a dozen modules and inheritance trees
just for basic understanding.

------
CyberDildonics
Whenever I see something like this I feel like it is someone unfortunate who
has thought a lot about language design but unfortunately hasn't heard of
julia. His list is almost a checklist of the reasons julia was created.

------
ahoge
The inference example is actually a good illustration for why you want to add
types to a function's signature.

As the author mentioned, a machine can look at how the arguments are used and
make some educated guesses. The big problem is that humans have to do the
same.

That's why I like optional types à la Dart. Not only do they help with static
analysis, they also act as documentation.

With a good editor, this documentation is right at your fingertips. When you
type a function's name, a call-tip will remind you of the expected arguments.
If you've added type annotations, the types will be there, too.

~~~
DanWaterworth
> a machine can look at how the arguments are used and make some educated
> guesses. The big problem is that humans have to do the same.

Why? Just get the machine to do it.

It's like when you see programmers doing arithmetic in their heads. "You're
sitting in front of a glorified calculator!"

~~~
ahoge
> _Why? Just get the machine to do it._

I meant the writing stage, not the checking stage.

Imagine you don't know which type to pass. So, you'd have to pass something
(null or whatever) in order to generate an error which gives you a clue.

That doesn't sound very convenient.

Well, the machine could check which types match that fingerprint, which might
work okayish if the list isn't too long, but it won't tell you anything about
the writer's intend.

Is a list of doubles, a list of ints, a Float32x4List, or a Float64x2List
really the same thing?

What if it's actually meant to be used with something else which also supports
the [] operator and whose items support the + operator.

Static analysis might not be able to tell you because it doesn't know all
packages in existence. That package might not have been referenced, because
that's not required to use a type from that package.

How does the generated documentation look like? It takes one argument "foo"
which is something which has a "bar" field and a "baz" method? I'd rather have
a concrete type there. "int x". Done.

What if you optimize the function a bit and now the fingerprint doesn't match
one or more types anymore. Was this a breaking change?

Your intention didn't change. You always had one particular type in mind.

~~~
DanWaterworth
I'd encourage you to try writing some Haskell. It's a good example of type
inference that works.

~~~
ahoge
You didn't answer my questions. I have no doubt that untooled unitypedness can
be improved upon.

------
octatoan
I kind of like languages that require "a complete upheaval of [one's] mental
model of the universe". :)

~~~
sparkie
I think it's necessary to look for such alternative approaches when the ones
we're using are resulting in ~5 bugs per 1k lines of code on average, frequent
security issues, crashes, race conditions, etc. Plus the hundreds of man hours
spent fixing these problems.

With technology coming more and more into our lives, such that our lives will
depend upon it behaving as was intended, we're really going to reach a point
where we've got to say enough is enough. The languages (and approaches to
development) we're using are not fit for purpose anymore.

------
frik
The lang I want would be mixture of C, C++, Go, Rust, Julia, JavaScript 6, PHP
7, Swift, Lua.

    
    
      * Optional typing (like PHP7/Hack/ES7)
      * support for compilation (statically linked native
        binaries) and JIT (like Visual Basic 6 with its P-Code)
      * memory safety (no null/dangling pointers like Rust)
      * procedural & object oriented & functional style 
        (like JavaScript/PHP/C++)
      * modern base standard library / API (like 
        C/Go/JavaScript/PHP but more modern with better naming, 
        not as heavy as Java class libraries or .Net Framework)
      * third party libraries (like Nodejs NPM)
      * online documentation with code samples and 
        community comments (like PHP.net)
      * good debugger
      * IDE plugins for IDEA/Eclipse/VS
      * good OS support (32 & 64bit) for:
        Windows & OSX & Linux & BSD & iOS & Android.
    

Edit:

    
    
      * Actor model (like Erlang)
      * Built-in concurrency primitives:
        ° light-weight processes (like Fibers in WinAPI, 
          Coroutine in Lua, Goroutine in Go), 
        ° Channels (interprocess communication and 
          synchronization via message passing like in Go 
          and OCaml)

~~~
ICWiener
"modern base API", what does that mean?

~~~
frik
I meant "language standard library" (I updated the text).

C/C++/Object-C/PHP have short functions with names like _strlen_ , _strstr_ ,
etc. Java/C#/JavaScript have _.length()_ and things like
_System.out.println()_ / _Console.Write()_. Ideally, I would like a middle
ground. The Java/C# standard library is too verbose and the C standard
functions are a bit cryptic.

It's great one can use different programming styles in JavaScript/PHP/C++. In
PHP many functions are available in procedural and object oriented style, e.g.
[http://php.net/manual/en/mysqli.query.php](http://php.net/manual/en/mysqli.query.php)

~~~
ICWiener
My own point of view is biased, admittedly, but I couldn't stop thinking that
Common Lisp was relevant for each item in your list.

Of course, much isn't built-in, but this is not as bad as it sounds:
concurrent channels are not part of the language specification, but you can
install the "calispel" or "cl-actors" libraries that gives you what looks like
primitive constructs.

Regarding "modern" languages, I like this quote from the author of pgloader:
"I switched from Python to Lisp because I wanted a modern language" (also
transcribed as: "[...] in searching for a modern programming language the best
candidate I found was actually Common Lisp."; see
[http://tapoueh.org/blog/2014/05/14-pgloader-got-
faster.html](http://tapoueh.org/blog/2014/05/14-pgloader-got-faster.html))

------
zem
the section on loops, in particular, really captured a small but ubiquitous
frustration in every language I've used. we really should be able to say "this
is the first iteration", " this is the last iteration" (though that one might
not always be possible) and "did the loop run at all?" without getting into
index comparisons or manually setting and modifying flags.

~~~
jedharris
Peel 6 has phasers to do exactly this.

~~~
zem
beautiful. i really should take the time to explore perl 6.

------
nathell
I find myself nodding along as I'm reading this.

------
k__
I would usw tab instead of space, so everyone can adjust their indentation
width.

~~~
paxcoder
That's fine for indentation, but all of it must be exclusively tabs, no
spaces. But then to align other things, you have to hold space and do it
manually.

------
Zelphyr
In many respects I think what you want is Rebol.

