1x41: Second Lunch is my Favourite Lunch

Show Feedback
1

Jeremy Garcia, Jono Bacon, Bryan Lunduke, and Stuart Langridge present Bad Voltage, in which hell may be slightly chillier than previously. Featuring the uses for abundant graphical power, the nature of what "cross-platform" really means, and:

  • 00:02:15 Google announce Google Fi, a new MVNO-style mobile network joining together wifi, Sprint, and T-Mobile for US customers and allowing international roaming and a pay-what-you-need rate for data. Is this actually a good idea? What about how it only works on the Nexus 6?
  • 00:18:00 We speak to Mashable senior tech correspondent and podcaster Christina "@film_girl" Warren about the Microsoft Build conference announcement that the Visual Studio Code editor is newly available for Linux as well as other platforms, and MS's apparent increasing friendliness to open source. Is it real? Is it good?
  • 00:37:16 Bryan reviews the NVIDIA Jetson TK-1 development kit, a Raspberry-Pi-style small board but with 192 GPU cores
  • 00:51:12 A blog comment from Glyph suggesting that "Linux is not, practically speaking, more tweakable" than alternative desktop OSes starts a discussion about whether that's the truth and why Linux desktop automation tools aren't (or are) as good as AppleScript and Windows COM automation

Download the show now!

1 Like
3

Do you have a link to the dbus script editor you mentioned?

4

http://www.kryogenix.org/days/2009/02/11/more-thoughts-on-linglish/. However, the source was in my old svn server and I’m not sure whether that all got lost. The point isn’t really the source code, here, though (it would take some hours, only, to rebuild it); it’s the concept.

1 Like
5

Also, I think @bryanlunduke over exaggerated the state of AppleScript on modern OS X.

I say this because I have dozens and dozens of AppleScripts that I access and play with every single day.

Is it worse than it was OS X 10.5/10.6? Yes. Has Apple reduced their AppleScript support on their own apps (such as Pages and Numbers), yes. (They’ve also added back support for more AppleScript stuff in the latest versions of Pages and Numbers. And Microsoft still supports it in Office, so there’s that).

But it’s hardly WORSE than the lack of any option that exists out of the box/repo/package manager that Linux has.

My friend and Overtired podcast co-host Brett Terpstra is in my opinion, the ultimate Mac developer geek. Like, he’s your kind of people. Like, he’s back to using Vim because he grew tired of TextMate 2 and Sublime. Like, he created a Lorem Ipsum generator for TextExpander (a macro utility on Mac that can execute shell scripts, JavaScript and other text expansion amazingness. Love the app. Rely on it) that has movie quotes. He’s awesome.

Anyway, if you look at his Projects page, you’ll see a ton of various projects and one-off tools he creates. Many of them are scripted and while not all are in AppleScript – many take advantage of Apple’s System Services menu – and basically run shell scripts or use AppleScript as a way to call and get certain things.

Brett is coming up with new stuff like ALL the time.

So my point is that while Apple is definitely not pushing AppleScript forward – you can still do a whole lot with AppleScript.

One of my favorite snippets is using AppleScript to grab the URL and title of each open tab I have in Safari or in Chrome and to import it as a MultiMarkdown reference list. For my job as a journalist (from the corresponding lands of correspondents :smile:), this is totally useful when writing an article where I reference like 18 things and I want a list of all my links to easily link to as I’m typing in MultiMarkdown in my text editor.

I simply type “;links” to give me all my Chrome tab URLs and titles in a markdown list or “;slinks” to do it in Safari. I could do it with Firefox, but for that, Mozilla would have to build a browser that doesn’t still run like ass on OS X.

Just throwing that out there! It’s to as good as it once was on OS X, but AppleScript is hardly dead.

Also, if you’re a script junkie, Daniel Jalkut’s FastScripts is awesome.

3 Likes
6

I think maybe I should clarify my stance here. :smile:

First, I should say this: I think AppleScript is awesome. I used AppleScript for years – and it saved me a ton of time. I even really loved AppleScript Studio (which is basically AppleScript on top of Cocoa in XCode… sort of like a VB-ish dev suite). I felt passionately about script-ability and this was one of the main reasons I used when trying to convince others of the value of MacOS (and, later, OS X) – going so far as being on the MS Office for Mac team working, specifically, on the AppleScript dictionary.

That level of script-ability is something that all platforms should strive for. It really is a feather in Apple’s cap (or at least… it was). On a Linux desktop we have many of the components to accomplish this… minus two big things: A good, user-friendly script editing environment and easy to browse/search documentation on the available scripting API’s. We are, simply, lacking those things. That doesn’t make script-ability a technical impossibility on Linux… just less accessible to most people.

Over the years the situation on MacOS X script-ability (specifically consistently available, non-changing AppleScript dictionaries) has deteriorated. To the point that, in my opinion, we shouldn’t compare Linux to MacOS X in this area. We should simply embrace the technologies that we already have on Linux and solve a few of the shortcomings that are there.

The important point here is that @sil is wrong. Whatever we, as a group, decide to agree on… we need to stand firm on that point.

1 Like
7

Side note:

Bryan Lunduke only over exaggerates.

No under exaggerating. No moderate exaggerating. If I’m going to exaggerate… it’s over.

3 Likes
8

