Minor: how to present Dao?

[dumblob]

I'm going to have a talk about Dao at the OpenAlt 2015 conference and I'd like to ask for revision of my notes, which will serve as an overview about the language. Feel free to comment on them.

borrows from
  C++ (object-orientation, syntax)
  Go (defer idea and few underlying concepts)
  C (simple things made simple, but at the same time high-level enough)
  Ruby (code sections, mixins)
  Perl (basic idea of type inference; dollar for enums :) )
  Python ("any" type evaluated in runtime; decorators)
  Scala (invar/var, mt.Future, synchronization functional principles)
  Rust (safe synchronization principles)
  Lua (inspiration for super-fast register-based VM; string patterns)
  Matlab (syntax for arrays and range loop)
  some other languages...
  few constructs might resemble Chapel (greetings to HPC guys), but this
    similarity was discovered after we did it ourselves

goal
  classification in the languages universe depicted using scales
    purely_imperative ... mathematical(purely_functional|declarative)
    syntax-oriented_people ... idea-behind-oriented_people
    small lang (brainfuck) ... big lang (C++, Rust, LiveCode [1900+ keywords])
    small implementation possible ... huge implementation needed
        (including std lib etc.)
    newbie ... programming_experts(e.g. game developers)
    low level (ASM) ... high level (BPMN)
    unsafe (sometimes it's needed) ... safe (don't trust humans)
    fully open ... partially proprietary (e.g. std lib) ... fully priprietary
  targets
    clean and minimal interfaces
    readability (short names, very small number of operators & keywords,
        proven mechanisms for structuring, ?????)
    extremely fast
    self-defence from myself
    portability (MacOSX, <strong>iOS</strong>, BSDs, Haiku/BeOS, Linux,
        Windows from XP)
    native support for real concurrency and asynchronous handling
      e.g. Kotlin, Ceylon and other JVM-based langs resemble rather a
          syntax-sugar to C/Java syntax then a really high-level approach
    feature-full (also "dualism" instead of one-fits-all - see below)
    small
      # stripped binaries, non-DEBUG versions
      # dao -e 'load stream; f=io.open("/usr/bin/dao", "r"); io.writeln(%f.read())'
      du -b $(which dao) /usr/lib/libdao.so $(which python3.5) /usr/lib/libpython3.5m.so.1.0 $(which perl) /usr/lib/perl5/core_perl/CORE/libperl.so $(which lua) $(which /usr/lib/jvm/default-runtime/bin/java) /usr/lib/jvm/java-7-openjdk/jre/bin/../lib/amd64/jli/libjli.so /usr/lib/jvm/java-7-openjdk/jre/lib/amd64/server/libjvm.so
      9896       /usr/bin/dao
      926192     /usr/lib/libdao.so
      10376      /usr/bin/python3.5
      2741072    /usr/lib/libpython3.5m.so.1.0
      10416      /usr/bin/perl
      2081760    /usr/lib/perl5/core_perl/CORE/libperl.so
      220040     /usr/bin/lua
      5264       /usr/lib/jvm/default-runtime/bin/java
      53216      /usr/lib/jvm/java-7-openjdk/jre/bin/../lib/amd64/jli/libjli.so
      12594896   /usr/lib/jvm/java-7-openjdk/jre/lib/amd64/server/libjvm.so
  targets from "the other side" (those with negative effects)
    not bound to relics in programming approaches
      just because such conventions, names etc. are unlogical (to us)
    minimize the number of unlogical things (still, one might find something -
        e.g. due to performance reasons UTF-8 indexing needs a built-in method
        as opposed to byte-indexing)
    don't stick to only one approach (functional, logic, imperative,
        object, instructions, ...), but rather pick only the best concepts
        from them (Java, Python3 - everything is object; Haskell - monad or pure
        function; Prolog - statements with only boolean result; Lisp &
        derivatives - functions and linear lists; ...)
    don't waste time: it took too many years to ECMAScript to end-up with
        https://github.com/Steida/este (no MVC, static typing,
        no framework - but a smart library, automatical testing, etc.)
    avoid the need for things as Nuitka for Python
      http://nuitka.net/pages/overview.html
    finally prevent "self licking ice cream cone"
      http://lighttable.com/2014/03/27/toward-a-better-programming/
      e.g. Nim language is self-licking (compiles to C/C++/Obj.C and uses safe
          concurrency due to messages)

