Focus: A simple and fast text editor written in Jai
github.com
github.com
I also recognize that I am participating in said dynamic.
Regarding Jai: the idea about a "language for good programmers" is just about the worst thing ever to say about a language and it's community in my opinion (and I'm being paid as a C and C++ programmer for 20 years now, so I guess I'm at least not totally bad at it).
I mean sure, people are in general hesitant when someone calls himself good, and for a decent reason.
But pushing it to extreme and defaulting to reverse JUST BECAUSE someone dared to call himself good is also a pretty childish reaction. At the end of the day it is a fact that there are differences in skill between programmers and different languages expect from you different levels of understanding. Pretending it's only valid to acknowledge these differences in others but not in oneself is irrational.
> Pretending it's only valid to acknowledge these differences in others but not in oneself is irrational.
I do hope that we can agree that people are way better at assessing others than themselves - in both ways, under- and overestimation of their own capabilities.
TL;DR Inexperienced != Bad
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
What Pike meant is that a company (e.g. google) cannot hire only people who have deep understanding in subtleties of advanced programming language theory and had the time to go through a long learning curve to actually reap the benefits of these advanced programming languages.
These young engineers are not bad, quite the opposite they are usually bright and brilliant young engineers
The problem with that kind of people is that they will use their cleverness to build complicated and beautiful stuff, but when combined with a lack of true and deep experience due to them being still young, this can become counterproductive.
Pike's argument is not about new hires being careless or incapable of writing tests or understanding dangling pointers and all that stuff.
The whole thing about memory safety is an external requirement to the whole discussion that Pike was starting. At the time it was already well understood that most security vulnerabilities at Google were caused by bugs around memory accesses and that even the most experienced engineers weren't immune to those.
What Pike was talking about was: among the solution space of programming languages that can address those issues, some require a lot of training, whole others are simpler to pick up and yet "good enough".
Rust is an example of a language that is solving the problem in a way that doesn't give up performance, but it does require a steeper learning curve. Pike argued that Google would benefit from a language that would require such a learning curve.
The tradeoff will change with time. Now that rust exists an argument can be made that there is sufficient learning already spent
Well I think this interpretation is reductive to say the least, and as such i don't agree with it. So that's that
Oh, and the compile times are just a joy, almost no other language even comes close to the speed of iteration that's possible with Jai, which is another great reason to use it for games and prototyping in general.
How do nested for-loops work, if `it` names the current iterator?
for particles {
// Inside for loops the "it" object is the iterator for the current object.
particle_left := view_left \* it.particle_size;
}- It's the innermost iterator that takes priority
- You are encouraged to name your iterators if you do so (for particles { part -> part.velocity } )
- Compiler throws warnings if you shadowed names.
Oh, i didn't know that there are any.
It would be a good idea to add the naming explicitly to the Wiki entry of loops: https://jai.community/t/loops/147, I've just found it buried in the `remove` section.
Btw. in for-loops the colon `:` is used inconsistently again, this time for naming the iterator (`foo` in this example:) `for foo: VALUES { ... }`.
Plenty! Although, it's not limited to iterators: most languages that have first class lambdas/closures behave this way. Kotlin has `it` as the default parameter of any lambda (but only accepts it for single parameter lambdas, two parameters and you need to name them:
`fun <T, U> Collection<T>.map(block: (T) -> U): Collection<U>`
is called like so:
`listOf(1, 2, 3).map { it * it }`
Swift has $0, $1
>Btw. in for-loops the colon `:` is used inconsistently again, this time for naming the iterator (`foo` in this example:) `for foo: VALUES { ... }`.
Sorry, Jonathan Blow doesn't believe in such silly things as "compiler research" nor "programming language research". Jai gets built by piling up crap on top of crap.
Talking about closures, I also don't know why Jai needs explicit capture lists. In C++ and Rust I understand the need for them, because you have various ways to pass them into the lambda, but Jai doesn't seem to care, at least in the examples at https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md.... To be honest, I also don't see how this is different from just writing the function definition by hand, just in more than one step and you have to throw away the intermediate versions?
Btw. I just replied to say that I really like your username, I have noticed it just now :)
The source code to the program is available, but the compiler with which to compile that code isn't.
To the OP I would say this is opensource.
If you received an open source recipe, despite not having a kitchen you could still modify the recipe, pass it on etc.
You still have the right to modify this code and pass it on, which is what the opensource licenses generally guarantee, opensource software for the latest supercomputer doesn't guarantee you access to that supercomputer.
(I'm not a fan of Jai's closed development model though, but to each their own)
Apparently Jai is specifically tailored to game development problems and frustration with C++ for game dev (or at least it tries to fix rough edges that a typical game developer encounters in existing languages used for game dev) - whether that is actually true I can't tell though since I haven't used Jai yet.
Well, but how do you recognize that there are still not enough options? I assume it should be a bit more specific than just a feeling or "personal preference", isn't it?
> Rust and D as attempts to a "better C++"
Rust has at least one big unique selling point which was not present so far in any other language (at least I'm not aware of any one): compile time automatic memory management. The unique selling point of D in contrast is not that obvious, at least not to me.
> whether that is actually true I can't tell though since I haven't used Jai yet.
Well then maybe someone else knows.
One language that's still missing is a simple C-like language that offers Rust-style memory safety but without Rust's design philosophy of repeating every C++ mistake (that's not about memory safety) and high level type system wankery (or generally too much influence from functional languages).
There are also many more areas still to explore when it comes to memory safety that are less extreme than Rust's approach (I completely forgot about Vale which tries out some really interesting things in that direction: https://vale.dev/)
Ok, I see; but why then not just add this feature to C, or maybe Zig?
> many more areas still to explore when it comes to memory safety that are less extreme than Rust's approach
Such as memory arenas/pools (like Ada), or runtime automatic garbage collection?
It would most likely need to 'break' C in a way that it wouldn't be recognisable as C anymore or at least break compatibility with existing C code (e.g. removing pointers, or at least pointer arithmetics, and the way pointers and arrays interact).
There never has been. There has been a lack of really successfull C alternatives for some time (after everything that wasn't unixish or Windows died, except for MacOS and Objective-C) - and still is. Rust is still less used than Pascal has been 30 years ago.
Looking at the explanation you linked, I would say that the author uses the language in a very unidiomatic way (if idiomatic Jai would be a thing :D). It takes a very template focused mindset and uses the features of the language to bastardize and complicate things needlessly (IMHO, as a not game developer). I think my main take away from the language is that it focuses on the way memory is mapped (similarly to how C does it) and less on behaviour associated with that memory.
So for that example, instead of trying to overthink a container that uses a generic behaviour through templated types, it would implement different overloaded functions for each type as needed.
It makes little sense to announce a language with a lot of details over so many years without providing a decent specification. Either the author is interested in feedback, then a specification or language report is the established vehicle among language designers, or he is not interested in feedback, which raises the question why he publishes any details at all.
> It takes a very template focused mindset and uses the features of the language
But as it seems that's a focus point of the language; why otherwise the author would take the effort to even modify structure declarations with compile time expressions.
> that it focuses on the way memory is mapped (similarly to how C does it)
What do you mean by that? And is this really a unique selling point if it is similar to C?
> Blow is not trying to "sell it" to anyone.
For that, he is doing a lot of promotion for his new language with all the youtube sessions and blog posts about it.
If it's promotion for anything I think it's rather for his sokoban like game.
You can do things like having structs remove or add members by just putting the member behind an if branch. You can also fully inspect any type and iterate members through reflection. There is a macro system that lets you manipulate and insert "code" objects, the iterator system works this way. you create a for loop operator overload where the for loop code is sent to the function as a parameter.
It also lets you convert a string (calculated compile time) into code. Either by adding it into the macro system, or just inserting it somewhere.
Some of the experiments ive done were implementing a full marc-sweep GC by generating reflection code that would implement the GC sweep logic, having a database system where it directly converts structs into table rows and codegens all the code relating to queries, automatic inspection of game objects by having a templated "inspect<T>" type thing where it exposes the object into imgui or debug log output, fully automatic json serialization for everything, and an ECS engine where it directly codegens the optimal gather code and prepares the object model storage from whatever loops you use in the code.
All of those werent real projects, just experiments to play around with it, but they were done in just a few dozens/hundreds lines of code each. While in theory you could do those in Cpp, it would need serious levels of template abominations to write it. In jai you write your compile time templates as normal jai. And it all compiles quickly with optimal codegen (its not bloating your PDB like a million type definitions would do in cpp template metaprogramming).
The big downside of the language is that its still a closed private beta, so tooling leaves much to be desired. There is a syntax color system, but things like correct IDE autocomplete or a native debugger arent there. I use remedybg to debug things and vscode as text editor for it. Its also on relatively early stages even if its been a thing for years, so some of the features are still in flux between updates.
EDIT: can you point to source locations in the referenced projects which demonstrate such features?
Some walkthrough:
Line 8 declares a SparseSet type as a fairly typical template. its just a struct with arrays of type T inside. Next lines implement getters/setters for this data structure. Note how std::vector style dynamic array is just a part of the lang, with the [..] syntax to declare a dynamically sized array.
Line 46 Base_Registry things get interesting. This is a struct that holds a bunch of SparseSet of different types, and providers getters/setters for them by type. It uses code generation to do this. The initial #insert at the start of the class injects codegen that creates structure members from the type list the struct gets on its declaration. Note also how type-lists are a native structure in the lang, no need for variadics.
Line 99 i decide to do variadic style tail templates anyway for fun. I implement a function that takes a typelist and returns the tail, and the struct is created through recursion as one would do in cpp. Getters and setters for the View struct are also implemented through recursion
Line 143 has the for expansion. This is how you overload the for loop functionality to create custom iterators.
The rest of the code is just some basic test code that runs the thing.
Last line does #import basic to essentially do #import stl type thing. Jai doesnt care about the order of any declarations, so having the includes at the bottom is fairly common.
The one issue with Nim I had while trying it out is that there is an incredibly rich amount of features but many of them seem half-baked and it’s constantly being changed, so you’re always a bit unsure what’s a feature stable and safe to use or is “experimental”. But at least it’s been public for quite some time and you can actually use it right away…
What this really reads to me is why not just use Rust. Rust is useful for the things Rust was designed for. Some people love it and think its the greatest language out there and that's fine but a lot of people have used it and they either do not like it or they like it but they wouldn't want to use it for the type of work they like to do.
Having more languages and each influencing another is the only way we can get better and better languages.
jai -quiet first.jai
So... where can I find the Jai compiler?
Yes, there is a whole Jai community wiki made from half cobbled together knowledge (https://github.com/Jai-Community/Jai-Community-Library/wiki), and a super secret discord made for the super elite, non-compiler-having plebs are banned.
Anyone have any GUI (non-CLI) recommendations for editing larger files, specifically text files 10 MB+?
If these GUI editors can't offer better than VIM + tmux, then something is wrong