vwwvvw
1. Read "Dragon Book" as an easy reading. Nothing from it is going to end up in your programming language, but it puts you on terms with other people.
2. Read on and practice "parsing expression grammars" (also "Computing Patterns in Strings", maybe?)
4. Start learning C++ and Haskell. You won't get enough low-level and high-level programming details anywhere else. Then get into "Design and Evolution" and "History of Haskell", then follow the links. Knowledge of these languages is not enough, you have to know why they were written this way. You should start seeing things around like "hey, η-conversion is broken in Javascript! I cannot pass `parseInt` to `map`, because they both removed requirements on number of arguments and used overloading! What a crap!"
5. Get into type theory. "Types and programming languages" (and "Advanced TaPL") is a nice entry point. From there you can start reading articles.
6. Learn lots of other programming languages, analyze concepts you see there, talk with other programming language theorists, especially when in doubt if something is bad or good. Join "Lambda the Ultimate" or at least read as much as possible on it.
7. Now and only now it's time to publish your first language whitepaper.
Yes, a lot of the reasons. Not only users might want to use those words for something else, and not only you make your parser bigger, but you also make a language description bigger. "Operators" are just functions written between their arguments. Just let users define functions that are written between arguments. Of prior art you might look at mixfix notation, or something as simple as Haskell's backquotes.
> I get what you're suggesting. Probably not today at this very moment.
Actually the point was not to implement `finally` at all. It's just a sloppy language design of Java that made it a thing.
> I was thinking they would use star values`
Take a look on C++ and its variadic templates, or heterogenous lists in Scala or Haskell. Variant is never ever an option (unless you're creating a Basic).
> Those things are hazardous to people's lives.
Do realize that bad programming languages are hazardous to people's lives too! Every stupid mistake you make in language design leads to millions of hours wasted by programmers, and even more if the language design bug persists in runtime of resulting programs. The lost time is computed in _lifetimes_. In a proper society this would be a criminal offence equivalent to murder, and yes, I'm serious on this.
> trying something is the best way of learning
Trying is a great thing, but publishing on github and announcing in one of the biggest newsfeeds for programmers is a different thing, don't you think?
First, nobody needs lists in 2018. Lists is a horrible data structure with most operations having bad asymptotic complexity. There are usages in algorithms (skip lists etc), but end-user code just never uses lists. Some pure functional programming languages have a set of compiler passes (that work only for pure functional languages) that allows to work with "lists" but in the end they get abolished from binary. That's not about your programming language.
The magical syntax I'm talking about is just that it has all these `[]` and `[...]` in type. Why can't you make it a generic, like, `array<int>` or `array[int]`?
> The latter is the splicing syntax—shorthand for running a for loop over elements 2 through 4 (exclusive).
Why do you have to use magic syntax, when you could have just made a function with 2 arguments? I mean, Haskell implements `enumFromTo` function and `[a..b]` sugar for it, but your `array[a..b]` is neither first-class (what do you do if you want to make a pointer to this function?) nor short.
> The plan is to make it that way because of how the visual representation of repeated exponents in math works. Your thoughts?
Either that, or just make it non-associative (a ^ b ^ c will be a syntax error then).
Self-humiliation never helped anyone to get more experience. I am not trying to look knowledgable. I'm scared of yet another determined person making a programming language.
> There should (ideally at least) be only one way of doing async functions. I know that I plan to have lambda functions in my language. You might say that I contradict my own example. I am yet to think of a way to counter having two ways of approaching async.
Sometimes you subtly change the way the programming language works by introducting several magical words to it. For example, you can add `throw` and `try...catch` to get very similar language, but now jumping from a point of error towards its handler doesn't require you to change all the functions that are between them. Likely there are `async` and `await` that let you pause and resume code execution threads. Such subtle changes are easily implemented through monads, but in current implementations burden of required knowledge is way too big.
> I did give this thought but implying the type doesn't make it obvious that the variable cannot store other types. What are your thoughts on this?
There is a nice property of programming languages: a language having principal types. This means that every expression in the language can have one and only one most general type. OOP languages don't have this property, so they lose type inference. If you have `class A extends B` and want to do `B x = new A`, you have to write both types anyway. I'd recommend avoiding OOP at all cost, and take a look at O'Caml, row polymorphism and MLsub type system.
> Am I misinterpreting what you're saying?
What's the type of `println`? Isn't it `println(string): void`? If so, how did it get `int` (or whatever type you assign to integer literals) argument without a type checking error?
You have to be able to design language to start doing it. We do not expect random people giving other people drug recipes to become doctors just from their experience of giving drugs.
> Maybe they learn something, maybe they fail but either way it doesn't hurt anything to try.
I'm horrified by onset of events when it does not fail, not when it does. History of programming languages knows a lot of exceptionally bad programming languages that got finished due to persistence of their authors, and got wide approval and usage.
> Errors should never pass silently unless explicitly silenced Yet you implement exceptions in a language, and don't annotate (or infer) exception annotations on functions.
> There should be one—and preferably only one—obvious way to do it Should you write `a + x` or `x + a`?
This smart-sounding babble was made by a person that has no education in programming language theory. Are you sure you want to put it as a basis for your language?
> /* block comments / Should it support nested comments?
> string example = "hello world"; I see that you're trying to pursue similarity to C++ or Java, but I don't see why. Which other type can "hello world" have in your language? It takes no effort to get computed type of RHS and set it as a type of variable. Also you should be aware that putting type in that position makes it hard to keep your grammar without ambiguity, especially in long-term.
> int x = 1; > float x = 3.21; > decimal y = 3.1416; It was 2018, and we still thought that we have constant, immutable word size on all platforms, and it won't change the next year. Come on, even C++ came up with int32 and int64 types.
> RegEx email = /[a-z0-9_-.]+@.+\.[a-z]+/ig; Please tell me that you've read on TCL's regexps, and how they managed to avoid exponential parsing times in most cases. Regexps inside of a programming language implementation ARE pain. You essentially enforce your implementation, so it has to be perfect, unicode support and performance-wise.
> out.println(i); Sure, more implicit type conversions!
> int[...] list = [1, 2, 3, ...]; Magical syntax for array is what everyone is waiting in 2018. Why keep it simple?
> int[] anotherArray = new int[15]; > int[] newArray = array[2..4]; In both cases we create some space on heap, and initialize it in some way. It's something like several constructors of the same data type. Why do they have different syntax?
> A kitten dies somewhere each time you use this type without a very good reason. Another Visual Basic programmer is born every time you add unbounded Variant type into your language. Don't forget support for COM!
> const int pi = 3.1416; Literally THE line of code that defines each and every programming language developer that didn't care to learn some PLT.
> x = 3 * 5; Fortran is dead! Use `3 ^ 5` or `3 pow 5`. It's in no way clear why double multiplication is exponentiation. BTW, is it right-associative?
> Eventually, I plan on supporting unicode characters like “≥” and deprecating their digraph alternatives like “>=”. Try writing a row or two of Agda without emacs, and you will drop that idea. The problem is that unicode characters are absent from your keyboard, and there is no standardized way to write them. So you're essentially putting programmers into a flaming pit.
> x = isOdd and isEven; > x = isOdd or isEven; Now this is actually something good.
> class HTTPError extends Error {} That's not how a good pascal case works. It should have been HttpError.
> finally { So every time I have an object that needs destruction - I have to write `finally` directive - I have not to forget to do so - It's somehow better than destructors Also Java didn't manage to properly implement `finally` on JVM, so if you have `finally` blocks inside of `finally` blocks, you get exponential growth of class-file size. Are you sure you will be able to handle it properly?
> int restParams (int ...values) {} What about parameters having different types? What is even the purpose of rest-params that have the same type? Avoid two extra square brackets in a function call?
> 1. Write language spec Consider this as "cease and desist" for writing programming languages until you get formal education in doing so. We don't need another Python 2, another Python 3, another Ruby or another Go. Economic impact of bad languages is way too big. Please, accept this harsh language, feel the offence and just stop.