architectural decisions/principles
  built-in types (lowercase) have no or very few methods
  typing (static and dynamic at the same time)
    inference
    scalars (string as well!)
    none (folding??? auto-folding??? ...)
    disjoint type (sometimes called "union type")
      very powerful idea!
      ensures "absolute" safety
      encourages good programming practices
      feels very intuitive (like in functional languages)
      prevents typing system "hacks" like a "lifted (nullable)" types
          in C# or very obtrusive wrapper types

      x: none|@T = none
      y.iterate {
        if (x == none)
          # type-checked in compile-time
          x = return_complicated_non_none_type()
        else
          io.writeln(x)
      }

    any - dynamic type evaluated in runtime => slower by cca ????% FIXME
    type holders
      evaluated in compile-time
          => no transitive non-nominative type information:
          map<enum<a,b>,int>[0x1e5a720]:map<enum<a,b>,int>
          map<enum<a,b>,int>[0x1e5a720]:map<@K,@V>
          map<string,@V2>[0x1e65580]:map<string,@V2>
      e.g. @T, @T<int|string>
    recursion (JSON, trees etc. as good examples)
    inheritance
    interfaces
    mixins
    # it took me some time to grasp how to efficiently and properly (write as
    #   few as possible while avoiding "any") use it, because I was used to
    #   2 extremes - explicit typing (C/C++/Java/etc.) or absolutly hidden
    #   weak typing (Python, Ruby, Smalltalk etc.)
    # hint: write the code more in a functional manner and the typing system
    #   will derive more than 99.9% of types as non-any
    #   use e.g. std.exec(){} which I'll shortly discuss later on
  types
    string, int, float, map (hash|RBTree)
    class
      constructors not necessary (if no logic needed)
        class C1 { var x: int }; C1.{5}
        class C1 { var x: int }; C1.{x = 5}
        class C2 { var x: int; C2(_x: int) { x = _x } }; C2(5)
        construction of C1 is much faster as it's only bunch of assignment
            instructions
        construction of C2 is slower as one needs to call a routine (which
            involves copying of scalars to stack; preparing the routine itself;
            execution of the routine; then finally the assignment instructions;
            but then again cleanup of stack and putting a return value - none
            is internally also a "value"!; update of internal structures in
            the routine)
        hint: imagine class as a tuple with methods
      destructors/finalizers
        supported only from C (see modules source code), otherwise they're
            hell in GC languages with concurrency
    class wrapped type
      have more features, but only under the hood (e.g. multi-inheritance,
          template-like type, ...)
    C data types (scalar-like objects)
      delay of several months (raised by an issue with pointers as keys in maps)
      another big change
      # FIXME update to current Dao
      invar class C {
        invar x
        routine C(){ x = 5 }
        routine (int)(invar self: C){ x }
        # `hashing = true' can be of course used also for cases where
        #   hashing is not needed (if the value makes sense outside of hashing)
        routine (int)(inavr self: C, hashing = true){ x }
        # artificial operator <=> (has prevail over other operator overloads)
        #   returns -1 0 1 (useful for balancing of RB trees in maps etc.)
        #   => no need to define == >= <= separately
        #   => and also better flexibility and performance
        routine <=> (invar self: C, invar other: C){ x }
      }
    CPOD plain old data
      C structure, but always copied when assigned
  immutability - invar
    == only local (one can pass an invar piece of data as a pointer to
        a non-invar container and through that container you'll get non-invar)
    "tags" variables, so that it's checked in compile-time there are no modify
        operations applied to them not modified
  code sections (also with implicit X, Y, Z - only 3 ??????? FIXME)
  decorators
  generators
  aspects (AO programming)
  eval
  std.exec(){}
  BNF-like syntax macros
    !!! always think of interoperability => don't diverge too much
    mimic Python decorator's wrap() adding the given type to a global list (
        used e.g. for registering handlers)
      # MACRO
      load macro
      syntax {
          '!' $ID1 [ '(' $BL1 ')' ]
          'routine' $ID2 '(' [ $BL2 ] ')'
          '{'
              [ $BL3 ]
          '}'
      } as {
          'routine' $ID2 '(' [ $BL2 ] ')'
          '{'
              [ $BL3 ]
          '}'
          '{'
              'func' '=' $ID1 ';'
              'arg' '=' $ID2 ';'
              'func' '(' 'arg' [ ',' '(' $BL1 ')' ] ')' ';'
          '}'
      }
      # MACRO INPUT
      !StaticDecorator
      routine Myfunc()
      {
          # ...
      }
      # MACRO OUTPUT
      routine MyFunc()
      {
          # ...
      }
      StaticDecorator(MyFunc);

  load name import ns
  load name import ns . { symbol, symbol2 }
    namespace has to be declared previously in a common file (matching ns
       names is not supported)
      stil valid?????? FIXME
  string path concatenationn using overloaded /
  concurrent tasklets (1:1 mapping to threads) using !!
    no built-in deadlock detection due to performance reasons, but is still
        an open question - any volunteer?
      for reference: https://github.com/daokoder/dao/issues/363
    exceptions and everything internally-related causing deadlock is
        though detected!
  dualism
    non-nominative type / nominative type
    types / classes
    abstract types / concrete types ?????????
    inheritance / mixing
    closures / code_sections
    hash / tree maps
    serialization (both built-in and user-defined types)
    var / invar
    routine decorator / class decorator
    asynchronous function (call) / asynchronous class
    abstract interface / concrete interface (~ generic [post-OOP](http://babel.blog.root.cz/2015/08/25/post-oop/))
  bytecode
  no intermediate Abstract Syntax Tree => faster parsing/load and simpler
      implementation (but not easy to hook something there
      => no compile-time checking of nesting in the html module)
  optimizations: dead code elimination, ...
  GC
    non-blocking concurrent (multi-thread)
    incremental (single-thread)
    generational
    => probably the most advanced and in theory fastest GC in the world (
        way ahead of those from Perl, Python, Ruby, Go, etc.)
      there are though no case-specific optimizations, so in these cases,
        e.g. the JVM GC will (hopefully) perform better
    but no extreme caching (yet) - missing statistical caching, compared
        to Java GC (which btw uses mark-scan with 2 generations:
        mark-copy -> young; mark-compact -> old )
    nevertheless GC is by far the slowest part of Dao
      => optimizations are seeked for mutator threads, which in theory might
        sometimes get faster then the single GC thread can collect in time
  semi-automatical generation of interfaces
  tools
    KISS profiler
    LLVM autobinder
    daopkg (neat package manager for modules)
  build system
    daomake
      for building Dao
      produces platform-dependent Makefiles
      == C99 multiplatform program (less than 4000 SLOC) embedding a
          small subset od Dao lang
        for bootstrap a hand-written multiplatform Makefile is used
      serves also as multiplatform wrapper for CRUD file/dir operations etc.
      very short, readable and hackable makefile.dao
      Dao-specific (not meant as replacement for Premake, CMake, etc.)
      very fast (also for embedded libraries, equivalent makefile.dao files
          are created and maintained to avoid e.g. ./configure and to
          ensure multiplatformity)
    modules can produce *.so (clang) or just intermediate *.o (ffi)
      *.o are used only for other modules
      *.so are getting installed

quality in use - remarks
  very quick learning curve (couple of minutes for those knowing C, Java,
      Scala, C++, Python, Ruby, Rust, or similar)
  in a given scope a declaration or definition ("x: int" or "x = 5") creates
      a local non-invar variable seen also from descendant scopes
    can't be though used for a class, because class itself has no scope (FIXME
        does this still hold?)
      => one has to use explicit var/invar
  first rvalue cast in a given scope or expression
    => sometimes needed for compound or disjoint types

    # FIXME verify when actually needed!
    invar x = std.exec(){
      switch (5) {
        case 4: return (none|int)4
        case 5: return none
      }
    }

    y: enum<a,b> = true ? (enum<a,b>)$a : $b

    # FIXME actually not needed!
    #   not needed if the first return is at the same time in the outmost scope
    routine r() => none|int { x = (none|int)5; return x }
  avoid multi-assignment if you're not 100% sure each element will get
    a type-matching value (e.g. none is not compatible with any other type!)
  type holders
    (a, b, c) = std.exec { switch (5) { case 5: return ("x", "y", "z") } }
      [[ERROR]] in file "command line codes":
        At line 0 : Invalid function definition --- " __main__() ";
        At line 1 : Invalid virtual machine instruction --- " RETURN:0,0,70 ";
      In code snippet:
           13 :  RETURN      :    11 ,     1 ,     0 ;     1;   return ("x", "y", "z") }
      >>   14 :  RETURN      :     0 ,     0 ,    70 ;     1;   } }
           15 :  GOTO        :     0 ,     4 ,    70 ;     1;   }
        At line 1 : Return is expected but not present --- " } } ";
    (a, b, c) = std.exec { switch (5) { case 5: return (none|@T)("x", "y", "z") } }
    (a, b, c) = std.exec { switch (5) { case 5: return (@T)("x", "y", "z") } }
  auto-pickup of matching casting method if available (e.g. io.writeln())
  custom memory allocator not tested, but you can do that by redefining
      dao_calloc() dao_malloc() and dao_free()
    FIXME mention here the officially supported concurrent allocator ?????
  n-ary for-in loop
    for (a in {5, 6}; b in {3, 4}; c in {1, 2}; d in {-1, 0})
      io.writeln(a, b, c, d)
  to avoid pointer comparison (e.g. in maps), always define == and < routines
    or use CPOD types
  switch
    no break (multiple values can be separated with , )
  VM implementation checked by a static analyzer (see github issues)
    first check was after 6 years of development, but only 2 mistakes (
        pointers) were found in those 60000 SLOC
      ??? FIXME ??? do I remember this correctly?
  exceptions - only a tiny set built-in; user can use in-place exceptions (
    FIXME test if it still works) or define/subclass some "master" exception:
      const e = Error::define("MyErr", "description ...")
  single file deployment
  a lean but powerful OpenGL framework module supporting all platforms
    => extremely simple and fast development of games for iOS (unfortunately
    building of Dao for iOS requires XCode)
  false sharing (line of memory owned by one HW core, but updated by one and
      read by another) considered in the reference VM implementation
  built-in "intrinsic" constants & functions (mathematical...)
  overloaded / (string concatenation) is not a syntactic sugar:
    it examines pairs of last part of lvalue and first part of rvalue
    if rvalue is an absolute path (starting with / or $( ), lvalue is ignored
    otherwise one and only one (if any) / at the end of lvalue is cut off
    and the pair search continues while resolving ../ in rvalue only (!)
      => "/a/b/c/../../b" / "../../a" -> /a/b/c/../a
    => no normalization is done, but if / is used for the whole path
      construction, one'll get a nice, normalized path
  special relative paths
    ::path - relative to the current source code file
    :path  - relative to the current working directory
  auto-restart capability in case of failure
  LLVM allows among others also compilation to JS using Emscripten
    it works very well except for the built-in threading parallelism (only
        the Hoare CSPs pseudo-threads are used)
    FIXME prepare canvas example for http://daovm.net/demo.html
  modules
    meta (inspects in runtime anything available in the language)
    coroutines (yield() + resume())
    protoobject (prototype-based OOP - non-existent fields can be set and used;
      also delegator acting like overlay)
  other new/experimental languages I am interested in
    Dao "system/low-level" counter part (in a design phase)
    Terra (low-level Lua + Lua)
    Factor (stack-based)
    Julia (high-level mathematical computing; LLVM JIT)

lessons learned
  incrementally use first simpliest structures, if not satisfied, add some
    more while refactoring, and so on until you reach the proper level or
    exhaust all the language possibilities (let me know about it as it would
    need to be a master piece program of all master pieces :) )
    => this is the way how C maintains it's popularity over decades (allowing
      low-level and also high-level); C is really everywhere!

