https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

Looks like it has some features that D has too, for instance CTFE and default value initialization that can be disabled.

Not that it's a superior language, but I like its fresh/innovative approach.

On Saturday, 19 March 2016 at 01:22:19 UTC, Piotr Szturmaj wrote:
> https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md
>
> Looks like it has some features that D has too, for instance CTFE and default value initialization that can be disabled.
>
> Not that it's a superior language, but I like its fresh/innovative approach.

https://a.thumbs.redditmedia.com/eo8ea7bl1ZrGQBovtU4jAmHzETH8-4xxfbt6rA5xEU4.png

"Not planned
- [...]
- Constructors and Destructors
"

seriously ?! constructors and destructors are always needed for manual memory managment !


Otherwise there's something that's pretty in the syntax:

identifier : type = initializer; // straight declaration
identifier : type; // no init
identifier := initializer; // infered type



However later in the function declaration:

"sum := (x: float, y: float, z: float) -> float {
    return x + y + z;
};"

I would expect the same system as for variables:

"sum : float = (x: float, y: float, z: float) {
    return x + y + z;
};"

or return type inference:

"sum := (x: float, y: float, z: float) {
    return x + y + z;
};"

On Saturday, 19 March 2016 at 08:38:20 UTC, Basile B. wrote:
> On Saturday, 19 March 2016 at 01:22:19 UTC, Piotr Szturmaj wrote:
>> https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md
>>
>> Looks like it has some features that D has too, for instance CTFE and default value initialization that can be disabled.
>>
>> Not that it's a superior language, but I like its fresh/innovative approach.
>
> https://a.thumbs.redditmedia.com/eo8ea7bl1ZrGQBovtU4jAmHzETH8-4xxfbt6rA5xEU4.png
>
> "Not planned
> - [...]
> - Constructors and Destructors
> "
>
> seriously ?! constructors and destructors are always needed for manual memory managment !
>
>
> Otherwise there's something that's pretty in the syntax:
>
> identifier : type = initializer; // straight declaration
> identifier : type; // no init
> identifier := initializer; // infered type
>
>
>
> However later in the function declaration:
>
> "sum := (x: float, y: float, z: float) -> float {
>     return x + y + z;
> };"
>
> I would expect the same system as for variables:
>
> "sum : float = (x: float, y: float, z: float) {
>     return x + y + z;
> };"
>
> or return type inference:
>
> "sum := (x: float, y: float, z: float) {
>     return x + y + z;
> };"

I actually find syntax the weakest point of Jai. Things like `it`, `#run`, etc. are extremely ugly and bad design, IMO.
D's syntax is much cleanner, IMO:

enum str1 = "manifest constant";
auto str2 = " run-time variable";
alias sum = (x, y, z) => x + y + z;
immutable float[SRGB_TABLE_SIZE] srgb_table = generate_linear_srgb();

foreach (idx, ref value; arr)
    value += idx;

Otherwise there are many good ideas like more powerful CTFE, Data-oriented structures, Integrated build process, structs with pointer ownership and better control over inlining.

The "Other Cool Stuff", bounds checking, here strings sections looks like directly but poorly copied from D.

On Saturday, 19 March 2016 at 10:02:44 UTC, ZombineDev wrote:
> I actually find syntax the weakest point of Jai. Things like `it`, `#run`, etc. are extremely ugly and bad design, IMO.

My remark about the syntax is only related to what's lead to ":=" in the declaration of variables. Later I regret that the declaration of funtions don't follow the same logic ;).

Anyway, if i understand well it's gonna be a domain spacific language so the comparison with D is not reasonable.

On 19.03.2016 09:38, Basile B. wrote:
>
>
> identifier : type = initializer; // straight declaration
> identifier : type; // no init
> identifier := initializer; // infered type
>
>
>
> However later in the function declaration:
>
> "sum := (x: float, y: float, z: float) -> float {
>      return x + y + z;
> };"
>
> I would expect the same system as for variables:
>
> "sum : float = (x: float, y: float, z: float) {
>      return x + y + z;
> };"

That's not the same system. This would claim that everything after the "=" sign is of type float, which is clearly isn't, even if type inference was allowed.

One thing that is strange about the syntax is that they use identifier: type everywhere except for struct fields.

On Saturday, 19 March 2016 at 01:22:19 UTC, Piotr Szturmaj wrote:
> https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md
>
> Looks like it has some features that D has too, for instance CTFE and default value initialization that can be disabled.
>
> Not that it's a superior language, but I like its fresh/innovative approach.



The problem is that the philosophical underpinnings of the language are extremely peculiar:


"Language features like garbage collection and templated data streams and dynamic string classes may help the programmer write code faster, but they don't help the programmer write faster code."

"Blow argues that the increase in productivity and reduction of friction when memory-safe mechanisms are absent more than make up for the time lost in tracking down errors, especially when good programmers tend to produce relatively few errors"

Later:

"Abstractions like RAII, constructors and destructors, polymorphism, and exceptions were invented with the intention of solving problems that game programmers don’t have, and with the result of interfering with the solutions to problems that game programmers do have. Jai jettisons these abstractions so that programmers can think more about their actual problems - the data and their algorithms."

On Sunday, 20 March 2016 at 01:18:43 UTC, Guillaume Piolat wrote:
> "Language features like garbage collection and templated data streams and dynamic string classes may help the programmer write code faster, but they don't help the programmer write faster code."

I agree on gc and strings, but not having templates means you need high level builtins or type variables/binding of some sort. However, you can have templated modules and do well.

> "Blow argues that the increase in productivity and reduction of friction when memory-safe mechanisms are absent more than make up for the time lost in tracking down errors, especially when good programmers tend to produce relatively few errors"

I can agree with this if you have different levels of runtime checks in debug builds, debug tooling, static analysis tools and a language designed for it.

> "Abstractions like RAII, constructors and destructors, polymorphism, and exceptions were invented with the intention of solving problems that game programmers don’t have, and with the result of interfering with the solutions to problems that game programmers do have. Jai jettisons these abstractions so that programmers can think more about their actual problems - the data and their algorithms."

He is probably right on exceptions, but not on the others. In fact OO was invented to support simulation. However languages and compilers should do it differently on current hardware. I think what he means is that he cannot get good speed out of the c++ OO model.

On Saturday, 19 March 2016 at 08:38:20 UTC, Basile B. wrote:
>
> Otherwise there's something that's pretty in the syntax:

Very much so. My own "toy language" project uses (well, _will_ use once I have more than 5% of a parser) a similar syntax, so it could just be my own biases talking, but I like it.

>
> However later in the function declaration:
>
> "sum := (x: float, y: float, z: float) -> float {
>     return x + y + z;
> };"
>
> I would expect the same system as for variables:
>
> "sum : float = (x: float, y: float, z: float) {
>     return x + y + z;
> };"
>
> or return type inference:
>
> "sum := (x: float, y: float, z: float) {
>     return x + y + z;
> };"

As far as the second example goes, sum is a function returning float, not a float variable. I could be wrong, but it appears to me that using variable-like syntax would make the grammar (or at least its semantics) less context-free. Plus the () -> type {} syntax works nicely for lambdas. I'm sure the type-inference option could be supported, though.

The language has some very interesting ideas. I probably wouldn't use it for general-purpose programming, though. I like my OOP, at least when it fits the problem at hand.