jbrennan

Ireland springs to mind, and in fact has strong ties to Indigenous nations in the Americas for their similar struggles

This is a great point, and I’m curious to hear what would be better alternatives. Like obviously there’s something great about having online connections with other people, but how could we do it better without surrendering to some big platform?

hi, author here :) happy to answer any questions! it was extremely fun to write a little browser, highly recommend it

I’m actually not proposing shutting down any website that allows uploaded content, just large / public sites that require this sort of moderation. Not every site gets this stuff uploaded to it. The more private the network, the less need for this kind of company-led moderation.

As far as “worth it” goes, some people have to be exposed to it so long as we have law enforcement (but I’m certainly open to alternatives here). I’m not sure the train operator is a fair comparison, because seeing a suicide is an exceptional circumstance in their job, it’s not the norm. The content moderators, however, are sadly expected to be exposed to traumatizing content as part of their job description — it’s essentially the point of their job.

There are plenty of kinds of work we deem as hazardous to people’s health, and thus are either banned or regulated. I’m not sure if there’s a healthy way to expose people in these moderator jobs to the traumatizing content they face. It just doesn’t seem worth the tradeoff to endanger them like this.

I think there’s a difference that depends on scale and privacy. If your network is private (or something more akin to p2p / messaging) this is much less of an issue, especially if you have strong blocking controls. Users moderate themselves.

I think the problems that Facebook, Youtube, etc are seeing stem from the fact that the content is much more public, thus in much more need of moderation.

In my opinion this is an argument in favour of shutting Facebook (and every other large social network) down. This sort of work is damaging and abusive, and nobody should have to endure it just so we can have social networks.

I understand there are some jobs in the world that need to deal with dark stuff (like law enforcement), but social networks just aren’t worth the human cost.

See also Mark Miller’s excellent blog post on the same topic, which really turned on a few lightbulbs for me: https://tekkie.wordpress.com/2010/07/05/sicp-what-is-meant-b...

I think this line of reasoning is victim blaming. It’s not the author’s fault that Instagram works the way it works. I think she’s entitled to want them to do a better job.

Yeah, it’s too prevalent. We best not talk about it.

I think most people grow up missing their actual potential as thinkers because the environment they grow up in does not understand these issues and their tradeoffs....

This is the meta-thing that’s been bugging me: how do we help people realize they’re “missing their actual potential as thinkers”?

The world seems so content to be an oral culture again, how do we convince / change / equip people to be skeptical of these media?

