Cakebrew: The Mac App for Homebrew
cakebrew.com
cakebrew.com
This software may be version one and still have some kinks to work out, but I love it anyway. Nice work!
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.
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.
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.
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.
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?
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.
If you don't like the GUI or want to combine into scripts the command line is always there behind the GUI.
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.
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.
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:
http://mercurial.selenic.com/wiki/CommandServer
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.
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.)
Thanks for posting this.
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.
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.
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.
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.
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.
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.
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.)
> 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.
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).
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.
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.
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.
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.
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.
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.
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.
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:\> C:
C:\> win> 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.
I just find this topic interesting. I haven't used AutoCAD in many years, so don't remember what it looks like at all. :)
On OSX, that's what applescript libraries are for.
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.
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.
It raises an interesting question - is it still a command-line app if it uses curses?
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.
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).
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.
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!
Is it just the $99 fee or is there some other reason not to sign it?
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.
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.
https://github.com/brunophilipe/Cakebrew/releases/tag/v1.0.2
Again, nobody has answered what the problem is with signing the installer. What gives?
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.
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.
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.
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.
Ah, now it makes sense.
When I homebrew, there's alcohol involved.
For somebody with an aversion to the command line I think the only reason to use Homebrew would be Cask.
Should just be "Too afraid to use the terminal"
[1] https://aroch.io/cakebrew.log (Sorry for the self-signed cert...)
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!
I'm just surprised I can't 'brew install cakebrew'.
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
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?
I know what you mean (I've had problems with a few things), but those are problems with the formulae, not Homebrew itself.
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.
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.
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.