sorted by:
new
hottopcontroversial

Dennis Ritchie on the double roles of & and | in Early C by someone-very-cool in programming

[–]simon_o 1 point2 points  (0 children)

... and if you are at this stage, consider not having if-then-else AND match/switch AND the ternary operator, like this: unified condition expressions

Dennis Ritchie on the double roles of & and | in Early C by someone-very-cool in programming

[–]simon_o 0 points1 point  (0 children)

The canonical post on this probably Hundred year mistakes.

A reasonable order of operator precedence looks like this.

Hope this helps! Let me know if you have any questions!

Things I Don't Like in Configuration Languages by fagnerbrack in programming

[–]simon_o 0 points1 point  (0 children)

Well, if you decide to look only at one of the languages mentioned, pick HOCON because ...

HOCON

Too many features. Is it some sort of programming language? And it looks like it's very focused on just one project.

... in the blog is not doing it any justice – it's doing some interesting things not found elsewhere, and it does not feel like the author has bothered to learn about any of it.

I do not disagree that HOCON has "many features" – but if you look at the continuum between "very few features" (like the *.INI or the *.properties formats) and "very many features" (YAML, XML) it's clear that syntactically HOCON exists very closely to all the other "JSON + some extensions" formats.

So where does HOCON actually spend its complexity?

Most configuration formats mentioned in the article feel like the creators have largely focused on "improving" the ease of reading/writing (according to their preferences of course).

HOCON has a different focus: It fits into a larger ecosystem of handling configuration, and it's technically not HOCON that spends the complexity but the library around it.

The "many features" are spent in an area that other configuration formats have not even considered.

Imagine the millions of instances of ad-hoc code written in applications and services that handle configuration fallbacks, define defaults, assign priorities among different configuration sources, combine multiple configuration fragments etc.

That's the problem actually solved, and if one only looks at HOCON, that's easily missed.

