Hacker News Reader

Comment by rdtsc | Hacker News Reader

> a=[int\]<-0; op=[char\]<-' '; b=[int\]<-0; r=[int\]<-0; 0 { clock => [int ms] { ("\r" + ms/1000.0 + ":" + a + op + b + "=" + r) ->std.out; 1 std.delay (ms+1) clock} }; inLoop => {\std.in->a \std.in->op \std.in->b inLoop}; \\op ?? {'+': (\a+\b) '-': (\a-\b) '': (\a\b) '/': (\a/\b) : 0} <->r;

That is not exactly selling the language.

Saw that, closed the page.

View on HN

Yeah, I'm having to fight really hard to continue giving the language a shot after seeing that syntax. Let's see, from their Dining Philosophers example:

[]{

Already, the syntax is starting to look a little strange, but OK, I'll give it a shot.

    id = [int\];

Hm. Backslash seems to be used for something other than escaping. Not a good sign.

=;

Huh? The equals operator is being used alone, with nothing on either side? That's really stretching the bounds of convention.

    -> --> <-> <-

We have various types of arrows that are used as syntax. In some cases, they're used as binary operators, in some cases as unary. Doubling up of dashes appears to change the meaning. This is really not looking good.

And then there's the example you mention. Besides how it looks; their example of solving a useful concurrency problem is "a bug-free, efficiently multithreaded real-time clock + infix calculator hybrid application"? Why would you even want that?

There may be something interesting here, but between their quite bizarre syntax and poorly chosen examples, they aren't doing a very good job of hooking me.

Hm. Backslash seems to be used for something other than escaping. Not a good sign.

From the tutorial[1]:

In ANI, \ means "latch". Basically, a latch is a place where you can "hold on to" an object of the specified type. A latch is like a box that you can put things in to, take things out of, and peek at what's inside.

[1] http://code.google.com/p/anic/wiki/Tutorial

The only thing worse than using backslash is using postfix backslash...

If it weren't for the long-running convention of using backslashes as escape characters, postfix backslash would make some kind of sense, at least visually.

Forward slashes are for prefixes, backward slashes are for postfixes. Nice parallel there :)

No, they would be perpendicular.

Aside from breaking the escaping convention, slashes in code give the page an unfortunate swirly quality. It seems like line other parallel or perpendicular can make the line of the page look it is at a different angle.

I'll never understand why people keep going out of their way to make new weird syntaxes. Is it really necessary? Does it really give something over well established C-like syntaxes?

At the very least, people should approach new languages from an ease of typing angle. I look at that and all I can think is "That would be a bitch to type out. Doing it all day? No thank you."

Ease of reading I hope!

I have too seemingly opposing thoughts on this.

One part of me says "Don't reinvent the wheel", but the other part of me suspects that forcing a new language to follow the syntactical conventions of another language that was designed with different considerations in mind is a bad idea.

The best example of a language that I think suffers from it's association with the syntax of another is C++. The features that it provides are all more or less fine, but cramming it into a syntax that was made for a much simpler language really wasn't a good idea.

(I understand why it was done from a historical perspective, and understand the few benefits it affords, but I think those are particular to that example)

On the other hand again, there really isn't a lack of syntaxes these days that a new language developer can look to for inspiration. Surely one of them should work fine most of the time.

This specific one is just bad though. I mean "\" is really difficult to type on almost all non-us keyboards. It's not even really easy on US keyboards (the pinky has to go a long way). See how often it's in there. Even standard C syntax is a pain on some non-us keyboards. I.e. on a German keyboard, the [, [, {, }, are rather difficult to type. That's why I (being German) switched to an English layout around two years ago. Now I have trouble typing umlaut and thus writing good German, but at least my coding speed improved by probably 50% and my Hand hurts far less.

Yes, without doubt this specific one is bad.

You might want to try the Neo layout. It's a modern layout that includes international characters, like German Umlauts.

