Replies: 1 comment 7 replies
-
|
Dao is IMHO the best example of the world ~15 years ago - much of the SW industry was up to "flexibility", "universality", "optionality", "choices", etc. That's where Dao excels and offers the most I've ever seen. IMHO this has changed pretty radically as people got finally fed up by all this complexity and want a highly constrained "one separate thing for each use case" (note, use cases are usually convoluted, so this doesn't produce more modular SW, it's actually quite often rather anti-orthogonal then not). We can see
|
Beta Was this translation helpful? Give feedback.
-
No, I haven’t thought about this model before. If I can find studios that are interested on the underlying engine of Craftica, I will be interested to try this model. I do have friends who seem quite interested (as in collaboration or involvement) in Craftica in the wake of so-called Metaverse, I just feel it is not quite there yet, but it could be an option to go this way. And like you figured, there was not enough (virtually none) marketing for Craftica so far, the main reason was that, after releasing the game on Steam I soon realized it was rather premature, so I decided that it is better to improve the game first before marketing it. Only recently the game has reached a marketable state, I think. And now I find it might be more difficult to market a game than develop it. I am considering the option of finding a publisher for the game, if it is still an option. (I did get approached by a medium sized Chinese game platform last year, but it turned out to be a real disappointment, essentially they wanted to trade almost nothing for a permanent license on Android!)
This is a tough but valid question. I agree that having a specific use area could make it easier to succeed, but if you look around, there aren’t many good choices. If I am to make a bet, game development seems to be good fit. I think Dao has some competitive edges over Lua, but there is also LuaJIT, I don’t know how many games using Lua also use LuaJIT, it’s hard to compete against LuaJIT without a good JIT for Dao.
For HPC, it will have to be backed by a research institute or university, I have connections in this area, but I don’t think it can be based on Dao. For better publicity, which is important for getting funds, it will have to be brand new, I think. For embedded development, the visual programming language is more appropriate. Compiling Dao to binary would be a huge task, and might require to changes some parts of Dao to make it possible. While for the visual programming, its macro can be written in a way to generate any target source/binary code. The Arduino example in my last reply, basically generate C/C++ like code that can be compiled to run on Arduino hardware.
So my best bet is on the visual programming language, and use Dao as its foundation. The idea I had, when I started to develop this visual lang, was to develop a code block based language that is easy for kid to learn and also suitable for adults/professionals to use. So like Scratch, a clear code structure will help kids to learn and try to code. But unlike Scratch, instead of finding and dragging proper code blocks into a program, this visual lang can provide highly relevant code suggestions (based on type inference) at the insertion point in the program. So it should be even easier than Scratch at the coding level. If the native syntax of the visual lang is still too high level for kids, it is possible to use macros to define a subset or simple set of syntaxes for them. For adults and professionals, this visual lang is a general purpose programming language, and its IDE supports highly efficient code navigation and editing (more efficient than VIM in my experience). And it is naturally suitable for coding on pads. For the visual lang to be general, Dao as its foundation will have to be kept general as well. And to make the visual lang and the IDE more interesting and fun to use, in the IDE I integrated the game engine I am using to develop Craftica, and made it possible to develop games with the visual lang and IDE. I already managed to worked all this out a few years ago. (I had high hope for this then, and so we tried to apply for a seed fund from a government department for technology innovation. But ironically, the approval criteria seemed not to be based on technological innovation, and we waited for almost a year to know our application was rejected.) Now I even made Craftica runnable inside the IDE, so in the future it will be possible to use the IDE and visual lang to develop mods for the game 😄. No matter what direction Dao should go, I do plan to do something about its GC. The algorithm is concurrent and realtime, but two things need to be improved: the allocator and refcount update. In order for the concurrent GC to work without pitfalls (currently a few ugly workarounds are used), the realloc() function must be slightly changed, so I have been considering to adopt a good open source allocator, and include it with Dao with slight modifications. Currently a mutex is used for refcount update. Previously I like code to be neat without much platform specific stuff, so I was a bit reluctant to change to use atomic operations, but for better performance’s sake it should now. Edit:
I forgot to clarify, it was not about the language per se, it was about the social condition in China: currently there seems to be a strong support for domestic technology. In such context, there might be a chance for Dao if it can attract enough attention to get it above the social media noise. There is probably no guarantee, but it could be an opportunity. |
Beta Was this translation helpful? Give feedback.
-
Yep, Metaverse could help the Craftica engine to get some publicity. Though I'm not sure about monetization. So I'd go with the strategy to sell time-constrained (i.e. pre-paid subscription) non-exclusive license to many different game studios first.
Sure, this happens and will happen. But by far not everybody is this "weird" - especially considering the universality of a sandbox engine which the buyer should understand. Try as many game studios as possible.
Well, 10 years ago I thought Lua is being used because it's a nice universal language. But only later I realized that the truth was different - namely the existence of the excellent LuaJIT. So actually it might have some potential in case of Dao because LuaJIT doesn't exist any more so to speak and despite a huge amount of Lua-based or inspired-by-Lua languages, none of them is fast nor safe enough nor comprehensive enough for games. What I'm though afraid of is the fact that you as the author of Dao didn't use Dao for your very own game because it was cumbersome to interoperate with C++ (both ways). That pretty much says Dao is not (yet) well positioned for this task. Btw. I think Julia is a "hidden killer lang" (not only) for games. Let's see what'll happen in the upcoming 10 years.
I'd be enough to rename Dao IMHO. But let's forget it - you said no to HPC, then so be it.
Hm, then I'm a little confused what the visual PL has to do with Dao if it compiles to native C/C++? Anyway, if the visual PL can produce binaries, then that sounds promising. In that case there'll have to be also JS target support.
This all sounds super cool technically. But how do you get the money for all the effort back? Any business plan? A programming language itself was never something anyone would pay for. So you'd have to bundle it with some significantly more important product. What would be the product(s)?
Yes, atomics should be nowadays much more portable than 10 years ago. So go for them. Also as of now it appears to me that mimalloc 2.0 is the best allocator available.
Interesting - then there is at least this chance. FYI - about 5 years ago I wanted to use Dao for one smaller commercial product a customer of mine requested. But then I decided not to use it because of two reasons - it's hard to make it run on unconventional systems (in my case it was a highly constrained Linux on a tiny embedded custom pllatform). And second because all the bindings to the outside world did not exist and had to be created manually or at least partially manually. So I chose Python (with type hints) and POSIX shell and it worked well. Btw. what would have helped me in that situation a lot were to maintain Dao in buildroot (and Yocto Linux and ideally also in OpenWrt) as e.g. Janet language does. |
Beta Was this translation helpful? Give feedback.
-
I agree, the license model you suggested sounds a solid one and can be a good starting point.
You are probably right about why Lua was widely used in games. I haven’t paid attention to LuaJIT for years, I wasn’t aware that it was no longer maintained, good to know.
Well, the reason I don’t use Dao to develop the game is actually a bit more complicated than that. Initially, I wrote the subvoxel engine prototype entirely in Dao as a plugin for the IDE I mentioned. Then I moved the performance critical parts to C++, because I needed every ounce of the performance. Everything else stayed in Dao. Then when I started to develop it as a real game, I found that the Dao interfaces were inadequate to do certain things, and it was not because it could not interoperate with C++ adequately, but because certain things required a direct access of some third-party libraries. The Dao interfaces for the game engine (Atomic Game Engine, based on Urho3D) actually wrapped nearly all the classes and methods of the engine. But Atomic only wrapped and exposed a subset of functionalities of some third-party libraries, so Dao could only access what were exposed by Atomic. But certain things (mostly in UI and physics) were impossible to to without direct access to those libraries. I could also create Dao bindings to those third-party libraries, but they all have different class/method designs and styles, it would be quite some work to wrap them properly, I didn’t consider it worthing the effort. Besides, I felt I could develop as efficiently in C++ as in Dao, so I thought it would be simpler to simply develop everything in C++. Still you are right that Dao is not yet well positioned for games. I did encounter a few issues in using Dao in the development of the game, for me they were easy to fix, but for others they could be nightmares. I plan to provide modding APIs in Dao for my game, and hope the use of Dao to mod the game could help smoothing out some rough edges for its application in game development.
Right, Julia has a lot potentials. But it is probably not a good scripting language for games, unless they create a good game engine entirely in Julia, which should be possible of course.
You probably misunderstood me when I said “I don’t think it can be based on Dao”. It is not that I don’t want it to based on Dao, it is they don’t want. Based on my experience, most Chinese research institutes and universities have no interest backing, sponsoring and promoting a project (such as Dao) that can not be branded as their own IP work.
The macros transform code in customized syntaxes to visual PL code: essentially AST, which is then compiled into Dao VM bytecode. Then the target C/C++ source code is generated by executing the bytecode (compiling-time execution also possible). This way, it can target anything including JS.
The idea was to create a product for programming and STEM education for kids, and sell it as an app and/or license associated courses to some training organizations (or collaborate with them, or setup our own training org). I had a ex-colleague working with me on this. He built quite some basic models that could be assembled into virtual vehicles and robots, which could then be programmed and controlled. We tried to apply a governmental seed fund for this, but the result didn’t turn out good for us. The business plan seemed ok, but I was not entirely sure about it. At that time, there were some competing products existed on the market, most of them looks more or less like Scratch. I wasn’t sure how well they were doing then. But two years later, namely last year, I heard that one of them made dozens of millions of dollars selling online courses, probably due to COVID. However, this year I heard they were laying off a lot of employees. So, hard to tell.
This should be a good choice.
Five years ago, I was working in a research institute and was under a lot of pressure which eventually led to a job quit at the end of the year. So I wasn’t very active and responsive online during that period of time, sorry about that. It was regrettable, it would have been interesting to see Dao application in commercial products. Manually creating bindings for more than a small number of APIs could be painful. I normally use ClangDao to generate bindings automatically or semi-automatically. Unfortunately, it currently stuck with an old version of Clang on my computer, it needs to be updated to the latest version of Clang.
I never used Yocto Linux or OpenWrt, I did wanted to try Dao on them when I first heard them, but never found time to do it. Dao should be supported on them. |
Beta Was this translation helpful? Give feedback.
-
This is exactly what I had in mind. It doesn't pay off to use Dao because libs are in C++ and bindings are either not good enough (feature-wise, performance-wise, ...) or it's extremely tedious to create & maintain your own bindings. The second reason you mention is though even more dangerous - if you were as efficient in C++ as in Dao, then there is truly no reason to even think of Dao. Sure, C++ compiles slowly, so in-game scripting is better to be done in something with sub-second compilation speeds (think V) or in an interpreted language (e.g. Dao). But in such case requirements on the language are pretty low, so Dao doesn't feel that interesting for this task.
Some people are working on that - and I read that they really liked the enormous amounts of mathematical libraries out there which are fully generic and really highly performant. So they can really focus on the game engine itself and not on how to write transformation matrices efficiently etc. Julia is extremely productive and the reason why there are no big game engines is simply that the Julia community is still small. That's changing though... But I digress.
Oh, I'm sorry. I really misunderstood. Now I see what you mean. That's a pity. On the other hand from my experience universities and research institutes are not the ones which would give you adequate money for providing Dao-based HPC solutions or at least HPC frameworks. Bigger companies are. But I myself think that Dao would need vastly more parallelism abstractions than it now offers to be competitive in this segment (btw. Julia would be one of the strongest competitors).
Ah, OK. Then Dao (its bytecode) actually serves only as convenient intermediate representation.
That'd be my guess. It doesn't sound like a long-term sustainable business for a mid-sized company. But rather something closer to a one-man show which I'd generally not aim for. Any other non-education products/services you had in mind?
Well, that's always the very first thing I'm telling the authors of any new language - please provide seamless (i.e. truly zero effort) bindings to at least one huge ecosystem. For interpreted languages it's Python. For compiled languages it's C/C++ and Rust ecosystem. No matter what the cost of the (in)efficiency will be (even if you needed to bundle the whole CPython with Dao), this is a must have. If the FFI/bindings will be less capable and even a tiny bit more verbose than https://cjdoris.github.io/PythonCall.jl/stable/pycall/ then Dao failed forever. Sure, this is my subjective opinion as it's hard to measure these effects, but try to look at it from this perspective and you'll suddenly see enough of "subjective statistical evidence".
I meant really to become "a member" of the maintainers of buildroot & Yocto & OpenWrt and actively provide Dao (incl. its modules etc.) in these ecosystems. That's much more than just supporting these systems. It raises the bar of the Dao deployment quality, release management, compatibility with HW & systems, etc. Btw. under the impression of recent years the biggest syntactical pain Dao is the need to write There are many more things I'd like to see in Dao, but that's for another discussion. First I'm interested in the general points above to understand what's in your mind and what you're after 😉. |
Beta Was this translation helpful? Give feedback.
-
I wouldn’t say it is extremely tedious to create and maintain those bindings, it was just that it wasn’t the best development strategy for a solo developer with limited time. Also my example of development speed is hardly typical, I have been using C++ regularly since 2003 (first time use years earlier). I wouldn’t say developing in C++ is faster than in a scripting language, but depending on what libraries I use, I could become almost as fast. In the case of this game development, when I say I was as efficient in C++ as in Dao, it is definitely not because it is not efficient to develop in Dao. One factor here is experiences as mentioned above. There are other factors such as:
In the early development stage of this game, flexibility was not very important, because it had not reached to the point that I needed to try different game logic. So scripting wasn’t an important part of the game. So as a solo developer, I choose the most frictionless path of development, so that I can customize as I wish and change things as I go.
Yeah, but it is not because they don’t have money, it is because they’d rather spend the money on hardwares (looking shiny, tuning benchmarks for better ranking and better publicity/funding, etc.). Sure, for Dao to target HPC, it will need huge improvements, which would be a good thing, and I would welcome such improvements.
No, I haven’t figured out a non-education product. In China education and training is actually a very good sector with big market. But things are changing.
I actually had thought about this more than ten years ago. Initially I considered R, because it has a lot of statistically packages. But after some digging, I found R and its APIs were too messy, and thought it was too much trouble. Then I looked to Python, and found its APIs were much cleaner. If I remembered correctly, I actually made a module that can call python functions in Dao. OK, I just searched on my computer, I found it! It was developed in C++ in 2006, when Dao was developed in C++. Then I switched to C for Dao implementation, probably at that time Python wasn’t a big thing then, so I didn’t port that module to a C implementation. After a long time, I almost forgot about it, and even thought I had lost it when my laptop hard disk failed in 2013. Finding this module is a big surprise for me, I will try to port it to the current Dao 😄 I also had made bindings for a number of big libraries including Qt4 and VTK. But unfortunately, I didn't maintain them when Dao's API evolved.
Right, it shouldn’t be a problem if I have time.
I think we had discussed years ago that it was not a good idea to omit var/invar. Now it is recommended to always use var/invar for declarations. But there is a command line option --autovar for omitting var, we could also add another option --autoinvar for what you suggested. However, in interactive mode, making invar the default may not be convenient.
In some way, what I am after will have to involve the Visual PL, which is also my strongest motivation to push Dao forward. But since it has not been made public, there seems to be no solid ground to make much discussion. This is also the situation I want to change. Without going into details, I can simply list the following right out of my mind 😉 :
|
Beta Was this translation helpful? Give feedback.
-
After being caught up in the development of a couple of other projects for several years, now I am considering to resume the development of Dao, and make a public release this year. I am still not sure how much time I can spend on Dao this year, so I think it is better to release it as it is, without significant new features or modification.
There is another thing I have been considering for quite some time. Since the last 2.0 RC and Beta releases was almost ten years ago, and it was only since then Dao started to mature feature-wisely, I wonder if we should reboot/reset its version number to 1.0?
In 2016/2017, I removed three major features: syntax macro, decorator (with type annotation) and aspect-oriented programming (based on decorators).
I removed syntax macro, because I was working on a new code block based visual programming language on the top of Dao, I implemented a more interesting macro system in that language, which would make syntax macro obsolete. However, that language won't become ready to be released without some extensive work. So maybe it was a bit premature to remove this feature.
As for decorator and aspect-oriented programming, they involves running time modification of Dao program, and are good for monkey-patching. I considered them not good for developing clean softwares, so I removed them. Maybe it was also premature.
However, to bring them back before the public release might be unwise, since this will introduce quite some not well tested code. Maybe the possibility of bring them back after the release can be investigated and discussed.
The visual programming language (I will use X to refer to it for convenience) I mentioned in the second part is one of the projects I mentioned at the beginning. The other project is a sandbox game named Craftica.
Before starting to work on the game, my plan was to work on X for a few month more, and then make a first release of X and a new release of Dao at the same time. Then I started to working on the game, I thought I could finish the main part of game soon enough, then resume my work on X again. But unfortunately, I vastly underestimated the time required to develop the kind of game I envisioned.
Anyway, with the last update of the game released, I consider the most technical challenging parts of the game are done, now it is just a matter of adding more game features and making some promotions. How it might turn out is not entirely up to me. So it is about time to resume some other work such as Dao and X.
Regarding X, it might be difficult to release it at the same time along with Dao this year, unless I can work on them full time for a few months. So maybe it is better to schedule its release to the next year.
Beta Was this translation helpful? Give feedback.
All reactions