Why is "many worlds" the most mathematically consistent? (I won't bother asking for the philosophical bit; I'm sure it's too long for an HN post.)

Christians: "We have faith supernatural selection at a cosmic level makes afterlife way more likely."

         All times in seconds (lower is better)
  
  benchmark          Node.js     Python 3    Py takes x times longer
  ==================================================================
  regex-redux          5.06         1.34     ** Py3 is faster (PCRE C)
  pidigits             1.14         1.16     0.02
  reverse-complement   2.59         6.62     2.56
  k-nucleotide        15.84        46.31     2.92
  binary-trees         7.13        44.70     6.27
  fasta                1.91        36.90     19.3
  fannkuch-redux      11.31       341.45     30.19 (wut?)
  mandelbrot           4.04       177.35     43.9  (srsly?)
  n-body               8.42       541.34     64.3  (no numpy fortran cheat?)
  spectral-norm        1.67       112.97     67.65 (Python for Science[TM])

Both ecosystems have billions invested by corporations worth trillions; bottomless money exists to make Python faster. So why isn't Python faster?

V8's tactics include dynamically watching which loops/calls get run more than (say) 10,000 times and then speculatively generating[2] native machine instructions on the assumption the types don't change ("yep, foo(a,b) is only called with a and b both float64, generate greased x86-64 fastpath"), but gracefully falling back if the types later do change ("our greased x86-64 'foo(float64,float64)' routine will be passed a string! Fall back to slowpath! Fall back!"). Why doesn't Python do this? Is it because Google recruited the only genius unobtainium experts who could write such a thing? Google is a massive Python user, too.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2] https://ponyfoo.com/articles/an-introduction-to-speculative-...

EDIT: HN commenter Jasper_ perhaps has the answer in another post[3]: "The current CPython maintainers believe that a JIT would be far too much complexity to maintain, and would drive away new contributors. I don't agree with their analysis; I would argue the bigger thing driving new contributors away is them actively doing so. People show up all the time with basic patches for things other language runtimes have been doing for 20+ years and get roasted alive for daring to suggest something as arcane as method dispatch caches. The horror!"

[3] https://news.ycombinator.com/item?id=30047289#30050248

After so many years of endianness bugs in C/C++ code, it's perplexing that the web standards committee voted to put typed arrays in Javascript in such a way that exposes platform byte order to Javascript programmers who can't generally be expected to have low-level C/C++/ASM experience with memory layout issues:

  function endianness () {
    let u32arr = new Uint32Array([0x11223344]);
    let u8arr = new Uint8Array(u32arr.buffer);
    if (u8arr[0] === 0x44)
        return 'Little Endian';
    else if (u8arr[0] === 0x11)
        return 'Big Endian';
    else
        return 'WTF (What a Terrible Failure)';
  }

Anyone have a PDF link to a paper about this Fortran analyzer?

The expansion of the observable universe itself being apparently FTL is perhaps the most interesting. If we point the Hubble telescope (and soon JWST) towards opposite ends of the observable universe, we observe extreme redshift galaxies receding away from each other in opposite directions greater than twice lightspeed if we measure according to "distance in light years" from earth. But no photons or information from a galaxy at one side of our observable universe can be sent to a galaxy at the opposite end: they are receding away from each other too rapidly, these two galaxies exist Beyond the Cosmological Event Horizon relative to each other and are forever unknowable to each other, and thus causality is not violated.

An advanced alien race in galaxy A might be able to beam a message to earth before galaxy A vanishes Beyond the Cosmological Event Horizon within the next 100 million years earth-time, and likewise galaxy B might beam a message to earth within the next 100 million years earth-time, but earth can't relay the message from A to B or B to A because they have already forever receded from each other and will soon both likewise forever recede away from us.

  - never talk to cops

  - never read a patent

  - never read proprietary source code

The patent system only benefits (1.) rich corporations that can afford the millions of dollars in lawyer fees to litigate patent claims, (2.) the lawyers that receive said fees.

  def foo(bar, baz):
      bar(baz)
      ...

  grep -ri '\(foo\|bar\|baz\)' --include \*.py

Comments URL: https://news.ycombinator.com/item?id=29970075

Points: 4

# Comments: 1

So the earliest C compilers were under 5000 lines of C+asm:

  https://github.com/mortdeus/legacy-cc

  http://port70.net/~nsz/c/c89/c89-draft.txt

C doesn't need "defer" because C programmers have managed since the 1970s to implement operating systems, compilers, interpreters, editors, etc., just fine without it. Those who want a bigger C can use C++, this pond is big enough for two fish.

A great strength of C is that if you want more features you just go to a subset of C++, no need to add them to C. C++ is the big, ambitious, kitchen-sink language. When C++ exists we don't need to bloat C.

Fortran was originally carefully designed so that people who aren't compiler experts can generate very fast (and easily parallelized) code working with arrays the intuitive and obvious way. But later Fortran added OO and pointers making it much harder to auto-parallelize and avoid aliasing slowdown. Now that GPUs are rising it turns out that the original Fortran model of everything-is-array-or-scalar works really well for automatically offloading to the GPU. GPUs don't like method-lookup tables, nor do they like lambdas which are equivalent to stateful Objects with a single Apply method.

Scientists are moving to CUDA now, which on the GPU side deletes all these features that Fortran was bloated with. Now nVidia offers proprietary CUDA Fortran which is much more in the spirit of original Fortran, deleting OO and pointers for code that runs on GPU. If the ISO standards committee didn't ruin ISO Fortran for scientific computing by bloating it with trendy features we could all be running ISO Fortran automatically on CPUs and GPUs with identical code (or just a few pragmas) and not be locked in to proprietary nVidia CUDA.

But GPUs are now mainly used for crypto greed instead of science for finding cancer cures or making more aerodynamic aircraft so maybe it all doesn't matter anyway.

If they bumped 1200 MW to 1210 MW they'd have the 1.21 GW they need to operate a Flux Capacitor.

https://www.youtube.com/watch?v=f-77xulkB_U

  https://lisp.com.br/archive/ansi_cl_standard_draft_nice.pdf

The Java JVM was carefully designed to give identical results on all hosts for the Java platform unless you go out of your way to get nondeterminism or platform specific behavior (make the value of the number N depend on thread scheduling, or use JNI that assumes a platform byte order, etc.). C/C++/Rust allow undefined behavior if you shift a 64-bit int more than 64 bits, but Java on the JVM for example masks the lower 6 bits of a 64-bit shift ('& 0x3f') so that you get the same result on all CPUs rather than a CPU-dependent result:

  https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.19

Clojure is a Lisp that runs on the JVM. I haven't personally used Clojure, but having done quite a bit of Common Lisp, Emacs Lisp, Scheme, etc., it looks to be very well designed and very well loved by its users, and using it could spare you from having to language lawyer the ANSI Common Lisp standard, as it seems to be more "try it and see" friendly.

I've been learning a lot about formal verification for C programs, how to truly make code that is bug free, and to do this you need to first make certain decisions about how you are going to formalize the language standard. E.g. will you assume that CHAR_BIT==8 or will you allow CHAR_BIT>=8 because the official ANSI/ISO C standard allows this even though all modern computers have CHAR_BIT==8? Then for any program you input to your verifier you must judge whether all its behavior is well-defined or if there is undefined behavior (arithmetic overflow, etc.).

There are quite good formal verification tools for Java, also, like JBMC and Krakatoa, and smaller Lisp languages are traditionally among the least tedious to formally verify (very simple semantics, unlike Common Lisp), but the time investment to learn these tools is enormous.