
Cakebrew: The Mac App for Homebrew - ingve
http://www.cakebrew.com/
======
arrel
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!

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

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

~~~
GuiA
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.)

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

~~~
GuiA
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](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).

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

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

------
benburton
Nice idea, but I immediately got a frozen app when trying to update formulae:
[http://i.imgur.com/3XDi0NA.png](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.

~~~
astrodust
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!

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

------
abalone
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?

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

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

~~~
vhost-
>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"?

Oops.

~~~
bennyg
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"

~~~
vhost-
Curl will still pipe partials: [http://blog.existentialize.com/dont-pipe-to-
your-shell.html](http://blog.existentialize.com/dont-pipe-to-your-shell.html)

~~~
bennyg
That's so sketch and dangerous.

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

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

Ah, now it makes sense.

~~~
Goopplesoft
Hah, interesting and facetious way to LMGTFYing someone.

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

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

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

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

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

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

Should just be "Too afraid to use the terminal"

~~~
robotresearcher
Or just "Afraid to use the terminal?"

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

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

~~~
bigstueyc22
+1 Crashes on 10.8.5 on launching.

------
wcdolphin
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!

~~~
Cymen
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'.

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

~~~
mratzloff

        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 \
            ~/.macports
    

Then install equivalent Homebrew packages based on installed_packages.txt. It
takes less time than you'd think.

------
chenster
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?

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

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

~~~
orkoden
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](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/](http://finkcommander.sourceforge.net/about/)).

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

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

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

------
venantius
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 :)

------
swah
Congrats for the launch, fellow brazilian.

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

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

------
pknerd
Why only for 10.7 or later?

------
davidcollantes
Very nice, thank you!

------
kstop
Oh look, Fink.

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

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

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

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

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

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

------
analog31
Nice web page. What is it?

~~~
analog31
Downvotes noted. Apologies.

------
mokkol
Really cool!

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

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

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

