Hi! Author here... actually it does use unicode (which we'll use to mean non-ascii at the moment, even though ascii is part of unicode (pedantry, pedantry)) for the starfield at the moment, those are braille characters so that it can have "smoother" and more fine grained movement of the stars. The frame around the game also uses non-ascii characters. However I'm planning on adding two modes: one that uses no unicode characters and is pure, and one that uses more unicode for a larger variance.
I tried being moderately conservative for the moment because I'm not sure which terminals support what! (Admittedly the recent addition of starfields in git master stepped away from that a little)
Hi, Chris Webber here. You're quoting my blogposts out of context.
Yes, the standardization process was a difficult one. Standards efforts often are, and social web ones especially. Nonetheless I think we did a good job.
The purpose of those posts is to ask people to stop fighting each other and try to work together; it feels highly ironic for you to quote them to increase division.
- Yes, there are some quirks in the standard library, but overall most of it seems very well designed. Having spent a bunch of time in Python, which also has a standard library with I'd argue even more quirks. But most Racket libraries seem very carefully thought out IME; I'm not sure that something this old can not have some weird oddities though.
- We used DrRacket to teach a class to students who had never programmed before. What's amazing is that a) the students picked it up quickly and immediately... what other lisp can claim having something like that? and b) it's the only editor that I myself am happy to use other than Emacs. That's an interesting and unusual overlap, and deserves a pat on the back.
Yes, Racket has its quirks, but what doesn't? It's still an extraordinary project, community, development environment IMO.
What kind of machine do you have where DrRacket functions at an appropriate speed? Does it run better on Windows, maybe? It's noticeably laggy on my desktop with 5GB RAM free, a fast quad-core processor, and a fast SSD.
I like the design and the ideas it has for teaching, but I can't imagine it being usable performance-wise on the kind of machines that schools usually purchase.
It's one person doing the recordings and has been the same the last few years iiuc. They were just under-resourced I believe, and last year especially. They're doing a damn good job given the constraints they've been putting things together under I think.
I haven't gotten a chance to update the website style since I set it up about 13y ago... it indeed could use a number of css tweaks to be usable on mobile devices, which weren't really available when I set it up.
FFI into C++ is a lot of work in any language. A lot of projects just define a plain C wrapper for the C++ code they want to call, and call that C code from whatever their glue language is.
However, Python does have CLIF[1], which is the nicest solution for calling into C++ that I'm aware of.
I think the biggest thing, for me is Cython. I've not seen anything quite like it in other languages. It allows you to compile python code to c, with gradual typing. It also allows you to write c code inline w/ your python or interface with other C/C++ libraries. https://cython.org/ Other languages will be pressed to beat its utility (esp in the scientific computing world)
pybind11 is a modern version of the Boost Python approach to Python bindings. Header only and can be installed trivially from PyPi.
I like it well enough that I even use it for binding C code. Especially because it has nice numpy array support (albeit a little underdocumented).
It’s the 80:20 rule, which naturally doesn’t always holds. Often, however, a small part of the code is responsible for almost all of the performance issues.
By picking the performance sensitive areas of the program to code in C one can often code the rest of the program in a slower more convenient language.
I've found that Typed Racket is still fairly hard to use. For example, type classes aren't there, and type polymorphism interacts poorly with general-purpose functions like "equal?". I would guess that ML or Haskell code translates fairly naturally, but there aren't the guide-rails those languages have to keep you in the subset of the language that type-checks well.
when i went through the coursera course "programming languages", i did part a in standard ml (what the course uses) but also in f# and in typed racket (using racket's pattern matching). the code was practically identical across all three languages. now, that's for someone simple programs, but i was surprised that the translation from two MLs was basically trivial to typed racket.
Hackett could really use some people who are excited about the intersection of lisp and haskell and want to build languages to join in on hacking on it :)
I think there are quite a few of those people... maybe that gives some hope for contributions
You are probably underestimating yourself. Imposter syndrome again? Building a language is a major undertaking and I’m sure the help would be appreciated.
I dunno, given https://github.com/lexi-lambda/hackett/issues/98#issuecommen... (saw this when it was sent initially because watching the repo). Knowing one's limits is not necessarily imposter syndrome. If I were to acquire the knowledge (say by reading my recently acquired copy of TAPL), I'll revisit this.
Hackett pushes the boundaries of the Racket macro system, and IIRC through its development has found a number of deficiencies/bugs (I may be misremembering this, however, so don't take it as absolutely true). Besides that, Haskell is a rather complex language, so undertaking the creation of such a thing is no small task. And then we have the issue of
what my own personal knowledge is.
I really hope development once again takes off! Its such a cool project. But I know I wouldn't have the first clue of the right way to do certain things that I know are outstanding.
Hi jordigh! (Historically) lead developer and co-founder of MediaGoblin here (and ActivityPub spec co-author/editor, so I have more than a bit of insight/bias I think).
You're not wrong. And neither is the parent post! MediaGoblin is in "unofficial retirement", but that's because we made progress unexpectedly in other ways, which is good, but not where we realized we were going. Allow me to lay out what happened and what the history is here.
About four (or was it five?) years ago, MediaGoblin was still a very active project and a lot of it worked, but we still didn't have working federation support. At the time we were looking at a lot of different protocols and it wasn't clear which approach was the right one, but Evan Prodromou had written up the Pump API document: https://github.com/pump-io/pump.io/blob/master/API.md
Even though pump.io didn't have the highest uptake, it seemed to have the cleanest design and addressed many issues that OStatus had. Evan did StatusNet which is what's also now called GNU Social, and has done more work to advance the federated social web than anyone else, and given how clean the design looked and that I trusted Evan, I thought this was the right approach. So we used the funds from the second crowdfunding campaign we ran and hired Jessica Tallon, who had written PyPump (and understood the practical details better than me at the time, I was learning as I went), to do the implementation. We got as far as getting MediaGoblin and Pump.io to talk to each other and pump.io clients to even work on MediaGoblin.
But there was still a problem... nobody else was using the Pump API but our two projects, and at this point all these different projects on the fediverse were speaking different protocols (and sometimes not even compatibly speaking the same protocol)... what I would call in talks as a "fractured federation". I heard Evan Prodromou mention he was going to be co-chairing the W3C Social Working Group and I asked that Jessica and I could participate, and we were brought in as what are called "invited experts". At this point Erin Shepherd had transformed the Pump API document into a prototype W3C spec document called "ActivityPump" and that was the direction Jessica and I got pulled in to.
There were a lot of smart people in the group, and my assumption was, they probably all knew what they were doing and I told Jessica "we can just show up for an hour a week to make sure they're on track and doing what we need and then we can focus on MediaGoblin". I didn't know the phrase "revolutions are run by the people who show up" but I certainly do now... Jessica and I got drawn in as co-editors of the ActivityPub standard. We had raised enough money from the second crowdfunding campaign to pay Jessica for a full year (I didn't take any money from that campaign) but we stretched it out to two years by Jessica and I contracting for Open Tech Strategies part time (great people, btw). This was helpful because when one of us was working on standards stuff, the other person could do some work on MediaGoblin as a project, and there was a lot to do.
But as time went on and deadlines became more urgent, standardizing ActivityPub grew more and more in time consumed. Eventually it became my full time job; I would work 40-50 hours a week on ActivityPub and do 10-20 hours of contracting on the side to pay the bills. It was clear we were doing something important and there was a real opportunity.
But ActivityPub grew to three and a half years of standardization work and as I said, we only could stretch out paying Jessica for two, so she had to find paying work and it wasn't possible for us to split our time to manage both. In the meanwhile, even though all this stuff was happening for MediaGoblin, I found less and less time to work on the project. Even worse, Gitorious (which we had previously been hosted on) went down, and we were unsure where to move to. A community member volunteered to do the work to move us to Savannah and we took it. MediaGoblin wasn't using Gitorious's issues/merge request tools anyway; the way people would make contributions is make a new git branch, publish it anywhere, and then link that branch on the issue tracker where we'd do the code review and then eventually we'd merge it in. In that sense we were already using git in a more distributed manner (the way that git was intended I'd even argue)... but actually I do think we lost something in the move from Gitorious to Savannah. What we lost is that many people didn't know where to host branches, and Gitorious (along with many other such services) tend to offer a one-click easy process to fork, where you don't have to learn or debate over how/where to host things if you don't already have a preference. Our server infrastructure also languished... we previously had some volunteers helping with the infrastructure but they ran low on time, there was a server migration that went badly (it's still in a bad state tbh), spam filled up our wiki and trac instances, and it was all a huge headache that I didn't really have time to deal with. And I wasn't there to help steward the project the way I used to... I did appoint a co-maintainer (Breton) who did great work but I guess I did help drive a lot of the energy for the project and so when I stopped working on it actively, the community languished. We went from dozens of active contributors to practically none over the course of ActivityPub's standardization.
It wasn't clear that it was worth it; towards the end of ActivityPub's standrdization it looked like we wouldn't even make it and I thought I wasted years of my life. Then Mastodon picked it up, then Peertube, then etc etc and we suddenly had dozens of ActivityPub implementations. It turns out it was worth it, and finally we had a fediverse that did talk to each other. It turned out MediaGoblin did make a large contribution to the federated social web, but it wasn't in the way I expected... it was a driving force, rather than the project people ran.
Still, afterwards I came back (and with a more strong sense of how finite and fragile time is than ever) and I had to debate: should I pick up and run full swing with MediaGoblin again? The project could pick up and with effort, merge the languishing federation branch, I could try to drum up excitement in the community again, we might even make it.
But the webdev world shifted and so did I. IPFS and Webtorrent didn't exist when MediaGoblin started, and Peertube did the smart thing of integrating those into their project and it felt like they handled our ideas better than we did there. There were also all these other projects (Pixelfed, Funkwhale) which, while not delivering all the media types in one package (why the heck not? I still don't understand that) which seemed to be doing the same thing we were and actually were already federating... with the protocol we built for our own needs with MediaGoblin no less! And web applications aren't typically built as request-response type systems any more (and I for one was tired of it and had become disillusioned for my interest/belief in for Python being a great asynchronous language), and I just didn't feel excited about the codebase anymore. What to do?
I had another idea, and I called up several of my closest free software friends to make sure that the path I was suggesting wasn't an awful one. The main success I have had turned out to not be in the applications I built but in the way I showed how to grow distributed systems, and I now understand even the deficiencies (but how we can improve building on the base we have) on the current federated social web. So that's where Spritely came from, and why I'm building it as a series of demos (more here:) https://dustycloud.org/blog/spritely/ (first documented demo here:) https://gitlab.com/spritely/golem/blob/master/README.org
So what lead to MediaGoblin's "unofficial retirement"? I think that it's both true that
a) the standardization effort of ActivityPub, while done for MediaGoblin, accidentally lead to a loss of energy in MediaGoblin's community
b) there was a falloff in code/infrastructure hosting and other challenges related to that
c) other projects picked up on what MediaGoblin was doing and arguably did it better, using ActivityPub even, and finally
d) I still believe there are serious problems and deficiencies in the current federated social web that are addressable, and so I started the Spritely project to document and demonstrate a path forward there.
You could focus on just any one of those, but I think the story is clearest when it's told all together.
Anyway, it's free software! If someone is interested in revitalizing the project and community, I'm still interested in that happening.. maybe reach out to me and we can figure out how to continue. I'm easily found: https://dustycloud.org/contact/
Would you consider copying this to a blog (or maybe the Mediagoblin website)? Seems like a lot of valuable background/history that I'd hate to see buried forever on HN.
Hi. Co-editor of ActivityPub here. Nothing about ActivityPub's design is Twitter-esque specific. In fact it largely comes from pump.io's design which is much more Facebook-like than Twitter's design. We also built ActivityPub so that Diaspora could use it. That's the whole reason collections are addressable, in order to be able to handle the design of Diaspora's aspects.
I'm curious about your thoughts on https://github.com/denschub/schubio/blob/master/_posts/2018-... and https://github.com/denschub/schubio/blob/master/_posts/2018-... specifically. As someone who is new to both the Diaspora* and ActivityPub protocols, the Diaspora* patterns of publishing messages seem to be much easier for me to reason about particularly for semi-private FB-esque social networks (as opposed to mostly public social networks akin to Twitter or Youtube comments). My reactions echo what is mentioned in those links, but maybe I'm just thinking about it wrong.
I tried being moderately conservative for the moment because I'm not sure which terminals support what! (Admittedly the recent addition of starfields in git master stepped away from that a little)