Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Urbit: A clean-slate functional OS

urbit.org

Post reply on HN
Print view View original

61–70 of 185 posts

Re: Urbit: A clean-slate functional OS

#62

Post by FeepingCreature »

urbit wrote: post #50
aray wrote: post #47

Earlier quoted context omitted.

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…

Spread the word of .Xcompose?

Re: Urbit: A clean-slate functional OS

#63

Post by samograd » 

    So if we had to read the above decrement...we’d say: 
    “luslus dec sigfas cen dec bartis a tis pat sigbar soq
    dec soq ketcab pat wutgal tis pel zero a per tislus b 
    tis pat barhep wutcol tis pel a lus pel b per per b buc 
    pel b lus pel b per per.”
Absolute brilliance.

Re: Urbit: A clean-slate functional OS

#64

Post by betenoire »

tlb wrote: post #21

You say addition is O(n^2), but I think you can write an O(n) addition with only increment, recursion, and equality testing. In Python syntax: def add(a, b): return add_r(a, b, 0) def add_r(a, b, c): if b == c: return a else: return add_r(a, b, c+1) +1

It's python, so it can't handle it either way, but by moving the final "+1" into the function call, it becomes tail-recursive.

  return add_r(a+1, b, c+1)

Re: Urbit: A clean-slate functional OS

#65

Post by FeepingCreature »

urbit wrote: post #48
cldr wrote: post #45

> Hoon is a keyword-free language - any alphanumeric text in the program is part of the program. Where other languages have reserved words, Hoon has squiggles. But... why?

You're saying, why are reserved words a bad idea? I think most defenders of the humble reserved word would consider it, at best, a hack. Maybe it's a necessary hack, maybe not. With reserved words you are overloading two very different namespaces, the space of language primitives and the space of user functions/variables. Sure, you can get away with this. But do you want to? A language is a UI, and the potential for…

The alternative, as I see it, is to let people add new keywords to the language from inside the language, so there's feature parity again.

Re: Urbit: A clean-slate functional OS

#66

Post by FeepingCreature »

Well, I've read most the docs, let's say _skimmed_ the code examples, and I think you're a very smart, competent engineer with a sense of what makes for good language syntax that is utterly, incomprehensibly alien to me. So I guess, martian-language mission accomplished?

Re: Urbit: A clean-slate functional OS

#67

Post by urbit »

FeepingCreature wrote: post #65
urbit wrote: post #48

Earlier quoted context omitted.

You're saying, why are reserved words a bad idea? I think most defenders of the humble reserved word would consider it, at best, a hack. Maybe it's a necessary hack, maybe not. With reserved words you are overloading two very different namespaces, the space of language primitives and the space of user functions/variables. Sure, you can get away with this. But do you want to? A language is a UI, and the potential for…

The alternative, as I see it, is to let people add new keywords to the language from inside the language, so there's feature parity again.

Yes. And that's what many people find so elegant about Lisp.

But, one could argue, the "is it a function? or is it a macro?" confusion is a significant cognitive load on the Lisp programmer. These are really two different things, even though you can fit them into the same namespace.

Hoon has the different problem that you allude to - it is hard to extend the macro set at the user level. While this is fairly limiting, many FP languages, like Haskell, seem to do just fine without macro extensions. Perhaps typedness plays a role.

The bottom line on this problem is that there does remain a fair chunk of unused ASCII digraph space, so there is probably a way to put that in the programmer's power, but user-level macros are an unsolved problem in this relatively young language, nor is it one that obviously needs to be solved. But it would be nice if it does get solved.

Post reply on HN