BruceM

The Nito Project on Youtube has 3 nice videos about this:

* 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)

There was a nice survey article last year: Coral restoration – A systematic review of current methods, successes, failures and future directions: https://journals.plos.org/plosone/article?id=10.1371/journal...

We still have a lot to learn!

https://link.springer.com/article/10.1007/s41024-016-0010-9 is a pretty nice discussion of concrete carbonation as well.

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 ...

It'll be interesting to see how much use Rust gets within Fuchsia atop the Zircon microkernel.

They have Ant Mobile! https://mobile.ant.design/

There's also Ant Design (https://ant.design/).

Have you seen http://www.margrave-tool.org/v3/ which builds on Kodkod (which came after Alloy...)?

It was relicensed as Apache 2 and GPLv2.

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. :)

Since you collect... be sure to check out the open sourced Harlequin MLWorks: https://www.ravenbrook.com/project/mlworks/ and https://github.com/Ravenbrook/mlworks

There are some branches on the repo with more recent work to get it to compile on other platforms.

I've occasionally wanted to run System3 again. I wonder what it would take (for OS X)...

We would welcome help from fresh eyes on improving that sort of material on the website.

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.

I do a lot of the work on and with Open Dylan.

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.

Blendish (https://bitbucket.org/duangle/oui-blendish/overview) is pretty amazing and lightweight (by itself).

It works with NanoVG, so it is useful in environments where you're already running OpenGL.

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:

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.

When writing extensions, you get full TypeScript typings for everything.

Dylan (http://opendylan.org/) does that via generic functions / multiple dispatch. The object system in Dylan is derived from CLOS from Common Lisp.

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;

The "Move to iOS" app is, to some extent, pointing out just how much of your data can be read by any application.

Dylan changed a lot after the early Newton days. The language changed a lot, but so did the execution environment. That evolution continues today as we're now working on moving to an LLVM-based compiler back-end over at http://opendylan.org/ (or chat with us in #dylan on Freenode).

LambdaMOO would be nice.