Joe Edelman’s Centre for Livable Media (http://livable.media) seems like a step in the right direction. How else can we convince people?

Great article although I think it’s worth mentioning the pattern of checking the iOS system version for method availability (e.g., `if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 8.0)`) should be avoided.

I think it’s a better practice to query the object in question if it responds to the desired selector. This way, if the method ever goes away (in say iOS 10), you won’t send the wrong message to the object/class.

The one thing I wish Objective C (or other languages, too, unless I’m missing some [totally possible]) is that the abstractions of metaprogramming are often hard to follow. You get to a point where you’re working entirely with abstract symbols (method or class names, for example), and it becomes difficult to track down problems.

I’d love to figure out a nicer way to deal with this.

Sean, I’ve read some of your research and it’s great! I agree completely. Hell, even the concept of “to create software means some set of sequential steps” is presuming quite a bit. Although I don’t have too much experience creating software otherwise, I at least acknowledge we really barely have any concept of what we’re doing and what’s possible.

Author here: Funnily enough, I have! I wrote the Super Debugger which uses F-Script (http://shopify.github.io/superdb/)

Please note though this is not at all what I’m describing in my essay. A REPL is hardly a graphical, direct manipulation drawing tool for creating software.

But it was fun to dip my toes in more dynamic waters.

Author here: you are correct.

Author here: Objective C is far and away mostly used for creating user-facing software. I want a better way to do that. That’s what the essay is about.

Author here. Please try not to get too caught up on the interpreted part. It’s far less important to what I’m trying to get across here in the essay. Yes, implementation matters, but what we’re implementing matters more. And don’t ignore the benefits of being interpreted, like having a more dynamic runtime. Being able to modify a system without needing a recompile cycle is a huge win.

See also more thoughts on the essay: http://nearthespeedoflight.com/article/2014_03_20_assorted_f...

No not really. Ruby is a fine text language but it offers no benefits or advantages like what I described in the article, safe maybe a REPL. But we can have that already with the Super Debugger, for example.

Heh, which is similar to what I drew up a year ago, and even linked to https://github.com/jbrennan/ObjectiveNext/blob/master/langua... :)

Author here. Good point, they are not mutually exclusive. I do think however it's not in Apple's culture to significantly move away from C/ObjC any time soon. For the time being, they are getting by well enough as is today. I think they'll continue to slowly evolve the language, but I'm not so keen to wait for major changes, and I'm hoping to get others onboard with me.

>Every talk is for an audience, and it's the speaker's responsibility to say what the audience needs to hear. > >Wait, what?

I don't think he means what you're inferring. I don't think he's trying to skew anything or anyone, but instead emphasizing for all of his talks, he's trying to present a message in a way the audience should understand it. It's not about deceiving any more than a beginner's programming book (with simplified examples) deceives a beginner. It explains what they need to know, on their terms.

Author of SuperDB here. I think you should be able to embed most of SuperDB itself directly in Spark Inspector. I'm not sure how you're doing runtime inspection, but SuperDB already has most of the underlying stuff already hooked up. I think they'd make a lovely pair!

It's true some artists can already work with interactive media through code, but I think his greater point might be that we're selling every other artist short if they've got to express themselves in code instead of geometrically.

So while there are some who are currently exceptional to that rule, we're still leaving out a ton of potential art by limiting interactive art to code.

Definitely. But you're also not going to stand to gain as much from writing some of the tools I'm talking about, anyway.

There will definitely always been places where software efficiency trumps programmer efficiency, but for a lot of cases, it doesn't. It's still important, just not always the most important.

>Your approach is to optimize for developer productivity. Mike's is to optimize for machine productivity.

Yeah that's a valid point. And it's probably just my lack of experience in language design or just general naïveté. It seems like for most devices (modern smartphones, tablets, traditional computers) are fast enough that we'd be better served focusing on developer productivity in newer languages. Sure, they'll never compete with C in terms of efficiency.

Besides, I can still easily create terribly inefficient code in C ;)

I feel like you could do even better if you approached a language design from the other side, instead of focussing on the lower-level aspects to instead be thinking of higher level aspects. If I were designing a programming language, I would start with what the development environment would look like, what tools do I want to build to support development in the language, etc., and then build the language to support that.

It seems so often languages are built, and then the tools are an afterthought, things like debugging, visualizing program flow, code assist, whatever it may be. What if program flow (that is, what's going on inside the program) were in mind from the start, instead of something you try and add later.

Just my thoughts. Is this a feasible way to design a language?

Well maybe it's a bit of a generalisation, but I've studied at two different schools in Canada, and neither of them had these in their curricula. And I haven't heard of any other in North America which really do, either. I could be wrong, but I haven't seen any examples yet.

Definitely. And Super Debugger can be used just as well for IB projects too (some things you can't test out with IB, like a corner radius).

And of course, this tool isn't just for UI tweaking. It's for any kind of messages you might want to send to objects. It's an object spelunker.

I'm the developer and I did the design myself! (I'm not much of a designer, but I try to stick to the essentials. Typography, contrast, and direction)

Although I haven't attempted it, I'm guessing that example would also be possible with Super Debugger. It would require a different interface, but I think it's possible.

>One thing that isn't shown is that the code is simultaneously saved to a file within the Xcode project, so live tweaks and XCode project stay in sync.

That's one thing I've yet to solve for superdb but would really love to get figured out. If you (or anyone) has any suggestions on how to implement it, let me know.