Hacker News Reader

Comment by Xeoncross | Hacker News Reader

Looks really interesting. The readme actually got me started with lots of good examples.

Side note though: I won't ever use a symbols-instead-of-words language unless I have to.

    let { (*>), (<*), wrap } = import! std.applicative

This is not my idea of good language syntax. I like jr developers, non-X language developers, hardware guys, and even graphic designers to be able to understand my code.

Consider simple string concatenation. This is what it looks like in Objective-C:

    NSString *one = @"Hello";
    NSString *two = @"World";
    NSString *three = [[one stringByAppendingString:" "] stringByAppendingString:two]

Total fail for something so simple.

View on HN

I'm dyslexic. I haven't looked into it in detail, but someone once told me that dyslexia is some kind of problem processing things that are pronounceable. When I was learning Japanese I was amazed how easy it was to read kanji (the Chinese) characters. Apparently processing things that are inherently symbolic (even if you can pronounce them) is done differently. It was like someone lifted a veil. Even now I prefer reading Japanese to English. I suspect if I learned Chinese I would enjoy it even more.

The same goes for languages with symbols. For me, they are an order of magnitude more readable. Obviously people with dyslexia is a very narrow group to design a language around, but I suspect that there are others who also find it easier to think about symbols than words. That's why people design languages in this way (and as someone else pointed out, probably why math has such a large number of symbols).

There are things that are easy to learn and things that are easy to use. Often there isn't as much overlap as you might expect between the two group. For something like programming languages, I'll take easy to use over easy to learn any day. Having said that, I am absolutely sure there are people who prefer having a big block of prose in their code. I see that kind of code frequently as well, so which one is easier to use almost certainly depends on the person.

Great insight, thank you for sharing. I'll keep this in mind. Maybe in some cases a middle ground could be finding a way to use less symbols instead of more. Verbosity isn't always desired with symbol or prose.

The input method for symbols is the other problem. Math notation is used for quickness.

Sometimes you are expressing a specialized concept that, even when translated into words, won't be readily understood by someone without domain knowledge. That's when I believe symbols are very useful.

In this case we are dealing with an applicative functor. If you know what's an applicative functor, you will immediately know what these symbols mean. If you do not, even if we translate <* as `sequenceActionsKeepFirstValue` you still don't know what this is doing.

I know what an applicative functor is and I struggled to map what <* and *> are. These are not standard, even in the niche world of functional programming.

These symbols are part of the definition of the Applicative type class in Haskell http://hackage.haskell.org/package/base-4.11.1.0/docs/Contro...

Same with Idris and Scalaz. I don't know how much more standard it could be.

standard it might be, but I seriously hope IDEs would give a hint on what to google when a junior sees "<"...

try googling < or "scala <*"...

I kind of miss the days where you would turn to the manual, read and understand it, before doing serious work in a language.

I've had a junior dev ask me what kind of strange multiplication thing was going on in our C code base. If you don't even know about pointers, maybe you're not "junior" yet and should learn some more.

The asterisk symbol in C is heavily overloaded too; it can mean a pointer type, dereferencing a pointer, multiplication (of ints, floats, ...).

another instance where IDEs can help juniors by providing hover-to-show-name/descriptions

An IDE should just show the pronounceable name of that symbolic alias on hover.

Symbols are fine as long as they're alias names for fully written out names.

I think Scala will support such an IDE feature with an @alias annotation in the future. (I saw that idea on a slide in a talk of M. Odersky some time ago but actually don't know the current status).

Search features for language documentation should recognize special characters as such. For asterisk that gets very ambiguous though, unless it uses regex or something else, standardly.

Then use nicknames, or abbreviations. Searching for symbols is very hard on the NLP dominated Web. And even if Google is getting better (but I tried a month ago with Scalaz symbols, and half of them failed), the other search engines (for example Lucene used by forums, or full text indexes) will strip out every non alphanumeric character.

I'm confused by your example, which seems to be the opposite of symbols-instead-of-words. It's words-instead-of-symbols gone berserk.

Cleaning things up:

NSString one = “Hello”;

NSString two = “World”;

NSString three = one.appendString(“ “).appendString(two);

I agree with him, except for the super verbose method name, the symbols are a problem.

one, two, and three are pointers. @"Hello" is shorthand for creating an NSString instance, which is a heap-allocated object. Both of those are important in the context of Objective-C, so they can't just be left out entirely. (I also think Objective-C is a pretty extreme example here since its syntax is limited by its history as a preprocessor layer over C.)

Setting aside those, the Objective-C code uses these symbols:

   ; = "" [] :

And the example you provide uses these symbols:

   ; = "" () .

It doesn't seem like the perceived improvement is from eliminating symbols, but from switching from Objective-C's Smalltalk-like method invocation syntax to a more familiar (to many devs) C++-style syntax. Also, it seems to me that leaning more on symbols makes the code even easier to read:

   NSString one = "Hello";
   NSString two = "World";
   NSString three = one + " " + two;

Judicious use of overloadable/custom operators can make code easier to read, especially when they express an operation that can't be expressed clearly in a word or two. <>, > and <* fall into that category.

I really, really wish people would stop using + for string concatenation in new languages they design. It shares only a tangential relationship to arithmetic addition, and even that's a stretch. It's caused an enormous amount of bugs in numerous different languages. Please, let's just let that concept die for newer languages.

Do you have examples of bugs that it causes when more strictly typed? That is, string + number is an error.

In those languages, it's more a cognitive mismatch (usually covered up as it's what people learned it as).

