Hacker News new | past | comments | ask | show | jobs | submit login
Cakebrew: The Mac App for Homebrew (cakebrew.com)
308 points by ingve on April 29, 2014 | hide | past | favorite | 144 comments

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 switched to Tower for git a couple years ago, and seeing people struggle with diffs and rebasing on the command line makes me sad.

This software may be version one and still have some kinks to work out, but I love it anyway. Nice work!

> 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.

>I'm talking the sciences here in particular

Heh, tell me about it. There are better programs out there but we still use some written 20 years ago because they have a UI.

This is startlingly true. The more I dive into development and open-source solutions, the more worrying this becomes.

Edit: to maybe relieve the concerns of downvoters: I find it worrying because there are lots of generally productive and intelligent people who will avoid command line tools as much as possible. These are some very good programmers. This means that tools as simple as Grunt are deemed to be "too much fuss."

I'm a big user and supporter of OSS, and I try and promote it as much as possible within my colleagues and peer group. I've had some success, but that's really another story for another time.

I was "volunteered" to maintain some old scripts that we use in the lab, some were written in Algol. The older the lab/institution the more worryingly old software is required by the researchers (Don't even ask about centrifuges that should have been retired almost a trillion revs ago).

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.

Hence on top of command line applications. The power and flexibility are still there for people who want them, but so are the GUIs.

> Hence on top of command line applications. The power and flexibility are still there for people who want them, but so are the GUIs.

You don't want the GUI to be "on top of" the command line. A CLI makes for a terrible piece of code to integrate with!

What you really want is for both of them to share a common library. The CLI should be a client of the library just like the GUI. Usually the CLI and the library will be developed in tandem (so you have an endpoint to invoke a new library feature) but keeping them separate is a good idea.

A typical CLI might make a terrible piece of code to integrate with. I wonder if you can design CLIs that are better to integrate with, though. To some extent, this is what Git's 'plumbing' layer tries to be, although i don't know how successful it is.

One advantage of building on top of the CLI rather than via a library is that it enforces the rule that any functionality available in the GUI is also available in the CLI. It also means that any functionality added to the CLI is also immediately available to the GUI. With the library approach, it's easier for one to get ahead of the other.

Mercurial has an interesting take on this - the command server:


This lets a process spawn a sort of daemon version of Mercurial, with which it can communicate via its standard input and output. Communication is a machine-friendly framing protocol which allows the parent to execute Mercurial commands. These are the same commands as you would use on the command line (interpreted by the same dispatcher, i believe, so really exactly the same). So, it's good code to integrate with, but exactly as powerful as the CLI.

The one real let-down is that the output is, AFAIK, the same as Mercurial's interactive output, which means the parent has to parse it with various command-specific regexps. If you were following this approach from the beginning, you would probably structure your CLI so that commands emit output in some structured form (eg a tree of named, typed values, or a table of named, typed columns), which is then rendered to the console somehow. You could then return a machine-friendly serialisation of that in command server mode.

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 lot of research out there that provides a lot of evidence that GUIs in general aren't slow, assuming they're well-designed; they feel slower to people used to CLIs and keyboard-driven interfaces, but when you actually measure objectively with a stopwatch the results tend to favor GUIs.

I think it's the second part of your statement about automating tasks where CLIs really have the advantage. For GUI programs to be automated they have to provide a scripting API much more complicated than just an input and output stream -- and then, of course, you need a scripting language to bind them. OS X's Automator is a really great glimpse of how that could be done in an entirely GUI fashion, but it also shows the limitations of such an approach -- most of which aren't in Automator itself, but the very fact that applications need to be written to support it. (Of course, some of the built-in actions let you run AppleScript or any shell language programs.)

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

And update/upgrade, and the occasional cleanup. It really is extremely simple, and I don't know why anyone would be using Homebrew if they're not already comfortable with the command line.

The modern programming movements, especially web development, have created many developers who can do (for example) some HTML, some CSS, a little bit of {Rails | Django | PHP}, a little bit of {Angular | JQuery | Ember.js }, etc. but are very uncomfortable with concepts/tools that a lot of hackers take for granted (using a command line being one example).

Not saying it's a good thing or a bad thing, just how it is (especially with things like programming bootcamps and associate degrees focused on quick web development). Some of us have been swimming in Linux and obscure hacker culture for decades, and we forget that maybe one doesn't need the huge entire body of knowledge we have to be productive employees in a certain capacity?

> Not saying it's a good thing or a bad thing

The tools we use are neither good nor bad. How well we use them, what we use them for and how we teach others to use them are what makes the good or bad.

I love the way you make this conversation good with a pragmatic point of view and an opinionated but reasonable voice. Thank you.

It's a bad thing.

IMO it has a really nice interface for a CLI. Lots of sensible colour coding and some of the clearest instructions/error messages I've come across.

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.

I think the point here isn't that command line tools are more powerful in general, its that building a GUI gives that access to more users who aren't as comfortable with the command line.

If you don't like the GUI or want to combine into scripts the command line is always there behind the GUI.

That's fair. Sorry, my "GUIs rule" knee jerk reaction flared up. There are a lot of bad GUIs that can give the illusion of helping users, but place upper limits on what you can accomplish. I have been frustrated by various hacked together UIs on top of Linux package management and wrappers around source control tools.

No worries, I understood where you're coming from. I partly agree with you: I switched to git at the command line from tower because I wanted to script some features (and understand the tool better), but having the GUI there made it easier for me to get used to git in the first place. (though admittedly, tower is one of the good GUIs which make it easy to do a simple task, too many of them do the opposite)

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.

Commando sounds a little like explainshell.com. It was a part of A/UX, an Apple UNIX which I never knew existed. Screenshot: http://toastytech.com/guis/aux3.html

Thanks for posting this.

I think Platypus will work for this on modern Macs.


> 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.

A toddler can pick up and learn to use an iPad in an hour or two.

That will never, EVER be true of CLIs, no matter how well designed.

Your perspective on this subject seems to be from an extremely narrow viewpoint that ignores the actual real world outside of your own use cases.

A toddler also can't operate a letterpress, solder, or fly a plane. Your point?

There are designers who worry about designing for toddlers, but that's a very specific niche, not at all representative of the average computer user. Hence my comment was not concerned with designing software interfaces for toddlers. Of course I wouldn't advocate using a CLI for an application meant for toddlers.

(My perspective on the subject comes from someone with a graduate degree in HCI, papers published at major ACM conferences, and who has shipped dozens of interactive software titles in the past decade (including some that have, surprisingly, been destined primarily for toddlers). I'd love to pursue a constructive conversation, but your ad hominem makes it hard.)

I apologize—I suppose I am somewhat irrationally offended by your seeming disregard for the biggest advance in user interfaces in the history of computers, the graphical touchscreen. Especially considering your position as an expert. GUIs have made computing available to the masses—not just to experts—and that is incredibly important. And touchscreen interfaces have accelerated this advance.

> A toddler also can't operate a letterpress, solder, or fly a plane. Your point?

My point is that you are focused on a very narrow set of use cases (e.g. operating a letterpress, soldering, or flying a plane). For the vast majority of computing tasks, a (possibly touch-based) GUI interface is ideal. Yes, CLIs are better for some things, but those things are a tiny minority.

> There are designers who worry about designing for toddlers, but that's a very specific niche, not at all representative of the average computer user. Hence my comment was not concerned with designing software interfaces for toddlers. Of course I wouldn't advocate using a CLI for an application meant for toddlers.

But I take it from this that you WOULD advocate using a CLI for email, social media, shopping, instant messaging, reading a magazine, designing buildings/airplanes/computers, audio recording and production, data visualization, doing your taxes, operating points of sale, etc., etc., etc.

(And now I imagine that you will try to convince me that a CLI is actually better for one or more of those things. I am unlikely to believe you.)

GUIs are better, not because they are more efficient, but because they are intuitive. People can understand them, so they can actually use them effectively. Being able to use an inefficient tool is vastly better than being unable to use an efficient one. Focusing on intuitiveness has opened up computing to the entire human race, instead of just an elite few.

The word "intuitive" is casually thrown around when talking about interfaces, and yet it has a very specific meaning in HCI, far from what most people believe. As posted in another comment: http://www.asktog.com/papers/raskinintuit.html

I don't deny that GUIs have their uses, and that there are certain use cases where they do outperform text-based keyboard-driven interfaces. But the reality is that those use cases are nowhere near as overwhelmingly numerous as GUI proponents make it out to be, and that for the vast majority of text driven tasks (including email, instant messaging, engineering work, doing your taxes, operating points of sale, etc.) they are superior in most regards. Note that I do not advocate abandoning all graphical tools on the computer - you're naturally always going to need an image editor, a video player, something to edit 3D models, etc. The framebuffer is always valuable; GUIs, not so much.

On top of that is the consideration that a lot of our computer use these days converges in the browser, which is a very unusual beast altogether. We originally designed the browser to view documents, and it has now evolved in a weird steam machine that does pretty much anything and everything. It's problematic, because the web is notable for being "disrespectful" of concerns such as accessibility to handicapped users. (note that the best citizens when it comes to such matters, such as Hacker News, Wikipedia, Reddit, and quite a few others, aren't that far off from purely textual interfaces)

Obviously it's going to be hard for me to convince you otherwise in a HN comment. That being said, if you have a genuine interest in the topic, I recommend that you read Jef Raskin's "The Humane Interface", and Ted Nelson's series "Computer History for Cynics". They're a good introduction that allows one to think about the design of computer interfaces independently from the GUI mindset that has imposed itself on the profession over the past couple of decades. The modern GUI (which is really Xerox Parc's GUI) is really not all it's made out to be, and there are many compelling things about the alternative branches (check out for example Plan9, for something completely different).

Xerox Parc's GUI changed the world in the Macintosh and Windows, bringing computing to the masses.

The iOS-like GUI changed the world again in the iPhone, Android, and the iPad.

The reason they did is that they were better. Not because they were pretty. You seem to be convinced that these paradigms were not massive improvements on their predecessors. I'm not sure how you manage to maintain that view.

What makes them better is that they are visual in nature. Human beings have an immense amount of latent machinery to help us deal with visual things. Literacy, on the other hand, is an incredibly recent phenomenon. Interfaces that are based on words for communicating semantics instead of primordial visual cues like space, size, contrast, color, movement, etc., will never be able to compete on intuitiveness/ease-of-use/ease-of-learning.

Problem I have with most touch interfaces (and to a wider extent the whole closed iOS ecosystem) is that they still have to show how they actually improve productivity. So far all we've seen is dumbing down the "user experience", turning computers from a productivity and creativity device into a pure media consumption device, glorified TVs basically. This is much much worse then the BASIC home computers of the 80's.

A CLI is more productive, generally while a GUI is more fun. They each have their own use cases. A CLI has an inherent learning curve no matter how great the API, a GUI requires physical interaction delaying potential working.

"Better" is a very subjective thing.

I had the unique experience of growing up with a PDP-11 in the house.

I could load the disk drive, type in my username and run commands on the command line to run the pac-man game.

You're (a) underestimating toddlers, (b) overestimating how difficult the command line is.

People really just don't learn it because it looks scary and isn't full of colorful pictures.

> People really just don't learn it because it looks scary and isn't full of colorful pictures.

This is so obliviously insulting to non-experts. The truth is that we geeks will waste hours of our time learning an obtuse interface because we LIKE doing that, but most people don't have time for that kind of thing. It's not that they are scared of apps that don't have "colorful pictures." It's that they have GOOD TASTE and aren't willing to waste their time learning a non-intuitive interface. They'll take their business to someone who has more respect for their time.

> This is so obliviously insulting to non-experts.

No, it really isn't. My point is that the command line isn't actually all that difficult. It takes a little more memorization up front, though that hardly makes it only for "experts" (but that seems to be how it mostly settles out in the real world).

I think many people consider the standard GUI to be self explanatory, but, having had to teach some older people how to use a Mac or and iPad, I've found it really isn't. It's only intuitive if you already know how GUIs should work—coming from nothing it's just as impenetrable as a command line prompt.

> No, it really isn't. My point is that the command line isn't actually all that difficult.

For you.

> It takes a little more memorization up front, though that hardly makes it only for "experts" (but that seems to be how it mostly settles out in the real world).

Hmmm, that pesky "real world."

> It's only intuitive if you already know how GUIs should work—coming from nothing it's just as impenetrable as a command line prompt.

Seriously? This is significantly overstating the case. Yes, you still need to learn some things to use an iPad. But the learning curve is orders of magnitude less steep than that of the Unix command line. The empirical evidence is against you here.

Try teaching those same "older people" how to read and respond to their email on the command line and see how far you get in the same amount of time.

> Try teaching those same "older people" how to read and respond to their email on the command line and see how far you get in the same amount of time.

Again, you are overestimating the difficulty involved here. You type "mail" to enter the mail program. Then you hit the return key to read your next mail message. You can type "r" to reply, or "d" to delete it. Type "q" to quit.

It's really not that hard.

This is true in the context of 2014, yes, but it's not necessarily historically true. My mom was basically computer-phobic before I got her an iPad in 2010, but in the '70s and early '80s, she was flat-out amazing on an electric typewriter and word processor. The word processor (a designated terminal, not a software package), was basically a really terrible command line with awful CP/M style menus and lots of complex key bindings. That, my mom could do. Windows 95-XP? Scared her shitless.

Another example. My mother-in-law worked at AT&T and then Bell South after the breakup for over 20 years. In the late '70s - late '80s, everything she did was on UNIX boxes. My husband literally spent parts of his childhood in data centers late at night while his mom did systems work.

My mother-in-law is very smart, but I still have to walk her through some stuff on a Mac or iPad. (And the Mac was a huge step for her, apparently she really struggled with Windows), yet at 74, this woman can still do UNIX commands and work in a shell in her sleep.

My late-Aunt was an engineer at CSX for 33 years. During the Year 2000 crisis, she was one of their senior COBOL leads (she got her CS degree in '74) and did a lot of the infrastructure work to fix those mainframes. But I remember her struggling with certain more "basic" computer skills, at least in the context of a Windows GUI.

It's about what you learn on. When I was in high school and college, I worked as a tech at a big box retailer, I would often have elderly people come in upgrading old machines, frustrated that they couldn't get the version if WordPerfect of Eudora or whatever to run on XP or whatever. Most of the time, those old programs were I intuitive by any standard, but it's what they knew.

If you grow up on a command line and continue to evolve what you use and try new apps, platforms and paradigms as they crop-up (which is the case for most if us here), you may not recognize the importance a first-system plays in future skills and usage, but it does. And that's why it's important to consider that the people growing up today won't enter a world where they type commands and wait for an output as SOP. Sure, some will learn those methods out of interest or for the efficiency that can provide, but people born today stwrt interfacing with systems very differently than we did generations ago, and that's why being aware of those paradigms is so key.

That doesn't mean you can't make something accessible that is CLI based - you can - but kids will enter pre-school knowing how to use an iPad -- and advanced usage too. It's the same way I was able to learn to program them VCR at 4 before I could read more than Dr. Seuss.

Our software needs to be accessible for them to use, because we're past the era of GUI being too expensice to program for or requiring too many resources.

You have an IT Corporate there

His original statement was:

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

Toddlers are not part of the engineering world...

A toddler can learn an ipad true, but it should be clear to any parent that they understand a "command" far earlier. it's no wonder the first baby sign language phrases they learn are "more" and "all done".

Problem is that iPads/touch devices in general don't scale up beyond non-toddler tasks. It's painful to watch someone do something simple as their email on an iPad. Even copy-pasting something from one app into another is hilariously involved.

Not as hilariously involved as doing the same thing on the CLI.

Well, the simplest form of copy-paste on the command line is piping output from one command into another, just a single character '|'. But I was mainly talking about iPad-style single-window touch-control environments vs. keyboard/mouse multi-window desktops.

    A:\> C:
    C:\> win

I don't see why restricting yourself to an array of monospaced characters is necessarily a good thing. You can make an argument that keyboard control is superior to mouse control but there's no reason why a graphical app can't be controlled by the keyboard.

In fact, you can trivially make any existing interactive CLI app better by recreating it exactly in an X window and adding a few graphically intuitive elements like icons and nice rounded tabs/scrollbars. And you can use proportional fonts- it's been proven that humans can read proportional fonts more quickly than fixed-width fonts.


I think the best UI is a CLI-GUI hybrid; it has all the features of a GUI, so you can point and click if you want, but also a CLI you can type commands in. AutoCAD is one of the few examples of this that I think got it right; on the other hand, Photoshop is one of the applications I use regularly that could really benefit from having a CLI.

do you have other examples of GUI apps that have attempted this? (even if they didn't do a great job)

I just find this topic interesting. I haven't used AutoCAD in many years, so don't remember what it looks like at all. :)

The only other example I can think of are file managers (e.g. http://docs.kde.org/stable/en/applications/konqueror/cmndlin... ); CLI-GUI hybrids are definitely quite rare.

Pretty much any IRC application?

The world would be a better place with both better command line apps and beautiful graphical front ends. The former makes doing the latter easier, while the latter also allows you to work easily with the less wonderful command line apps.

> 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.

That's only one argument against command line apps. There's also ease of use, progressive disclosure, learning curve, the relative ease of recognizing and remembering versus memorizing, and so forth.

Out of curiosity, can you provide an example (or examples) of what you consider to be a well-designed CLI?

I would like to suggest mitmproxy as a well-designed CLI. It is a dream to work with and takes a little bit of effort to learn how to navigate but afterwards you fly around effortlessly.

There's no perfect example, but if all CLI apps had as much thought put into them as there is in Midnight Commander, then I think we'd be somewhere fairly good :)

I confess, I've never used Midnight Commander, so I thought I'd be a good guinea pig. I just installed it on my Mac and I don't find it at all intuitive. Two specific issues I had is that we're limited to displaying everything as text (e.g. what is ".[^]>" meant to represent? if it were a graphic, perhaps it'd be easier to understand), and also there's limited space in my terminal so commands are abbreviated (what does 'RenMov' mean? I can't 'mouseover' it to find out more information either–there's no way to interact with the app that might not also issue a command). Overall, it's left me with a vague anxiety I might accidentally delete a file.

This isn't meant to be a criticism of Midnight Commander anymore than it is a criticism of myself as a user. I have no doubt it's invaluable in certain situations. But I do think GUI apps offer clear advantages, and they're to be embraced.

Perhaps better would be the idea that all GUI apps should have lightweight CLI counterparts, to enable easier scripting/integration with a UNIX workflow, and be done with. OS-level scripting support is halfway there (e.g. AppleScript) but it could be better.

I agree with you that mc is far from perfect.

That being said, its goal is not to be 100% usable out of the box without reading any documentation. Rather, the goal is to offer a tool that, after a few hours of learning, can be used extremely productively and efficiently for the rest of your life. I have yet to see a single GUI file explorer that offers something that mc couldn't (and for that matter, I have yet to see a single GUI file explorer that offers a level of functionality anywhere near mc - for many features in mc, a GUI driven interaction would be detrimental to the tool).

Also, one thing to keep in mind when talking about interfaces is that "intuitive" is a very tricky word that doesn't necessarily mean what we'd like to think it means: http://www.asktog.com/papers/raskinintuit.html


To answer your specific point pertaining to mc:

> there's no way to interact with the app that might not also issue a command). Overall, it's left me with a vague anxiety I might accidentally delete a file.

You can press F1 for context sensitive help (you can also click on any interactive element in mc, if you really want to use your mouse!). And of course, every destructive action asks for user confirmation before being committed.

Thoughts like "what does 'RenMov' mean?" are totally normal (and also occur with GUIs for sure) - but knowing the answer takes you 30 seconds, and then you're set for life. Again, when you're considering the fact that this is a tool you're likely to use for thousands of hours over your life if you commit to it, it makes it a worthy investment. Sure, the OSX Finder doesn't take a few hours to understand - but the huge amount of time lost doing things in Finder.app (or explorer.exe or dolphin or nautilus or ...) that can be done in mc much faster pale in comparison to that learning curve.

A Curses GUI is still a GUI. Midnight Commander is a GUI interface to the file system that I only install when my mother has to shell into my server (it is definitely a good GUI, though.)

> A Curses GUI is still a GUI.

No, a curses-based UI is a text-based UI, not a graphical UI; it is distinct both from GUIs and from CLIs. It does share some characteristics with GUIs, sure.

I'm confused GuiA. You have spent considerable time and energy promoting your view that well designed CLI apps are "insanely superior", but you can't cite an example? And the closest thing you cite, MC, is a text-based GUI?

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.

> Until I can chain GUI apps together for my specific needs with some combination of pipes and basic logic

On OSX, that's what applescript libraries are for.

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.

Would it?

Pipes, for one, are not even a properd full featured stream implementation. Most of this power is for obsolete text-based processing.

And CLI interfaces are inherently inferior. There's nothing you can do in a CLI you can't do in a GUI (since the GUI can have an additional textual input interface for CLI commands).

But GUI adds full color-coding, image capabilities, direct manipulation of objects (with mouse, digitizer, touch, etc), discoverability of commands (they are there on your eyes), and tons of different ways to compose workflows and actions.

The only problem is that we don't have a generic GUI stream standard like we have Unix Pipes etc. We only have it for specific apps and domains (e.g Quartz Composer or any video NLE node GUIs). But than again, unix pipes are pretty contrained and specialized themselves. If you're not text-mangling there's not much you can do with the regular userland.

In principle you can add full colors, image capabilities and direct manipulation of objects to a shell, see for example IPython (the Qt-shell) or Mathematica. Ultimately any large enough GUI application will add scripting support, take autocad for example. There are arguably tons of simple applications that are simpler to use if implemented as command line tools, for example video/audio conversion, archival tools

>In principle you can add full colors, image capabilities and direct manipulation of objects to a shell, see for example IPython (the Qt-shell) or Mathematica.

Sure, but I'd call those GUI apps.

A GUI app can have textual command input, as it just needs a text entry widget to do so, but a CLI command can not have graphical elements -- since with CLI most people (including me) mean stuff that runs in a terminal, either with command line input or with some curses library.

In my eyes it is unfortunate that the terminal standard we are stuck with is dictated by a device designed in the 70s (vt100). There have been more advanced terminals, that had support for graphics and so on.

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?

Nice idea, but I immediately got a frozen app when trying to update formulae: http://i.imgur.com/3XDi0NA.png

EDIT: On further inspection, it did not only freeze... it broke a lot of my formulae. I'd be very wary of using this application.

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!

My first thought after clicking a single button. GCD threads are cheap and easy - just launch a spinner and start a thread, don't block the main one.

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.

Looks good but I'm curious, why is it not distributed signed with an Apple developer account? That means there is no kill switch Apple can flip in case it turns out to be malicious software. (Especially important for a package manager!)

Is it just the $99 fee or is there some other reason not to sign it?

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

Yeah, off of an open source repository on github that the community can inspect. But here you are being asked to trust a binary from some developer out there.

That's the reason Apple added this signing feature. I'm just wondering if there's really a good reason for a developer to not follow it.

>Yeah, off of an open source repository on github that the community can inspect.

That doesn't make it better. What if your internet connection craps out while it's downloading the line "rm -rf /usr/local/bin/old-binary" and it happens to stop at "rm -rf /usr"?


This is trivially fixable by wrapping the body of the script in a function which is invoked at the end. Homebrew's install script doesn't do this, but it's written in Ruby and all of the side-effecting statements are within a single block, so the worst that could happen is it could fail to print the message telling you that it's installed at the end.

Is it on a stream-and-run method of executing tasks? Surely it looks for an end-of-line or end-of-command terminator like "\n"

That's so sketch and dangerous.

Of course if you'd looked at the web page you'd see that you can do exactly the same here.


Why so condescending? I looked at the web page. The binary download is from cakebrew.com, not GitHub. You have to trust cakebrew.com.

Again, nobody has answered what the problem is with signing the installer. What gives?

You're saying that an Apple killswitch would be a good thing that users would want?

Yes, it is definitely a good feature. It's part of their security architecture. They figured out a way to allow developers complete freedom in distributing their software directly / outside of the App Store while still offering users protection against malware.

The point of the killswitch is to disable malicious software that someone tricked you into downloading off the internet and installing. That is the only thing it would be used for (and I'm not aware if it ever has.. maybe because it's a good deterrent).

It is not the same as the broader App Store approval guidelines. This is specifically for disabling malware, e.g. a bad actor tricking 10% of Hacker News into installing a malicious fork of brew.

I also want to make it clear I have no reason to believe this developer is anything but trustworthy. I just am curious why they decided not to sign it.

No, OP is saying installing an unsigned binary that is a package manager that has access to all of your system files is uncomfortable for some people.

I'd gladly fork it and replace it with a signed binary, but I'd want to ensure there isn't anything suspect in the project.

And seriously, I've never even heard of the kill switch being used for anything that wasn't malicious. Especially if it's not distorted in the Mac App Store.

Sorry, this was overly harsh on my part.

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.

That's only if it's in the Mac App Store. You can still sign an app (or in this case, a packaged script).

ETA: The malicious kill-switch obviously works on all apps, App Store or not -- but I'm unaware of any non-MAS app ever being "kill-switched" because of a customer dispute.

This is one of those things where I don't have any idea what's going on. I assumed from the title it was about using your Mac to write apps for your Mac. But reading the page I can't even confirm or deny that theory.

Homebrew is an OS X package manager. Most of Cakebrew's target market will be familiar with that, but agreed on the page not making it very clear.


A quick google search of 'homebrew' tells me: 'Homebrew — The missing package manager for OS X'

Ah, now it makes sense.

Hah, interesting and facetious way to LMGTFYing someone.

Thank you. I now feel less stupid. I could not figure out what the heck it was all about.

When I homebrew, there's alcohol involved.

Nice. Now add "brew cask" support (https://github.com/phinze/homebrew-cask basically brew for GUI apps) and I could see non-developers using it as well.

What's the point of homebrew cask? Why is it any easier than finding an app I need and installing it normally?

Same reason people love package managers in general. A single bash script can install all the programs you want. Add Homebrew Cask and even your GUI apps can be included in that script alongside wget, vnstat, whatever.

Makes sense to me! Probably not worth re-installing programs I already have, though, would you agree?

Yea, I only do a "brew cask search" for new apps I want to install. I believe you would want to avoid attempting to re-install an app via Cask that was installed normally (~/Applications vs /Applications). Personally, I would do a clean install to transition an app to being managed by Cask.

Hah, I was going to ask if they planned to add a formula to homebrew-cask so that I could use it to install Cakebrew.

I checked cask before I downloaded Cakebrew. :P

I agree. Isn't Homebrew primarily used to install CLI tools? Sure you have things like compilers/programming languages, but with the frequency that you install those types of things it doesn't make sense to use a dedicated app.

For somebody with an aversion to the command line I think the only reason to use Homebrew would be Cask.

Looks great! Small grammar suggestion: >Too much afraid to use the terminal

Should just be "Too afraid to use the terminal"

Or just "Afraid to use the terminal?"

Crashes on 10.8.5 [1] due to NSColor being used improperly

[1] https://aroch.io/cakebrew.log (Sorry for the self-signed cert...)

+1 Crashes on 10.8.5 on launching.

What can I do with this that I cannot do with the command line?

My use of brew is rudimentary, but I only ever use four brew commands:

brew install brew update brew upgrade brew uninstall

If this helps make brew more popular, then I think it is a great addition. It seems I am not the target audience, but hopefully one exists!

Maybe make it easier to discover features. I didn't realize you could pass options to brew install. If you do 'brew options package_name' you can see the options you can pass. For example, poppler can be compiled with glib support by running 'brew install poppler --with-glib'.

I'm just surprised I can't 'brew install cakebrew'.

Congrats, this is wonderful. Now I just wish someone would create a utility to sort out conflicts caused by running MacPorts at the same time (or a straightforward way to migrate to just one or the other).

    port installed > installed_packages.txt
    sudo port -fp uninstall installed
    sudo rm -rf \
        /opt/local \
        /Applications/DarwinPorts \
        /Applications/MacPorts \
        /Library/LaunchDaemons/org.macports.* \
        /Library/Receipts/DarwinPorts*.pkg \
        /Library/Receipts/MacPorts*.pkg \
        /Library/StartupItems/DarwinPortsStartup \
        /Library/Tcl/darwinports1.0 \
        /Library/Tcl/macports1.0 \
Then install equivalent Homebrew packages based on installed_packages.txt. It takes less time than you'd think.

Cakebrew is a godsend!! Starting using it now, I have to say I'm not disappointed!

Coming from MacPort, Homebrew actually is one of the simplest commend line tool I used to install an application on a Mac. Still, numerous occasions I had to spent a considerable amount of time troubleshooting warnings and library conflict issues. In situation that I need to setup development environment quickly such as PHP and Apache, Laravel etc, the last thing I wanted is more overhead.

I only wish something like this would exist for Composer, or is it already exist that I'm not aware of?

How will Cakebrew fix that?

I know what you mean (I've had problems with a few things), but those are problems with the formulae, not Homebrew itself.

Nice app, but it's in desperate need of threading. I get that it's launching brew and putting it's output in a panel, which can be slow, but it'd be better to kick off a GCD thread to do the work and update the UI when it's finished. The beachball is never a good experience, and every command I tried to run briefly beachballed.

This was my first issue with it too. It makes it feel clunky and slow. The UI is generally not that great anyway. E.g. updating and upgrading is too complicated. There should be one button to do it. And it should update automatically when launching.

The sheet that shows the output of an upgrade command does not have clickable links if something fails. It's also really small.

Even then always unfinished [PortAuthority for macports](http://www.codebykevin.com/portauthority.html) was a lot better. The GUI package manager for Mac OS X I liked best was [Fink Commander](http://finkcommander.sourceforge.net/about/).

Cakebrew looks like the authors have never seen a graphical package manager before.

Looks great, but brew is such a simple tool. It's one of the ones I don't think I need a GUI for. Maybe if I start installing lots of packages it will come in handy.

Looks good. Although out of all the CLIs I use on a daily basis, I'd have to say Brew is probably the easiest and most user-friendly.

I'm not likely to use this personally, but kudos for taking the time to make what looks like a lovely GUI to sit on top of HB :)

Congrats for the launch, fellow brazilian.

nice to see a programmer from central brazil for a change.

Finally! This is such a good idea. For non technical people that need specific tools this is golden. Great job!

Why only for 10.7 or later?

Very nice, thank you!

Oh look, Fink.

Glad it's so easy and simple to use. It looks great. What is it?

It's a GUI for Homebrew (brew.sh - OSX package manager; akin to aptitude or yum etc).

Oh I see! Not homebrew as in home-made software :D Now it all makes sense.

ok, I get it, I'm not part of the in-crowd. WTF is homebrew please?

And can we please stop it with the sites that blather on about stuff in a way that assumes every visitor knows the jargon and slang.

Even if you've never used a Mac, not knowing about homebrew is somewhat living-under-a-rock-ish.

Googling Homebrew comes up with

#1 - brew.sh, the homebrew homepage #2 - the homebrew github #3 - the homebrew wiki

It's really not that hard to figure this stuff out.

I should tell you to just google it, but you're also right. Lots of stuff that ends up on HN is actually really opaque about what the hell it actually is. See also, this item currently near the top: https://news.ycombinator.com/item?id=7669449

if you don't know what it is, it's probably not for you?

Is anyone else disappointed this thread is not about brewing your own beer?

Nice web page. What is it?

Downvotes noted. Apologies.

Really cool!

why do people find it necessary to add a GUI to every fucking thing

Because there are plenty of users who are not comfortable using a cli for even a few things. Homebrew specifically is a pretty core staple in the OS X community and this now provides more accessibility for those people.

Anyone else find the phrase 'King of the Forest' slightly cringe-worthy?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact