Main objectives

[igorbonadio]

We should start defining some main objectives.

I think it is important to have an aim before choosing if Positron will be a static/dynamic programming language, or if it will be oo, functional, or whatever else.

My suggestion is that Position should be a system programming language. Like other system programming language, it should compile to native and performatic code.

So, I would say that Positron's main objectives are:

• Performance
• Without (or with a thin) runtime

Plus, I would add:

• Be friendly, because in general, languages like C, C++, Rust, etc are not friendly
• Should have a great ecosystem (package managers, auto-build tools, repository of libraries, etc)

What do you think?

[renatocf]

Increasing a little bit this discussion, I believe that we should define not only objectives, but also talk about the basic principles of the language. We can have something like The Arch Way - not necessarily with the same guidelines - that would work as the foundations of the language. Every time we take a decision, it should comply with this principles, and they will guide the language to accomplish its objectives.

I believe in the phrase "great tools are simple", and I think that this is essential to the success of any programming language. I see simplicity as one of C's greatest powers - and one of the reasons why it's still so used (even in programming introductory courses). But languages also have to evolve, in order to suit to the needs of its user. And this needs can (and almost always will) change over time. C++ was born to adapt C to an increasingly popular paradigm (OOP). Java used features similar to C++, but filling the gap of a language for a connected world (multi-platform and web-based). Today, we see Java and C++ trying to adapt again (for functional programming, mainly). But they cannot ignore the huge amount of legacy they created over time. Joining new features made C++ and Java difficult-to-dominate and far-from-simple languages.

My argument is that simplicity and evolution are very important, and I believe both should be principles of the Positron programming language. At first glance, they may seem opposite. But I believe that dynamic and functional languages showed a way: the core language has to be simple, but easy to extend through libraries. And if Positron become a fun language for library implementers (allowing metaprogramming with an easy way to share features with the community), it will be simple for new users and suitable for advanced specific needs. The community itself will dictate how far the language will go.

Based on this, I would say that Positron's principles should be:

• Simplicity (KISS and DRY)
• Extensibility (Open/Closed Principle)
• Programmer-friendliness

Keeping as objectives:

• Performance
• No/Thin runtime
• Great Ecosystem

[igorbonadio]

Yes! Good point Renato! I like the "less is more" principle. And extensibility seems to be essential too.

So, the main objective should be:

• Simplicity (KISS and DRY)
• Extensibility (Open/Closed Principle)
• Programmer-friendliness
• Performance
• No/Thin runtime
• Great Ecosystem

There is another thing that I was thinking which is compatibility with other existing tools. Should Positron be able to call C functions as easy as Positron functions? And More: Should Positron be able to export a function as a C function?

[renatocf]

I think it would be nice. With this feature, we could get a bunch of functionalities from the C libraries. And I'm not totally sure about the implications of this, but I'd love if we get compatibility with C++ features too. I believe that being able to integrate Positron's libraries with C, C++ and Fortran (Fortran from induction of C/C++) would bring people interested in a language with nice and flexible features, but that could be used with their legacy systems.

My opinion have some implications: which language should we use to implement our future compiler (C or C++)? Which paradigms will our language support? (Procedural? OO? Functional?) There is a lot to discuss, and depending on this features we would be able to decide what type of compatibility we could get.

But just one note: I wouldn't like Positron to be constrained by C/C++ compatibilities. As I defended in the last comment, I believe Positron must seek evolution - and some designs of C and C++ may be (today) recognizable bad. So, I prefer sacrifice full compatibility in order to create a better language. Do you agree?

[igorbonadio]

Yes, I agree. I believe that positron should be independent of C/C++. But I think we can add an "export" feature that produces a "c-style" library.

Rust has something like that: http://doc.rust-lang.org/1.0.0-beta/book/ffi.html

But maybe it is too early to think about something like that...

[igorbonadio]

And yes. We have to talk about other thing too, like paradigms, etc. (I have a huge list of things that I want to discuss hahahahahahah)

[igorbonadio]

So, at this moment Positron's objectives are:

• Simplicity (KISS and DRY)
• Extensibility (Open/Closed Principle)
• Programmer-friendliness
• Performance
• No/Thin runtime
• Great Ecosystem

(it may change in the future)

[igorbonadio]

@renatocf, feel free to change the text.

[ademar111190]

Increasing a little bit more this discussion, I'm thinking in a domain specific language for genetic manipulation.

I agree, this language should be simple and Programmer-friendliness maybe something "artistic and beautiful".

I think that the performance should be a target, but not a first rule.

About C integration, I would like to see something more generic, that allows the positron call and receive messages from/to any other language, maybe through an "ambassador" library specification, but not as a first target.

[vinivendra]

Hi all, mind if I jump in?

I think you guys have some great ideas put together already. Allow me to comment on a few of them.

On the matter of principles, I believe The Arch Way really is a great example. The idea of having just a few principles and basically letting them make the decisions about the language can make the whole thing very consistent and clear. On that note, I would propose a list of principles (based partly on the list of objectives, partly on what's been discussed here), with the intent that it should be complete (have the answer to any problem) but never conflicting or redundant (principles should not interfere with one another). Also, it is meant to be ordered: only try the second principle if the first one doesn't fit.

• Clarity: Every feature should be obvious in what it does, as well as how it's used, with little to no need for external references. (This is meant to avoid turning Positron into another Rust).
• Standards: Prefer offering the programmer one good way of doing something over allowing him to do it in several different ways. (I feel this, along with clarity, gets us to programmer-friendliness; it allows code written by others to be easily read, allows the compiler to catch obvious code errors, and keeps the language simple).
• Performance: Prefer making it easy for the programmer to do something over doing it for him at the cost of language performance. (This seems to be enough to make sure positron doesn't end up as slow as most script languages, which seems to be something we'd like to avoid).
• Simplicity: Well defined by Arch as "without unnecessary additions, modifications, or complications". (A failsafe: When in doubt, KISS).

I think these principles cover most of what you guys suggested and are a good starting point to get to the objectives mentioned above, though they may be too specific; feel free to scramble and mess with them as desired ;)

On the matter of evolution, I think we might consider avoiding the legacy problems of C++ (and the likes) with a system of different, incompatible versions. That is to say that if ever we feel the language is starting to become old, we should not be afraid to release a new version, even if it means old code will become incompatible with it. (I believe Python does this, though I may me mistaken).

Finally, on the matter of C/C++ exports, I think we might consider altering the language slightly as a means to achieve it. Though this might look undesirable at first, I believe that ignoring the fact that there are countless excellent libraries written in C/C++ (many of which are imperative to several programs and programmers) would be naïve, and it might also help boost early adoption of the language. Imagine, for instance, that this would mean being able to write performance code with OpenGL right out-of-the-box, as well as automatically interfacing with several script languages that have engines written in C such as Lua and JavaScript.

[igorbonadio]

Hi guys! @vinivendra @ademar111190 you are welcome!

@ademar111190 I think performance is important because there aren't a friendly system programming language... C is so simple that the use of collections (like lists, vectors, maps) is very difficult... C++ is so big that you need many years to learn it... Rust is... I don't know... I like its concepts... but programming in Rust is a pain in the ass...

And there are a lot of beautiful dynamic-scripting language (ruby is my favorite! :heart: ) and I don't think we need another one.

Now about integration with other languages, I think if we can "talk" to C, we can comunicate with almost all languages.

@vinivendra I liked your list of principles. And I vote to set them as Positron's official principles. What do you guys think?

[renatocf]

I agree. I believe that @vinivendra has summarized the same principles in a better (and simpler) way. I'd even include his detailed explanations (without the comments in parentheses).

Just for symmetry, I prefer to change Standards by Standardization, finishing with something like:

• Clarity Every feature might be obvious in what it does, as well as how it's used, with little or no need for external references
• Standardization It's better to have one good way of doing something over several different ways of doing the same
• Performance Prefer making it easy for the programmer to do something over doing it for him at the cost of language performance
• Simplicity Without unnecessary additions, modifications, or complications

When in doubt, KISS and DRY.

[vinivendra]

I'm glad you guys liked it, and I agree that standardization is better. Also, @igorbonadio has a point: if we can talk to C, then through it we can talk to anyone.

If the principles part is done, would anyone care to suggest a next step (or just another discussion topic)?

[renatocf]

Hi guys,

Today, discussing with @igorbonadio, I figured out we could reference to Asimov's Laws of Robotic and make our principles the Positron's Laws of Design. As the name Positron came from "A programming language for Positronic Brains", I believe this is a fair tribute to one of the greatest sci-fi authors.

Here they go. Check and say what you think:

---

Positron's Laws of Design

---

1. (Law of Clarity) A Positron feature must be obvious in what it does, as well how it's used, with little or no need for external references.
2. (Law of Standardization) A Positron feature must favor a good way of doing something over several ways of making the same, except where it would conflict with the First Law.
3. (Law of Performance) A Positron feature may not harm performance for doing something to the programmer that he can choose to do by himself, except where it would conflict with the First and Second Laws.

After some time, our programmers came with a 0th Law, valid above others:

0. (Law of Simplicity)
   A Positron feature must help to make the language better and greater, without unnecessary additions, modifications or complications. When in doubt, KISS and DRY.