some facts :)
  discussions about inflections, plurals etc. (e.g. .contain() -> .contains())
  each of us has quite different style of writing code (not only syntax!)
    but the project uses one style, so you'll find only one style in repos
  "meta" programming out-of-the-box (not like //go:generate in Go - see the
      stringer example http://blog.golang.org/generate)
  daokoder invented FLAME, a novel approach to fuzzy clustering solving
      non-linear "transitive" dependencies while being 2x slower than k-means
      in practice for small and large inputs - that makes it the fastest known
      algorithm for clustering while having this unique property of inherent
      "transitiveness"
    complexity is only about N^2 (that's wonderful in the field of clustering!)
    requires a defined neighbourhood (as the only requirement)
    unfortunately not many people know about this algorithm (which is quite
        simple compared to other clustering algorithms)
  daokoder got a new job due to knowledge and skills from working on Dao
  NightWalker got a new job due to knowledge and skills from working on Dao
  ShadauxCat joined us and the next day, he sent us a fix for few bugs in the
      (at that time not yet maintained) macro module (=> Dao is easy to grasp
      and hack on if one has sufficient knowledge background - this guy is a
      developer of AAA games like Mass Effect, Star Wars: The Old Republic)
  makes you more self confident (bugs are not always your mistake, but
      sometimes also a bug in the language or VM itself)
  not yet present in https://github.com/mame/quine-relay

This presentation will bring several new interested guys, so this project will catch some momentum and we should prepare at least a little bit for that. I'm talking about minimal "project management" - especially a firm roadmap (not to be confused with time scheduling) and the possibility to collaborate using github pull requests (including the awesome inline comments on the committed code).

[Night-walker]

My feedback will likely be very long, so I'll split it in parts. Here is chapter one -- borrowing.

borrows from
C++ (object-orientation, syntax)

I'd better omit this fact which hopefully will become history earlier or later, on which I myself have been working for some time. For a modern high-level language, C++ is mostly a poor choice to borrow ideas from. The influence of C++ in Dao is already relatively faint, and I expect it to subside further during subsequent design revising.

C (simple things made simple, but at the same time high-level enough)

In C, simple things exist mostly in abstract examples. In reality they quickly become stupidly complicated because real-world code requires proper handling of errors, portability, safe concurrent data access, etc. Not to mention miserable and awfully designed (due to historical reasons) standard library. With regard to simplicity, Go is a considerably better example.

Overall, mentioning C/C++ as a source of inspiration for a scripting language today is a sure way to be perceived an oldfag and freak. Conclusion: refer to other languages, mention C/C++ only if you sense dominating presence of oldfag freaks :)

Perl (basic idea of type inference; dollar for enums :) )

