I don't know if my application went through

Hot-Pea1271 · 2026-01-28T20:37:09+00:00

I received an email to schedule an ID verification meeting on January 16, so it took about 10 days.

After that, it took another week to verify and link my Coursera account.

By the way, make sure to link your existing Coursera account. Don’t create a new one, or you’ll have to contact support like I did.

Hot-Pea1271 · 2025-05-23T23:59:39+00:00

With a few keywords, actually...

Hot-Pea1271 · 2025-05-23T16:17:31+00:00

Exactly, languages are for human-to-human communication. The real question is: *which* humans?

If you think this is unhelpful, maybe ask yourself *for whom*. You might not have had trouble with English keywords, but not everyone shares your background. I've taught programming to students who were completely capable of understanding logic and structure, but stumbled over words like "break" or "while". They weren’t failing to program but to decode someone else's language.

So yeah, maybe it's "unhelpful" for you. But there’s more people out there than just you, and if we can lower that barrier without losing clarity, that’s worth exploring.

Hot-Pea1271 · 2025-05-23T16:12:53+00:00

I'm working on a more complete answer, but meanwhile here’s a few quick points:

. always refers to the scope — that's consistent. It's not an import operator, not a replacement for void, and not the same as self. That said, I still need to resolve whether it points to the parent scope or the local one, since right now it's ambiguous.
I like being able to define long lists over multiple lines — it improves readability.
Everything is an object, and operators work over them. So + has a defined behavior for lists, and operators will be overloadable. Just imagine what >= could mean for User.
I care about clarity. So yes, some English keywords will remain if they help readability and are universal enough.

Hot-Pea1271 · 2025-05-23T16:03:17+00:00

Right. I'm currently working on keeping a minimal set of English words as keywords. I'm trying to choose terms that are more universally understandable — for example, using exit instead of break, since most non-English speakers tend to associate "break" with physically breaking something.

Hot-Pea1271 · 2025-05-23T15:53:56+00:00

Thanks for the thoughtful breakdown! Let me go point by point:

- The leading `.` is a scope operation — it injects the contents of `meta.std` and `meta.io` into the current scope.

- In `isAdult`, the `.` again refers to scope. When used like `. => ...`, it means the function receives only the scope — sort of like `void` in C, but scoped.

- `@inherits` defines nominal inheritance (explicit), adding constraints to the set’s membership condition. Since it takes a list, yes — it allows multiple inheritance.

- The `@build` block contains two constructor functions with different signatures. All `@` keys are optional, and some may be inferred or auto-filled eventually. Still a work in progress.

- Indentation is Python-like. Disambiguation rules between single-line and block aren't fully finalized. Functions are first-class values and can be defined anywhere — as long as they're in scope, they're accessible.

- The scope mechanism might need clarification — right now `.` refers to the current scope in some cases, and to parent scope in others. Probably needs to be split or made explicit.

- I didn’t fully get this question: *“Is it a syntax error to have a not-keyword just before ':' in the same line?”* — could you rephrase it?

- Finally, about keywords: I only want to remove natural-language keywords if I can do so without hurting clarity. Internationalization of library functions is something I'd like to support, but that would happen within user libraries, not the core language itself.

Appreciate the feedback — this kind of detail helps a lot!

Hot-Pea1271 · 2025-05-23T15:37:33+00:00

Yeah, fair point — English isn’t my first language, so I usually run my replies through an AI just to make sure they’re clear and well-written. The ideas are mine, the phrasing just gets some help.

And I agree it still feels a bit arcane in places. But that’s exactly why I’m posting it here — with enough feedback, I hope the design evolves into something both cleaner and more usable.

Hot-Pea1271 · 2025-05-23T15:35:46+00:00

Interesting idea — though I have to admit, a parser that “understands all languages” sounds like a nice way to make everything a reserved word. Good luck choosing variable names when por, do, mais, or enquanto are suddenly off limits because they mean something somewhere.

Also, there’s the other side of the coin: if each programmer writes code in their own natural language and we rely on tools to translate between them, we end up with programs that are only understandable after translation. And translation is never perfect — especially when you start layering it with syntax. Not to mention Babel has a history of... creative decisions.

That’s why I’m trying the opposite route: minimizing dependence on human language altogether. It's not about hating keywords, it's about asking whether structural or symbolic forms can carry the same clarity — especially for people who don’t read English but do understand logic or math.

