diffxx

I support the push towards memory safe languages but emphasizing Rust in the way this paper does seems misguided. It creates a false dichotomy between c style languages without safety guarantees and Rust as though there are no other alternatives. There are other approaches and models that can also achieve bare metal performance for many problems without taking in all of the complexity of Rust. Moreover, we will never settle on one language to rule them all (and if we do I am 100% sure it will not be Rust), so we should be emphasizing approaches to mitigating vulnerabilities rather than prescribing a particular tool.

My gut reaction is that independent of the quality of this product, $30 is easily spent on lunch for 1 in many places. I would like to see more developers willing to pay for tools that they benefit from using. Since we generally don't culturally, it is very difficult to make it as an independent developer which has many unfortunate consequences.

It can work if you think carefully about module boundaries so that the dsls do not leak out of their containing scope. Most of the time, dsls are not well bounded and even if they are, they are likely to confuse newcomers to the codebase. Of course, whether or not dsls are used, every program does have custom dsls in the form of functions that newcomers also aren't going to understand so it isn't as though programs written in a vanilla host language don't have many of the same comprehensibility problems as those written in a dsl.

That being said, not every piece of code needs to be accessible to everyone. Dsls allow you to create a hermetic world inside of a programming environment in which certain properties always hold, even if the environment does not guarantee these things for you. Programs written in the right dsl can be more productive to write and have much lower overall operational costs. But the price is that the rules of the dsl are not necessarily the same as the rules of the host language and this leads to confusion. For the truly ambitious programmer, it can be worth sacrificing accessibility to the median coder to build systems that the median coder can't even conceive of. Of course your reward is to be derided for not expressing the solution in a language they can already understand.

Wrt to Forth itself, Chuck Moore has pointed out that Forth is a multiplier: it makes good programmers better and bad programmers worse. I personally care more about the former property and frankly don't want to work with bad programmers anyway.

This feels like an argument against learning how to play an instrument. Why would anyone do that when there are so many other highly skilled players out there?

Yes, and there is an incentive problem too that people are rewarded for being decisive but rarely punished for being wrong. In many contexts the odds are really stacked against you if you have a strong opinion that deviates from the consensus which is perhaps why persistence is a trait that we valorize given that it does require real courage.

There are some good points, but I disagree pretty strongly with some of the premises in your blog post. I ask this quite seriously: why should I care about the health of the jvm ecosystem? Unless I am oracle, how does that fit in with my personal or business goals?

I know definitively that for me, personally, the quality of my build tool significantly impacts my productivity. Maven does not meet my personal bar and if I needed to use java for whatever reason, I'm not making a sacrifice to the altar of the jvm ecosystem purity and subjecting myself to maven.

The irony of a substacker attacking the concept of bullshit jobs is a bit much...

Why should my tax dollars pay for your special interest group to have free meetups? How would we distribute access to this newly created resource equitably?

I don't disagree with the concept, but it gets hairy in the particulars. The problem is that of course we rarely ever get to vote on issues such as "should we build a community meeting space?" so we never really get to understand how the electorate truly feels.

I truly loathe that quote. It is a tautology that is used to deflect legitimate criticism.

I found GEB understandable but ridiculously long winded and the passages with achilles were insufferably annoying.

Premature optimization is the root of all evil. Instead of optimizing the performance of the interpreter, they should optimize the language semantics to be fast by default.

I don't agree that this is what living in a democracy means. It has been known since ancient times that democracy is vulnerable to hostile takeover by a populist demagogue. Sometimes, paradoxical as it seems, it is necessary to overrule the people to preserve the democratic system.

I do not understand how you can not see this is an activist court. They have by fiat invented new judicial principles out of thin air: "history and tradition" and "major questions doctrine" come to mind. And they apply these arbitrary principles in a heavy handed, inconsistent and simultaneously predictable way while sanctimoniously acting as though we can't see what they are doing.

How would you feel about someone who says "we believe we should follow what the bible says even if it’s (in)convenient"?

I think it's really unfortunate that most programmers are taught c style loops before tail recursion. But this is also a symptom of standard c's problem of not allowing one to define functions inside of functions. A loop can always be expressed with tail recursion. While the reverse is also true, there are many problems for which this is not straightforward given that a tail recursive function can have multiple exit points and these have to be coalesced into a single flag for the loop.

I feel reasonably confident that most of the people who are making these hyperbolic claims either don't understand programming at a deep enough level to make the claim or are trying to sell you something.

I am confused by this comment. All the enumerated features are dependent directly or indirectly on the memory management approach that the system uses. If one chooses badly for the target workload, there are many things that will go wrong including excessive copying (which kills the performance of the system) and inscrutable crashes/logic errors as well as security vulnerabilities.

Personally, I tend to think that if you nail the memory management technique all the other items will tend to work themselves out. And I think this is actually harder to get right _systemically_ than all of those other things.

Writing documentation up front is a good idea, but only if one treats it as the first iteration of the program with the expectation that the initial documentation may well be thrown out. The process of writing the documentation no doubt will help you organize the plan for writing the code. But there will also be things that the documentation does not capture or problems it does not foresee that emerge as the program is being written.

The danger is that either you fail to update the documentation to account for the changes in the system that emerge in development or you only update parts of the documentation as you go which causes the documentation to become inconsistent and unreliable.

