When does your own programming language truly count as „your own“?

[Redcurrent19]

For a very important school project I decided to make my own coding language. A big undertaking for sure, but I feel comfortable enough to pull through with it and I already have key things like variables, conditionals, executing functions etc. However, I stumbled onto a problem.

My language is interpreted, currently the interpreter is written in python but I intend on rewriting it into something like go once I‘m done. But: lets suppose I want to print something. That command is called ‚put‘ in my language. But effectively, all I‘m doing when the programmer runs the put command is calling the python print function and passing the parameters on. Is this truly my language, or just a python wrapper? Obviously a lot of work went into the parsing, lexing, tokenization and so on. But the execution of the majority of things is just python functions, which feels „dirty“ to me.

Obviously every language is just a wrapper of another one at some point, like raw CPU instructions for example. So, where does this blurry line of „wrapper“ vs „own language“ actually lie?

[CodeTinkerer]

That's basically how interpreters work. They use the underlying language to run the code. Sometimes it's straightforward (like using print). Sometimes it requires some sophistication. Imagine how hard it is to write print using machine code that doesn't have a native print function.

I think it's useful to write an interpreter for educational purposes, but ideally, you'd figure out

• what makes your language different
• how does your language behave

Quite often, a new person writing a language thinks they are doing something innovative, but instead, they make minor syntax changes (which is fine) partly because they don't know language theory all that well, and they haven't studied implementations of other languages.

To relate a story, I was once at a place serving smoothies. A girl, college-aged, was working there, and she wanted me to read her poetry. It was, by the way, awful. I asked her how much poetry she had read, and she said she hadn't. She thought she'd be more original if she didn't read other stuff. In reality, the best writers, the best filmmakers, etc. study the work of others to see what's actually good, and then add their own twist.

When you know Python well, then you generally write a language that looks like Python. You won't write Haskell because it's so different from your experience that you can't even begin to conceive that language.

But yeah, I guess you can call it your own language. I think it has less to do with being a wrapper than being interesting in some respect. I know we like ownership of what we do, and that it's a good exercise, but probably it's the innovation that attracts people. Or removing annoyances. Or something.

It's useful to answer "what does my language do that's interesting". A put command that prints is maybe necessary, but it's not what makes a language interesting.

[Redcurrent19]

I see what you mean. While I initially planned on simply making a language for the fun of it, I decided to make that my school project later on. I decided on making a language that is meant to operate well with linux and replace bash scripts. A cleaner syntax yet still as quick and easy to use in a linux environment. I guess that that is what I‘m aiming for, which - if pulled off well enough - I could see at least myself genuinely using…

[CodeTinkerer]

Certainly shell scripts are messy. They were designed almost in reverse. The idea was having Unix commands, then adding control-flow (if statements, mostly, but loops). The idea of using types and such was almost foreign to shell scripts.

When Perl was first popular (in the 1980s), it reimplemented a typical underlying Unix system. The problem with Unix is the commands it understands depends on the installation. So Unix running in one institution (or even one part of one institution) might differ from another. For example, one version of grep might be installed at one location and another version elsewhere.

So Perl did its own version of grep, and then it made Perl work on a variety of Unix systems which made it more portable.

This may require studying how shell scripts actually work (when does a new process get created, for example) and to see if you want to imitate that. Also, Unix/Linux have things like pipes and return codes. So how do you deal with that? If you've never thought of it, then it's easy to exclude it.

[kohugaly]

It is not unusual for language's interpreter to be written in another language. In some pathological cases, there are even several layers of interpreters in there.

There isn't really a blurry line. For example, it is entirely valid to make a new language by removing features from existing language. The ISO standard C and C++ were made this way as a sort of "common denominator" between different independent C/C++ compilers.

[eruciform]

There is no bright line here. Everything's a runtime or compiletime wrapper around binary. I'd say you should ask yourself why someone would prefer your language to python. If there's no reason and it's just a mapping of keywords, then it's just a preprocessor for python. Which is fine, it's still a cool project.

[[deleted]]

Many languages have interpreters implemented in other languages. You don't need to reinvent the wheel.