Hacker News new | comments | show | ask | jobs | submit login

Er...what?

The iDevices are completely orthogonal to whether a MBP is a "developer-focused" computer. I use mine for Android development (oh noes! locked bootloaders!), Web development, and Windows development about equally, and everything works pretty much flawlessly, with the tools I need kept close at hand. (Hell, I don't even use Quicksilver anymore, as Spotlight's gotten better and Quicksilver hasn't kept up to date.)

The Mac App Store is entirely optional and none of my developer tools except XCode come through it. MonoDevelop and IntelliJ I get separately, pretty much everything else comes through homebrew. Loads and loads of applications are sold outside of the Mac App Store, too, with absolutely no problems.




From ChuckMcM's original post: But for that company to exist, you have to pay for the products you use, and to get to that point you have to not be able to get something 'good enough' by hacking and slashing something else into shape.

Based on this and other things he said, I think Macs count as the "something else" that can be hacked into shape, since Apple is not specifically targeting all of your listed use cases.

I'm also not the only one who's extrapolated the recent trend of Macs more closely resembling iDevices to imagine a possible future in which Macs become appliances, and the developer-focused computer ChuckMcM envisions can come into being.


I agree — if an when Apple locks down OSX so that the only source for software is the App Store, that's when ChuckMcM's company can take off. I think there are enough people who are technically minded (no even necessarily developers) and currently use OSX because its a UNIX system that "just works" and can also run popular commerical software (MS Office and Adobe CS mostly). The day Apple does this I and others will need to buy computers from somewhere else — I think there's room for a company to fill that role.


This is exactly why I use OS X; thanks for stating it so succinctly.


I like my MBP for this as well, but the writing is on the wall. The Mac App Store is entirely optional now but I don't have any reason to believe it will continue to be that way. The App Store on iOS is not optional and Apple sees some benefit over Android because of that (well they define it as qualities), installing from 'outside' the Sandbox has only been getting worse.

So how about a development environment for Android in the 'cloud' ? How cool would that be, your files are in iCloud so you know they are safe, your tools are always current and compatible since you're just talking to them over web API, and you can pay for a months worth of access to the compilers and debuggers for cheap instead of wasting all that time to put together an open source environment or spending big bucks for the MSDN Library equivalent service. You can watch movies on your MBP while you are building the Android manifest and running regression tests on that thing in some cloud instance that spun up just for that one task and will go back to idle when its done. Click a button and blam! it's submitted to the App Store.

You may not realize it but that is the vision that is driving moving away from a computer that you hold and do things with, vs a 'viewer' into a service somewhere that is doing the lifting and "adding value" in other ways.

If you read the thread on the Lisp epiphany [1] then this is the same kind of thing. But rather than data is code and code is data the epiphany here is that if you have enough network bandwidth and its available 24/7, then it becomes just another bus on the backplane and where your "computer" is and where your "screen" and "keyboard" are becomes irrelevant. At the office we have folks who put their desktop computer in some room, out of the way, and using X have their 'screens and keyboard' on their actual desk, they do this because the desktop machine is modestly noisy (we have quite cases but its not silent) and really on a gigabit LAN you can't tell that your machine isn't under your desk anyway.

That is coming to the world, faster than you expect, and because it will be insanely more convenient for most people supporting the few people who want to do this 'locally' will fall by the wayside.

Step 1, you figure out how to present a interaction rich UX

Step 2, you figure out how to move most of the data into the network.

Step 3, you create tools that present the UX, process data in the network, and deliver the result.

Google Docs is crushing Microsoft office, services like Box.net, DropBox, and S3 are capturing more and more of the data.

Free startup idea: Github + APT, add a button to a GitHub like service that says "Build this for Ubuntu-x86-64-12.10 and give me the link to the package." Click the button, wait, then post the link to a modified APT

   apt-get install <URL>
All of the pieces for this exist, a couple of weekends coding can put it out into the world. Now if the packages can be built in the cloud, why does your machine need to be a 'computer' again? Build it then 'add this feature with apt' is a pretty powerful thing.

Probably won't happen for a couple of years at least but it will happen, too many people want it too, and too few will demand local compilation to keep it supported.

[1] http://news.ycombinator.com/item?id=4765067 - "The Nature of Lisp"


How cool would that be, your files are in iCloud so you know they are safe

My open-source stuff is on Github, sure, but none of my private code is. I run a Redmine+gitolite instance on a physical box in my house for my private and private collaborative projects (one on-site backup, taken daily and rolled over three days; one off-site backup, stored every week). My code stays local and on machines I control, and the same is the case for many other businesses. It's for that reason that I don't think what you're describing is likely to be so commonplace as to make local development "fall by the wayside" in the near future.

While I get where you're going, I admit I had to restrain an eye-roll at the idea that this will be "the thing" anytime soon if only due to inertia. A development environment for Android in the cloud would be "cool," until it breaks. I have a very overpowering need to control my toolchain and my environment and that doesn't mesh with what you describe. I find the situation you are describing to feel really fucking oppressive. Unsettlingly so.

(I don't see Apple locking down the Mac, by the way. I see Mac sales being cannibalized by iPads, but I do not see Apple, at least in the near future, killing its most attractive feature--flexibility. Both for developers and for consumers. I think Microsoft has a much better chance of offing the traditional desktop/laptop with WinRT, though I'm personally not a fan.)

.

I fully agree that something similar will eventually happen for a certain subset of development; there are certainly some developers to whom this no doubt sounds really awesome. But I think that, and I don't say this to be either insulting or patronizing, this may be a bit of projection on your part. This feels like a "Valley bubble" idea, a "wouldn't it be cool if" that ignores a lot of real-world use-cases. Even aside from the "ew, remote" factor for me personally, I think there are enough infrastructural hurdles to make this really difficult to do in the sort of timeframe you're suggesting.

But I am not the target market for such things anyway. I find "always-on" technology overwhelming. I find that my best development time is when I turn off the Internet and go sit outside and write code; I keep local copies of the Python manual, the Java APIs, and the MSDN library for that reason. (And my Mac is silent when I'm doing development work, FWIW.)

Perhaps I am wishcasting, but I don't think so. Here's hoping you're wrong. =)


"But I am not the target market for such things anyway."

I think we're more alike than you realize. My point is that there is much of what you and I do in our day to day development efforts that depends on the notion of "I own a computer, and I run these tools on it, and I get these results." And we can do that reasonably easily because even though our requirements are outside the mainstream (the target market as you put it) they are enabled because the piece work, the foundational stuff, is required for the target market, for now.

My prediction, fear, belief, what have you, is that the bulk of the 'investment' in terms of time and energy and thought power, will become more and more focussed on that market and worry less and less about what you and I are trying to accomplish.

Here is a milestone which you can look for in order to measure progress toward that future. When you see a GCC release which supports a system or processor where the only way to use it initially is through a remote API to some remote server with source code on some network accessible repository. The rationale will be

"We didn't want to delay releasing it for all the ports to 'catch up', most people can use it like this, installable packages for local OS'es will be available in a few {days/weeks/months}."

That is when you know that it has started changing 'faster' than people are willing to wait for the ports. Then the folks doing the ports will start to drop off because the number of people who use the port is dropping off because all the new kids just use the remote API anyway and you can do it from a command line as if it were running locally so why complain? But that milestone will tell you, to get the feature you want right now you have to use the remote version or wait for a port to come out. Here is a pointer to the source if you want to start porting it yourself.

Except the source will embed various network services which it can 'assume' are there, its the remote version after all, and you will have to code up an equivalent.

I've seen build systems like this, they are very powerful, I will buy you a beer and we can talk about the 'old days' when you could do development without having to be connected to the network. The kids will pity our backward ways. But the beer will be tasty as usual.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: