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

Urbit: an operating function

urbit.org

Post reply on HN
Print view View original

71–80 of 177 posts

Re: Urbit: an operating function

#71

Post by AnimalMuppet »

csense wrote: post #58
pcmonk wrote: post #36

Earlier quoted context omitted.

Traditional punctuation names suck. "Ampersand", "at sign", "caret"? For a language like hoon where we use a lot of symbols, that gets really tiring. Having one-syllable names for glyphs is really convenient, and they tend to roll of the tongue. Everyone's free to use whatever names they want, of course, we just find these useful. Most people love these once they get used to them. I don't think you can judge syntax b…

> For a language like hoon where we use a lot of symbols Languages with lots of symbols tend to be incredibly difficult to read at first. If you have a programming language where a typical program looks like line noise, it means the programming language is going to likely have a very steep learning curve (because a lot of those operators are probably not going to have their standardized meaning). Think about Python.…

Well, C has ++, which is different from +, and it has &&, which is different from &. It also has ?:, and >> and To me, C syntax is obvious, because I've been using it for 30 years. It may be a small set of operators, but "meanings close to their standard mathematical ones" may be a bit of a stretch.

Re: Urbit: an operating function

#72

Post by MichaelAza »

yarvin9 wrote: post #23
MichaelAza wrote: post #6

Earlier quoted context omitted.

I always think of TempleOS as well. Both project maintainers have created some impressive and/or interesting technology that is hindered by inflated self importance and being different for the sake of being different. Another common point - HN has a soft spot for both and upvotes most content related to these projects.

It'd be interesting to hear a more detailed description of what you'd classify as "different for the sake of being different." There's certainly plenty of code in this world that's the same for the sake of being the same. It's not terribly interesting to use CGA graphics for the sake of being different. On the other hand, I do wonder whether my children will grow up learning 1970s programming for the sake of being th…

Well, as I see it, the design of Hoon is definetly different for the sake of being different, syntax wise and considering the pronounciation guide. Using new terminology where existing terminology will suffice (off the to of my head, twig and span) is different for the sake of being different.

Re: Urbit: an operating function

#73

Post by MichaelAza »

dustingetz wrote: post #41
MichaelAza wrote: post #6

Earlier quoted context omitted.

I always think of TempleOS as well. Both project maintainers have created some impressive and/or interesting technology that is hindered by inflated self importance and being different for the sake of being different. Another common point - HN has a soft spot for both and upvotes most content related to these projects.

> being different for the sake of being different Urbit has brilliant technical insight into perhaps the hardest problem our industry currently faces: why does everything always turn into a big ball of mud? Urbit may turn out to be incredibly important. Parent comment is unjustified, uninformed, poor tone and ad hominem.

On the contrary, I'm quite interested and impressed by the technical quality of the project. I'm pointing out that throwing all first principles out of the window, even when its clearly unnecessary (renaming the ASCII characters) makes it harder to approach for no good reason.

Re: Urbit: an operating function

#74

Post by oldmanjay »

colanderman wrote: post #57
mcantelon wrote: post #33

Earlier quoted context omitted.

Their opinions about things unrelated to technology are, of course, highly relevant to their technological insight.

Meh, I prefer not to work with bigots. Good to know this fact; I was considering getting involved.

I'm curious. Did you do some research into what was meant, or did the phrase "post opinions about black people" carry some hidden meaning I am not equipped to detect?

There's a heavy implication, of course, but you mentioned a fact. I'm wondering what fact you reference.

Re: Urbit: an operating function

#75

Post by proveanegative »

mcantelon wrote: post #33
GFK_of_xmaspast wrote: post #29

Earlier quoted context omitted.

They're both run by unpleasant individuals who like to post their opinions about black people on the internet, the main difference is Mencius Moldbug uses fancier words.

Their opinions about things unrelated to technology are, of course, highly relevant to their technological insight.

Urbit embodies Moldbug's politics.

Speaking of politics, one of the most interesting practical user-facing things about Urbit that I saw in an earlier video demo was the user choosing his or her political affiliation when registering. The claimed affiliation then acts as a mandatory filter for political conversations. You can opt out of participating in any political discussion but not opt in to more than one camp. I think this is a brilliant idea.

Re: Urbit: an operating function

#76

Post by jpt4 »

pcmoore wrote: post #68

For a more accessible alternative approach to all this madness see this mirror project https://github.com/tibru/tibru

I do so enjoy seeing the casual vivisection of that which tends towards attracting mystical appreciation; what remains intact is all the more deservedly numinous.

For an exactly diametric plunge from the same origin into the rarefied esoteric, there is: https://github.com/mnemnion/ax/blob/master/commentary%20on%2...

Re: Urbit: an operating function

#77

Post by Detrus »

yarvin9 wrote: post #54
tptacek wrote: post #44

Earlier quoted context omitted.

