Hacker News new | comments | show | ask | jobs | submit login

I love the project concept. A toy functional OS would be an admirable counterpart to e.g. MINIX. That said, I have one minor quibble:

A programming language is called a language for a reason - it should activate the human linguistic lobes.

Another programmer said this, a long time ago, and that's how we ended up with Perl. Please don't seek to emulate Larry Wall. Perl is great for quick automation, but anything complicated built with Perl quickly converges to unintelligible line noise (barring the exercise of zen-like discipline). If you're making something for beginners, please, please, give them the tools to build abstractions in a consistent and understandable manner.




Well, of course, Larry Wall is a god.

But that said, the main difference between Hoon line noise and Perl line noise is that most of the ASCII we use has a very regular structure, with a (relatively) limited set of exceptions. So it looks about equally alien at first, but the Hoon ideogram (digraph) set should be easier to learn. Unfortunately at present the set of people who know it is very small - so the theory really hasn't been tested.

It is what it is. But at least there's no Unicode. (Not that you can't have Unicode in strings, of course.)

And anyone who doesn't like line noise has to stand up for reserved words. Some of us welcome that conversation...

-----


The unicode-in-strings but not in variables/etc bothers me about Java (coming from Go, where unicode is allowed in variables). It seems inconsistent to have two separate character sets for different semantic subsections of what is a single text file.

What about unicode in comments? If I put a string in a comment can it go there?

-----


Restricting symbols to a strict subset, rather than a strict superset, of global keyboards in practice, is about cultural literacy in practice.

If you put unicode in variables, perhaps because you're using a national keyboard with special unicode powers, your code will be extremely hard to work with for programmers using a different national keyboard. Thus, even if you could do it, you shouldn't.

Now, the symbols on American programmers' keyboards are not all on every keyboard in the world - but pretty much every programmer in the world knows how to find them. Thus, sticking with ASCII is basically sensible use of Postel's Law in the language design context.

In comments - it should be ok but I think it breaks right now. Not a high priority bug, but definitely a bug.

-----


Spread the word of .Xcompose?

-----


I can search Google for reserved words. But I can't search Google for $@_{}

-----


Hey, man, that's all on Google as I see it.

And besides, I can't Google for "go." And yet, Go seems to be doing just fine...

-----


Larry Wall is a great man. And Perl was mighty force. An empire was built, and it may have crumbled, but all empires crumble.

One day you will be repeating these words, to a youngster that says the heroes of your Ruby palace, (or your conquering Pythonistas) were weak men of little vision, and laughs at you for following them. And when that day comes, I ask only that you think of me, and Wall, as I now think of one who followed Backus, and the mighty FORTRAN army.

-----


It's not age. C is older than Perl by decades, but I think C is a lovely little language. Lisp is as old as FORTRAN (almost) and I think it's probably the most elegant language invented yet. No, my quibble with Perl is that in throwing around implicit state everywhere (in an effort to make programming languages more like human languages) Perl is just bad as a system for building complex systems. It's not unique in this regard - Perl shares its weakness with the shell scripts it was supposed to replace.

-----


Python is about as old as Perl

-----


Larry Wall released Perl 1.0 in Dec 1987 - two years before Guido started writing Python. First usenet release of Python was Feb 1991, with 1.0 coming in 1994, with Java coming approx 1 more year later.

-----




Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: