yesterday at 11:55 PM
I'd like to come up with some constructive comments, but I find everything so inconsistent and alien to me...
For example, variable declarations use the pattern <colon> <type>, as in
var a: Int32
a = Int32: 42
func foo(a:Int):Int
import func bar(a:Int) -> (Int)
var w, h, d = 640, 480, 2
var w=640, h=480, d=2
today at 8:30 AM
Author here. The language has still many inconsistencies but not these ones.
Import functions is done the same way:
func foo(a: Int): Int
import func foo(Int): Int
The multiple declaration is consistent with assignment:
var w, h = 640, 480
w, h = 640, 680
w, h = getBoundingBox(obj)
var a = Int: 32
var id = expr
var a = Int32: 42
var b = Uint8: 42
println("The answer is \a", Float32: 42)
var id: Typetoday at 5:07 AM
The parallel assignment just work mostly like it does in ruby so that doesn't look weird to me (except the need for 'var' in the first place).
Agreed on the rest, though I don't understand what the problem would be with recursion. Is it using reference passing also for primitives like integers?
today at 6:40 AM
> Is it using reference passing also for primitives like integers?
That's what I assumed, but honestly I might have misunderstood the docs. This passage is not very clear:
> Copper manipulates only references to objects. Simple data types such as integers must be seen as references to stateless objects (i.e. objects that have no state in memory).
today at 7:26 AM
Sounds like they store the integer in the reference itself in that case. Which also is how Ruby does things (though Ruby has to decide what is what at runtime and thus steal a couple of bits off every integer).
today at 3:02 AM
Agreed.. and what is going on with the `!` syntax? The docs are not exactly clear on the purpose in all cases.
https://tibleiz.net/copper/documentation.html#basic-syntax
today at 6:46 AM
I think it's the opposite of & in C++, that is T! is an object, while T is a reference to an object.
yesterday at 10:11 PM
Surprisingly, the most irritating nitpick for me is the choice of the file extension â surely that should've been ".cu", not ".co"? If I were developing an e.g. Iron programming language (hypothetically â although perhaps so named a language already exists), I'd pick ".fe" in a heartbeat.
Then again, I'm the kind of person who've chosen $'.\U0001F9CC' (that is, $'.\xF0\x9F\xA7\x8C') for a file extension of my own toy language so...
yesterday at 10:43 PM
Unfortunately for Copper in particular, .cu is associated with CUDA (so perhaps thatâs why).
today at 7:01 AM
And donât ask what it means in Portuguese.
yesterday at 10:57 PM
My first thought
yesterday at 10:56 PM
Not a programming language, but Jane Street has (had?) a code review tool called Iron, abbreviated "fe".
https://blog.janestreet.com/code-review-that-isnt-boring/
yesterday at 11:15 PM
And theyâre not alone â mercurial is hg and the silver searcher is ag.
yesterday at 10:14 PM
I like the way you think.
yesterday at 10:30 PM
You're appreciated
today at 9:50 AM
So nice to see a low-level language without those pesky semicolons
yesterday at 8:46 PM
Itâs nice they tried with a more fleshed out exemplar. Polymorphism (âgenericsâ) and interfaces (âOOPâ) would have been even better to see, especially across any kind of visibility boundary enforced by the language (packages, and the like.)
Programming to an abstract interface â and in large codebases, enforced visibility controls â represent the middle ground everyone wants, in my experience, between âOOPâ and âsir, this is Câ.
yesterday at 10:40 PM
> Polymorphism (âgenericsâ) and interfaces (âOOPâ) would have been even better to see
Yep. Interface-based (true) delegation between objects would be my go-to if it existed.
today at 12:22 AM
Subtyping and generics raise the question of whether containers are covariant or contravariant.
yesterday at 9:16 PM
Yes,
The example definitely shines. Doing something barely non-trivial is great since it gives a feeling for the language. I wish other language introduction pages would take note.
today at 4:06 AM
I really like this language introduction.
It does feel like you need some shared understanding with the author about what the interesting parts of a programming language are and what can be left implicit.
Perhaps the author and I have similar intuitions? I guess I also like that isn't pure LLM output style. It was refreshing to see some human work.
yesterday at 6:27 PM
As a Crystal fan, really nice syntax. The documentation leaves open several questions:
What is the memory model here? What does it compile to? What makes it 'low level'? Is there a GC? Does it have ABI compatibility with C or a FFI?
yesterday at 6:58 PM
last Friday at 7:09 PM
Not mine, but I found this to be really interesting as a language created by one person for their own use.
Also really interesting are the author's blog with articles on language design (for example his thoughts on exceptions, and how he added them to his language, then decided against them), and the change log for the language, showing its evolution.
https://tibleiz.net/copper/changes.html
yesterday at 5:48 PM
I need to put a disclaimer to say that I hate when people hijack a post about foo to talk about bar, but:
> The language is not object oriented but it provides some features to facilitate object oriented designs.
It has classes and implicit `self`. Not nothing, but I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense.
Something like Pony[1] is a more mature and feature rich entry and has a much better OOP story.
All that said: a) I'm sorry for doing the thing I hate when other people do
b) Creating a language is a big undertaking, and it's super cool that they did it
c) I see it seems to already be written in Copper too, which is also very neat!
yesterday at 6:16 PM
Re "c)": No, self-hosting is the biggest temptation, and the worst mistake, for any programming language. It's death to bootstrapping. However, if you do succumb to the temptation to self-host, having a C backend, as Copper does, is probably the best way to handle it.
yesterday at 9:34 PM
I've never really understood the opposition to self-hosting.
As long as:
* Your language is the kind of language that suits compiler development.
and
* You support compiling to C or something so that bootstrapping doesn't involve an opaque binary or compiling 30 different git commits in a row.
What are the downsides exactly?
today at 12:56 AM
The usual argument is that it is a distraction when youâre designing a language, and it leads to programming languages that are all excellent for writing compilers and parsers, but not particularly good for other things.
Since the majority of programs are not compilers, it might make more sense to focus on interesting things that arenât relevant to compilers.
Some ideas from the top of my head: async I/O, a great SIMD story, effect systems, robustness systems for long-running processes (Iâm only aware of Erlang/Elixir), and many others.
Compilers do exercise some things, like error handling and memory management, but theyâre not particularly difficult or interesting in general.
yesterday at 6:20 PM
What's the problem with self-hosting? I do imagine it's easier to write a compiler in something like Haskell.
yesterday at 7:46 PM
The problems with bootstrapping a self hosted compiler are often greatly overstated.
yesterday at 8:27 PM
Self-hosting is a trivial matter if you can roughly map a subset of features of an existing language to your language. Write bootstrap compiler in that language and translator in parallel (as long as you have good AST/LST), run conformance tests on both.
yesterday at 8:31 PM
As long as one of the backends is something widely available, I don't see a problem. C is a decent option. LLVM IR is another.
yesterday at 10:59 PM
This isn't at all true, as proven especially by Zig.
today at 1:41 AM
I would go so far as to say Zig even tries too hard to solve it (although they reused existing technology they already wanted, so it was almost free). You can bootstrap a self-hosted compiler to new environments by porting the source, cross-compiling it, and scp'ing or otherwise downloading it over to the target. And that's if you don't want to just use QEMU to develop it. We already do this exact thing when developing for embedded devices or often any type of aarch64 programs.
today at 2:04 AM
As someone who has monkeyed around with the zig compiler, having the bootstrap done made monkeying around way, way more straightforward than when it wasn't around. I will admit I don't know the details and it's possible the QOL improvements that affected me only depended on other things that got solved along the way. But I have been building the stage0 and stage1 compilers to get my first artifact when I bump to the latest.
yesterday at 11:15 PM
Why is it harder to bootstrap a self-hosted language than it is to bootstrap a language implemented in C, which itself must be bootstrapped?
Bootstrapping is a one-time cost, but implementing the toolchain in C is a cost everyone has to pay every single time they touch the toolchain source.
today at 7:29 AM
What additional cost does it have to implement the toolchain in C? I would say there is some benefit in terms of implicit testing to have a compiler self-hosting. But having a toolchain in C also has real benefits.
yesterday at 11:10 PM
OOP is one of the weirdest topics in computer science in that no one can agree on what it means. Even proponents of âOOPâ have wildly different ideas about what it means. For some itâs âencapsulationâ, for others itâs âinheritanceâ, for others itâs âmessage passingâ. It seems the glue that binds OOP proponents together is little more than the sequence of letters: O-O-P.
today at 3:41 AM
I drank the Elegant Objects[1] koolaid, and recommend the two books (Elegant Objects vol 1 and 2) whole-heartedly to anyone interested in OOP. Pony lang lets you write 95% of the kind of OOP described in the books idiomatically, without any kind of crazy shenanigans.
I think most people today would say encapsulation and message passing are pretty core to the definition of OO and inheritance is largely seen as an anti-pattern.
One thing I really like about Elegant Objects is that it is very palatable to FP enjoyers. Objects must encapsulate state, but they must also be immutable. Good OOP is declarative like good FP. It looks a lot like lisp imo. You're encouraged to code against interfaces instead of using inheritance etc.
[1]: https://www.elegantobjects.org/
yesterday at 5:54 PM
Since weâre nitpicking: you used a double negative, which is a confusing way of communicating an idea.
yesterday at 6:21 PM
The bike shedders have entered the chat.
There's a difference between nitpicking the topic of the article and nitpicking someone's grammar.
yesterday at 6:40 PM
To be fair, it really is a confusing way of communicating, and itâs useful feedback when taken to heart.
yesterday at 7:47 PM
It's not confusing.
yesterday at 8:36 PM
> Not nothing, but I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense.
IMO, that text is confusing.
âNot nothingâ is saying it has some OO features.
âI don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that senseâ = I think this language has more OOP than languages like Lua or JavaScriptâ
So, that more or less says âA, but Aâ. If so, whatâs the âbutâ about?
yesterday at 9:10 PM
I think it needs more negatives. "I don't think it's incorrect to say [it does not have] any more OOP than general purpose languages like Lua or JavaScript in that sense".
I had retyped it a few times trying not to come off as overly negative or a jerk.
yesterday at 9:28 PM
> Not nothing, but I don't think it's incorrect to say has any more OOP than general purpose languages like Lua or JavaScript in that sense.
The comment is saying that the language has more OOP than Lua or JavaScript, but it seems like it might have been meant to say the opposite. That, and it appears to be missing a subject (which I assume to be âitâ or âthe language in questionâ, based on context). So personally I do find it somewhat confusing.
The problem is not the double negative itself, though; itâs more how itâs being used in context here.
yesterday at 9:37 PM
It was also to me. I also prefer simple clear language, so much for my feedback. Can we now move on?
yesterday at 9:21 PM
Lampshading that you're doing something wrong doesn't make doing the thing less wrong. Hijacking a language post, of all things, to tell people some other completely unrelated project is better is ridiculously uncouth.
yesterday at 6:53 PM
How does it free memory? I don't get it. I browsed the docs a bit but didn't find a single reference to deallocation. There's alloc for heap allocation but no free?
yesterday at 6:58 PM
In the standard library, there are some allocators with free, so it looks like youâre expected to call those. It is strange that none of the examples seem to cover this, though.
today at 6:51 AM
if every `=` is always a copy of reference, are we losing some "rvalue" optimizations? (I think Stateful Objects / Stateless Objects are basically lvalue / rvalue, respectively) For example, if a struct is small enough, even smaller than a pointer, and we know its address is never taken, wouldn't it be more profitable to just copy by values to avoid another pointer dereference? Furthermore, if only a single struct field (or attribute) is used, wouldn't it be more profitable to just pass that field value instead of passing around the reference to that struct, assuming there is no ABI issue? (the classic scalar replace of aggregate)
yesterday at 6:39 PM
I wish the author has written about the motives behind the language and why someone should choose Copper. We have in fact more programming languages than we actually can use.
today at 8:04 AM
Author here. I have written this language for many reasons but I won't detail here, I'll just say it's a lot of fun for me to design a language and write a compiler.
This language is a playground where I constantly add and remove features or try various experiments, so I have no intention to promote it. The only reason I have published it is that I publish an open source text editor written with this language.
After twenty years of evolution, it starts to become stable but not yet, I had recently added some basic option types.
yesterday at 7:28 PM
It is a personal project, which the author uses for some other personal projects.
Clade - a programming editor with elastic tabstobs and Smalltalk like navigation
Maybe, there is more. Looks to me like an illustration of the "It is a quiet life" meme
today at 9:30 AM
I'm excited to see this language. The author has a good track record with Codebrowser/Clade. What I would like to see is the C interoperability story.
today at 3:02 AM
yesterday at 4:17 PM
Garbage collected? Couldnât tell from the docs.
yesterday at 6:10 PM
I thought it would be because it looks so Python/Ruby-like, but in the source I don't see anything related to a GC at a glance and it has an allocator interface: https://tibleiz.net/browser.html?path=std&title=Standard%20L... (click on "memory" then "memory-allocator.co")
yesterday at 4:25 PM
It seems pretty tasteful, but I don't see anything about character sets. How does it support Unicode? What does a string of 16-bit characters represent?
There do seem to be some Unicode constants in the standard library:
https://tibleiz.net/browser.html?path=std&title=Standard%20L...
yesterday at 4:51 PM
Looks like Crystal to me. But with stronger typing.
Neat little language...
yesterday at 7:11 PM
Stronger how?
Definitely more explicit by default though.
But yes, very neat. I'd miss Enumerable though, if they manage to get that to play with manual allocation that would be even neater.
yesterday at 5:11 PM
Seems like Dart with indentation instead of braces.
yesterday at 5:39 PM
It doesnât look like it cares about indentation. Itâs more like Basic or Ruby.
yesterday at 10:42 PM
Hmm... Copper, I guess it must be great for representing lists. :-)
yesterday at 6:20 PM
Looks nice and small. Too bad it doesn't quite actually build (on Linux). Also, no string interpolation (AFAIC) and no kebab-case.
Here's my current stab at a small compiled language: <https://codeberg.org/stevefolta/lx-2025>.
today at 1:10 AM
It's a bit like temple os :/
yesterday at 10:14 PM
What about binding to external C ABI? I can haz Vulkan?
yesterday at 8:21 PM
Seems really interesting
yesterday at 9:02 PM
Really hard to make opinion based on few small examples but I can say I like what I see, Ruby like syntax definitely doesn't hurt language.
Multiple return values are kind of weird, but maybe it is just me. Overall this is something I will give a try.
yesterday at 5:42 PM
The simplicity is appreciated.
yesterday at 6:41 PM
"Copper is a programming language that I use as a replacement to C."
That's used... to make what?
yesterday at 8:19 PM
Seems for the other public project they've https://tibleiz.net/clade/ and its predecessor https://tibleiz.net/code-browser/.
yesterday at 4:55 PM
This might be my new favorite language. Deeply sane.
yesterday at 7:05 PM
Exactly
yesterday at 3:41 PM
Itâs similar to Python syntax.
yesterday at 3:52 PM
From the website itself:
> Ruby-style syntax
Also, Python has significant whitespace, which this language does not appear to have.
yesterday at 8:23 PM
Glad they chose the more sane way of Ruby, regarding whitespace.
yesterday at 4:24 PM
The end syntax is definitely Ruby-style, but I guess I felt that way just from looking at syntax like var, func, and for x in. It does seem like a mix of the two, but maybe itâs because Iâm so used to Python that I noticed the Python-like syntax first. Thanks for pointing that out.
today at 5:07 AM
Is it memory safe? Or is it yet another "better C"?
today at 8:07 AM
[dead]
today at 4:52 AM
[dead]
today at 6:42 AM
AI slop
yesterday at 7:18 PM
This seems to have a lot of potential, but there are important details missing. Hopefully the feedback from this thread will result in those questions getting answered by the author soon.
yesterday at 6:58 PM
I think the days of releasing new programming languages is gone, it's like releasing a new punch card format. Humans don't code anymore and so programming language is really a choice LLM's make for you.
yesterday at 7:01 PM
What leads you to think that? All the engineers I know always choose the language depending on the project details, scope, their own or team preferences, etc.
yesterday at 7:23 PM
They ask Claude or some other model, this is the correct thing to do though, given it has the whole internet of software engineering history trained into its model and can read thousands of articles docs in seconds.
yesterday at 7:08 PM
> Humans don't code anymore
I find that difficult to believe. Is there some objective evidence?
yesterday at 8:19 PM
I can supply anecdotal evidence - of all the people I stay in touch with only one person occasionally opens IDE to write code. This transcends from interactive client apps through novel database engines.
AI is undergoing cosmic inflation, we get further apart faster.
yesterday at 7:49 PM
I guess Iâm not human
yesterday at 7:25 PM
The ones that do are at a massive disadvantage, like someone writing out machine code by hand vs using a compiler back in the day.
yesterday at 7:49 PM
Someone who can write assembly will always be at an advantage over someone who canât. Yes even in the agentic era.
yesterday at 10:06 PM
This feels like a photographer telling a painter that they're at a massive disadvantage and that no human paints by hand anymore. Meanwhile painters still exist and are probably not particularly upset by how many pictures per second a DSLR can do.
> like someone writing out machine code by hand vs using a compiler back in the day
Programming using a compiler is still the same kind of thing, just in a different language.
yesterday at 11:13 PM
I was a programmer back in the day. That statement is simply misinformed.
today at 5:12 AM
This is a silly take. I think you underestimate how talented some programmers can be. I think you also overestimate how far being good at coding will get you. Pre-LLM, the job was maybe 30% coding. So at worst someone who codes by hand is only disadvantaged by a manageable amount.
yesterday at 8:24 PM
Quite the contrary: the barrier to rolling your own <anything> was never lower.
As others have proclaimed: what matters is taste. And (perhaps?) a deep understanding of the subject matter. Which may or may not be encoded in formal specifications. But may also include 'fuzzy' domain-specific knowledge that can't be scraped from the web.
> Humans don't code anymore
I do, and I'm far from alone. Whether 'product' gains traction, that's another matter. But you know what? It doesn't matter. If it works for [author], that's enough.
yesterday at 8:43 PM
Why? Did mathematics end when pocket calculators became popular? As today, the world initially overreacted (as usual): calculator opponents did warn about dependence, loss of arithmetic skills, and erosion of mathematical understanding. Making an existing exercise easier does not establish that the underlying discipline is in jeopardy.
yesterday at 11:10 PM
"The days of the very thing happening here are gone."
Uh, no.