3,597 karma · joined December 11, 2011
* https://www.youtube.com/watch?v=BDSee1-4bUI (How to make...)
* https://www.youtube.com/watch?v=pfBGGuezus8 (Shiny Graphite Ball made from Clay and Graphite)
* https://www.youtube.com/watch?v=jG7wHTmKtjQ (Textures in Dorodango)
We still have a lot to learn!
It is also worth pointing out that the GP's comment was showing the chemistry for a lime-based concrete. OPC (Ordinary Portland Cement) based concrete is substantially different in terms of the chemistry and the amount of energy involved in the manufacturing process (due to the increased amount of energy involved in producing the clinker).
I had parts of Deuce up and running as a terminal-based editor at some point. Well, I didn't do input which is clearly a very important thing ... but I'd made good progress on the output side of things. :)
There are some branches on the repo with more recent work to get it to compile on other platforms.
I was talking with someone else last night that has worked on and with Dylan for the last 20 years or so over dinner.
He commented "I'm sometimes afraid to use Dylan as I don't know if someone will be supporting the compiler." I replied that "I'm afraid to support the compiler sometimes as maybe no one will use it."
That said, I've put some years of effort into it and have been actively maintaining the compiler for a while now. Now I'm building up libraries that I need for my green field project and working on some language changes to support that.
I'm now working on a 2-5 year time frame.
That said, if we got another like-minded hacker out of any attention, I'd fall over from joy. We have so many things that we need help with, especially things like type system work, but also plenty of easier things.
So, why?
Rather than point to any particular language feature or design aspect of the language (which are what originally drew me to Dylan), the thing that keeps me there now is that it is a green field.
If one has newer or different ideas about how things could be done or structured, this can't really be introduced coherently and consistently across a language ecosystem that is already big. I think Node did well at the start in part due to being able to build everything new with non-blocking I/O in mind. That's unlike the use of Twisted in Python which had a number of caveats when working the standard library (and now there are a number of other non-blocking I/O libraries).
The other side is that I do it because I enjoy it and we're building something good.
We do have some good language features (like multiple dispatch as someone else has mentioned), we have some pretty good documentation, our upcoming LLVM compiler back-end is generating good code, we have a good debugging story.
People start languages all the time. I find it best to just pretend that Dylan isn't an old language, but something new that is being created on the grave of Open Dylan. We're working on changes to the type system, the compiler, the libraries, and soon, I'll be starting in on some stuff that takes advantage of our green field status. We just didn't go and start a new language from scratch, but decided to build upon the massive amount of work and design that went into Old-Dylan.
It works with NanoVG, so it is useful in environments where you're already running OpenGL.
We have some macros and a bunch of functions then that make emitting LLVM IR simpler. For example, the "ins--iterate" and "ins--if" / "ins--else" macros in this code handle phi nodes and so on:
https://github.com/dylan-lang/opendylan/blob/05271f6fec9da05...
This library is currently in the process of being updated from LLVM 3.5 to current HEAD as debug info has changed significantly upstream. After that, we will be landing some documentation for it as well.
If you're interested in learning or hearing more about this, we're typically around on #dylan on freenode IRC.
Dylan allows sealing of generic functions to limit extensibility where needed and can use that information (along with other information) to optimize, generate warnings, etc.
define class <weapon> (<object>) end;
define class <sword> (<weapon>) end;
define class <wand> (<weapon>) end;
define class <person> (<object>) end;
define class <wizard> (<person>) end;
define class <warrior> (<person>) end;
define method wield (who :: <wizard>, what :: <wand>) => ()
...
end;
define method wield (who :: <warrior>, what :: <sword>) => ()
...
end;Unfortunately, it isn't clear at all where to best obtain the sources.
Since Google Code is going read-only soon, it would be nice to have a canonical location outside of there.
In 2010, there was a post on the mailing list:
https://groups.google.com/forum/#!topic/strongtalk-general/S...
But that GitHub repo has been idle since 2010:
https://github.com/talksmall/Strongtalk
It seems other people have also tried exporting from Google Code to GitHub as well:
https://github.com/szKarlen/strongtalk https://github.com/rvedam/strongtalk https://github.com/rmacnak/strongtalk https://github.com/Michaelangel007/strongtalk https://github.com/DmitryVSkiba/strongtalk https://github.com/emanuelpeg/strongtalk https://github.com/liutanyu/strongtalk
At that point, I got distracted and moved on to something else of interest at the time.
Open Dylan (http://opendylan.org/), a Lisp-like language without Lisp-like syntax, also can use Boehm or the Memory Pool System.