www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Jai - interesting programming language

reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
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.
Mar 18 2016
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
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;
};"
Mar 19 2016
next sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
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.
Mar 19 2016
parent Basile B. <b2.temp gmx.com> writes:
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.
Mar 19 2016
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 19 2016
prev sibling parent BLM768 <blm768 gmail.com> writes:
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.
Mar 19 2016
prev sibling parent reply Guillaume Piolat <name.lastname gmail.com> writes:
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."
Mar 19 2016
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
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.
Mar 19 2016