A Forth programmer who bootstraps their own Forth probably isn't that excited about having a c compiler.
587 karma · joined August 16, 2022
When you develop in this style, you tend not to write type errors because you are constantly validating your program inputs and outputs, which the tight feedback loop encourages. Most statically typed languages have slow compilers. It is not uncommon for an incremental compile to take at least 1s, which is 50-100x slower than what I'm used to. Indeed, I find it distracting when compilation is that slow so with such a language I will still use a monitor script for iteration but I will manually save when I want validation. This means that I am not only getting slower feedback, I am getting less of it, which ultimately makes me less confident in my program. If I were making lots of type errors, maybe it would be worth it to have a type checker, but I'm generally not.
The language itself leaves a lot to be desired, in my opinion, but the core idea of having a small extensible compiler around which one can build efficient problem specific DSLs is brilliant. Unfortunately I think it is too easy to get bogged down in the bad parts (or at least parts that appear bad to our modern programming sensibilities). For a good overview of what makes Forth special, I recommend Thinking in Forth https://thinking-forth.sourceforge.net even if you never expect to program in Forth. It was written in the 80s but it still holds up. Read the first 80 pages or so carefully and I can almost promise that it will change the way you think about programming in a good way.
Once you have internalized the Forth mindset, you don't need to actually write Forth code. But you may be grateful that Forth taught you how to find your optimal programming language that exists somewhere inside of yourself.
I can't help but long for the day when this quotation is out of date.
What is great about this approach as an individual is that it requires you to tighten your ideas. When you have to implement all of the functionality in a DSL, you really start thinking about what you truly need. A big language nudges you towards using all of its features while a small language challenges you to consider what is truly essential.
Of course DSLs always run the risk of being write only and/or only comprehensible by the original author. Like any powerful tool, DSLs should be used judiciously and responsibly. Often that isn't the case, in part because I don't think the tooling for writing DSLs is generally very good. But I am betting that new tools that make DSL writing easy will have a profound effect on software development.
Given the externalities involved in Amazon style delivery, I personally wish they would optimize more for throughput than latency.
While reading, I assumed they were talking about western civilization itself.
For many years, I cycled > 10 hours per week. But these days I only walk and haven't ridden a bike in over a year. Even though cycling can be a lot of fun, I don't really miss it. When walking you have a different relationship with the environment. You feel like a part of it. Cycling is much closer to driving than walking. You are just passing through. It's also far more dangerous so you have to focus more on the road which allows your mind to wander less than you can while walking. There are things that you notice while walking that you would never see on a bike. I once watched an epic battle between a caterpillar and a wasp. You realize there is so much more going on in the world than what we tend to focus on.
I disagree with this assertion (look at the heated arguments between different interpretations of quantum mechanics as a simple counter example that comes to mind). If I'm reading you right, you're claiming that taste is just appreciation for beauty, which is itself an undeniable objective truth. But I think this is too extreme in discounting any subjective role in the assessment of beauty. Any object that we deem beautiful just is. Whether or not we ascribe it as beautiful or not says as much about us as it does as the object. What does universal even mean here? Universal to humans? Can dolphins have an appreciation for beauty? If not, can it be said to be truly universal? If so, do we think that the dolphin's standard for beauty is identical to ours?
Again, I do agree with you that there are certain archetypes of beauty that most people will agree on. I also agree with your point that some people will dismiss beauty out of a sense of sour grapes. I just think you are taking things too far in the claim that beauty is a universal, objective truth outside of the realm of subjectivity. The concept of beauty itself cannot even exist outside of subjective experience so how could it completely transcend it?
Taste can differentiate between different forms of beauty and form subjective preferences. Beauty is both relative and absolute. Your 16th century London building may cross the beauty threshold on some absolute scale, but consider a block that is filled with equally beautiful, but stylistically distinct buildings. It would be in poor taste to build a new building on that block in the 16th century style, even if the new building is objectively beautiful.
I actually mostly agree with you about intuition, but your claims are too extreme for my taste ;)
That being said, as your skill improves, your taste is likely to improve because you are better able to differentiate between high and low skill work. But in many cases, you don't need any skill to tell the difference. It's not exactly difficult to tell the difference between a mediocre amateur singer and a well trained professional. Where it gets really tricky though is that you may find that you may not prefer the most technically skilled practitioner. There are many people who would rather listen to Bob Dylan sing than Luciano Pavarotti. Is that poor taste? I'm not so sure. It's certainly possible to acknowledge Pavarotti's technical vocal superiority while still preferring Dylan. Whichever singer you prefer, you don't need any vocal skill to immediately tell the vast technical difference between the two. Many things are like this.
Our civilization is going to collapse long before the heat death of the universe, and honestly probably within the lifespan of people living today. We could at least try and soften the blow and stop doubling down on the same mindset that created most of the existential crises that face us today.
Not so fast. For any given project, what are the associated externalities? You can't build a house without exploiting the earth's resources. You can't build furniture without chopping down trees or digging up oil. You can't harvest energy without disrupting the environment in one way or another. Your renting your house on AirBnB is extracting more money from your guests than the time value of the house. Your guest must then do something exploitative to earn the money to pay you. The chain eventually will make its way back to the extraction of natural resources. It isn't possible to turn a profit without exploitation.
Do we really not care that we have burned up an unfathomable amount of precious, irreplaceable fossil fuels to prop up our industrial economy? We should be worshipping fossil fuels, and using them as sparingly as possibly, not frivolously wasting them.
Until we have an economy that doesn't rely on unsustainable extraction, it's hard to see any form of wealth creation as positive sum.
And they evidently spend very little time on the things that would actually improve the lives of their users in macroscopic ways. The fact that our dominant model of an operating system is essentially c + shell is a tragedy. The operating system does almost nothing for us to help write fast, correct programs in a reasonable amount of time. It is of course for this reason that unix itself has barely improved in a material way in 30 years except in these kinds of microbenchmarks. Third party tooling and languages have of course improved, but largely to cover the gaps that the operating system has largely failed to address in a meaningful way.
Now, perhaps the scheme I just outlined is a bit too obvious, but I certainly don't doubt that far more sophisticated money laundering schemes that leverage the recent supreme court decision are happening now and will happen in the future.
What I find interesting about Forth is that it is a language that is simultaneously a high level language and a low level language. It encourages the programmer to write high level programs but if they need to write low level assembly routines for maximal performance, they can (though they may need to write their own Forth interpreter to do so).
I believe that the viral spread of c and unix is possibly the worst thing that ever happened to computing. There is a quote attributed to a physician named Vincent Felitti in the context of addiction: it's hard to get enough of something that almost works. This is the story of c. It is neither a high level language nor a low level language and is thus the worst of both worlds. We've added a staggering amount of complexity to work around the limitations of c, which have also infected most of our other supposedly high level languages, e.g. java, go, rust, etc. To your point though, because we know no other way, we can't even see that much of this complexity is largely unnecessary.
Much of this goes back to Gabriel's observations in the rise of worse is better: https://www.jwz.org/doc/worse-is-better.html. What I think Gabriel doesn't fully articulate is that worse is better is an essential feature of market capitalism. The most profitable customers are addicts. Most of the time, you can't just sell them something that is complete garbage. The best thing to sell is something that is almost good enough and that the customer is not empowered to improve themselves. Then they have to keep coming back to you for updates. Why would you sell a customer a complete program that does exactly what it is meant to do and nothing else when you could sell them something incomplete that you can keep repeatedly selling back to them?
This is the water that we swim in, and it sure seems to me that we're all having a hard time breathing.
Ha, I have been working on a DSL for writing DSLs, which perhaps explains my perspective a bit.
It isn't necessarily clear to me that writing a language server implementation is that much easier than writing an editor. To be fair, I have personally done neither (though I have written REPLs) so perhaps I am wildly off in my estimation.
Syntax highlighting is nice, but fast semantic analysis is the real holy grail.
I have come to think that the best way to develop a new language would be to implement a text editor in that language before releasing the language. The editor should (ideally) have emacs and vim key bindings, though it would surely at least have the bindings that the language author uses. The compiler/interpreter for the language would embedded in the editor. This would allow for a much richer editing experience that goes beyond syntax highlighting. Indeed, the source code would become like a living document in the editor where they editor could display inline information about both syntax _and_ semantics. The editor need not be fancy. It could be written as a terminal application, kind of like a language specific nano or vim.
If the language/editor author is careful in how they design the editor, all of the syntactical and semantic tooling should be exportable into packages that can be consumed by other editors with plugin systems/lsp like vscode or neovim. Then the rich editing experience can be relatively easily exported to any other text editor. Tool authors would also then be able to write static analysis/linting/formatting/whatever tools on top of the semantic tooling that the language supports.
In some ways what I am describing is a more minimalist version of what one would get out of an image/IDE based language like smalltalk but the code representation would still remain as text files. The editor then becomes like a REPL except rather than being an ephemeral process, the REPL state is continually being written to disk and is resumable at any time from any computer capable of running the editor.
Few things in life make me less happy than the externalities of car culture. It fosters among other things: 1) Disconnection from one's community and the natural environment 2) Noise and air pollution imposed on one's neighbors without their consent 3) Worse collective physical health due to replacing walking trips with car trips 4) Excess consumption of all goods, including fossil fuels 5) Risk of serious injury or death for both drivers and pedestrians 6) High stress due to the inevitable presence of traffic 7) Environmental degradation and expansion of the urban/wilderness frontier 8) Repressive political regimes propped up by oil exports
Of course there are positives to cars too but many of the positives only exist due to the problems that the widespread deployment of private cars caused in the first place. We need cars to visit our friends and family or go to work because we constructed a society in which we don't actually live in the same communities as our friends, families and employers because the car allowed us to. We buy things that we don't need because the car allows us. Consumerism fills the void of meaning in our lives that is in no small part due to the disconnection that the car created in the first place.
Personally, although driving a car can be great fun under the right circumstance, I find most of the time it is either tedious or stressful. I would almost always rather be walking, which engages my body and allows my mind to wander without fear that I might seriously injure, or even kill, someone in a moment of inattention. At the same time, whatever mode of transportation I am using: car, biking or walking, I know that I am at risk of being hurt by an inattentive or reckless motorist, of which there are many.
I am making a distinction between private vehicles and vehicles in general. Obviously we need some vehicles to move crucial goods and people with limited mobility. And to occasionally make long journeys. Since the pandemic began, I have been only been in a car about a half a dozen times and I have experienced no material deprivation whatsoever. Of course I have been reliant on trucks delivering groceries to my local stores and the occasional home delivery (which again does not require a private vehicle).
Your fear does make me optimistic though. It suggests that people are waking up to the catastrophe that widespread deployment of private cars has had on human life.
Just as a heads up, one of the strange fsevents issues is that it fails if you register two directories where one directory is a prefix of the other. So say that you want to monitor directories $ROOT/foo and $ROOT/fo and you register an event stream first with $ROOT/foo and then $ROOT/fo, you will only receive events for paths in $ROOT/fo and no events for paths in $ROOT/foo (I just double checked that this is still the case in Monterey at least). I never bothered to report this to apple but worked around it by just registering a stream with $ROOT if I detected that one path name was a substring of another.
It is, but it's badly implemented and buggy. But the real problem is that there is no posix like specification for file system events so every platform does it differently. Even if every platform implementation were perfect and bug free, it is a huge pain to write wrappers for each one.