Ballerina: A Data-Oriented Programming Language
1–10 of 22 posts
Re: Ballerina: A Data-Oriented Programming Language
#2Ballerina is quite interesting and its flexible structural typing seems to make it a great fit for solutions that weave together multiple services.
One thing that the article does not highlight is the interop story [1]. It is currently hosted on JVM, but that is supposedly intended to be an implementation detail. So unlike Kotlin explicit ffi bindings are needed. This may create some friction for early adopters, but I guess is necessary if the type system is substantially different from the java type system. This will hopefully also make ballerina applications more portable if alternative implementations emerge in future.
Re: Ballerina: A Data-Oriented Programming Language
#3Ballerina is quite interesting and its flexible structural typing seems to make it a great fit for solutions that weave together multiple services. One thing that the article does not highlight is the interop story [1]. It is currently hosted on JVM, but that is supposedly intended to be an implementation detail. So unlike Kotlin explicit ffi bindings are needed. This may create some friction for early adopters, but…
Ballerina team told me that in the future Ballerina will not be hosted on JVM.
Re: Ballerina: A Data-Oriented Programming Language
#4This is a great idea (with implementing them myself resulting in limited success). I do wonder if such languages are better served as either embedded libraries in a target language (like lua runtime) or as a front-end for cross compiling to a target language? Ie better served as DSLs?
Re: Ballerina: A Data-Oriented Programming Language
#5It is called data-oriented, but most part is about typing, a clever mixture of static and dynamic. Note that also a language like C# has a mixture of dynamic and static types. At least you can define all sort of values without having to specify an explicit type. I do not know how far C# goes into defining methods and functions over those types.
What are the semantics of assignment? Is is creating a reference or does it 'clone' the value. In some languages, it is always a reference, except if you explicitly create a clone. In some languages with immutable data structures, it is always a copy (or at least, it behaves like that).
I am asking this, because I have found this a common source of errors, which are often hard to debug, because at someplace in the program a reference is created where a copy was intended and that in some other part of the program, a change is being made with unexpected side effects.
In some relational database it is possible to define existence constraints and define cascading deletes. For example, if I remove an author from a database, it also causes to remove all books written by that author. Or you could define the constraint that an author cannot be removed, if there is still a book written by that author in the database. I feel that a 'data oriented' language should also focus on these aspects of data.
I started to develop a (still dynamically typed) data oriented language myself. It is still very premature without any implementation, but a description can be found at https://github.com/FransFaase/DataLang
Re: Ballerina: A Data-Oriented Programming Language
#6It is called data-oriented, but most part is about typing, a clever mixture of static and dynamic. Note that also a language like C# has a mixture of dynamic and static types. At least you can define all sort of values without having to specify an explicit type. I do not know how far C# goes into defining methods and functions over those types. What are the semantics of assignment? Is is creating a reference or does…
It does it, via the dynamic runtime that was created to ease COM interoperability and at the time, IronRuby/IronPython implementations.
dynamic keyword, DLR runtime infrastructure like DynamicObject and IDynamicMetaObjectProvider which trigger special behavior on the compiler.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
Re: Ballerina: A Data-Oriented Programming Language
#7Ballerina is quite interesting and its flexible structural typing seems to make it a great fit for solutions that weave together multiple services. One thing that the article does not highlight is the interop story [1]. It is currently hosted on JVM, but that is supposedly intended to be an implementation detail. So unlike Kotlin explicit ffi bindings are needed. This may create some friction for early adopters, but…
Ballerina team told me that in the future Ballerina will not be hosted on JVM.
> Ballerina team told me that in the future Ballerina will not be hosted on JVM.
They also told me that back at Kubecon in 2018 :D
Re: Ballerina: A Data-Oriented Programming Language
#8Confusingly, it doesn't seem to have much to do with data-oriented design.
https://en.wikipedia.org/wiki/Data-oriented_design
Re: Ballerina: A Data-Oriented Programming Language
#9At first glance:
The syntax seems to lean on JavaScript (C-like with data literals, long keywords, dot notation for de-referencing etc.), the types are put at the front of an expression (like C, Java) as opposed to the back (Pascal, Go, Rust, Typescript).
The type system seems to take inspiration from Typescript. With structural typing, optionality and so on.
The query language looks very similar as Clojure's list comprehensions (for macro).
But I think the interesting stuff is things like this:
https://ballerina.io/why-ballerina/graphical/
And this:
https://ballerina.io/learn/configure-ballerina-programs/conf...
Re: Ballerina: A Data-Oriented Programming Language
#10This is a great idea (with implementing them myself resulting in limited success). I do wonder if such languages are better served as either embedded libraries in a target language (like lua runtime) or as a front-end for cross compiling to a target language? Ie better served as DSLs?
Clojure is what you describe in a sense.
A hosted language that has the idea of symbiotically interweaving into existing ecosystems.
I've done a lot of clojure in my past, and while I love the language and it's heigh ceiling, I've found the floor not quite low enough.
I do indeed think that there is room to bring a more data driven approach to existing ecosystems, especially when it comes to interoperability between them. Something living in the area between SQLite, protobuf and a hash table.
And I don't think there is actually much needed to achieve this.
* A dead simple binary graph representation format.
* An easy to implement immutable datastructure to represent that graph.
* A simple conjunctive query DSL to that translates between the data graph and the tree semantics (structs, maps, arrays, e.t.c) of the host language. Implicitly providing join and filter operations (similar to GraphQL).
These tree declarative primitives would probably be enough to pull any host languages 80% over to being data-driven. All the other fragments of relational languages, like recursive queries in Datalog or negation and optionals in SQL, would be recoverable by using the capabilities of the host language.