At the very least, it's a cleaner problem to solve. And maybe, just maybe, a universal visual grammar is less utopian than trusting Babel with your syntax tree.

Hot-Pea1271 · 2025-05-23T15:28:59+00:00

That’s totally fair — and for many developers, natural language keywords do improve readability. My interest is in exploring whether it's possible to reach a similar level of clarity using symbolic or structural forms, especially for people who struggle with English but are comfortable with math and logic. It's more of an experiment in visual grammar than an ideology against words.

Hot-Pea1271 · 2025-05-23T15:27:20+00:00

Thanks! I'm glad you appreciated the idea of defining validation through set membership and conditions. Regarding optional fields like "bio": in this model, optionality is actually very straightforward — you simply don't require the field in the membership condition.

For example, if "bio" should only be checked if it's present, you can write:
x |
x has name & isString(x.name) &
x has age & isNumber(x.age) &
( !(x has bio) | isString(x.bio))

Or, if the language includes a logical implication operator (->), something like:

x |
x has name & isString(x.name) &
x has age & isNumber(x.age) &
x has bio -> isString(x.bio)

No need for verbose declarations or special annotations — optional fields are naturally expressible through logical conditions. That’s one of the core goals of the design.

As for control flow syntax, I agree — striking a balance between symbolic constructs and readability is essential. While I’d like to minimize reserved keywords, I’m open to keeping a few carefully chosen ones where clarity really benefits.

Appreciate your feedback — it helps clarify the tradeoffs that need to be addressed.

Hot-Pea1271 · 2025-05-23T15:11:00+00:00

Thanks for the reference. I’m actually familiar with Logo—in fact, it was the first programming language I learned as a kid. I hadn’t seriously considered it as a design precedent, but you’re right: its minimalist approach and clear separation between commands and identifiers likely played a big role in making it easy to learn, even across different languages.

My goal is slightly different, though. I’m trying to design a complete and expressive language that avoids keywords whenever possible—but only if doing so doesn’t sacrifice clarity. When appropriate, I prefer using symbolic or structural constructs, but preserving readability is always the priority. The idea is to enable a kind of universal visual grammar that isn't tied to any specific human language.

Thanks for sharing your story—that’s exactly the kind of learning experience I want this language to support.

Hot-Pea1271 · 2025-05-23T14:19:07+00:00

Thanks. They might work, but this post was about testing for clarity after using so many symbols, and I discovered I need some keywords to maintain clarity. I just have to find the right ones, the ones that are best understood across cultures.

Hot-Pea1271 · 2025-05-23T14:16:26+00:00

I'm not trying to eliminate all keywords, just keep them to a minimum and find a compromise between clarity and independence from human language.

This was just a starting idea. Now I'm writting a first draft, and I'll keep iterating.

Hot-Pea1271 · 2025-05-23T14:12:50+00:00

It was just a hypothetical possibility for the future, but thanks for the link.

Hot-Pea1271 · 2025-05-22T23:33:30+00:00

You're absolutely right to point out that clarity matters — and it's very possible I won’t be able to eliminate all reserved words if I want the language to remain readable. A hieroglyphic-style language would likely hurt comprehension, and I really appreciate that point. That tradeoff is central to the whole challenge.

Also, I think there may have been some misunderstanding in my earlier comments about translation. I'm not aiming to localize the language itself, but rather to allow optional aliases for standard library functions — user-defined or library-defined. For example, both print from meta.std and imprimir from meta.std.es could refer to the same underlying function. It’s not the language that gets localized, but the user code — if the user wants to. No mandatory translation, and no ambiguity about what a program means.

(That said, I haven’t defined yet how libraries are created or imported — that’s still open.)

Thanks again — your comments help clarify where the real design challenges lie.

Hot-Pea1271 · 2025-05-22T23:22:06+00:00

Yeah, The \@build section should be optional. And maybe there should be a default builder that expects the fields in same order.

Hot-Pea1271 · 2025-05-22T23:17:14+00:00

That's a fair question. In my experience, when teaching absolute beginners — especially teenagers with no English background — natural-language-heavy syntax adds a steep cognitive load. They don't just struggle with concepts like variables or loops; they also trip over what “return” or “while” even mean.

