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

The Norway Problem

hitchdev.com

Post reply on HN
Print view View original

201–210 of 339 posts

Re: The Norway Problem

#201

Post by IshKebab »

atombender wrote: post #191

The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…

JSON5 is the best option currently. A fair number of tools in the JS ecosystem support it.

Re: The Norway Problem

#202

Post by debug-desperado »

atombender wrote: post #191

The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…

Thanks for this list, I’ve never heard of Ion. I’ll consider it for config and even replacing Avro & Protobuf in future projects.

Re: The Norway Problem

#203

Post by namelosw »

I prefer JSON over YAML because I spend more time confused and burned by the problems caused by it.

I understand that people don't like directly use JSON because it's not very friendly: no comments, no multi-line string, etc.

A great alternative IMHO is cson[0]. It's like JSON to JavaScript but for CoffeeScript (though nobody talks about it nowadays). It has indentation-based syntax, comments, and multiline string which usually don't need to escape. The advantage is it's close enough to JSON which is the canonical format that everybody can agree on nowadays. For YAML and TOML there are too many visual part-aways from JSON.

Or just create a JSON variant that enables comments and the backtick multiline string from JavaScript.

[0] https://github.com/bevry/cson

Re: The Norway Problem

#204

Post by majkinetor »

lokedhs wrote: post #178
lunfard00 wrote: post #136

Earlier quoted context omitted.

There is a lot of elitism around bash, like the "Arch btw" thing but far worse because a lot of important things depends on it. Powershell has been working on linux for quite a while now and doesnt seem get any attention even when it has a nice IDE support and copy the good things about bash.

It doesn't copy all the good things about the Unix shell though. The reason people are comfortable with the POSIX shell is because you use the same syntax for typing commands manually as you do for scripts. But, you're going to have a hard time finding people who prefers writing: Remove-Item some/directory -recursive Rather than rm -fr some/directory People who write shellscripts are often not seeing themselves writi…

Nonsence. This is the same in powershell:

    rm -r -f some/directory

Re: The Norway Problem

#205

Post by unionpivo »

lixtra wrote: post #187
unionpivo wrote: post #175

Earlier quoted context omitted.

I disagree with most of what you said but I want to specifically call out: > 3. Go on with a warning is a sane strategy in some situations. No, if its sometimes ok, to continue, than you should not assert it. Assert means "I assert this will always be true, and if it's not our runtime is in unknown/bad state." If you think you can recover, or partially recover, throw/return appropriate error, and go into emergency/re…

Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits. Downvote me if you want to open a bug ticket with the vendor and wait a week for the fix. Upvote me if you’d give it a try to restart with a switch to ignore assertions. You may abstain if you never shipped a bug. Edit: not to forget that this website runs on lisp which violates all…

> Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits.

Several points:

1. Most of such critical components have several different and independent implementations, with analog backup (if possible).

2. You are arguing one specific safety critical case, that 99.999% or even more programmers will never face, should somehow inform decision about general purpose programming language.

3. Even if you are working in such safety critical situation, you should not really on assertion bypass, but have separate emergency procedure, which bypasses all the checks and try's to force the issue. (ever saw a --force flag ?)

Because what happens in reality, is developer encounters a bug (maybe while its still in development), notice you can bypass it by disabling assertions (or they are disabled by default), log it as a low priority bug, that never gets fixed.

Then a decade later me or someone like me is cursing you because you enterprise app just shit the bed, and is generating tons of assertion warnings, even when it running normally, so I have to figure out, which of them are "just normal" program flow, and which one just caused an outage.

I never experienced situation like you described, but I have experienced behavior like I wrote above, too many times.

Botom line is:

- don't assert if you don't mean it

- if you need bypass for various runtime checks, code one in explicitly.

Edit: Hacker News is written in ARC which is schema dialect. ARC doesn't have assertions as far as i can tell.

ARC doesn't have its own runtime and is run on racket language, that has optional assertion, that exit the runtime if they fail https://docs.racket-lang.org/ts-reference/Utilities.html

Re: The Norway Problem

#206

Post by corpMaverick »

sokoloff wrote: post #151
JoeAltmaier wrote: post #148

Earlier quoted context omitted.

I've done the same thing for decades! Soul mates?

You might like this one as well. Load soap into the dishwasher after emptying rather than after loading . If the soap dispenser is closed, the dishes are dirty.

I want to have two dishwashers. One with the dirty dishes and one with the clean dishes. So you never have to put the dishes away. They go from the clean dishwasher to the table to the dirty one. And then flip them.

Re: The Norway Problem

#207

Post by sergeykish »

anticristi wrote: post #190
sergeykish wrote: post #134

Earlier quoted context omitted.

You've just used XML tech as it was designed to post this comment. XML is serialization. I hardly believe you was concerned about serialization while posting comment or thought about attributes-tags distinction. This page utilizes request to server for multi-user editing. But it is easy to build truly serverless (like a file) document with same interface: data:text/html, Host: example.com Change it, save it, done. We…

You are right. XML is great for encoding the DOM. However, I didn't find it practical for interfacing with humans, due to the concerns I raised.

It is not practical to edit plain text in binary:

    636f 756e 7472 6965 733a 0a2d 2047 420a
    2d20 4945 0a2d 2046 520a 2d20 4445 0a2d
It is not practical to edit Excel documents in plain text:

    
    
      
        
          
            ID
Tim Berners-Lee browser was browser-editor. Can't you see parallels?

Re: The Norway Problem

#208

Post by mc10 »

atombender wrote: post #191

The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…

S-expressions are super easy to parse and are fairly easy for humans to read. See e.g. using s-expressions in OCaml: https://dev.realworldocaml.org/data-serialization.html

Re: The Norway Problem

#209

Post by wongarsu »

msiemens wrote: post #176
mcv wrote: post #133

If it ignores part of the spec, I don't think "strictyaml" is the correct name here. Instead, if it interprets everything as string, perhaps "stringyaml" would have been more accurate, though I'm sure that's not as good PR. I'm reminded of the discussion we had a few days ago about environment variables; one problem there is that env variables are always strings, and sometimes you do want different types in your conf…

> JSON, which is [...] unambiguous about its types With the one exception that with floatig point values the precision is not specified in the JSON spec and thus is implementation defined[1] which may lead to its own issues and corner cases. It for sure is better than YAML's 'NO' problem, but depending on your needs JSON may have issues as well [1]: https://stackoverflow.com/questions/35709595/why-would-you-u...

Also JSON's complete lack of many commonly used types, and no way to define any new ones.

Re: The Norway Problem

#210

Post by teddyh »

sneak wrote: post #168
sokoloff wrote: post #151

Earlier quoted context omitted.

You might like this one as well. Load soap into the dishwasher after emptying rather than after loading . If the soap dispenser is closed, the dishes are dirty.

My rule is that loading the dishwasher means that one loads all the available dishes, and runs it, even if it's only x% full. We use the (large) sink as an input buffer. If the dishwasher has dishes in it and it's not running, they're clean.

That’s not a zero-copy algorithm. The algorithm with using the soap dispenser being closed as a flag is zero-copy.
Post reply on HN