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

141–150 of 339 posts

Re: The Norway Problem

#141

Post by exyi »

pansa2 wrote: post #27
speedgoose wrote: post #26

Earlier quoted context omitted.

Python vs PHP also.

> full of these sorts of interesting behavior I don’t think that applies to Python - it’s quite strongly (although not statically) typed. I agree that it does apply to JavaScript and PHP.

I think this applies to Python pretty well. Although certainly not as bad as PHP, most JS traps also exist in Python (falsy values, optional glitchy semicolons, function scoped variables, mutable closure). There is many JS specific traps like this and also other Python specific ones (like static fields are also instance fields, Python versions and library dependency hell). However I find it easier to avoid them in JS than in Python with TypeScript, avoiding classes, ...

Re: The Norway Problem

#142

Post by sergeykish »

masklinn wrote: post #82
trhway wrote: post #34

Earlier quoted context omitted.

XML with a convenient UI tools to edit should have fit the bill. Yet, for whatever reason a convenient UI tool would never happen to be there when needed, and thus scared and tired of manual editing of XML the world have embraced YAML.

> XML with a convenient UI tools to edit should have fit the bill. "You need this special tool to work" immediately and instantly rules out "easy to edit". Or makes the debate irrelevant: every format is easy to edit if you have "a convenient UI" to do it for you.

The fault was in XML editing, pure data authoring is hard. We have convenient UI — web browser, think of it as literate programming, a way to merge man page and configuration file.

And plain text editor is a "widely deployed special tool to work". Actual data is

    countries:\n- GB\n- IE\n- FR\n- DE\n- NO
Or

    636f 756e 7472 6965 733a 0a2d 2047 420a
    2d20 4945 0a2d 2046 520a 2d20 4445 0a2d

Re: The Norway Problem

#143

Post by atleta »

lelanthran wrote: post #132
atleta wrote: post #77

Earlier quoted context omitted.

I agree with the general observation, but the need for ";" ? Quite a few languages (over a few generations) have been doing fine without the semicolon. Just to mention two: python and haskell. (Yes, python has the semicolon but you'll only ever use it to put multiple statements on a single line.)

> I agree with the general observation, but the need for ";" ? Quite a few languages (over a few generations) have been doing fine without the semicolon. Just to mention two: python and haskell. (Yes, python has the semicolon but you'll only ever use it to put multiple statements on a single line.) But then it's inconsistent and has unnecessary complexity because now there's one (or more) exceptions to the rules to r…

There are no exceptions. You only need it if/when you want to put multiple statements on a single line. That's its sole purpose.

And I'd also add that it's something that you almost never do. One practical use is writing single line scripts that you pass to the interpreter on the command line. E.g. `python -c 'print("first command"); print("second command")'`

If you don't know about the `;` at all in python then you are 100% fine.

Re: The Norway Problem

#144

Post by paulintrognon »

I am sometimes annoyed by the fact you have to put double quotes around string properties in JSON. It would be so much lighter to use JS syntax..! Then I read articles like this one. Thank you JSON for not trying to be smart.

Re: The Norway Problem

#145

Post by mcv »

asiachick wrote: post #115
WalterBright wrote: post #47

> The most tragic aspect of this bug, howevere, is that it is intended behavior according to the YAML 2.0 specification. This is one of those great ideas that sadly one needs experience to realize are really bad ideas. Every new generation of programmers has to relearn it. Other bad ideas that resurface constantly: 1. implicit declaration of variables 2. don't really need a ; as a statement terminator 3. assert shoul…

What do think of implicit member access (C++, Java, C#) vs explicit (python, javascript)? Is there a concrete argument one way or the other? I feel like I prefer explicit self.member = value this.member = value vs implicit member = value But clearly C++/Java/C# people are happy with implicit ... though many of them try to make it explicit by using a naming convention.

The fact that people introduce naming conventions to keep track of member variables is probably the biggest condemnation of implicit member access. People clearly need to know this, so you'd better make it explicit.

It's actually a bit surprising that this is one thing that javascript does better than Java. In most other areas, it's Java that's (sometimes overly) explicit.

Re: The Norway Problem

#146

Post by labawi »

lelanthran wrote: post #132
atleta wrote: post #77

Earlier quoted context omitted.

I agree with the general observation, but the need for ";" ? Quite a few languages (over a few generations) have been doing fine without the semicolon. Just to mention two: python and haskell. (Yes, python has the semicolon but you'll only ever use it to put multiple statements on a single line.)

> I agree with the general observation, but the need for ";" ? Quite a few languages (over a few generations) have been doing fine without the semicolon. Just to mention two: python and haskell. (Yes, python has the semicolon but you'll only ever use it to put multiple statements on a single line.) But then it's inconsistent and has unnecessary complexity because now there's one (or more) exceptions to the rules to r…

When you use ; and possibly {, }, code statements / blocks are specified redundantly (indentation + separators), which can cause inconsistent interpretation of code by compiler / readers.

I find it much, much easier to look at code and parse blocks via indentation, than the many ways and exceptions of writing ; and {, }, while an extra or missing ';' or {} easily remains unspotted and leads to silly CVEs.

Re: The Norway Problem

#147

Post by sokoloff »

bonzini wrote: post #33
m463 wrote: post #30

Earlier quoted context omitted.

slightly related, on my microwave 99 > 100, even 61 > 100

Why does your microwave compare numbers?

It doesn’t compare them, it just counts down.

If I enter 1-3-0-start, I get 90 seconds of cooking. If I enter 9-9-start, I get 99 seconds of cooking, so in that sense, 99 > 130.

If I want about 90 seconds, I’ll use 88 as it’s faster to enter (fewer finger movements).

Re: The Norway Problem

#148

Post by JoeAltmaier »

sokoloff wrote: post #147
bonzini wrote: post #33

Earlier quoted context omitted.

Why does your microwave compare numbers?

It doesn’t compare them, it just counts down. If I enter 1-3-0-start, I get 90 seconds of cooking. If I enter 9-9-start, I get 99 seconds of cooking, so in that sense, 99 > 130. If I want about 90 seconds, I’ll use 88 as it’s faster to enter (fewer finger movements).

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

Re: The Norway Problem

#149

Post by earthboundkid »

It's fashionable to hate XML because it was used in a lot of places it was a bad fit in the 00s, but at least it's a pretty good document language.

YAML though is always a bad fit. If you want machine readable config, use JSON; human readable, use TOML. When does YAML ever fit?

Re: The Norway Problem

#150

Post by kenshoen »

progval wrote: post #50
yellowapple wrote: post #12

This is exactly why configuration/serialization formats should make as few assumptions about value types as possible. Once parsing's done, everything should be a string (or possibly a symbol/atom, if the program ingesting such a file supports those), and it should be up to the application to convert values to the types it expects. This is Tcl's approach, and it's about as sensible as it gets. ...which is why it pains…

> Once parsing's done, everything should be a string Or give a schema to the parser, defining what type is expected in each field.

Yes, that looks like a right way to handle this problem without ignoring YAML spec. Define what to parse upfront.
Post reply on HN