The notion that Urbit believes it can solve all the problems , rather than tackling a single important problem, is one of the things that makes it unserious to me. The inflexibility of the Internet service model is a serious problem. Poor formal methods for verifying protocols is a serious (albeit not lucrative) problem. Programming languages that make it difficult to express correct programs: serious problem. It is…

At a certain scale, it's often a lot easier to build one system that solves all the problems . Building a building: hard problem. Building 1/3 of a building: impossible problem. Building a cow: hard problem. Building 1/3 of a cow: impossible problem.

Well, some types of buildings are designed to be modular. Cows are not.

I'm also in favor of a single system that solves a bunch of problems than a hodgepodge nightmare. That was the vision behind NLS, the Mother of All Demos, SmallTalk, Plan9 etc. And Doug Engelbart can be found favoring the easy to master but complex at first glance approach https://www.youtube.com/watch?v=VeSgaJt27PM instead of the easy to get started approach of Mac GUIs that won out. The problem arises when the system makes too many weird decisions and people fork it to make their own all encompassing systems. Then it takes forever for crippled versions of these system to be adopted. It doesn't help when even the niche audience is divided. Things that can be disagreed on should be minimized.

So there is no technical need to throw the complex at first glance syntax at new users these days. You could convert it to a more verbose syntax and back again.

Terse syntax looks clean and easy to scan when you use it daily. But what if you don't? Then it's not self documenting, you have to look up commands to read code. If I don't use command line for a few months, I remember the basics like mkdir, ls, cd but I forget the nuances like ls -a and the billion other options. So it becomes a chore of looking things up constantly. Could be fixed with natural language autocomplete for writing code, but not reading. If you considered such use cases, you wouldn't be so sure about the terse syntax.

So many made up words are also asking too much. They'll certainly be worth learning if the system is proven. Haskell has it's own way of doing things, does a lot of things well, but seems to make many things difficult in practice. So it remains a niche that very few learn beyond the surface curiosities. Same for APL, J and K.

And I wrote most of this before seeing https://news.ycombinator.com/item?id=10280348

Re: Urbit: an operating function

#78

Post by yarvin9 »

JoshTriplett wrote: post #64
pcmonk wrote: post #36

Earlier quoted context omitted.

Traditional punctuation names suck. "Ampersand", "at sign", "caret"? For a language like hoon where we use a lot of symbols, that gets really tiring. Having one-syllable names for glyphs is really convenient, and they tend to roll of the tongue. Everyone's free to use whatever names they want, of course, we just find these useful. Most people love these once they get used to them. I don't think you can judge syntax b…

> Traditional punctuation names suck. "Ampersand", "at sign", "caret"? Hence why geeks and programmers rarely call them by name. See http://www.catb.org/jargon/html/A/ASCII.html .

There's a lot of folk workarounds for this problem. They're mostly fine for languages that use ASCII lightly. But it'd be a pretty confusing mess if we applied the "pick something in the jargon file" approach to something like the Hoon syntax.

Everyone who's learned our ASCII dictionary, which admittedly is not a whole lot of people, applies it compulsively.

Re: Urbit: an operating function

#79

Post by KingMob »

yarvin9 wrote: post #54
tptacek wrote: post #44

Earlier quoted context omitted.

The notion that Urbit believes it can solve all the problems , rather than tackling a single important problem, is one of the things that makes it unserious to me. The inflexibility of the Internet service model is a serious problem. Poor formal methods for verifying protocols is a serious (albeit not lucrative) problem. Programming languages that make it difficult to express correct programs: serious problem. It is…

At a certain scale, it's often a lot easier to build one system that solves all the problems . Building a building: hard problem. Building 1/3 of a building: impossible problem. Building a cow: hard problem. Building 1/3 of a cow: impossible problem.

Without addressing the merits of Urbit, these examples aren't valid. A third of a building is just a building in progress (foundations laid, i-beams installed, etc.) A third of a cow is a calf.

It might be the case that you will get synergistic effects and/or Urbit's vision isn't possible without solving multiple problems. But it could equally be you've bitten off more than you could chew by choosing to work on multiple orthogonal problems.

Re: Urbit: an operating function

#80

Post by anon4 »

jpt4 wrote: post #51
tptacek wrote: post #46

Earlier quoted context omitted.

This right here is what I mean when I suggest Urbit is unserious. "Green is just yellow and blue. Why do we call it 'green'? That name sucks. From now on, we're going to call it 'yellue'." There's overreaching first-principles boil-the-ocean dorm room rethinking of concepts, and then there's renaming the ASCII characters.

A better analogy would be a modern day SSB [0] proposing a constitutional amendment to officially rename federal offices by their standardized acronyms, e.g. "President of the United States" to "POTUS", "Supreme Court of the United States" to "SCOTUS", etc., especially as this would be an equally superficial distraction from this hypothetical neo-SSB's real goal of replacing all Congressmen with AIs and relocating th…

Well you should drop the OTUS, since it's redundant and implied. So you have the P, the SC (pronounced scee - with a long s), etc.
Post reply on HN