
Show HN: Nirvana, a WIP programming language - shreyasminocha
https://github.com/shreyasminocha/nirvana
======
AnaniasAnanas
No offence but literally everyone can design a language without bothering to
implement it - in fact I am pretty sure that most programmers have done
something like that at some point of their journey. I would suggest to post
about it again once you have completed its implementation as well as share
your experiences on it. If you have not implemented a language before I would
suggest that you start with something simpler, such as a stack-based language
or a lisp instead and ignore more complex features like exceptions or classes.

As for the language itself, is there any reason why would you want booleans to
be primitives? I would suggest to investigate something like haskell's ADTs
and move them to the standard library.

~~~
shreyasminocha
Alright, I'm sorry, Will look into your suggestions.

------
gitgud
Looks very similar to typescript, also...

 _Eventually, I plan on supporting unicode characters like “≥” and deprecating
their digraph alternatives like “ >=”._

I get allowing unicode characters, but you do know that will make it much
harder to write and maintain programs, as it's not a key on a regular
keyboard...

~~~
shreyasminocha
Yes, I realise my mistake.

~~~
gitgud
Have you tried Typescript? It's extremely popular now and seems to have all
the features you're presenting, it would also be a good place to start if you
really wanted your own language.

------
brett40324
Ok, it's a show HN. But there is literally only a license and readme. I don't
get why you would even post this. What language is the interpreter or VM?
being implemented in?

~~~
shreyasminocha
Sorry, I wasn't familiar with HN's culture. I was just looking for feedback on
this stage of my journey but didn't realise that my current work wasn't show-
worthy. My mistake.

~~~
brett40324
Don't be sorry. I didn't mean to be discouraging, if that's the case. You did
say a WIP, but often people like to see and evaluate that, especially for
implementations of languages. A slightly more informative title would get you
more feedback - along the lines of WIP spec, or Nirvana - new language project
idea. Good luck on Nirvana, post again soon!

------
vwwvvw
> Flat is better than nested That's fine for namespaces, but given the choice
> of aggregation (which implies more nesting) or inheritance (which implies
> lack of rigor), I'd choose more nesting.

> 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.

~~~
shreyasminocha
Let me start off by conceding that you're more knowledgable and experienced
than me (which you inferred from my post and attempt at designing a language
anyway) and I am in no way trying to challenge that.

I'll look up all the jargon that went above my head. I'll learn
something—thanks for that.

Now let me reply to everything that I understood and have answers to.

> `a + x` or `x + a`

commutativity is a thing in mathematics too. No one will be stumped by seeing
this written in two different ways. It doesn't introduce any confusion. In
javascript, there is more than just one way to do async—callback, promises,
the new syntax sugar async-await. This is, or at least was for me, a cause of
confusion. 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.

> /* block comments / Should it support nested comments?

Good point, I'll think about it. What do you recommend?

> 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?

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?

> Sure, more implicit type conversions!

User-defined datatypes will be able to define their print behaviour. Also, I
don't wish to interpret printing as a type conversion. Even abstract concepts,
say a car, have a possible textual description, maybe their registration
number. Am I misinterpreting what you're saying?

> Please tell me that you've read on TCL's regexps

Doing. (So sorry I haven't already).

> 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.

Point. Will do some research of my own and consider.

> Magical syntax for array is what everyone is waiting in 2018. Why keep it
> simple?

Not array, but list. I gave how to represent list literal some consideration.
I came up with this for the time-being. The right side seems natural and
intuitive enough to me. What do you suggest instead? Parentheses and angle
brackets are options...

> > 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?

The latter is the splicing syntax—shorthand for running a for loop over
elements 2 through 4 (exclusive). Yes, it too does does create some space on
the heap and initialize it, but I mentioned in my readme that the language's
syntax will be dealing in abstractions, not low-level details. It seems a
natural enough thing to do, right? I mean I could do the latter in two steps.
First initialize, then splice and store. But then we use string an integer
literals all the time. I think the two are similar.

> It's in no way clear why double multiplication is exponentiation.

I made that decision when I was planning to include bitwise operations. I'm
not sure if I'm going to keep them (probably not, in which case I'll switch to
the caret). If I do, I might stick to the conventions that programmers of
other languages are familiar with (for lack of better alternatives).

> Is it right-associative?

The plan is to make it that way because of how the visual representation of
repeated exponents in math works. Your thoughts?

> 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.

I agree. Not going to deprecate >= etc any more.

> Now this is actually something good.

Based on feedback from someone else, I was second-guessing this. Is there any
reason I should avoid having too many keywords? I can see why they would
suggest that, but what are your thoughts on the too-many-keywords issue?

> That's not how a good pascal case works.

My mistake.

> Are you sure you will be able to handle it properly?

I get what you're suggesting. Probably not today at this very moment. I can
learn though (oh wait, but I shouldn't do something if I don't know how to.
I'll address that in a bit).

> What about parameters having different types?

I was thinking they would use `* ...values`. But then you mention that ` _` is
a bad idea altogether.

> We do not expect random people giving other people drug recipes to become
> doctors just from their experience of giving drugs.

Those things are hazardous to people's lives. There are regulations in place
to prevent that. I guess you want regulations in place to prevent anyone from
creating their own programming languages. Unfortunately for you, that isn't
going to happen any time soon. In my (admittedly limited) experience, trying
something is the best way of learning. I used to have a habit of going through
tutorials, trying to learn things. I realised soon that in the long-term, I
wasn't learning anything altogether. It was only when I started making things,
experimenting, and, of course, making mistakes, did I actually _learn _. Also,
I learnt lots_ along* the way. This is not the final spec (like I emphasized
over and over again). In the process of designing a language, I _will_ learn.
To be perfectly honest, my biggest objective in doing this altogether is to
learn how to write compilers, parsers etc and how to work on large-scale
projects. I agree that I am being too ambitious by thinking that others might
find my language useful; yet, it gives me encouragement vs working on just a
"toy language". I don't have much to say in terms of "Economic impact of bad
languages is way too big. Please, accept this harsh language, feel the offence
and just stop." I really don't have much to say. Maybe I'll add a screenshot
of this comment in my readme to warn the public. I'm not going to stop. I can
only hope and work towards not creating a "bad language". And so can you.

Like I said earlier, stuff I didn't reply to is something I either didn't
understand or have no answer to. I assume that since your objective is to
discourage me from doing any of this, you would rather not explain the stuff I
didn't understand. I'll look it up.

Finally, I would have really appreciated it if you would have given me
links/references to resources that would help me learn how to write
programming languages. Consider this my request for you to do so (although
considering the amount of—admitted—aggression you showed towards me, I'm
unsure about whether you would do me this favour).

~~~
vwwvvw
> Is there any reason I should avoid having too many keywords?

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?

~~~
chedine
Sir, now, may I ask you step down from that Ivory tower and stop making grand
claims about Haskell the safest and java, Javascript the hazardous.