[vinivendra]

I think the reference is perfect (Daneel would be proud), but should the law of simplicity really supersede others or is it the 0th law just for reference's sake?

[renatocf]

I believe that "Law of Simplicity" is not a good name. I think Clarity is far more important than Simplicity. Thinking about this laws after some time, I believe that "Law of Common Sense" (or a single better word) would express what I meant. I just wanted a law to be above other to say "decide for the best of the language, even that this is not the clearest, most standardized or performatic feature"

[renatocf]

I think we could rewrite it as the "Law of Good Sense":

0. (Law of Good Sense)
   A Positron feature must help to make the language better and greater. When in doubt, keep it simple and don't repeat yourself.

I believe it passes the message I intended (always make the best decision for the language) and yet stimulates the philosophy of simplicity (through KISS and DRY).

[ademar111190]

I think the programmer need to have room for creativity, if he needs to worry about things like performance the final result is lost of time, Therefore the Law of Performance introduces difficulty to programmers, in my point of view Programming languages should be tools and tools should do our work. We have a lot of performatic languages too C is the big example, the point is not if we need another one, the point is what is the value that Positron wants to offer as a programming language?

What is more precious, the machine time or the human time?

Good Sense is so subjective, but I like the idea.

[igorbonadio]

Just putting them all together:

---

Positron's Laws of Design

---

1. (Law of Clarity) A Positron feature must be obvious in what it does, as well how it's used, with little or no need for external references.
2. (Law of Standardization) A Positron feature must favor a good way of doing something over several ways of making the same, except where it would conflict with the First Law.
3. (Law of Performance) A Positron feature may not harm performance for doing something to the programmer that he can choose to do by himself, except where it would conflict with the First and Second Laws.

After some time, our programmers came with a 0th Law, valid above others:

0. (Law of Good Sense)
   A Positron feature must help to make the language better and greater. When in doubt, keep it simple and don't repeat yourself.

I think it is good. I liked @renatocf 's proposal.

[igorbonadio]

@ademar111190 that's why the Law of Performance is the third one. If it was the first, Positron would be an "Assembly".

The point is that Positron should be a system programming language. So it could be used to program operational systems, for example. So we need to care about performance.

[vinivendra]

@ademar111190, I believe this is why the principles should be applied in order. I've been talking to @renatocf, and we concluded that though good sense must be taken into account, it should not supersede the other principles, since it's subjective. The idea behind having principles is, to a certain degree, to let them make the decisions for us and avoid discussions over what is better or worse for the language. To that end, we proposed a reorganization of the principles (written as Isaac Asimov's laws):

---

Positron's Laws of Design

---

0. (Law of Clarity)
   A Positron feature must be obvious in what it does, as well how it's used, with little or no need for external references. When in doubt, keep it simple and don't repeat yourself.

1. (Law of Simplicity) A Positron feature must help to make the language better and greater, without unnecessary additions, modifications or complications, except where it would conflict with the Zeroth Law.
2. (Law of Standardization) A Positron feature must favor one good way of doing something over several equivalent ways of doing the same thing, except where it would conflict with the Zeroth, First or Second Laws.
3. (Law of Performance) A Positron feature may not harm performance with the purpose of doing something for the programmer that he is able to do by himself, except where it would conflict with the Zeroth, First, Second or Third Laws.

We believe that Performance, though a great concern, should not be so important when designing the language. At design time, we don't usually know how a feature will impact performance, and prioritizing this principle might make the language much like assembly. Basically, premature optimization is the root of all evil.

[renatocf]

I believe this one could be the final version of our Laws of Design. I want to submit them to the official spec. However, I purpose a slightly change in the way the text is written, to make it more compliant with Asimov's Laws of Robotic:

---

Positron's Laws of Design

---

1. (Law of Simplicity) A Positron feature must help to make the language better and greater, without unnecessary additions, modifications or complications.
2. (Law of Standardization) A Positron feature must favor one good way of doing something over several equivalent ways of doing the same thing, except where it would conflict with the First Law.
3. (Law of Performance) A Positron feature may not harm performance with the purpose of doing something for the programmer that he is able to do by himself, except where it would conflict with the First and Second Laws.

Later, when our programmers had taken responsibility for software that affects whole planets and human civilizations, they added a fourth law, the Zeroth Law, to precede the others:

0. (Law of Clarity)
   A Positron feature must be obvious in what it does, as well how it's used, with little or no need for external references. When in doubt, keep it simple and don't repeat yourself.

What do you think? Does this text complies with the 0th Law? (Is it clear?)

[igorbonadio]

Yes. It is clear. And I think we can close this issue.

[vinivendra]

Agreed! Let's close the issue.