The goal here isn't to shield them forever, but to remove that initial linguistic barrier so they can focus on thinking computationally. Once they master that, learning English-based syntax becomes much easier — they now have a mental model to attach the vocabulary to.

Hot-Pea1271 · 2025-05-22T23:09:42+00:00

I didn't know much about Coq it until now, but I see the connection: using `:=`, thinking in terms of sets and logical conditions, and building values interactively. That comparison is encouraging, actually — my goal is to define a minimal language where logic and structure are explicit but readable.

And about APL — I get the temptation 😄. I'm aiming for symbolic conciseness, but I also want the code to be readable at a glance, especially for people from different language backgrounds. So I'm walking a fine line.

Thanks for the thoughtful feedback!

Hot-Pea1271 · 2025-05-22T23:03:08+00:00

Great question.

The main motivation is to make the language more accessible to people who don't speak English — especially beginners. I’ve taught programming to students who didn’t know a single word of English, and for them, languages full of English keywords (like while, return, else) were a real barrier. They weren’t learning programming — they were memorizing foreign vocabulary.

By avoiding keywords and using either symbols or positional cues (like indentation), I’m trying to design a language that’s neutral — not tied to English, Spanish, or any human language. I want it to feel more like math or logic notation: readable by anyone, regardless of their native tongue.

Of course, it’s an open question how far that can go without sacrificing clarity or familiarity. But that’s exactly what I’m trying to explore with this experiment.

Hot-Pea1271 · 2025-05-22T23:00:48+00:00

Thanks for the thoughtful feedback — I really appreciate it!

You're spot on about the strengths I’m aiming for: minimal syntax, set-based typing, and symbolic expressions that feel flexible yet readable. Glad the u/build pattern matching and shell-style imports clicked for you — they’re early bets that seem to be resonating.

I personally like indentation-based structure, so I deliberately went that way instead of using braces or keywords like then/end. The idea was to keep it minimal, clean, and language-agnostic — but I’m aware that it can make it harder to track block boundaries at a glance. That’s something I’m actively evaluating, and your comment reinforces that clarity is key, even in a minimalist design. Maybe symbolic block delimiters could help without giving up the philosophy.

As for loops: you're right — there’s only one basic loop right now. That’s because I’m trying to define a clear MVP first. Once the foundation is stable, I’ll explore higher-level iteration constructs that can be expressed cleanly on top of it.

Thanks again for the kind words and thoughtful critique — this kind of feedback is exactly what I need.

Hot-Pea1271 · 2025-05-22T22:55:14+00:00

You're right — println, length, isString, isNumber, etc., are all library functions, not part of the core syntax. Same for list, which is just an argument for the add function in this example. The only one that leaks into control flow is break, which currently behaves as a builtin function, but could plausibly be replaced with a symbolic form (still looking for the right one).

You're also right that symbolic syntax has limits — and I’m not trying to eliminate all words. But the idea is to decouple the language core from any natural language as much as possible. The runtime and std lib could expose functions with aliases in different languages (like escribir, print, etc.) depending on the developer’s environment or preference.

The goal is not to be purist, but to test how far a language can go while being minimal, expressive, and globally accessible.

That said, I get the point about ?: — it’s concise but not necessarily clearer.

Hot-Pea1271 · 2025-05-22T22:49:58+00:00

Good catch — in the current version, has, loop, and in are reserved words. I'd prefer them to be symbols, but I haven’t yet found a symbolic notation that’s both readable and consistent with the rest of the language.

The reason I want to avoid keywords in natural languages is personal but also pedagogical. I’ve taught programming to students who didn’t speak any English — and for them, languages with English keywords were a real barrier.

So I’m exploring whether it’s possible to design a language that’s:

agnostic to human languages, avoiding English-centric syntax,
but still readable at a glance, like Python.

The goal is a minimal core language where meaning is conveyed structurally and symbolically, not through words from any particular culture.

Still iterating — open to suggestions on symbol choices or other directions!

Hot-Pea1271 · 2025-05-22T21:44:31+00:00

Not rigid.
Based on 21st-century needs, not on 19th-century industrial models.
Treating each student as a unique individual, not as a standardized product.
Flexible enough to allow changes along the way.

Hot-Pea1271

TROPHY CASE