Cakebrew: The Mac App for Homebrew

> The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on.

I can't tell you how much I agree with this. Far too little engineering effort is spent on nice GUIs, especially for 'niche' applications (I'm talking the sciences here in particular), because the GUI doesn't add any functionality. It's true, but it sure as hell adds productivity.

In regards to homebrew specifically though, I think the 'brew' command line app is actually one of the better ones and is actually pretty easy to use.

Personally I loathe having to use any sort of GUI because in general its slow and I cannot as easily automate tasks to customize my workflow. There's a reason there are more command line tools and GUI tools, the command line tools can be easier to build. Compound that by the fact that a lot of engineers lack a certain design sense to create a beautiful easy to use GUI but they can build powerful command line tools.

I respect the people who take the time to put together a GUI that make the end users life easier, it undoubtably takes a lot if not more work than the original application to get right.

Is homebrew that confusing though? I thought it was much simpler compared to other CLIs. Primarily, all you do is search, install, and uninstall.

I'm going to have to disagree. Command line tools can be composed and allow you to do more than the original tool builder provided as well as make it easier to automate tasks. I find it very frustrating to work on systems when everything needs a custom GUI to interact.

It'd be great if more GUI tools were built with the same principles as command-line tools: modularity, interoperability, compactness, textually (in input and output), simplicity.

I feel the same way.

Amiga and environments like Smalltalk and Oberon spoiled me for GUIs.

I do master the CLI across multiple OSs, but only use them when I really need to.

I really like "commando" from the old macintosh toolbox. It allowed you to create a simple GUI for a command-line tool, complete with checkboxes and text and numeric entries and menus. It showed you the actual command arguments as you selected options, and when you hovered over an option it explained what the option would do. Obviously a lot of tools need a more specialized GUI, but for a lot of simple or moderately complex tools that are used infrequently, it's great. Instead of looking up the man page, you just open the GUI and have the options explained to you while you configure the tool.

> The engineering world would be a much better place if more people built beautiful, easy to use GUIs on top of the confusing command line apps we all rely on.

I'd correct that to:

The engineering world would be a much better place if more people built beautiful, easy to use command line apps

It can be done, although it takes a lot of effort to do well- and a lot of the developers who write CLIs* have very few notions of HCI design. As a result the vast majority of CLIs are inspired from programs that are decades old, and in which no thought was given to the interface, thus perpetuating the cycle.

When well executed, a CLI is insanely superior to a GUI on many fronts (with a few exceptions, naturally, such as image/video editing), and more respectful of the users. It is much more friendly to users with vision or motor impairments: any font and any color scheme can be applied, any method of text input can be used, text readers behave in a much more predictable manner, etc. And of course it enables scripting to a level that GUIs just can't compare to.

Ideally you'd have a well designed CLI for the users who want it & scripting, and a well designed GUI - but let's face it, doing both is a huge drain of time. If you're going to do one, then a CLI is much, much preferable.

On the usability scale, there isn't "CLI apps" on one end and "GUI apps" on the other. Some GUIs are extremely usable, some aren't; some CLIs are extremely usable, some aren't.

I am a staunch supporter of the idea that while GUIs became mainstream and CLIs were relegated to a niche position, it should have been the opposite. But we had mediocre CLIs and decent GUIs, so it's only natural that it went that way. Great CLIs would have been preferable on many fronts.

Traditionally, the main argument against CLIs is the lack of discoverability that GUIs afford, which is a very valid point. That being said, most CLIs don't make an effort to enhance discoverability, which makes the argument still valid, but a little unfair.

Ultimately, I fully subscribe to Jeff Raskin's argument that if you're going to build a tool that users will use on a daily or weekly basis, then it's better to build something with a steep learning curve the first few hours which then results in an efficient and effective tool, rather than something that any newcomer can master within seconds but that will be tedious for extensive use.

GUIs that you can master in seconds belong in smartphone apps that you will use a handful of times and then delete a few weeks/months later (this isn't dismissive- if there's a market for it, then it's legitimate). Powerful CLIs that are a bit rough the first handful of hours but become extremely powerful tool belong in your browser, your email client, your text editor, your calendar, and so on: tools that you expect to use for years, if not your lifetime.

* : In this comment, by CLI I mean any form of program that runs solely in a command line, but that also includes highly interactive apps built with ncurses etc. There are very, very few command line apps that are solely "type a command, get an output" anymore.

Until I can chain GUI apps together for my specific needs with some combination of pipes and basic logic, I'm inclined to disagree. GUIs can be really nice for specific apps, but they are often terrible as part of an easily repeated and fast workflow.

And the wider world would be a much better place if more people knew the command-line, the Unix philosophy and were able to unlock the true power of their machine.

I've never used Tower, but I haven't found diffs and rebasing on the command line to really cause me much trouble. I will agree that there is a segment of users who find such tools useful. I think part of the problem is that the segment of people who want GUI tools and the segment of people who build the underlying tools rarely overlap.

I agree, though I often use CLI tools due to many GUI tools have let me down. When something goes wrong with git at the command line, there is nothing hidden. That being said, it's a matter of trust - perhaps time to revisit some tools, as the few GUIs I rely on are ones I trust implicitly to do the right thing.

As a designer, I find command line apps to have exceeding beauty. Design is all about stripping away the unnecessary and producing effective work. Doesn't get much more minimal than that.

Amen to this. Coincidentally, I've been working on a GUI on top of git specifically targeting non-programmers. The goal is to give them an approachable subset of git, help them appreciate its power and potential, and provide them what I call lossless versioning which is missing in so many consumer applications. It's a fun challenge to identify and map git commands to actions that would be familiar to nontechnical audiences.

Did anyone ever use Norton Commander back in the DOS days (http://en.wikipedia.org/wiki/Norton_Commander). It was very well-designed and powerful, text-based, GUI for DOS. The only problem was that once you get used to the GUI, you become dependent on it.

I tend to agree, but all of it isnt available on your production machine, so you'll have to use the cli interface at some point.

It is one negative side effect of having not enough females in our industry. It is seen as "manly" to use the most painful tools available (What you use a graphical text editor? Sublime? Use emacs/vim or you are a newb).

I see the opposite, I see people struggling with Git when using different kinds of application (SourceTree and Tower)

Usually I end up helping them by using the command line. Sometimes I install ZSH first to get some nicer colors and autocomplete because they haven't even set that up yet.

Bit of a digression, but I use "tig" to interface with git on the command-line. It's basically a curses-based gui for git.

It raises an interesting question - is it still a command-line app if it uses curses?

This thing needs to use threads. It's almost embarrassing to not make use of that when facilities like Grand Central are readily available.

The app locked up for me beach ball-style when doing an update. There's no reason for this. Do not block the UI thread. Ever!

I updated and it looked frozen as well. After a long stroll the coffee shop, it appears to have came back and reported a successful update although the "Outdated" icon still shows the same amount as when it started. Regardless, I applaud their efforts.

Fair question, but keep in mind the standard Brew install is piping a shell script from curl.

Isn't the benefit of this that Apple can't flip the kill switch if they get into a dispute with the developer?

If I paid for a piece of software that was rendered unusable a week later because the developer didn't check the right boxes on a form, or because someone lodged a trollish complaint with Apple, I'd be quite pissed.