atilaneves

Wouldn't it be more useful to build a programming language that LLMs can use better?

> I don't understand how people have that stated as a fact. Coding was never the slow part.

Because, for them (and me!), it was. I never understood why people kept saying that typing speed wasn't a problem since coding was never the bottleneck. It always was for me.

> functions ?

Macros can condense code down a lot more since you're essentially writing a language within the language.

> but in practice it doesnt because llms arent trained to that extent on this.

Right, but it probably works with words instead of symbols.

> You can write DSLs in Rust which gives you static typing, a borrow checker, and clippy.

It also makes your agent wait for the compiler to finish.

How is Go simpler to deploy than the alternatives? C++ has been able to compile to statically linked binary for ages.

I think Go's compile times are great for the AI age, but that "pretty fast runtime" is not.

> You don't need Emacs

Yes, I do.

> and lose access to most things

What "most things" are these?

No, you can just write D. It'll have the same performance as C, if you write C-like code. It might have better performance than C if you use templates (just like in C++).

Yes, that's my point. I'm replying to claims that "if it compiles it probably works". My limited experience with both is "nah".

Because it is also possible to write tests that don't adequately capture real-life requirements.

It was an MQTT server, and the tests basically went "if we have these subscriptions, then...", but no subscriptions ever got actually stored by the server.

Every language with a GC drastically reduces the chance of memory errors.

I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock.

So...yeah.

I made the same comment last week upon learning of a redis clone entirely vibe coded in IIRC ~70k lines of Rust. Why Rust? Why does a computer need a memory safe language?

I'm still figuring out why anyone would want to write a shell script in C. That sounds like torture to me.

Wouldn't the instance state here be "was constructed"? That is: you should always be able to call `Read` because the constructor opened the file, and you shouldn't have to call `Close` anyway because the destructor did.

I just posted on the forum about it, I didn't do it before because of surgery (I'm still nowhere near 100%).

What changes would you like to see happen?

FWIW, I just posted this on the D forum: https://forum.dlang.org/post/vwnefgsszqxobssylhmc@forum.dlan...

Proof of the fact that this works is that D does exactly this.

> What do you think, is there a potential niche for like NeoEmacs, a test editor written in a modern Lisp / Scheme

I think that's a non-starter because you instantly lose the entire ecosystem of elisp packages out there and nobody's config would work anymore. The latter is especially important when for some people that's a decades-developed init.el file in a repo that's migrated from CVS to subversion then git.

I've git bisected (mercurial at the time, but whatever) my .emacs repo to figure out what I did to break my Python config, so there's that.

Switzerland has a population of 8.6M, isn't part of the EU, and yet...

The problem there has been getting enough doses delivered.

If the array fits in the cache, deleting from the middle of an array and copying all the subsequent elements one to the left is actually faster than a linked list.

And most arrays fit in the cache.

dpp* can't do function definitions yet but for declarations it's as easy as #including a C header file natively.

* https://github.com/atilaneves/dpp

I think you missed the point where they mentioned you can change any and all keybindings in Emacs.

1. That's a rare use case 2. There are ways of measuring that without hampering readability. I mean, are programmers supposed to add all the variables' sizes up in their head??

And yet, it's worse than both.

> Source code is for humans

The reason why making the scope as local as possible is important is for humans, not compilers.

> Put all the vars at the top to tell the humans "here's all the scratch space I'll be needing in this block"

Why would humans care about how much scratch space is needed? That's for the compiler to know.

That would be satan's language.

No need to imagine, it happens all the time in D, and it's not that bad.

Simple is better. People however tend to not agree on what's simple.

Not really - the concrete type isn't important, but what you can do with it is. One could argue that instead we'd use a concept in place of `auto`, and Bjarne has argued exactly that for C++.

> > It takes an input range > Which should have a type.

It does. That'd the `Range` here: https://dlang.org/phobos/std_algorithm_iteration.html#.map.m...

> > and returns a type that iterates through that range > Which should have a type.

It does. But the name of that type depends on the type of the range and on the callable.

> Functor f => (a -> b) -> f a -> f b

This doesn't work because the return type isn't `f b`, it's `g b` where g depends on what f is. It also depends on the callable, because the first parameter isn't necessary a function. The closest is

Callable c, Range r0 => c a b -> r0 a -> r1 b

Where `r1` isn't even a concrete type but a type that depends on both `c` and `r0` and is made up on-the-fly (per instantiation).

> Documentation is good.

I agree. How would you suggest improving the signature of map given that D doesn't have typeclasses? Or with types that depend on other types in the template?