nbuilding/N-lang

N does not have any direction

Ashvin-Ranjan opened this issue · 1 comments

Currently, a major problem with N is that it does not have a use case. It is able to do backends but there are other languages, such as rust or typescript, which are able to do the job better than N can at the moment. So to get N on the road to being a used language, I think it is time to step back and evaluate a use case for N.

Before we take a look at refactoring the whole picture, I think I will also include some quality of life improvements for N.

OOP

Object Oriented Programming would work well with N, as it already has classes and a type system, and an any type would help it compete with typescript, which also has an any type. an example of how it could work is:

class Child extends Parent (arg1: str, arg2: str) {
  // some code here...
}

Inferring return types

This is something typescript does as well, as it can infer the return type of most functions, which allows the users to program faster as they do not have to take the type typing out the return type and changing it when the function needs to be changed, how this could work is:

let func = (a: int, b: int) -> {
  return a + b
}

Here the int return type is inferred as there is only one possible type this could return, however, if the type checker is unsure, it can always throw an error.

Change how strings are treated

Currently the str class is treated as its own class, however, it may be best to make str an alias for list[char] as in most languages, strings are just lists of characters. This would also fix a number of issues, such as str types not being able to be put as the list in a for loop.

Define more granular types

Currently we have the very broad int type, which itself can change by accident through different implementations of N if we are not careful with it. However, it may be best to define int as an integer taking up 32 bits of space, changing its name to maybe i32, and in turn adding the i16, i8, and i64 classes, along with their unsigned counterparts.

let byte: i8 = 172
let unsignedByte: u8 = 255

Creating a use case

Now that we have looked over some quality of life changes, let us now work on a use case for N. Here are a few ideas of things that may give N a purpose:

  • Increase Speed
  • Compile to JS
  • Compile to WASM
  • Compatibility with JS libraries
  • nx (similar to jsx or tsx)

For all of these it seems clear that the js branch will be the new main branch of development, as the python branch seems unable to meet any of these new goals, though, if people wish to work on the python branch, then please go ahead.

Please reply with any ideas for a use case that you can give, as well as feedback on anything said, this will help me greatly as then a true idea for what N should be can be narrowed down and created.

I see N primarily as an academic language, a project showing how to build a language from the ground up, from the language-lawyer-like syntax debates to the pains of implementation and debugging. It's incredibly difficult to make headway in a world of more and more languages and frameworks—especially in the web domain—but despite knowing very little, I can tell that N (especially its type and concurrency systems) is very innovative and is, overall, an incredible achievement. Unfortunately, that novelty also means that there must be a big reason for people to adopt the language.

If you're totally set on getting N to adoption, I'd say focusing on concurrency in the web. Web Workers, SharedArrayBuffers and the like are quite finnicky to get right; since I don't really use WASM, I tend to eschew the latter and prefer passing around array buffers through messages. It would be amazing to have a truly efficient and concurrent web language; emscripten and rust's bindings are a bit lacking in precise control.