JavaScript is an ok language to write code in. But it is a terrible language to read. Languages need variable locality so you can comprehend what you are reading. If a language requires an IDE to compile the language in order to resolve variable bindings, that is bad. I remember spending most of my time trying to track where variables were being declared and set when referenced in completely different places and contexts. Drove me nuts, turned me off big time.

I also don't like "magic" shortcuts. Python django uses a lot of magic shortcuts. They go so far as to put meaning into variable names (double underscore things)!! The problem is while it makes code smaller and easier to write, without deep knowledge of the framework it is impossible to read.

And far too few people read code. The ratio of code readers to code writers needs to go up. We think open source is safe because somebody *could* read it and verify it is good.... but nobody actually does.

Code should be readable and comprehendable by someone who doesn't even know the language. It should be self describing enough for that.

Rust breaks this rule too, but only because it had to define a brand new concept of lifetimes.

Reply to this note

Please Login to reply.

Discussion

I used to code

Heck, half of my thesis was in assembler (who tf knows why)

But now I don’t even know what you are talking about

It seems I have forgotten about code more than some of coders will ever learn.

Shame, double shame.

javascript added let and const in es6 (2015) to address the scoping problems.

I'm aware of var and let and const (aware but not adept). People can and will still write hard to read code with distant vars, and you'll still have to read such code.

If you are disciplined, you can write C++ almost as good as rust now. But when reading C++ you never come across such disciplined code. When reading code you have to be aware now of all the different ways of doing it, which just grow and grow over time.

agreed. too many languages provide too many ways to do things. that’s one design decision Go got right, but even that is evolving into more complexity (generics, iterators, etc)

Open-source devs should surround themselves with trusted collaborators to review and test their code.

At my day job, I spend probably a third of my time reviewing and QAing my teammates' code, a third on planning, and a third on writing my own code.

Recently, my side project on Nostr with nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz has taken on a similar breakdown.

Sure, individual bits of work may take longer, but it's easier to maintain momentum on a big project.

That and rust macros. Does anyone read macros? Luckily one can write rust without lifetimes and macros it is just a pain. Just not as much of a pain as using them.

I use macros where typing it all out would be crazy. But the macro language isn't super easy to read.

If rust devs didn't care about the usually *tiny* cost of copying things, they wouldn't use lifetimes. But they want perfection. I'm sick in the head that way myself. Lucky for us newer compilers are much more able to figure out the lifetimes and we can elide them.

I will freely admit that I don't use lifetimes because I haven't taken the time to understand them yet. It never makes sense to me. Everything the compiler complains about seems to want a static lifetime.

The basics are easy to understand, but what is tricky is interpreting what the compiler is actually saying. The basics are just that if you borrow something, you must ensure that the owning variable stays alive during the entire lifetime of the borrow.... otherwise it will be freed and the borrowing reference will point at memory that isn't safe anymore. But the details about how to do this, and what the fuck the compiler just said, that is where the nightmare arises.

I have to admit I've avoided using Rc and RefCell and gone straight to Arc and RwLock instead because those work in more cases and I can't be bothered with the single thread cases anymore.

And I usually only have to reference lifetimes if a structure has borrowed data. Borrowed parameters in functions giving borrowed return values don't need explicit lifetimes anymore.

Yes! Arc all the things! Because you know whatever you want to pass contains an object from a library that does not impl clone.

Reading Ada is a joy, but most programmers cringe when it's mentioned.

Yes, the Ada language designers understood this way back in 1977. That is because they had studied and were fixing problems with (and superceding) 450 different languages!