(I'm also German and switched to American Dvorak earlier. I only heard about Neo later, and am too lazy to switch now.)

I guess if LCtrl and their LMod3 were swapped (ie so that capslock is used as Ctrl for shortcut keys), I could see this being an interesting layout. It has all the common keys either on the home row or easily reached from the home row. I can't ever see myself switching from Colemak though, I like how the fingers roll across adjacent keys too much.

(Plus since I don't type much German, I don't need quick access to üöäß, though an English-centric variant of Neo would be.. interesting, maybe using those keys for the most common programming symbols?)

There are various keyboard layouts that are superficially English but which allow various diacritics via dead keys, such that, for example, you can type AltGr+" followed by u to get ü. (I just did exactly that.) I know of us altgr-intl on Linux (that is, xkb), but there are similar layouts on OS X and Windows.

Now I'm interested to know which languages exist that don't rely heavily on backslashes. I guess I can't think of a language that doesn't use blackslashes for string escapes. Some other uses off the top of my head:

    * C -- line-continuations (important for macros).
    * Perl -- regex back-references.
    * Haskell -- anonymous functions.
    * Python -- line continuation.
    * Tcl -- line continuation.
    * Icon -- non-null test (unary), generator limitation (binary).
    * Prolog -- \+ for not provable.
    * J -- the prefix adverb and the grade-down verb (\:).
    * TeX -- Yes.

Technically, for Perl you can use $ for regex backreferences. I don't remember which one is preferred, but I remember it frowning upon one of them.

What you use depends on where you use it. Inside of a match, \1 refers to what was matched by the first parens. After the match $1 refers to what was matched. In a substitution, \1 is special cased to mean $1, but that is frowned on.

Thus: /\b(\w+)\W+\1\b/ means "match repeated word".

And: /\b(\w+)\W+$1\b/ means "match word preceeded by the word matched on your last match.

Moving on: s/Hello (\w+)/Goodbye $!/ means "Replace Hello followed by a word with Goodbye followed by the same word."

And finally: s/Hello (\w+)/Goodbye \1/ is special cased to mean the same thing, but is frowned upon.

> Now I'm interested to know which languages exist that don't rely heavily on backslashes.

I posit that line continuations don't count, at least not in the "rely heavily" category.

Then I am not sure how popular J and Icon are. So let' keep those away. Is the backlash really used that often in Prolog? I wouldn't say "heavily". So that leaves us with:

    * Perl
    * Haskell
    * Tex

I think that's a more realistic "rely heavily" category.

"\tDon't forget the \"main\" uses.\u263A\n"

During my perl experience, I learned that any special character next to $ is usually some magic variable that does something. So I would bet that $\ also does something.

edit: oh yeah.

$\ - The output record separator for the print operator. If defined, this value is printed after the last of print's arguments. Default is undef.

I solved that problem by binding capslock to Alt Gr and using a custom US layout with Alt Gr plus e-[;' bound to €ßüöä. This basically allows me to quickly switch to the German layout when necessary without losing much speed.

"Surely one of them should work fine most of the time."

S-expressions?

NB I once got paid to write Lisp, C and PostScript on the same project, if nothing else it taught me to be somewhat flexible about language syntax.

You could ask they the same question about C-like syntaxes? Was it really necessary to invent anything new after somebody had hit upon S-Expressions?

Anyway, to answer in the affirmative: Certain paradigms provide from certain syntax. E.g. Haskell would be much clunkier to write in a C-like syntax than with the ML-derived one it has. And Lisp's macros would be harder to pull off with a different syntax. In my opinion, Python also profits from syntactic differences with C.

Somebody more knowledgeable could talk about SQL-syntax.

> At the very least, people should approach new languages from an ease of typing angle. I look at that and all I can think is "That would be a bitch to type out. Doing it all day? No thank you."

Old languages would also benefit from that approach. We've seen some alternative syntaxes JavaScript, but not really for something like C.

Have you read the tutorial?

ANI is a very different language to C. Using a C-like syntax wouldn't make sense.

It's the other way around, language designers go out of their way to conform to C-like syntax in order to cater to programmers of C-like languages.

C's syntax is a fairly low level, which makes it fairly easy to map to assembly, but not very well suited for representing high level constructs (see C++).

LOOK UPON MY WORKS, YE MIGHTY, AND DESPAIR: http://kx.com/q/c/c/k.h

Note: This is production code.

Oo, where'd you get the C minimizer?

This is the way that APL programmers write C.

Jesus, my research project once depended on this file. The day we deleted it from the repository was a very happy one.

That was a fun search and replace exercise I bet... ;-)

I imagine searching for Z, R and O in a large code repository.

  // remove more clutter
  #define O printf
  #define R return
  #define Z static
  #define P(x,y) {if(x)R(y);}
  #define U(x) P(!(x),0)
  #define SW switch
  #define CS(n,x)	case n:x;break;
  #define CD default

Thanks for that. The comment makes it classic.

orz: the person maintaining this code

Maybe the tutorial would be a better first impression:

http://code.google.com/p/anic/wiki/Tutorial

I thought the idea of Streams was interesting and appreciate OP for posting this.

This is a free creation by someone out there who gave their time to do something harmless, useful and freely shared.

There is obviously a lot of effort put in it. The idea behind it is so cool. He shared and put it up. That's very good.

But unfortunate part of sharing is also receiving criticism.

Sometimes criticism is stronger when the initial expectation is higher. I think most clicking that link got excited about all the features they read before then they got disappointed when they saw that piece of code.

So his job is not to babysit other techies, i.e. he doesn't care about how others see this project, so then he wouldn't mind the criticism either, right?

Indeed, but criticism is subject to criticism too, specially if perceived as latent cynicism.

If the headline were not so ridiculously conceited, I would agree with you entirely.

On the other hand there's something to be said for terseness. Ever read a math or CS paper that's full of equations and other graphical shorthand? To the uninitiated, it's gibberish. Once you learn the conventions, it's a way to communicate complex formal ideas with very concise notation.

I'm not saying this language does a good job at that, but to dismiss something interesting just because of syntax prejudice is shortsighted.

Maths is not about conventions. It is a dynamic writing style. All operators get replaced by adjacency after a few lines as writing them is boring. Computer verifying proofs is very hard for notation reasons.

Pretty much every CS paper I've read that was full of equations could have easily done without them. There certainly are sub-fields of CS where complex equations in papers are justified, but far too often it is laziness, and hides assumptions or imprecise descriptions that makes implementing the described methods harder.

Mostly, when I come across complex equations in CS papers, I tend to skip over them and only go back to look at them if there are parts of the paper I can't make sense of without them - it is very rare to find that they are necessary at all.

The cases where I find I need them are usually a sign of trouble - it tends to mean there'll be a lot of guesswork to figure out parameters and parts of the algorithms that are not spelled out in the paper at all. But usually the same ideas will be expressed in English, code or pseudo-code in much simpler ways.

My research for my MSc involved a bunch of papers on error correction in OCR, including a ton of image processing and statistical analysis, and not one of the 50+ papers I reviewed actually depended on the equations present in them for understanding the ideas, but I quickly learned to appreciate the ones that were light of equations for the seemingly substantially higher odds that the algorithm descriptions would be pretty much complete and precise.

There certainly are sub-fields of CS where complex equations in papers are justified, but far too often it is laziness, and hides assumptions or imprecise descriptions that makes implementing the described methods harder.

But without such obfuscation, how would CS PhDs retain their competitive advantages?

I mean, if anyone could just read your paper and actually implement the algorithms that you talk about there without having access to your base code and the real details that you didn't publish, then they might scoop you on the next (quite obvious) iterative improvement to your algorithm without having to do two years of preliminary work. And then you'd only get one paper out of it, whereas by obfuscating the hell out of the thing, you can milk it for five or six.

> Mostly, when I come across complex equations in CS papers, I tend to skip over them and only go back to look at them if there are parts of the paper I can't make sense of without them - it is very rare to find that they are necessary at all.

Obviously any equation can be expressed in words, but those who are familiar with the notation are able to read the equations and understand the ideas in a paper in a fraction of the time. This is important for those who read papers regularly.

Apparently, you didn't read the line above the code, saying that this is a compacted version. If you removed whitespace from a C code, you would get something that is even worse.

Why would you showcase a compacted version of the code...?

I guess he was trying to demonstrate what you can achieve with a small number of characters. It may not be a good idea from a marketing perspective but come on... "Saw that, closed the page" is simply narrow minded.

It's not a good idea from any perspective. In my experience, the only people who cram as much logic into as few characters as they possibly can are beginner to intermediate level programmers who are in that awful phase where they think they know a lot more than they do.

My point was that displaying that on the front page about your language is not going it any good.

It is like showing obfuscated C to someone you are trying to convince to look at C

It's just a little dense to demonstrate the succintness of the language. The 2 samples above are normally dense. I really don't see the problem. It's not clever to make a judgement about a language (whose syntax you don't know) just because you don't like some sample of it.

