Development status?

74 views
Skip to first unread message

Sandy Maguire

unread,
Jan 1, 2014, 10:24:05 PM1/1/14
to magpi...@googlegroups.com
Hi all,

I'm looking for a project to contribute to as part of my new year's resolution, and was thinking Magpie would be a really cool candidate -- but AFAICT the project seems dead (github page hasn't seen any activity in 6 months, outstanding pull requests, no groups activity, etc). Is this indeed the case, or are things just on the down-low currently?

Thanks,
Sandy

Mathnerd314

unread,
Jan 2, 2014, 12:29:24 AM1/2/14
to magpi...@googlegroups.com
I think this document answers it:
https://github.com/munificent/wren/blob/master/doc/site/qa.markdown#what-about-your-other-languages

"Magpie is a trickier one. I really really like the ideas behind Magpie. It's the general-purpose language I wish I had most of the time. I love patterns and multiple-dispatch. I like how it integrates the event-based IO of libuv with the simplicity of fibers.

But it's also a much more challenging project. As a general-purpose language, there's a ton of library work to do before Magpie is useful for anything. It has some unresolved GC issues. And I'm frankly not skilled enough right now to implement multiple dispatch efficiently. Meanwhile, since I started working on Magpie, Julia has appeared and Dylan has reappeared. I was really astonished at how much Magpie had in common with Julia when it came out. I created Magpie partially to carry the torch of multiple dispatch, but others are starting to spread that light now.

I think I have a greater chance of success with Wren, but that doesn't mean I don't still love Magpie and want to work on it. I tend to rotate through projects. I rarely abandon them forever, I just take long breaks. Ask me about my roguelike sometime."


-- Mathnerd314

Bob Nystrom

unread,
Jan 11, 2014, 10:42:00 AM1/11/14
to magpi...@googlegroups.com
Yup, that's pretty much it. I'm also currently focused on finishing writing a book I started several years ago: http://gameprogrammingpatterns.com/.

Cheers!

- bob

--
You received this message because you are subscribed to the Google Groups "Magpie" group.
To unsubscribe from this group and stop receiving emails from it, send an email to magpie-lang...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Mark Janssen

unread,
Jun 3, 2014, 3:53:23 PM6/3/14
to magpi...@googlegroups.com
> But it's also a much more challenging project. As a general-purpose language, there's a ton of library work to do before Magpie is useful for anything. It has some unresolved GC issues. And I'm frankly not skilled enough right now to implement multiple dispatch efficiently. Meanwhile, since I started working on Magpie, Julia has appeared and Dylan has reappeared. I was really astonished at how much Magpie had in common with Julia when it came out. I created Magpie partially to carry the torch of multiple dispatch, but others are starting to spread that light now.

Before you worry about "library work", contact me.  This is the same issue which made Prothon fall (an attempt at making a new language similar to Python).  If you design the language right (with a unified data model), you won't need complex libraries because you will be making mash-ups apps of many, loosely-coupled, modular components.

A programming language with many complex libraries should be seen as a indicator of a [design] failure of a language, *not a bonus*.    ***Trust me or ask me until you understand this.***

Mark


Message has been deleted

Bob Nystrom

unread,
Jun 9, 2014, 12:55:36 AM6/9/14
to magpi...@googlegroups.com
On Tue, Jun 3, 2014 at 12:53 PM, Mark Janssen <dreamin...@gmail.com> wrote:
Before you worry about "library work", contact me.  This is the same issue which made Prothon fall (an attempt at making a new language similar to Python).  If you design the language right (with a unified data model), you won't need complex libraries because you will be making mash-ups apps of many, loosely-coupled, modular components.

A programming language with many complex libraries should be seen as a indicator of a [design] failure of a language, *not a bonus*. 

I'm having a little trouble understanding why "many loosely-coupled components" is good, but "many complex libraries" is bad. What's the difference?

- bob

Reply all
Reply to author
Forward
0 new messages