This comment here, I think, has the answer. The inial returns from using the more functional and mathematical view of programs are smaller than that of traditional approach. But the former scales better if you invest more time in it, and eventually can give you much more.
> It's pretty bizarre given there are few laws which seem more universally opposed by the open source community, and seems to me quite at odds with the values of FOSS - as is any DRM scheme.
Even if we don't like a law, it's a law, and you live in reality where it applies — and you should use it when needed. I don't find it bizarre at all.
I think you can prove that one can't just map the edge weights (so that edge's new weight only depends on its original weight) to make all weights positive, and also preserve all shortest paths.
You may try something more complex, i.e. where the new weight of an edge would depend on some more edges around it. But then the cost of doing so may be close to Bellman-Ford algorithm itself.
Assuming a directed graph. At the entry to each negative edge collect all the nodes reachable in 1 extra hop from that edge and compute the total cost. All that have a positive weight, add as edges from the source of the negative edge. If they still have a negative weight, expand further. Once you're done, drop all the negative edges. This essentially replaces every negative edge with a set of 'shortcuts' that encode all the places the negative edge could have gotten you, such that the shortcuts have positive cost. Use regular Dijkstra on the augmented graph.
This obviously has a potentially exponential complexity, though it will work if there isn't too much negativity. It should at least be enough to convince you that preprocessing is possible absent the existence of negative cost loops.
> In my country, Sweden, such actions at a state-funded institute fall under the umbrella of “kränkande särbehandling” (victimization) and are unlawful.
Does this mean that Sweden is a good place for people who are, like the author, critical of the wokeness and "cancel culture"? I used to think they're the ones setting the trend there. I don't understand anything now.
> If I think my neighbor's a dick, I don't need to hold a trial by jury to decide if I'm allowed to disinvite him
In this case you are exempt from that principle because following it will cost you disproportionally more than the possible damage done if you're wrong. Not because universal justice principles somehow become inapplicable outside of courtroom.
It’s more like : you win a Turing award by finding a strategy to parallelize this problem as you’ll be able to use that approach to parallelize all problems in P, proving NC = P.
This applies both ways. You'll win a Turing award if you prove NC ≠ P, which is kind of what you said — at least, that the best way I see of reading your first and a few following messages.
Also: x86 is very much statically typed. Your types are 8-, 16-, 32- and 64-bit words. Each machine instruction knows the exact types of its operands, so there's no overhead on determining the types of values at runtime (like you'd need to do in case of dynamic typing).
What is "untyped" exactly? Google tells me it's the same as "dynamically typed".
Remember the context. The thread started with Elang VM making it impossible to make code faster, due to the need to accommodate Erlang's dynamic typing features and do runtime checks for that. Top comment said that dynamic typing per se can't be the obstacle for programs being faster, and gave x86 as an example of a presumably dynamic VM which does not limit the speed of the programs.
So "dynamically typed" from the article here meant that there's some runtime checks you can't unsubscribe from, and due to them there's a cap on how much faster you can make your code. It applies to some extent to x86, there's also checks there like segfault for example, and maybe you could save some space on silicon if you removed them and required the machine code to be verified to never cause segfaults. But I argue that this is too much of a stretch. Runtime checks that x86 performs are negligibly simple, and x86 is not a valid counter-example for the article's point. In my view the article's point is valid.
> 1/ there is no static checker
"return 0" is the static checker for x86 machine code.
But seriously: this is not a necessary condition for something to be statically typed, it can't be.
> 2/ if there was, the interpreter would run the failing code anyway
Failing code does not exist. All code is valid.
Haskell is undoubtedly statically typed. But division by zero will still cause a runtime error.
> 3/ memory can be integers, floats, machine instructions all at the same time
Ok. Disregard what I said about machine words. The only datatype in x86 is byte. Some operations use 2 bytes, some use 4. They may interpret them differently (some may see an int, some float), but it changes nothing, since both int and float operations are operations on bytes.
Spent so long trying to get quote formatting on a mobile that I didn't notice I've replied to the op, not the subthread. Bad times.
Whether x64 is typed or untyped feels like the start of an argument about whether xmm registers have the same type as stack memory which is kind of interesting but orthogonal to elixer.
I would agree that static, dynamic and untyped are distinct things. You can compile from a source language with any type system to a target language with any type system. I think, there may be edge cases around excessively constrained languages.
As an extreme example, the target machine says nothing about whether you can constant fold 1+2 into 3 in the source language, but the source language can definitely block or enable that minimal optimisation.
Your points concern everything around text editing, but not editing itself. Emacs brings nothing new to the table with respect to editing model, it's essentially notepad (with different interface, plugins, yada yada yada — all the things you mention). Vim has a model with modal editing, much better than Emacs. Kakoune and Helix improve this model even further.
It's like comparing cars by the color of the trim and air conditioning, instead of… er… their car performance (power, speed, fuel usage, durability).
If you don't care about editing models, and just want to "type code", then Vim is hardly the best choice. Emacs and Intellij are much better than Vim at plugins, and are as available as anything else.
> Emacs brings nothing new to the table with respect to editing model, it's essentially notepad
Emacs (1976) predates Notepad (1983).
I do understand what you mean, though. For people using Windows, Emacs needs to be sought out and installed, this effort needs to be justified (assuming one is permitted to install software at all), and hence the requirement for Emacs to "bring something new to the table" over the default option, Notepad, which is just /already there/.
The most basic, implicit, requirement, then, is exactly as GP says: availability. All else follows.
I meant Notepad as an example of something that implements the basic "move the cursor between the characters with arrow keys and type to insert text" way of interacting with text. In terms of this, Emacs is exactly Notepad + plugins. And plugins (unless they drastically change the way you interact with text, like Evil mode) are usually doing something that is orthogonal to the editing model, and can be slapped on top of any editor with any model.
I didn't mean that one is based on the other historically. Notepad was meant as the most minimal example that implements one of the Emacs'es aspects.
> Emacs brings nothing new to the table with respect to editing model, it's essentially notepad
Wow, and here I thought I had seen all derogatives about Emacs ;-) But claiming that it doesn't bring anything new compared to Notepad is really strange.
1. Emacs predates Notepad by one or two decades.
2. Have you actually had a look at what is actually included in Emacs? I am not talking about mail readers and other "apps" inside emacs. I mean just for editing text in a non-mode specific way. Things like rectangular cut and paste, vertically aligning stuff, infinite undo, undo restricted to the selection (region) and many many more stuff. That Notepad doesn't have.
> Have you actually had a look at what is actually included in Emacs?
Yes, I've been using it for a few years and made my own plugin with a couple dozen users. Then I discovered Vim overnight and never used Emacs again (literally).
> But claiming that it doesn't bring anything new compared to Notepad is really strange
It does indeed sound strange because you missed the "with respect to editing model" which is crucial for my point. Emacs has nothing in it other than Notepad + a large number of ad-hoc, non-coposable plugins each doing one task.
> Things like rectangular cut and paste, vertically aligning stuff
Ad-hoc things that do only one very specific task each. Incomparable to Kakoune's powerful and composable way of interacting with text.
> infinite undo, undo restricted to the selection (region)
Orthogonal to the editing model. These can be slapped on top of any text editor, be it vim or notepad. Just make a plugin.
Chordal editing isn't as popular as modal editing, but I do like it and think it's something uncommon in other editors, at least to the same extant as emacs.
The thing I like about emacs is the integration and consistent experience.
I can do everything in emacs (and use exwm as my window manager), so I have the same keybindings for everything.
As perhaps an extreme example, imagine having
1. A window manager like i3
2. tmux or screen
3. (n)vim or helix sessions with edited files, possibly inside tmux/screen
Each of these need to be configured separately, and each layer needs different keybindings so that uncaught ones can be forwarded from one layer to the next. Each layer is limited to only the subset of things it manages. E.g., i3 can let you switch between firefox and the terminal running tmux, but not the different sessions tmux manages, or views of any of the files in your nvim session.
Etc.
Or I could just use emacs create tiles I can move between, and each of which that is capable of opening any of my x-windows, terminal sessions, or open files.
You can even use the same autocomplete in your shell as when editing files.
I don't know of anything that gives the same simple, unified, workflow of EXWM (+ corfu&consult&...).
It does have issues and could use a serious modernization -- still single threaded in 2023, with some commands blocking IO??? -- but perhaps it's simply much too ambitious for someone to try and make a competitor.
These can have modal editing, tree sitter and lsp integration would be great, etc.
The thing I want is the smooth integration of everything I may do on a computer into one interface that emacs, but no other software I'm aware of, offers.
What is chordal editing? Google search didn't give me any results.
I agree that having different programs on you computer integrated and consistent is a good thing. Sorry for the reference to the old joke, but wouldn't all the things you list look better in a wishlist for an operating system instead of a text editor?
By chordal editing, I just meant pressing combinations of keys at the same time. Lots of editors support this to some degree, but most (AFAIK) are either modal, or don't support keyboard-driven workflows.
One of the other classic emacs jokes is about how it can take key-combinations to extremes, e.g. https://xkcd.com/378/
I agree that I'm looking for a tiling window manager. This is what EXWM (the Emacs X Window Manager) is.
The problem with things like i3, is that it is not integrated enough with editing and navigation of files.
I wish there was more in this space, as Emacs has some limitations for this purpose (e.g. multithreading), but AFAIK emacs stands alone.
This comment here, I think, has the answer. The inial returns from using the more functional and mathematical view of programs are smaller than that of traditional approach. But the former scales better if you invest more time in it, and eventually can give you much more.