bakery2k

what can you expect from a language that uses "+", the quintessential notation for commutative operations, for the (very non-commutative) operation of concatenation?

Is this any worse than using `+` for floating-point addition, which isn't even associative?

So, Envoy will be embedding WebAssembly alongside (or instead of) Lua?

Are other projects moving from Lua (or other embedded scripting languages) to WebAssembly? What are the benefits of compiling an extension to WASM rather than writing it in Lua?

Thanks, that makes sense.

It was released just as the PS2 was announced

I think that's the point. A lot of people bought a PS2 because it was also a DVD player (same with the PS3 and Blu-ray).

Isn't code generation during parsing still common today? In particular, bytecode generation in interpreters (and JIT compilers) for scripting languages, e.g. Lua?

`range` is an example. Lack of support for overloading makes it harder to replicate its API in our own functions.

Well, however the `range` function is implemented, IMO its API would be better expressed as true overloading - as two functions with the same name.

If all we do is write Pythonic code (especially now that "Pythonic" seems to include type hints), what's the benefit of the highly dynamic CPython virtual machine?

Surely a faster VM, or even an ahead-of-time compiler, would be possible if we give up on some dynamism? Is that a direction the community should take?

(I think Guido's answer would be no, based on his apparent dislike of existing "Python compiler" projects such as Nuitka.)

`range(stop)` and `range(1, stop)` are both supported, but without overloading, the implementation of `range` is messy as it has to work out the meaning of each argument manually.

That's the thing - it's documented as overloaded, because that's the most intuitive explanation. Wren would allow it to actually be implemented as an overloaded function.

Python doesn't support overloading, and it doesn't support optional arguments before required ones, so the actual implementation in Python is a bit messy - something like:

  def range(start_or_stop, optional_stop=None):
      if optional_stop is None:
          start = 0
          stop = start_or_stop
      else:
          start = start_or_stop
          stop = optional_stop
      ...

The Wren scripting language supports this kind of "overloading by arity" [0].

Wren therefore allows overloads such as `range(stop)` and `range(start, stop)`. This is more intuitive than Python's `range(start=0, stop)`, which might be the only function in the language that has an optional parameter before a required one.

[0] http://wren.io/method-calls.html

"Distances longer than a few kilometers are measured in miles" was a direct reference to the OP's "yards to measure distances shorter than a few kilometers".

I think Jedd was commenting on the spelling of "meter" vs "metre".

The UK doesn't use the metric system for distances, at least when talking about travel. The only switching is from yards to miles.

That shouldn't be surprising. Distances longer than a few kilometers are measured in miles.

an engineer in silicon valley

Good point. The biggest factor that determines an engineer's salary is location, followed by years of experience. Not whether they work on compilers/embedded/web/whatever.

From GitHub [1]:

  "Plans to try MIR light-weight JIT first for CRuby or/and MRuby implementation"
  "MIR is strongly typed"

More generally, I'd love to see something like MRuby+MIR be successful. It would be great to see an alternative to the aging LuaJIT.

[1] https://github.com/vnmakarov/mir

I wonder if it's similar to embedded software development (which also requires "rigorous working methods"). Salaries for embedded are generally lower than for web development because there's much less demand for embedded skills.

In a language like Python that encourages duck typing, type hints can become extremely complex [1] and can get in the way of the ideal of "executable pseudocode" [2].

[1] https://mail.python.org/pipermail/python-dev/2015-April/1392...

[2] https://twitter.com/dabeaz/status/981832805540909056

Spot on. Static typing has benefits, but it also has a cost. Python's optional type hints have all the complexity but only some of the benefits - in my experience, runtime type errors are still common.

To me it feels like python is running as far away from simplicity as fast as possible.

Despite its reputation, Python hasn't been a simple language for a long time.

the actual creator of the language was so against the addition of this operator that he saw the community’s insistence on it as reason to step down as BDFL.

That's backwards. The community was generally opposed to the walrus operator, and Guido stepped down because of (among other things) the community's reaction when he insisted on adding it.

I think Python’s direction changed when Guido moved to Dropbox. Suddenly he was working on a million-line Python codebase, and started working to make the language more suitable for programming in the large.

Because if `a` and `b` are lists, `a.__iadd__(b)` mutates `a` in place, then returns it.

Is saving 5 lines of code really worth breaking Python's "one way to do it" design principle?

`a += b` does something along the lines of `a = a.__iadd__(b)`. Here `__iadd__` performs the actual append, but then the assignment fails.

Braces in Python would have issues, e.g. ambiguity with set/dict literals. Most similar languages (except JavaScript) seem to use begin/end instead. Would that be more acceptable than significant indentation?

"Effect and exception" is bad, but its a special case of a more general bad design - the fact that `a += b` is sometimes equivalent to `a = a + b` and sometimes changes in-place.

I came across this recently, when writing a blog post about a puzzle I solved. I wasn't sure whether to structure the post "chronologically", telling a story:

    1. Here's an interesting puzzle.
    2, 3, 4, 5. These are the steps I took to solve it.
    6. Hence the solution is X.

    1. Here's an interesting puzzle.
    2. I found the solution is X.
    3, 4, 5, 6. These are the steps I took to find that solution.

RPython's restrictions [1] are quite strict - I'd say its more likely that 99% of normal Python does use features that aren't supported by RPython.

[1] https://rpython.readthedocs.io/en/latest/rpython.html

I don't think its possible to efficiently compile a dynamically-typed language like Python to statically-typed WASM.