At present, Dao has little or nothing in common with Perl in particular. Dollar sign was definitely chosen in favor of simple parsing rather then by Perl's example. Also, Perl is a remarkable example of ludicrous programming language design. Conclusion: mention it only in jokes :)

Rust (safe synchronization principles)

That would be a huge exaggeration -- Dao does not provide anything really similar to what Rust does in terms of concurrent safety, superficial resemblance in few minor details doesn't count. Dao's approach to concurrency is much closer to that of Go, with emphasis on simplicity.

Now, it is important to show that Dao is not just a language X plus language Y with the syntax of language Z, as many minor programming languages are. It borrows heavily from various languages, but virtually every idea goes through rethinking which may eventually produce a result substantially different from the origin. Good examples are enums (Ruby), decorators (Python) and defer (Go, obviously).

Having its own vision is what differs a good language from a mediocre one.

[Night-walker]

Chapter two -- goals.

classification in the languages universe depicted using scales

Might be somewhat redundant unless the audience is deeply academic. I'd focus on hot topics:

• growing influence of functional programming concepts, including advanced typing systems, immutability and the like, which solve problems with expressiveness, readability and safety
• broadening adoption of scripting languages and subsequent increase in code's size, which calls for readability and controllability to take higher priority then ease of use

That would help to emphasize strong points of the language's design comparing to mainstream alternatives.

