skitter

The vec already gets allocated with capacity == length

https://doc.rust-lang.org/nightly/src/alloc/slice.rs.html#16...

merde_json should also be relatively small.

We do in fact talk about technologies that don't exist. Creating new technologies would be rather difficult otherwise.

Adding an enum variant can be backwards incompatible just as easily in languages that don't do this, you just don't get to see the error at compile time.

According to Stroustrup & co, it's less: They see a good dev optimistically writing 2k lines of finished non-test code a year, and that's when rewriting code ¹, so that checks out! (To be clear, I'm joking and agree with your sentiment, but they really did say that in an official reply to the US gov)

¹: https://downloads.regulations.gov/ONCD-2023-0002-0020/attach...

I agree that list comprehensions aren't any easier to read. A proper streaming interface on the other hand lets you easily follow how the data is transformed:

    foo
      .stream()
      .filter(x -> x.contains("banned"))
      .collect(Collectors.toList());

As an aside, Go conflating lists and views irks me, in part due to what weird semantics it gives to append (e.g. if you have two disjunct slices and append an element to one slice, that might modify the other slice).

The type checker is specified in Prolog and rejects the above scenario:

    instructionIsTypeSafe(fadd, Environment, _Offset, NextStackFrame, ExceptionStackFrame) :- 
        validTypeTransition(Environment, [float, float], float, StackFrame, NextStackFrame),
        exceptionStackFrame(StackFrame, ExceptionStackFrame).

Fun fact: Said type system has a 'top' type that is both the top type of the type system as well as the top half of a long or double, as those two actually take two values while everything else, including references, is only one value. Made some sense when everything was 32 bit, less so today.

I think it's appropriate linking directly to Kriesel's blog¹ or his talk, as that's about the scanner creating fake data and not about rce. Though technically it too is not an OCR bug as there's no ocr in JBIG2.

¹: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_...

Afaik the import sets the module in the importing module's context only after the code in the imported module is run.

Edit: Oh, you don't mean in the importing module's globals, you mean `sys.modules`. Yeah that works!

Time team's great, glad to see them back.

Maybe it's because I don't use it that intensely, but I've found the default a bit noisy, so I switched my default layout to only contain `pane` and turned pane frames off.

> Well, make a choice and write it down.

Or don't and don't allow unnecessary ambiguity. For * and +, there's a agreed upon order of operations far more universal than a programming language, but it's sensible to use a partial order so nobody is mistaken about whether e.g. logical or and bitshift binds tighter. Similary C counld have just not have allowed omitting the braces around single-line else clauses and would have been a simpler language for it.

Compilers don't claim that part of the standart doesn't exist, they just go eith option 1: Ignoring the situation. E.g. if one branch of an if-statement is UB, compilers ignore that that branch can happen and only need to compile the branch they know exists.

Related, this article discusses difference generators and tradeoffs for Go using them as Source: https://zephyrtronium.github.io/articles/randomness.html

Pedants would say that null pointers exist in safe Rust too.

> This sounds good when the system is small and tight and applications are written mostly by people who designed the whole system.

I think that's intentional because that's what Hubris is aimed at.

Impressively, there's Mess Detector, a machine built in Minecraft itself that predicts the internal state of the rng, using the position a lit tnt (instead of a block drop):

https://www.youtube.com/watch?v=FPmQ0rnJjNc

> it's a local binding getting bound to different values on each scope entry.

It is, I just wanted to point out that the term "immutable variable" is sensible. I think a good way to put it is that b is a variable, and when the statement runs a value is bound to b. So the value bound to b varies yet b can be immutable, in contrast to a constant which is a binding to always the same value.

> Did you mean `const b = a;` ?

Fixed, thanks :)

Immutable variable isn't a oxymoron. It can still vary between instantiations. If you have (a)=>{const b = a}, b can have different values even though it can't be reassigned.

Sadly enums are too advanced of a concept to be included in Go.

And Rc can still be useful for multithreaded programs. Not every value needs to be shared between threads.

Thanks! So it is/was indeed UB.

I don't think it's undefined behavior though. Looking at (the working draft of) the C ISO standard, I don't see a requirement that the comparison function must be transitive.

The closes thing there is 7.22.5.2 §4: "If two elements compare as equal, their order in the resulting sorted array is unspecified"

So I'd say blaming users for a bug in glibc isn't fair.

They already mention the issue of using substraction for comparison; here's another different accidentally intransitive comparison function:

    int cmp(const float *a, const float *b) {
        if (*a < *b) {
            return 1;
        } else if (*a == *b) {
            return 0;
        } else {
            return -1;
        }
    }

Valgrind can only detect this for single executions, not for all possible ones.

> C can teach you useful things, like how memory is a huge array of bytes

Careful: In C, memory isn't a huge array of bytes.

> panic = very serious problem, what do you expect?

Even the Go standard library itself panics (and recovers) when you try to e.g. json-encode a NaN, which doesn't seem like something that should make the system unstable.

Shouldn't this simply return true instead of throwing?

Afaik for C & C++, that's not true – you can turn const references into normal references and are even allowed to mutate the object they point to unless said object is declared as const.

Odd choice to tell readers to stay tuned for the other articles instead of linking to them. The intro seems a bit superficial – if Groovy combines Java & Python, wouldn't it make sense to at least mention what inspiration it takes from Python and where it's on the untyped-typed scale is? The tone of the series feels like marketing speech: "Variables in Apache Groovy: Powerful, concise and easy"

Instead we get an entire article about getters and setters, which uses a Java example with pointless getters and setters that just directly read/write a variable.

> Groovy has syntactic support for maps using [] to get and set the value based on the variable within the square brackets

Why variable? Does that mean you can't use expressions for indexing?

    System.err.println "Usage: groovy Groovy01.groovy input-file"
    System.exit(0)

Why does only the second call need parentheses?

    String s
    s = 42

Looks like Groovy is weakly typed?

    strParam != null && strParam.isInteger() ? Integer.parseInt(strParam) : 0

Doesn't Groovy already have if-else? Why also add `?:` ?

> In the previous article, you learned that Groovy’s version of truth means you don’t need to test for not null

The previous article doesn't even mention the word truth.