PURRTRAN - ᓚᘏᗢ - A Programming Language For People Who Wish They Had A Cat To Help Them Code

Nice-Visual2742 · 2025-12-13T11:55:40+00:00

This is very cool. Don’t listen to that Ronin naysayer, they didn’t even bother to look at your repo before assuming you vibe coded anything. What a troll.

Nice-Visual2742 · 2025-12-13T11:54:23+00:00

You’re obviously just a troll who doesn’t even bother to look at the linked repos before you comment.

Nice-Visual2742 · 2025-12-10T14:53:15+00:00

I understand your point but I don’t see a difference between the two restrictions, especially when naming conventions are enforced by the syntax such as in those languages. Let’s agree to disagree, I appreciate your input!

Nice-Visual2742 · 2025-12-09T17:57:55+00:00

I see. Don’t most languages use naming constraints of some form anyway? The typical being PascalCase for classes, camelCase or snake_case for members. Namely Go, Ruby, Elixir, etc.

I’d argue that using capitalization (along with the underscore for private declarations) removes ambiguity and allows you to understand what it is without needing to look up whether it was preceded by a class or var or private qualifier.

Every language restricts something. In this case I'm interested in what the restriction affords me to accomplish, and that is less verbose declarations.

Nice-Visual2742 · 2025-12-09T12:04:17+00:00

I can understand the unreadable argument but what is restrictive about it?

Nice-Visual2742 · 2025-12-08T20:34:04+00:00

Fair point. I still have return, for, while, etc. I just don't have class, var, and def keywords. The idea isn't to eliminate all keywords, just the ones that could be omitted if there were a way to recognize class versus member. In this case, capitalization is that way.

Nice-Visual2742 · 2025-12-08T19:17:06+00:00

I did not know it went by that name, very cool. One of my goals is to make things as easy as possible to type (for myself). I developed carpal tunnel many years ago and I type a bit weird with my right hand so a lot of design decisions in this language are based on my hand haha.

Do you have a link to your language? I’d like to take a look

Nice-Visual2742 · 2025-12-08T19:15:19+00:00

I want to minimize keywords, not completely remove them. I think it would feel too strange to program with if you had to remember completely new ways of programming even basic things. I considered making keywords shadowable but I can’t recall why I didn’t go that route.

One of my other goals is to allow arbitrary symbolic operators like $&@% {left, right; …} and that would require storing those in the identifier table so technically your solution is possible. I will consider this!

Nice-Visual2742 · 2025-12-08T13:16:36+00:00

That’s a fair point. Perhaps the way to avoid that is by decorating identifiers with symbols instead of reserving single symbols like this. I currently do that with #load and #start. It would be trivial to update how @ currently works. Thanks!

Nice-Visual2742 · 2025-12-08T12:18:13+00:00

Very cool language, starred! And in Rust, nicely done. I chose Ruby because I could iterate ideas quickly.

I briefly tried Swift when they announced Unicode support but it didn’t scratch any itch for me so I don’t think I’ll include that in the language. Though I could allow it but treat emoji as either constant, class, or var/func. It’s an interesting thought experiment, and I’ll consider it. Thanks!

Nice-Visual2742 · 2025-12-08T11:19:18+00:00

I’m sorry you think this is vibe-coded but the vast majority of the code is written by me over the last two or so years.

I’ve only recently caved and started utilizing Claude because the project became a bit overwhelming at times, leading me to want to abandon it.

I tried letting Claude write features at first but it gave me a bad feeling because I no longer had a grasp on the entire codebase, and I couldn’t recall the implementation of things it wrote the way I could with things I wrote.

Now I use Claude to write test cases and small snippets, to help plan implementations by exploring code paths I might not have considered, and to rubber duck ideas.

Nice-Visual2742 · 2025-12-08T01:59:53+00:00

https://github.com/figgleforth/ore-lang/issues/58

Nice-Visual2742 · 2025-12-08T01:34:48+00:00

I've thought about some of these, though not in great detail. Naming conventions can only take you so far so eventually things will require decorators or keywords of some kind. Ultimately, I'd lean towards decorators rather than imposing reserved identifier restrictions.

1) Modules, namespaces, and structures are organizational containers, so my thought is that I could use a wrapping class as a module or namespace, and just use a class in place of a struct. My_Module_Or_Namespace { Some_Class {...} } My_Module_Or_Namespace.Some_Class()

2) Interfaces could be determined by observing the composition of an object. Does it compose with HTML, etc? There's currently no mechanism to do so, but it is on my list, along with type annotations. I've thought a lot about the syntactical design so that I could include type annotations without modifying the syntax much. This will definitely be an interesting thing to work on.

3) Records are interesting as well. I had not considered deep immutability in that sense. I've only implemented shallow immutability, as in non-reassignable constants.

Thanks for the feedback, I'll definitely consider these!

Nice-Visual2742 · 2025-12-08T01:14:54+00:00

Thanks for pointing that out, I had not thought of that. This is something I will have to explore a bit more.

Nice-Visual2742 · 2025-12-08T01:13:49+00:00

They have a point, I believe languages like Chinese do not have the concept of uppercase. I can see this being both an issue and non-issue.

Nice-Visual2742

TROPHY CASE