targets
clean and minimal interfaces
readability (short names, very small number of operators & keywords,
proven mechanisms for structuring, ?????)
extremely fast
self-defence from myself
portability (MacOSX, iOS, BSDs, Haiku/BeOS, Linux,
Windows from XP)
native support for real concurrency and asynchronous handling
e.g. Kotlin, Ceylon and other JVM-based langs resemble rather a
syntax-sugar to C/Java syntax then a really high-level approach
feature-full (also "dualism" instead of one-fits-all - see below)
small

Definitely not 'extremely fast' -- that would be a hype. Under some circumstances faster then some languages -- that's close to the reality. Dao has potential to be quite fast, there is JIT compilation, but the language does not put particular emphasis in that.

Dualism is more an accident then an ideology. Overall, the design of Dao is not very clean due to certain practical reasons; this begets certain ad hoc solutions and lack of strong unification. Dualism is not a goal, it's a side effect which can hardly be viewed as an advantage.

Clarity, expressiveness, control -- these, I suppose, are the goals of Dao and its strong sides. Also clean and convenient interfaces, yes. Modern concurrency, but not anything outstanding as of now. Maybe some accent on embedding. Satisfaction from coding, after all :)

[daokoder]

I think @Night-walker has given excellent feedbacks. I will briefly comment on his feedbacks.

