4 ms·

Just because it’s illegible does not mean it is suboptimal. It purposely breaks with existing conventions because it does things in a way not current code does.

lidHanteyk 6y ago
Here [0] is but one example of Urbit's suboptimality: Their encoding into C is insecure, and they have no interest in changing it. Writing a new operating system is hard. Taking lots of questionable paths, like writing "jet" templates [1] that call directly into existing C libraries, or defining a brand-new Boolean type that doesn't behave like standard Booleans, is not the right way to build confidence in any kind of quality, let alone optimality. Also, as a word-choice note, "optimal" means "best". Urbit is clearly not the best operating system, because there is clearly no metric by which to measure it against other OSs. It doesn't support the same sorts of hardware or APIs or processes or other common components of our craft. "optimal" is a terrible word to use around greenfield projects and nebulous designs; reserve it for when you can prove that your approach truly is the best one. [0] https://github.com/urbit/urbit/issues/752 https://github.com/urbit/urbit/issues/752 [1] https://en.wikipedia.org/wiki/Template_metaprogramming https://en.wikipedia.org/wiki/Template_metaprogramming
- strbean 6y ago
  That issue is pretty hilarious, and reveals a lot about Urbit. This topic on HN is my first exposure to the project, and I was on the fence about the (seemingly much debated) 'is this satire?' question. This ticket pushed me over to the 'yes' side. Of course there is the 'loobean' schtick, but the best part is them sneaking in three-valued logic as a trojan horse, where the third state is "NO". They evens steer the reader towards the obvious footgun: > You should ignore the numeric values and use comparisons against c3y and c3n for everything. So I should say if (bluebeanValue == TRUE) { ... } and if (bluebeanValue == FALSE) { ... } Making any value outside the expected range mean "NO to any boolean test".

lidHanteyk 6y ago

Here [0] is but one example of Urbit's suboptimality: Their encoding into C is insecure, and they have no interest in changing it. Writing a new operating system is hard. Taking lots of questionable paths, like writing "jet" templates [1] that call directly into existing C libraries, or defining a brand-new Boolean type that doesn't behave like standard Booleans, is not the right way to build confidence in any kind of quality, let alone optimality. Also, as a word-choice note, "optimal" means "best". Urbit is clearly not the best operating system, because there is clearly no metric by which to measure it against other OSs. It doesn't support the same sorts of hardware or APIs or processes or other common components of our craft. "optimal" is a terrible word to use around greenfield projects and nebulous designs; reserve it for when you can prove that your approach truly is the best one. [0] https://github.com/urbit/urbit/issues/752 https://github.com/urbit/urbit/issues/752 [1] https://en.wikipedia.org/wiki/Template_metaprogramming https://en.wikipedia.org/wiki/Template_metaprogramming

strbean 6y ago
That issue is pretty hilarious, and reveals a lot about Urbit. This topic on HN is my first exposure to the project, and I was on the fence about the (seemingly much debated) 'is this satire?' question. This ticket pushed me over to the 'yes' side. Of course there is the 'loobean' schtick, but the best part is them sneaking in three-valued logic as a trojan horse, where the third state is "NO". They evens steer the reader towards the obvious footgun: > You should ignore the numeric values and use comparisons against c3y and c3n for everything. So I should say if (bluebeanValue == TRUE) { ... } and if (bluebeanValue == FALSE) { ... } Making any value outside the expected range mean "NO to any boolean test".