I think some of the language's concepts are pretty neat and unusual.

See I think language is a tool and some judgement about a tool is more rational -- so I appreciate all the features listed about it, it is very unique, other judgement is more subjective -- "oh I don't like to use curly braces" or "stupid Emacs keybindings are breaking my pinky finger" etc. and those are also very important decisions for picking a tool.

I just highlighted that the choice to present the most obfuscated and hard to read (and by number of upvotes it seems that most agree) piece of code on the front page of the language is not helping appeal to that second (subjective) part it drives people away before they even get to click on the the tutorial (which explains what is what).

Reading the tutorial (http://code.google.com/p/anic/wiki/Tutorial) is a less unpleasant experience.

I agree. After reading the tutorial, I want to try this out. It looks like fun.

But after skimming over the tutorial my impression is that the concepts are so simple there's even less excuse for that horrible syntax.

Uncomfortable syntax can be excusable if you have a clear rationale for it, but I can't for the life of me see why this syntax would need to be this awkward.

That particular snippet caused me to have a bad flashback to the days when I admired Perl for its terseness and "expressivity".

At this point I shudder at the thought of having to maintain any of that code. I'd even prefer to work on the C I was writing in high school.

As I say. There is write-once code. When I write it and nobody else can't read it. Then there is worse, there is wire-once and even I can't read it.

It made me scrub my eyes and go 'buhhh?'. I'm all for new languages trying new things with new syntax and design choices, but make them half decent.

Agreed, but the tutorial is actually quite good and the syntax (mostly) makes sense to me now.

What I don't understand is that writing a stream that unlatches a "variable" (a thing bound to a latch) executes once per time the variable is set, but it's not clear why the same code bound to a constant doesn't loop infinitely.

i.e.

i = [int\] <- 10; \i -> std.out;

executes once because i was set once.

i = [int\] <- 10; i -> std.out;

executes once because...

Of course, every new language should look exactly familiar to us users of existing languages.

God forbid we should need to learn any new syntax or shudder concepts! The old ways are the best ways.

If the example code doesn't look INSTANTLY, IMMEDIATELY awesome and amazing, it isn't worth a second glance. Even the first glance was a horrible waste of time!

You're attacking a strawman. OP never said that any new syntax is bad.

I admit I was snarky and maybe jumped to conclusions ;) But it sounded like OP took a look at the syntax, had a quick visceral reaction to it and closed the tab.

If I read that wrong though, then my apologies.

The syntax put me off at first, and still bothers me a bit (something to do with too much symbolic sugar and existing familiarity with escape chars)

That said...

I feel like this streaming syntax might be better suited as a meta-programming framework of sorts...build the more intricate objects/modules in a language such as C/C++ or java, and use these stream/latch metaphors to orchestrate those modules.

Yes, you can already do this with *sh (largely the point of Unix pipes), or directly in C/C++/Java (e.g. Storm), but ANI seems to provide a really rich interface for this kind of orchestration. It has many of the right primitives.

> feel like this streaming syntax might be better suited as a meta-programming framework of sorts

I think that is why the criticism is more apparent. It is exciting to have those features, but then the syntax just pushed you away.

On a german keyboard \ is not just "a single keystroke". What a pain -_-

The dining philosophers example doesn't look too unreadable on first glance.

Yeah that was ok, but why put this obfuscated code on the front page?

same here.

Agreed. Here is a suggestion to budding syntax creators: If 90% of the code is written by your pinky finger; stop. You're doing it wrong.

Reply on news.ycombinator.com