Precisely the point I’m trying to make here is that other desktop platforms have significantly deteriorated in this and they’re still better than us. And this is the stuff we’re supposed to be good at. @jeremy made the point that perhaps nobody needs this any more – mobile platforms don’t do it – and perhaps that’s the answer. But it’s a sad answer.

It also occurs to me that maybe in addition to D-Bus APIs one could use the menu items of an app, as the HUD did.

1 Like
9

It’s interesting you mention mobile platforms because ironically, that stuff is getting kind of awesome. See Tasker on Android and stuff like Workflow and Launch Center Pro on iOS – not to mention IFTTT.

The irony there is that all the work is basically being done by the indies (though some major developers are supporting x-callback and URL schemes in iOS) and the operating systems themselves aren’t embracing stuff as much as they could.

If you ever have the time, Federico Viticci from MacStories has some mind-blowing posts about how he has automated setups configured using Pytonista, Launch Center Pro and Workflow for iOS. I know there have to be people who similarly geek out over the myriad of Tasker integrations you can do on Android, I just don’t run in those circles as much.

Fear not - the future will be automated!

2 Likes
10

I was going to point out exactly this. I’d say the situation is actually a bit better on mobile than it is on Linux, which is a little bizarre.

–jeremy

2 Likes
11

I was asking this, but I don’t think it’s necessarily true. It’s possible people don’t think they want/need it, but that’s a different problem IMHO.

–jeremy

2 Likes
12

Oh, that’s a good point. Tasker is quite cool! I’ve played with it a bit, but I have yet to actually use it in any meaningful way.

There’s even a set of tutorial videos for it here:

And a good selection of plugins for it here:
http://tasker.wikidot.com/plug-ins-and-3rd-party

Anyone here actually use Tasker on a regular basis? I’d love to hear how people are using this (on a phone, tablet, laptop, etc.).

13

I really do disagree with that. Linux is profoundly automatable and scriptable. It’s just usually via the shell. Which, most of the time, is sufficient. But the lack of consistent script-ability on GUI-apps is, I’ll totally agree, less than ideal (bordering on the crappy).

14

I think this may be a cultural thing. In the old days, GUI apps on a free desktop were viewed with a certain amount of contempt: they were thin abstraction layers over the top of command line tools, used by those who weren’t studly enough to grasp the underlying terminal. And so GUI apps didn’t need scripting APIs; by definition one existed, because the GUI was just providing access to underlying components anyway. But that’s really not the case any more. And so, there’s no culture of requiring scriptability, just as we reach the point where we’d really like to have it.

2 Likes
15

We explicitly excluded server and command line on the show, so that bit was implicit in my comment.

–jeremy

1 Like
16

Now this is an interesting topic! Why didn’t we talk about this instead of the whole “compare scriptability to MacOS” thing? :smile:

1 Like
17

And, importantly, the shell tools are no longer necessarily the best in class. When GUI apps were just attractive presentation for essentially command line tools, the CLI tools were the best thing around by definition. But that’s no longer the case by definition, and it’s increasingly not the case at all. Audacity can do more than sox can. Chrome more than html5lib. Libreoffice more than pdftk. And even when these tools are scriptable (inkscape has a basic but quite useful command line API, for example) it is specific to that application and not discoverable. In other words, proprietary. It feels like we could be better.

1 Like
18

…this is like saying, “no, no, no! I am not a shitty cook, I just need two things: (1) cooking ability and (2) a kitchen”. :smile:

From my cursory research into this Apple provides the following:

  1. A standard scripting platform.
  2. A simple editor for (a) browsing interfaces in apps, and (b) writing code.
  3. While not entirely complete, a comprehensive range of apps that provide AppleScript interfaces.

On Linux, we have:

  1. A standard scripting platform (DBUS + different bindings).
  2. A simple app for (a) browsing interfaces but (b) not able to write code.
  3. A smattering of apps that provide DBUS interfaces.

Is Linux able to be better, of course, no one was denying that in the discussion - the point is, it isn’t as good today. Would be like it to better? Yes indeed!

The point being, and as @sil mentioned: Apple has deteriorated somewhat, yes, but it is still waaaay more comprehensive than what we have on Linux, and suggesting Linux is better or even equal, is just utter bobbins. :slight_smile:

19

More like…

“I’m a good cook with a complete, functioning kitchen and an expensive set of implements… but my cupboard is cluttered and I can’t seem to find the measuring cups.”

Linux has all the pieces and parts… except for the ones that provide ease in discover-ability (and, to a lesser extent, ease in usability).

That is, without even the slightest doubt, incorrect. Borderline bobbins. (I’ll stop short of declaring you as having achieved “Total Bobbins-ness” because your heart is clearly in the right place… you’re just applying blame to the wrong thing.)

Linux is profoundly more comprehensive and powerful in the area of scriptability – thanks, in large part, to the Unix/Linux history that Stu was talking about. The issue is one of ease of use and discover-ability. Which, I absolutely agree, are areas that need (significant) improvement.

20

…ease of use and discoverability… and consistency.

It is indeed possible to script at least some of our best of breed apps. But you have to learn each one individually. If you spend some time learning how to create and render svgs with inkscape on the command line, that’s great, but you’ve learned nothing about how to script audacity, or even sox. They’re all separately implemented dissimilar APIs, when an API exists at all.

2 Likes