A middle ground is write the documentation up front and then rewrite it after the system is done. The initial draft helps guide the design and the final version captures the full and complete essence of the finished program, which is nearly impossible to do up front.

It's not an either/or.

I would be very happy if you streamlined the approval process for my project.

vs.

I will donate $20k to your reelection campaign if you streamline the approval process.

Clearly the former construction could not possibly construed as an implied bribe and we shouldn't punish those who want to reward our hard working civil servants for their honorable public service. /s

> I don't think it has been possible to sell a compiler which isn't a loss-leader in a bundle for what, 30 years?

I agree and personally feel that this is unfortunate and that we are in some ways imprisoned using mediocre to bad compilers by our collective refusal to pay for better ones.

Not the OP, but for me one of the main lessons from Forth is that the boundary between high and low level code can be as thin as you make it. With Forth, you can define high level words using low level primitive words. You then weave these low level words together at a high level. After you have written a correct solution at a high level, bottlenecks can be optimized out by introducing new low level words. It's like you are solving a problem by designing an instruction set specifically for that problem. But unlike a hardware ISA, you can add new instructions tailor made for the specific problem you are presently solving.

Paul Graham has described lisp as a tool for writing fast programs fast (that's the gist at least). IIRC, he clarifies that each fast is a phase. Lisp allows you to write a fast, high level, prototype that might have poor runtime performance and then you refine the prototype so that the compiler can generate fast machine code.

Forth is similar but feels closer to the machine than Lisp because of the stack based threading model. In Forth, you often don't need manual memory management _or_ garbage collection and you can easily extend the system with new low level words. But it does require you to think differently about your program design so that it fits the stack based vm model.

Historically, Forth has been implemented in assembly but you can write a Forth that targets any host. The truly mind expanding thing is that you, an individual, can write a Forth compiler and you can also write it in such a way that it has multiple targets. For example, you can generate native, jvm and js targets from the same underlying source. Usually this can be done by translating the forth generated AST to source code for another high level language. This allows you to write a fast high level language quickly without getting bogged down in writing, say, fast x86 codegen or a garbage collector. To get started, you just target the host language with the best high level properties that you need (which will be problem and context specific). I don't enjoy writing c, but I have no problem translating to c if I need to for performance or for syscall access.

To illustrate the practical power of this. Suppose that you have an important subcomponent of your system that was written in, say, Node.js. It turns out that this is a critical bottleneck that cannot easily be optimized in javascript. You don't want to rewrite the whole system, but you do want to rewrite that component and have it seamlessly interoperate with the existing system. You could write a small Forth DSL for that subcomponent. This Forth will target javascript initially. You translate the subcomponent into Forth and reuse all of the existing tests (that were presumably also written in javascript). Then you rewrite the tests in Forth so that the entire subcomponent is now written in Forth. Now you write a new backend that translates to say, c or rust with node bindings. You can run the native implementation against a native implementation of the test suite since they're both written in high level Forth at this point. Then you can flip the switch between the native or javascript implementations and be confident that both implementations are identical because they have the same high level description.

Once you start seeing things this way though, you start realizing that you can write Forth style code in any language (and the reverse is also true). Forth is as much about a process for solving programming problems as it is a specific, concrete language. This is also why there is the old adage "once you've seen one Forth, you've seen one Forth."

I mainly agree although I think that the trough of despair often comes after an initial bump. At first when designing the new system, you pluck the low hanging fruit of improvement for a small subset of the system. There is no dip yet -- things are just getting better. But when you start migrating the rest of the system, you inevitably do hit that dip and descend into the trough of despair before climbing back out.

The art is to design things in such a way so that a minimum amount of time is spent in the trough.

> Dr. Sutskever’s title at the new company will be chief scientist but he describes his role, according to Ms. Meservey, as “responsible for revolutionary breakthroughs.”

My word that is an impressive level of self-confidence.

I happen to be reading Poincare's Science and Hypothesis right now and he introduced a way of defining the square root of two that I found enlightening. In less articulate form: consider two sets, one of which contains all numbers whose square is less than two and one of which contains all numbers whose square is greater than two. The square root of two is then the symbolic name for the element that divides those two sets.

Poincare says it better in the book though.

Do you believe that all humans possess equal amounts of consciousness?

This is neither distinct to religious beliefs nor universal among practitioners.

> One of the interesting tradeoffs in programming languages is compile speed vs everything else.

Yes, but I don't think that compile speed has really been pushed aggressively enough to properly weigh this tradeoff. For me, compilation speed is the #1 most important priority. Static type checking is #2, significantly below #1 and everything else I consider low priority.

Nothing breaks my flow like waiting for compilation. With a sufficiently fast compiler (and Go is not fast enough for me), you can run it on every keystroke and get realtime feedback on your code. Now that I have had this experience for a while, I have completely lost interest in any language that cannot provide it no matter how nice their other features are.

> Is there really any value in having profs generate thousands of different explanations of the same concept for the same topic? I don’t think so, especially as most don’t put much effort in.

Would you be satisfied with a professor who is mindlessly reading back to you information from external course materials? I know I wasn't when I was in school. It was only the professors who made the effort to teach what _they_ knew who were worth learning from.

Cool language. One modest suggestion: perhaps return 0 rather than 1. Feature request: addition and division as well as subtraction and multiplication ;)