Live data from Hacker News

The Unison language

unisonweb.org

141–144 of 144 posts

Re: The Unison language

#141
post #59
post #50

Earlier quoted context omitted.

Syntax is easy to show, but ultimately rather unimportant. If the big idea of a language is something substantial, starting by showing the syntax arguably just creates a distraction.

Syntax stops me from even considering some languages, because to a lot of us it is important. I spend most of working hours reading code; as a result how easy it is to read is important not just for my productivity, but for my overall happiness in life. A small sample on the front page will not tell me if a language is good enough, but it can give me an idea if it's worth spending more time reading up on it or not.

What makes a program easy to read is not its syntax but its semantic, that dictates how much context one has to keep in mind to be able to understand a small fraction of code.

For instance, C and Go are easy because they do not hide anything and what one sees is pretty much unaffected by what one does not see. On the other hand, because those languages do not permit to build efficient abstractions they are also harder to read because each given sample, although unambiguous, perform very little.

Other languages like C++ (despite a syntax that is close to that of C) or Haskell, allow the behavior of the simplest operators, including the application and the sequencing operators, to behave in unfamiliar way or hide subtle but meaningful details, which makes understanding any small bit of code like a gamble (one has to assume some behavior for operators, constructors...). On the other hand, they allow to build abstractions that make programs more terse and therefore easier to read.

In this trade of, none of the alternatives depends significantly on the syntax.

I think a lot of people have associated obscure syntax with bad programming experience because of perl, the language which syntax became synonymous for bad. Indeed, this is a case where the syntax can be teacherous, but still the language is made more problematic by its semantic, that tries hard to give a meaning to any use of any variable in any context, this delaying runtime errors even more than other runtime typed languages and even masking them entirely (then performing something else than intended).

I think this mental association must be done away with.

Re: The Unison language

#142
post #46

Earlier quoted context omitted.

How can you tell the elegance or gotchas from a 6 line Hello World?

It's how I picked my favorite Python web framework, I compared all the hello world samples they all had, and wound up with CherryPy. The rest had too many decorators and it just looked silly to me. You can also figure out if it's C-like or Lisp-like, and so on from looking at syntax.

From what you describe, sounds to me you picked your framework mostly at random, like one would pick a car for its color.

Re: The Unison language

#143

Earlier quoted context omitted.

There's nothing philosophical about it! There will exist a conflict as far as Git (or any other) version control system is concerned. That's all he saying!

The files holding the ASTs are append-only. So you get: PR #1: appended stuff PR #2: appended stuff So there is no merge conflict in the git sense.

> The files holding the ASTs are append-only. So you get: PR #1: appended stuff PR #2: appended stuff

But that description also applies to git. Which could not avoid having to deal with conflicts.

Re: The Unison language

#144

Earlier quoted context omitted.

There's nothing philosophical about it! There will exist a conflict as far as Git (or any other) version control system is concerned. That's all he saying!

The files holding the ASTs are append-only. So you get: PR #1: appended stuff PR #2: appended stuff So there is no merge conflict in the git sense.

I disagree: in #1 and #2, the mapping between the key and the function name are different, so there is a conflict.
Post reply on HN