borrows from C++ (object-orientation, syntax)

Overall, mentioning C/C++ as a source of inspiration for a scripting language today is a sure way to be perceived an oldfag and freak. Conclusion: refer to other languages, mention C/C++ only if you sense dominating presence of oldfag freaks :)

Agree.

Perl (basic idea of type inference; dollar for enums :) )

At present, Dao has little or nothing in common with Perl in particular. Dollar sign was definitely chosen in favor of simple parsing rather then by Perl's example. Also, Perl is a remarkable example of ludicrous programming language design.

Correct. Dao had borrowed a couple of things (only one thing I actually still remember: syntax support for regexp) from Perl, but those things were eventually removed long time ago.

Another reason for using dollar sign for enum symbols is that there is S in $ :)

Conclusion: mention it only in jokes :)

Interesting idea:)

Now, it is important to show that Dao is not just a language X plus language Y with the syntax of language Z, as many minor programming languages are. It borrows heavily from various languages, but virtually every idea goes through rethinking which may eventually produce a result substantially different from the origin. Good examples are enums (Ruby), decorators (Python) and defer (Go, obviously).

Well said.

Maybe some accent on embedding.

Agree. It has been one of my primary goals to make embedding and extending simple, I think this goal is more or less achieved, and it has become significantly simpler than other languages for embedding and extending.

[dumblob]

Thank you for such a detailed feedback. I'll try to incorporate your perceptions into my presentation :) Should you have more comments, continue with them here.

[daokoder]

Some more feedbacks:

probably the most advanced and in theory fastest GC in the world

I would not make such a grand claim. This algorithm (without the generational part) was inspired by an algorithm proposed by David Bacon (2003), his algorithm is more sophisticated and very likely to be faster. Including the generational part, it would be hard to say.

I did no survey, but the concurrent GC algorithm in Dao is probably the simplest one using refcount:)

nevertheless GC is by far the slowest part of Dao
optimizations are seeked for mutator threads, which in theory might
sometimes get faster then the single GC thread can collect in time

This is correct. The next thing I am planning to do on the GC is to use atomic operations on reference counting and some other things. I will probably use C11 for this, if I cannot find a small and portable library for atomic operations.

daopkg (neat package manager for modules)

It is far from usable, so it is better not to mention it.

other new/experimental languages I am interested in
Dao "system/low-level" counter part (in a design phase)