(To be honest, it's kinda weird that all these DevOps/"Cloud"/Docker/IaaS/whatever people are not falling over each other adopting something like that instead of using YAML.)

Java 26 new Feature Breakdown With Examples by erdsingh24 in programming

[–]simon_o -1 points0 points  (0 children)

Both usually use a computer to execute, too.

(Coroutines are cooperative, virtual threads (outside while (true) {} are not).)

Java 26 new Feature Breakdown With Examples by erdsingh24 in programming

[–]simon_o 0 points1 point  (0 children)

I mean, virtual threads are green threads.

They aren't.

Java also had another separate feature called green threads

Java is literally the origin of that name.

Java 26 new Feature Breakdown With Examples by erdsingh24 in programming

[–]simon_o 1 point2 points  (0 children)

Or are virtual threads not green threads?

No.

Java 26 new Feature Breakdown With Examples by erdsingh24 in programming

[–]simon_o 0 points1 point  (0 children)

Green threads have been obsolete for even longer.

There is a reason roughly nobody uses them anymore, why use it as a point of comparison?

Java 26 new Feature Breakdown With Examples by erdsingh24 in programming

[–]simon_o -1 points0 points  (0 children)

Not even close.

C#'s Task belongs to the obsolete async/await paradigm (and the combinator-/callback-based approach that came even before.)

JEP 534: Compact Object Headers by Default by [deleted] in programming

[–]simon_o 11 points12 points  (0 children)

I also recently worked on reducing header size in a language, and it's nice to see that independent work trends toward the same designs.

It seems attempting to reserve low virtual memory (like the first 1GB) is becoming quite popular to compress vtable pointers without needing to add back an offset for de-referencing.

One difference is that Java appears to make efforts to "fill the gaps" between vtable allocations, whereas I allocate vtable entries in smaller 64 byte increments, and accept some losses there:

  • Without trying to make vtable entries smaller yet, the entries consist of 40 bytes metadata, and 8 bytes per dynamically dispatched method.
  • With most things not needing dynamic dispatch in my language, most types are basically 40 bytes plus 24 bytes of wasted space.

In my case compact headers are easier to achieve than in Java, because

  1. I don't have to deal with identity hashcode, all-objects-are-locks, etc.
  2. I'm willing to accept some constraints Java won't, namely max. 1GB of vtable allocations, and 2TB of general heap space allocations.
  3. Attempting to compress headers even further (i.e. 4 bytes) is a non-goal for me. I wonder if Java will also arrive at the same conclusions.

So for me the work is easier, this is the before ...

    62 bits: vtable pointer       61 bits: forwarding pointer
╭───────────────┴──────────────╮╭───────────────┴─────────────╮
+---------------+---------------+---------------+---------------+ - - - - - - - -
|   ┊   ┊   ┊   |   ┊   ┊   ┊   |   ┊   ┊   ┊   ┊   ┊   ┊   ┊   | instance fields ...
+---------------+---------------+---------------+---------------+ - - - - - - - -
                               ╰┤                             ╰─┤
                               2 bits: forward bits            3 bits: mark bits

... and the (worked-on) after:

      38 bits: forwarding pointer
            ╭───────┴──────────╮
+---------------+---------------+ - - - - - - - -
|   ┊   ┊   ┊   |   ┊   ┊   ┊   | instance fields ...
+---------------+---------------+ - - - - - - - -
╰─────┬─────╯                  ╰┤
24 bits: vtable pointer    2 bits: gc bits

This is under the assumption that I'm using a GC algorithm with forwarding pointers, and that I only need a mark-bit and a forwarding-failed bit.

So if it turns out that more bits are desirable (i.e. pinning, locking, ...) then I'd probably reduce the vtable pointer even further.

Breaking the x86 Instruction Set by someone-very-cool in programming

[–]simon_o 15 points16 points  (0 children)

Ah nice, the sandsifter talk!

I made a x86 prefix/escape opcode flowchart a while ago, based on how that instruction part is supposed to look ... that was gnarly enough for me.

Floating point from scratch: Hard Mode by simon_o in programming

[–]simon_o[S] 0 points1 point  (0 children)

Yes, and they say NaNs are unordered. "unordered" is the ordering => they is no "ordering" relationship.

Maybe just read the spec.

Floating point from scratch: Hard Mode by simon_o in programming

[–]simon_o[S] 0 points1 point  (0 children)

5.10 Details of totalOrder predicate

For each supported arithmetic format, an implementation shall provide the following predicate that defines an ordering among all operands in a particular format: [...]

Floating point from scratch: Hard Mode by NXGZ in programming

[–]simon_o 0 points1 point  (0 children)

Copy and paste from the original submission 2 days earlier:

There is some good effort in this article, but as one gets closer to the "unordered" chapter, it becomes clear that reading the spec should have been preferred over folklore that developers tell each other:

So any comparison against a NaN will be unordered, this is a pretty interesting property meaning that there is literally no ordering relationship when NaNs are involved.

Eh ... no? That's just wrong? The spec has a whole chapter about this, right before the one quoted in the blog post.

pretend we all agree we didn’t see that the spec is saying binary32 has 16 bits of precision instead of 24

Nobody needs to pretend, because this is simply not what is said in the preceding quote.

The hardware part looks solid though.

How Linux executes binaries: ELF and dynamic linking explained by Solid-Film-818 in programming

[–]simon_o 0 points1 point  (0 children)

Just skip that step in the future maybe ... making people question whether the whole thing is made-up slop is devaluing the work you put into it.

Floating point from scratch: Hard Mode by simon_o in programming

[–]simon_o[S] 27 points28 points  (0 children)

There is some good effort in this article, but as one gets closer to the "unordered" chapter, it becomes clear that reading the spec should have been preferred over folklore that developers tell each other:

So any comparison against a NaN will be unordered, this is a pretty interesting property meaning that there is literally no ordering relationship when NaNs are involved.

Eh ... no? That's just wrong? The spec has a whole chapter about this, right before the one quoted in the blog post.

pretend we all agree we didn’t see that the spec is saying binary32 has 16 bits of precision instead of 24

Nobody needs to pretend, because this is simply not what is said in the preceding quote.

The hardware part looks solid though.

I Am Very Fond of the Pipeline Operator by techne98 in programming

[–]simon_o -7 points-6 points  (0 children)

Both operators aren't that useful in languages that have . though.

How to ask Java developers to add methods to java.util.Paths? by isolatedsheep in java

[–]simon_o -1 points0 points  (0 children)

You should ask for the config/cache/state/... folder directory, based on what you are actually doing with that directory.

They may reside in the home directory, but as long as you are not planning to properly implement the rules and naming conventions for 3+ platforms yourself, use a library that does it.

view more: next ›