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).
Yes... but another advantage here of lime over Portland cement is that the cooking of the limestone doesn’t require as much heat as the cooking of Portland cement. It won’t be carbon neutral, but it is a big improvement.
It is too bad more isn't done with lime mortars and plasters. Hydrated lime (CaO + H20 => Ca(OH)2) reacts with CO2 to form CaCO3 + H20. And it is fun to work with ...
That is me. I haven't seen much development effort since I switched to Rust. But ... I would still mentor someone who wanted to work on it or do something with it.
I wrote that on the Atom forums ... that's the editor in Open Dylan, which used to be Harlequin Dylan (and was Functional Developer after Harlequin folded and before being open sourced).
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. :)
Also, I need to get back to using your LittleLogs! I sort of traveled a few times too many last year and in the process, fell out of the habit. I will set a reminder to start it again once I'm back home on the other side of the world.
Maybe? (I'm going to leave where I am shortly on a 6+ hour drive. I'm on holiday in the US for another several days.)
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.
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.
In Open Dylan (http://opendylan.org/), we have a library of our own written in Dylan that lets us write out LLVM IR in binary files. We have to update it as LLVM changes, but that typically isn't all that bad.
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:
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.
* 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)