Even then, people seem to think of + as a special case, and in a language that is otherwise very strictly typed will decide to automatically convert between different numeric types (floating point and integer, for example). That's admittedly a different problem, but it shares a lot in common with what I originally mentioned.

I personally like forms of string interpolation:

NSString three = f”{one} {two}”;

Readable and should be efficient.

> It shares only a tangential relationship to arithmetic addition

You’re right—string concatenation is not addition, it’s multiplication. (Contrast “sum types” and “product types” for an intuition, if you don’t have an education in abstract algebra.)

I'd disagree and say that it's value-level addition. Adding the number `3` to the number `5` gives us a single number `8`, not a pair of `3` and `5`. Likewise appending `"hello "` to `"world"` gives us a single string `"hello world"` not a pair of strings.

If we model arithmetic addition with Peano numerals, that would be:

    three = S (S (S Z))
    five  = S (S (S (S (S Z))))
    eight = plus three five
          = S (S (S (S (S (S (S (S Z)))))))

We can model strings as lists of characters (which Haskell does, but is inefficient). It's essentially the same except the second constructor takes a character as argument:

    hello = Cons 'h' (Cons 'e' (Cons 'l' (Cons 'l' (Cons 'o' (Cons ' ' Nil)))))
    world = Cons 'w' (Cons 'o' (Cons 'r' (Cons 'l' (Cons 'd' Nil))))
    greet = append hello world
          = Cons 'h' (Cons 'e' (Cons 'l' (Cons 'l' (Cons 'o' (Cons ' ' Cons 'w' (Cons 'o' (Cons 'r' (Cons 'l' (Cons 'd' Nil)))))))))

The algorithms for adding Peano numerals and appending lists of characters are identical:

    plus Z     y = y
    plus (S x) y = S (plus x y)

    append Nil         y = y
    append (Cons x xs) y = Cons x (append xs y)

If we replace 'Char' with '()' (i.e. `List ()` or `[()`]) then they're isomorphic.

I wrote up some thoughts about this connection at http://chriswarbo.net/blog/2014-12-04-Nat_like_types.html

You'd use `<>` or `++` in Haskell for strings, lists or whatever other instances of Semigroup or Monoid type classes.

I had the same opinion about symbols until I learned some APL. It taught me that symbols can be so useful as they are in math.

It is true that non-math people, hardware guys, or graphic designers may not be able to understand a complex equation and think it is just some kind of hieroglyph, but the right notation can help to make things more clear. Anyway, it is very likely that, for example, a graphic designer would not be able to understand the Maxwell equations even if we wrote "rotational of the electric field" instead of using symbols.

I am not claiming that symbols are always the best solution, but I think they have their place and there is usually a sweet spot for the problem at hand. I'd suggest you to try to keep an open mind.

All this said, there are many (way too many) terrible examples.

> It is true that non-math people, hardware guys, or graphic designers may not be able to understand a complex equation and think it is just some kind of hieroglyph, but the right notation can help to make things more clear.

The semantics of these "hieroglyphs" very much depend on the context, though: "a x B" itself only says "apply some operation x to the named entities a and B".

> The semantics of these "hieroglyphs" very much depend on the context

We need context to understand words too. What is your point?

Words also inform context (bi-directional), symbols derive their meaning entirely from context.

They may give some more context, but you usually need to know the domain up to some point anyway.

For example:

    a = &b;

may just be a weird bunch of symbols if you don't know C. But my point is that, anyway, for someone who doesn't have any idea about what a pointer is:

    a is pointer_to b;

is not going to make it obvious, and it is going to make a simple program with a linked list a nightmare to read for those who know.

I am aware it is also very easy to show an example where symbols are much less helpful than words. Some good ones were given in this thread. I am just suggesting to keep an open mind because I have the feeling symbols can actually make some programs more readable, although finding the right balance is not an easy task.

It is like symbols once internalized like strings, could be used as a tool of thought.

Ah, Objective-C, the language that seems designed as if on purpose to confuse and confound. I'm glad it's on the way into the garbage bin.

Another way to write that would be:

    NSString *one = @"Hello";
    NSString *two = @"World";
    NSString *three = [NSString stringWithFormat:@"%@ %@", one, two];

Not sure if you were trying to make it simpler, but honestly, this also looks needlessly difficult to understand.

Would you say the same about the operators in Java or C?

Reply on news.ycombinator.com