And the Go, Java, Ruby, JavaScript, C#, Typescript, PHP, Kotlin, R compilers, and so on.
But even for hobby projects, it’s just a matter of personal preference. OCaml is great for implementing compilers. So are Go, C++, and Java.
686 karma · joined August 21, 2023
But even for hobby projects, it’s just a matter of personal preference. OCaml is great for implementing compilers. So are Go, C++, and Java.
I was more so pushing back on the the implication that if it’s not OCaml, it’s not the right tool for the job.
Like, I honestly can’t think of a mainstream language in which it would be hard to implement a C compiler in.
You can write compilers in almost any language. I fail to see how C, C++, or even Java or Python aren’t the right tool for the job here. I like pattern matching too, but given that hundreds of successful production compilers have been written without pattern matching, it’s surely just a personal preference.
2) It’s actually easier to read than to watch live. We’ve heard all the arguments by now. “Go see it live”, “You need to see it with better actors”, “It makes more sense when the accents are British”. All made up, none of it is true.
3) “Early Modern English” is “Modern” only relative to “Middle” and “Old” English. It isn’t modern in any normative sense. It’s just a linguistic classification, not to be taken literally in casual parlance.
Look, I have a degree in English literature. I’ve read the canon. I’ve read all the major works of Shakespeare. I’ve seen many of the plays live.
It’s difficult to read. Because he’s writing in a language that we don’t speak.
If I see a play live, I have to read it beforehand in order to refresh my memory. If I haven’t read it recently, I have no clue what the actors are saying.
John Mcwhorter, a linguist Phd and a lover of Shakespeare agrees with me.
The truth is that understanding Shakespeare is hard because he doesn’t write in anything that would be considered English.
Perhaps English literature majors should still be forced to learn the original plays.
But for high school students in Ohio, can we please just translate the plays into something they understand? Can we give up the bit and stop pretending like these 16 year olds have the slightest clue what on earth is happening in those plays?
Most people just severely underestimate the amount of work it is. You probably need 1,000 hours of listening to be decent, and 2,000 to be strong. If you practice 30 minutes a day, that will take 11 years.
So the only “trick” is that you need to find things that you genuinely enjoy doing in French. So that you can practice for multiple hours each day without burning out.
I’m a native English speaker who has a very high level in Spanish. It takes a long time for your brain to figure out how to decode the type of mumbling people use in casual speech.
Yes, practice vocabulary, practice grammar, read. But you’re probably already doing this. You just need to listen to a ton of stuff right at the edge of your abilities and you’ll notice improvements every few months.
My one final tip would be to not get in your head so much. Literally everyone who has learned a language will tell you that if you review vocab, do grammar exercises, and listen to the language for 1-3 hours every day, you’ll learn it.
But it happens so slowly that it doesn’t feel like it will work while you’re on the journey. It’s sort of like the gym: if you lift every day and eat healthy, you will have muscles in a year or two. But it’s really demotivating because you won’t notice a drastic difference even after 3 months.
"Innate grammar" are essentially the meta-rules that govern why the rules are what they are. For instance, an English phrase can be recognized as valid or invalid by other native speakers according to the rules of the language. But why are the rules what they are?
This is especially puzzling due to the dazzling variety of human languages. And the fact that, after a period of immersion, humans seem to have the natural capacity to learn all of them.
How do LLMs fit into this? Well, I think it would be interesting if we left a group of LLM to talk to each other for 1000 years. Then see if 1) they developed a new language branch 2) that could be relearned by humans through immersion alone.
It's true that LLMs have learned (have they? I suppose that's a loaded word) human languages like English. But it's unclear if they are governed by the same meta-rules that both constrains and drives the evolution of humanities thousands of distinct languages.
I suspect Ladybird’s success has a lot to do with Andreas himself.
The theory is that JS JIT compilers don’t actually improve real world performance on the majority of websites. This was apparently per the advice of the authors of Chrome’s and Safari’s JITs.
Is it that there isn’t enough housing period, in the entire country. Or is it is people and investments abandoning rural areas in favor of a handful of city neighborhoods?
I’m also curious if those vacancy rates can be / have incentive to be gamed by the homeowners, or otherwise don’t paint a very accurate picture. I lived in a wealthy part of NYC for a while, and my apartment faced a courtyard on the interior of the block. As a result, I could see into the windows of 100s of apartments of 3 adjacent buildings. Only maybe like 5 out of 100s of apartments consistently had someone living in them. This reflects my feeling on the street: the streets were empty, especially given the relative density of the apartment buildings.
I know this is anecdotal evidence, but everyone I know that lives in NYC has the same observation.
I wish scientists and experts would take these concerns seriously and research by this gap in perception and the reported vacancy rate is so different.
But, do you know how hard it is to fluidly conjugate into 50 verb forms in spoken speech?
Plus, people gloss over this fact, but Spanish is highly inflected. After you choose 1 out of 50 conjugation for your form, you have to choose a gender for your noun, and inflect your adjectives by number and gender. Conceptually, it’s not difficult. But if you open your mouth and starting try to talk this way you’ll mess up for about the first 5 years.
I can do it. But of course a language which I know seems easy to me!
But point taken that most languages have conjugations + all that other stuff, too.
This article feels so foreign to me because I’m not trying to be productive. I don’t have a productively system, because I’m not.
I complete my works tasks. Those usually have lists.
After work and on the weekends, I spend time with friends and family, and do hobbies as I enjoy them.
Beyond that, I don’t try to remember things. I let stuff slip through the cracks (ok, I have a planner for birthdays). I don’t try to get things done.
For what it’s worth, if you looked at my life on the outside, you’d probably think I was “productive”. I can speak multiple languages, I make music, I play sports, and I have various programming projects going.
But I don’t do any of those things because they are productive. Every day after work, I spend an hour or two doing whatever I enjoy in a completely non-systemic manner. And I find that over a multi-year time span you actually can accomplish a great deal with this “non-system”
So, they stay on the bleeding edge if C++ compilers. So in terms of core language features, they are C++20-something.
But, everything is written from scratch, including the standard library.
As such, the code is a lot cleaner than a typical C++ codebase.
Someone who has been learning for 20 or 30 years probably can pick up a new ecosystem easier. “I can learn it in a day because I’ve been learning for 30 years”, etc.
You can see that in Go. It was a hugely hyped language, backed by Google, but without a lot of wishlist items that C++/Java/Python/Ruby/etc developers would have liked.
You can see that with Rust. There is the “rewrite everything in rust” crowd, which inspires anti-rust people to speak up.
I find it crazy how much criticism Rust, Go, Ruby, etc receive when Python has such glaring flaws. From the 2-to-3 migration, to package management. The consensus seems to be that’s just the cost of doing business.
By the way, I’m a Python developer. I don’t hate Ruby. But it seems like most Ruby fans love the elegance and consistency of its design, whereas that never resonated with me. E.g calling obj.length rather then len(obj) is surely more elegant. I never really cared though?
I guess I just find it interesting how some languages cons are excused while others aren’t. And how people can be drawn to some languages while others hate them.
I like Go, but to me it isn’t a scripting language like Python and Ruby because it has less ergonomic APIs for common operations (especially for strings and slices). Rather, Go prefers a literal representation of what’s going on in memory. For instance, there’s no “str1[1:5] + str2[1]” api, or you append to a slice with “s2 = append(s1, newElement)”. You can’t just “s1 + newElement”. I think Go’s reasoning is that it likes to avoid less literal features like operator overloading, and append() hints that a heap allocation might occur. But in a scripting language, you shouldn’t care that a heap allocation occurs and instead should choose a more concise and ergonomic api.
Java isn’t a scripting language because it’s so wordy.
Rust isn’t a scripting language because its type system and borrow checker are a bit too much.
Haskell isn’t a scripting language because monads and lazy execution are a bit much.
When I think of scripting languages like Python and Ruby, they focus on making common scripting type tasks easy, which often involves giving the programming less control over the machine. But at the same time, they don’t introduce any opinionated language abstractions like monads, a borrow checker, and actor threading model, etc. It also just shouldn’t be that wordy or type-heavy in a way that would slow down prototyping.
Traditional scripting languages have been dynamically types. But I think they can still be statically typed (like this language is trying to do). There isn’t a hard boundary, but once you are “too far into the weeds”, you notice that you are too far into weeds and not in scripting language territory anymore.
But something to keep in mind. I’ve seen servers before that could serve in the 100,000 QPS range on a single instance! They weren’t written in Ruby.
So iostreams were a mistake, they shouldn’t have happened in the first place. And given that they happened, std::format should have been added 20 years ago, or at least in C++11.
The problem is that many professional shops never used iostreams, and instead hand rolled their own format library. Now, they don’t really care about std::format, and probably will never use it, because it would involve migrating off of their hand rolled solution which is working great.
On the other hand, for small shops and hobbyists that don’t have the resources to reimplement std, this is a huge quality of life improvement. Meanwhile, more modern languages like Rust are encroaching.
And this is all just about how to print “Hello World!”. This situation is really emblematic of the challenges faced by the C++ committee. It is really impossible to please everyone, or even a majority, since the community is so fractured.
Then the thick client is controlled server side by the devs.
If you design the thin and thick client intelligently, you can make a lot of changes to the system by merely modifying the thick client (which you control), without needing to update the thin client.
Problems tends to come in a few flavors, namely that this increases complexity and that some changes will always require modifying the thin client.
The biggest pitfall, though, is that you have to actually put thought into the thin client design. “Thin” is an emergent property of a well thought out client. You can’t just “touch thin_client.java” and think because you named it “thin” that it’s inherently decoupled from the service. You have to actually put thought into it.
Your example is exactly right. The service can support either v1 or v2 depending on the version of the thin client.
The main other technique is to have the thin client communicate in a relatively abstract and generic manner. For instead a “write()” endpoint that accepts an “options” dictionary.
“write()” is so generic that it probably won’t have to change, and changes in behavior can be modified by shoving stuff into dict, perhaps with a “version” field to instruct the server how to interpret the call.
When you add a new feature, you can bump the thin client to v2 and shove new options in the dict. Then the server can support v1 and v2. But also, you can modify the server to handle v1 differently. E.g the absence of a “disable_new_feature” key automatically opts v1 callers into the new feature.
I think the details are are really coupled into what you are engineering and what you want to roll out. There’s no magic bullet, and this increases the complexity of your code. Good engineering in my opinion is deciding when these approaches are worth it and how they should be implemented.
They bring this up, don’t address it, then proceed to the results anyways.
The idea of grammatical or language complexity is very dubious. They seem to define it by number of distinctions. But, how is that inherently more complex?
Wouldn’t we expect Russian children to start speaking later than, say, Chinese children? But we don’t actually see that, all children seem to learn their respective mother tongues at about the same rate.
Now, if you’re an adult monolingual English speaker trying to learn Russian, then I’m sure the crazy conjugation and declination systems would appear complex. But it’s probably simply different rather than complex.
5 year old Russians seem to think that case declinations are the easiest thing in the world!