Better not to mention it, because in a foreseeable future, I will not have time for it :(

complexity is only about N^2 (that's wonderful in the field of clustering!)

That's the time complexity of calculating the pairwise distances, which is usually not included as a part of the complexity of the clustering algorithm. Because distance matrix is often the input to clustering algorithms. The complexity of the actual clustering part is not known exactly, someone published an empirical test on it, it was shown to be N^1.x, I don't remember the exactx, but seems to be something around 3.

daokoder got a new job due to knowledge and skills from working on Dao

I actually did not accept the job that can benefit the most from my experience on Dao for various reasons.

especially a firm roadmap (not to be confused with time scheduling)

Now there is a simple and unspoken roadmap: 1. solve all/most the issues here; 2. make a module management tool. In terms of releases, there should be at least 3 releases to go before the next official release: at least 1 beta release and 2 RC releases.

the possibility to collaborate using github pull requests (including the awesome inline comments on the committed code).

I agree we should do this for Dao, but we (or just I) better practice this a little bit first on the module repo:)

[Night-walker]

daopkg (neat package manager for modules)
It is far from usable, so it is better not to mention it.

A remark: I stopped working on it because I don't think it's a high-priority task given the state of the language and available modules. As of now, we have no real use for it anyway; besides, there may be changes in the project organization in the near future which can render the current approach obsolete. I think the issue should be addresses when its scope and application becomes clear.

Now there is a simple and unspoken roadmap: 1. solve all/most the issues here; 2. make a module management tool. In terms of releases, there should be at least 3 releases to go before the next official release: at least 1 beta release and 2 RC releases.

My vision would be the following:

1. Resolve all design-related backward-incompatible issues (better earlier then later)
2. Address the documentation issue (without proper docs language use does not seem realistic)
3. Fix show stopper bugs, establish solid test base (not just the core but the modules as well)
4. Everything else

Apart from the above stands the necessity to make the project more manageable -- without something like pull requests the collaboration is rather inefficient.

[Night-walker]

Chapter three -- architecture.

built-in types (lowercase) have no or very few methods

That is not a goal or design principle by itself. It doesn't mean much, so I wouldn't make accent on it.

aspects (AO programming)

Will likely be transformed into something not looking like aspects much.

code sections (also with implicit X, Y, Z - only 3 ??????? FIXME)

No Z. Just X and Y -- using more then two such names easily leads to non-readable code.

any - dynamic type evaluated in runtime => slower by cca ????% FIXME

It's just a label to accept arbitrary type, it does not get 'evaluated', rather down-cast.

tools

Nothing to boast of as of now. Not worth accentuating because any comparison to mainstream languages would be suicidal.

Overall, key architecture points which may be used to promote the language are:

• typing -- expressive and sophisticated type system with exhaustive compile-time guarantees; immutability, template typing and other type-related functionality
• control flow -- higher-order functions, decorators, code deferring and exception handling, concurrency means, minor syntactic sugar
• modularity -- namespaces, classes and wrapped types, interfaces and other OOP-related means

[Night-walker]

Summary.

There is a lot of insignificant things which don't really need to be mentioned. I would concentrate on making a solid and clear impression about the language as the whole without diverging too far or diving too deep. The main rule is to avoid being meticulous, at all costs, as the goal is to make people interested, not lecture them.

A bit on modern state of programming -- demands, problems, solutions. A bit on the project in general -- how the language fits into the described picture, what it tries to solve and what makes it different from existing alternatives. A tour of key features with examples for look&feel. Plans on further development as final accord. Should be enough.

[dumblob]

Thanks again for the valuable feedback. I'll try my best with choosing proper wordings and making everything much simpler than it seems from the detailed notes :)

My vision would be the following:

1. Resolve all design-related backward-incompatible issues (better earlier then later)
2. Address the documentation issue (without proper docs language use does not seem realistic)
3. Fix show stopper bugs, establish solid test base (not just the core but the modules as well)
4. Everything else

My words. But this requires deciding which issues are to be addressed in the first release candidates which in turn requires something like milestones creation and assignment of issues to them (which in turn might require granting some GitHub priviliges to active Dao contributors).

[dumblob]

After the success at the OpenAlt conference in Czech Republic ("the developer heart of Europe"), I'm considering presenting Dao at OSS Víkend Košice in Slovakia on 22. - 23. 10. 2016.

@daokoder may I make a web page about Dao (subtly modified version of the archived version as discussed in #517 and #526 ) or do you have other plans? I'd like to show visitors the web page (it significantly strenghtens people's beliefs in the project).

[daokoder]

Recently I have setup a new website: http://daoscript.org. The content still needs update, but should be sufficient for introduction. Also, I recently has made some significant improvements and changes in the language and VM. I will open a new topic to discuss them.

[dumblob]

Well, I decided to skip OSS Víkend Košice due to time constraints, but had a talk at the OpenAlt 2016 conference. I decided to focus on new changes in Dao in the talk, so I've signed up only for a 30 minutes talk. It turned out to be too short, but I think the message was delivered.

Thanks @daokoder for not abandoning this great language and VM implementation!

[daokoder]

Well, I decided to skip OSS Víkend Košice due to time constraints, but had a talk at the OpenAlt 2016 conference. I decided to focus on new changes in Dao in the talk, so I've signed up only for a 30 minutes talk. It turned out to be too short, but I think the message was delivered.

Thank you for presenting Dao on that conference!

Thanks @daokoder for not abandoning this great language and VM implementation!

Even though I became occupied by other things and spent little time on Dao, I have never considered giving up this language. In fact, I often feel the itch of improving and perfecting it :)

[dumblob]

Even though I became occupied by other things and spent little time on Dao

I've already decided to found a SW company (3 people for the beginning) and for the main SW product & service I'd like to use Dao as backend language to speed up development significantly. The company is planned to begin it's function at the latest at the end of 2017. With regards to company funding, planning, etc., the current state of Dao development is the only bottleneck as it lies exactly in the gray zone of "unknown whether the most important issues on the Dao Issues page will get addressed soon enough or not at all".

In fact I'm willing to pay anyone in the world (especially including you @daokoder) who would like to contribute regularly (or even on demand in case of bigger issues) to Dao. I'm though still not convinced Dao ecosystem is currently sustainable (which is a must have for the first two years of a new company) - therefore all my comments about project management and Dao direction in the past year. The company will by the way use also C for system programming as well as a little bit of Lua and then minimal bits of web Javascript, Android Java, and iOS Objective C.

[daokoder]

I've already decided to found a SW company (3 people for the beginning) and for the main SW product & service I'd like to use Dao as backend language to speed up development significantly. The company is planned to begin it's function at the latest at the end of 2017. With regards to company funding, planning, etc., the current state of Dao development is the only bottleneck as it lies exactly in the gray zone of "unknown whether the most important issues on the Dao Issues page will get addressed soon enough or not at all".

Interesting, I also decided to start a company that will develop software products on top of Dao (through the visual programming thing I mentioned in issue #524). It will start to function in the next year as well. Dao and the development of Dao will stay independent of the company, but developing technologies and products based on Dao will surely stimulate the development of Dao. I expect significant improvements will be added to Dao in the next year (including improvements to address the issues).

In fact I'm willing to pay anyone in the world (especially including you @daokoder) who would like to contribute regularly (or even on demand in case of bigger issues) to Dao.

This is very nice. If my plan goes will, this will not be necessary for me. In fact, I plan to similar thing in the future to sponsor the development of some modules and tools. There might be one problem about this, it may be difficult to find other people who are willing to work on this, before we do some promotion on Dao and make it relative known. But the current state of Dao may be a bit premature for serious promotion. When I decided to start the company, I was also hoping to make it more production-ready before promoting it seriously, through using and testing it in real products.

[dumblob]

There might be one problem about this, it may be difficult to find other people who are willing to work on this, before we do some promotion on Dao and make it relative known.

Based on my experience with several universities (as well as companies) in Germany, Finland, Czech Republic, and Slovakia, I know at least three constant sources of people highly interested in programming language development & design while being capable of solving the hardest issues. With regards to them, there is though still one significant weakness I know about - the lack of their ability to design perfect APIs. I must confess, that you @daokoder are the best person for API (both external and internal) design I currently know in the world (especially when you get a sophisticated opposition from @Night-walker). In case you'd want to find such person, I can't unfortunately help much.

I was also hoping to make it more production-ready before promoting it seriously, through using and testing it in real products.

Judging based on the evidence I've gathered throughout my life, this is not needed at all and the approach "Release early, release often!" works the best basically under all conditions in all cases.

Dao as a project is already so functional and consistent, that occasional harm originating from some mistake will not affect the overall Dao status. Therefore I'm confident we should promote Dao everywhere using all possible opportunities without any postponement.

By the way, programming language projects which offer clearly worse APIs, capabilities, performance, usability, etc. (like Crystal and basically all others) are very successful just because they release early and often - there is basically no other advantage (a little bit of syntax & semantics similarity to a particular existing language increases the community, but it's not significant) over Dao.