For your use case I recommend buying a spec'd up PC, such as a gaming laptop or desktop replacement laptop.
Apple is forcing a segment of it's customers to abandon it's ecosystem to continue getting their work done . Their lack of reassuring response insinuates that macOS is a non-scalable toy platform.
I have no horses in this race myself, but if I had hundreds+ invested in Mac software and accessories, with no machines available on the market to handle my workload, I would be pretty bent.
Considering how all the tools you mentioned were written for and runs best on Linux, I don't buy your argument.
You'll have to leave a DE behind. Big deal.
Dude, are you seriously suggesting a laptop marketed for developers not be used by people writing and compiling code?
Seriously any project of decent size written in a systems language just consumes all the ram you can throw at. If you think this only happens to 1% of the developers, you need to step out of your echo chamber and see what other developers are doing.
I know right - it's like everyone has forgotten that Pro means "for professionals". And also forgot that the booming sales of the iPhone and iPad owe everything to the ecosystem of apps and content created on Macs.
People doing 3D, engineering simulations, computational bio and chem, financial modelling, yadda yadda, there are loads of people who can make use of every byte of RAM and every core for Real Work. So some guy can make websites adequately on a smaller machine - he or she needs to look up and realize that that's a tiny corner of what computing is about...
The number of people on this planet who need to have 16+ cores of CPU power on the tray table of an aeroplane could probably be counted in single digits.
i'm pretty sure his problem is only that the new mbp has the specs of a budged laptop, at best. Which is perfectly fine for most usecases, hardware has gotten pretty good over the last few years. still, shouldn't qualify as a 'professional' version.
This was on a small - fairly certain <1MLOC - codebase. I'm small fry. The only unusual thing would perhaps be having small enough compilation times (due to e.g. incremental compiles and small changes not rebuilding the world) for linking of multiple projects to overlap. Boost and the Linux Kernel, noodling in at closer to ~20MLOC, or VS2012's ~50MLOC, might spend more time compiling in their typical edit cycles.
> Expecting Apple to completely gimp the macbook for the average pro user (dev, photoshop, video editing)
I suppose I'm having difficulty here seeing how a small weight and size increase for more DDR chips, or a larger battery, is going to "completely gimp" the macbook. Since I already touched on dev - I'll let someone else touch on video editing: https://www.youtube.com/watch?v=eJtrQ5CcCN0&feature=youtu.be... . Things will only get worse on that front as 4K becomes popular.
> They can't cover all use cases, but they can cover most.
Agreed. I'm just not sure they have covered most "pro" users.
Xerox PARC had, effectively, a simple version of what we consider "Personal Computing": word-processing, E-Mail, laser printers, software development, proto-Internet. Alan Kay claims it was less than 20KLOC, and that's a plausible figure considering the Alto had 128K RAM and a 2.5MB disk pack.
MS Office alone is >400MLOC. That's 20000x the code, or 20KLOC^2. There is no way it is 20000 times better or more useful. However, let's assume for the sake of argument that it is 100x better/more useful (something I'd consider dubious, but it's a good upper bound). That still leaves a factor 200x unaccounted for. Or 99.5% of the code.
TBL's first web-browser was ~5KLOC, took him a couple of months to write, in his spare time IIRC. It included editing. NCSA Mosaic took a team of five one year to complete, was 100KLOC and did not include editing. The current (last time I checked) version of Firefox is 13MLOC. Is it 2500x better?
And if you think compile-times are the biggest problem with multi-MLOC code-bases, you're not paying attention.
As written, I'm running into issues in <1MLOC codebases, on hardware just a touch more limited than the max spec of Apple's latest line. The 1MLOC equivalent would break on Apple's hardware, I'm sure. So, no - I don't think 20-50MLOC code bases are to blame.
> Xerox PARC had, effectively, a simple version of what we consider "Personal Computing": word-processing, E-Mail, laser printers, software development, proto-Internet. Alan Kay claims it was less than 20KLOC, and that's a plausible figure considering the Alto had 128K RAM and a 2.5MB disk pack.
It's fine and all to pine for the good old days when computers were simpler than the computer within even your lowly modern hard drive - which is itself inside your modern computer - all in the name of the ever increasing performance we today take for granted. But it's sheer fantasy to think we can support the cambrian explosion of hardware options out there since then (all from different vendors with different interests and standards) with the same sized codebases as we had back then. Simply working around the hardware errata will take more code for many individual pieces of hardware - much cheaper and easier to fix things in software than fab a new revision of chips and toss out all the old, after all.
Nobody's claiming linear relationships between source quantity and product quality. Nobody goes to an all you can eat buffet expecting caviar. Hell, most would argue an inverse relationship - the less code you have, the better you can polish it. But can a modern kernel work with thousands of times more unique hardware SKUs? Wouldn't surprise me. And hardware's expensive to design! If the hardware options out there can multiply by such magnitudes, take a fraction of a second to think what must have happened to software options - relatively cheap by comparison.
It's a miracle we're not measuring individual software projects in BLOCs. Yet - give it time. If such compatability, flexibility, choice, and performance concerns don't interest you - well, I'd be quite interested in what you found necessary to get your Alto talking to the HN website!
> And if you think compile-times are the biggest problem with multi-MLOC code-bases, you're not paying attention.
I have mastered the skill of caring about a second problem at a time. I've heard legends of masters who could care about a third problem, but I have no evidence nor belief in such myths. But yes - link-times are worse ;). And refactoring. And testing. Security. And...
Sure, but for most things, even that is somewhat ridiculous, and I mean both: having ~1MLOC code-bases and those being problematic. Elsewhere, I posted some number comparing tcc and Xcode's default cc (clang+llvm).
Tcc was able to compile+run a (synthetic, non-representative) 300KLOC program in 0.168 seconds. I didn't get a memory reading. cc took 9.3 seconds, so a factor 60. Would a 60x faster compiler work for you? The reason we don't have faster compilers is not that it's not possible, but that it's not a priority. And it hasn't been a priority because in the past performance sins were always covered up by hardware getting faster (by itself, without any extra work). This is no longer the case, increases in single core performance are over.
> It's fine and all to pine for the good old days when computers
> were simpler than the computer within even your lowly modern hard drive
I apologise if that was your take-away, because I obviously didn't make my point very well. However...
>all in the name of the ever increasing performance we today take for granted.
...that is not correct. In fact, in the spirit of Hans Bethe: "Ach, that isn't even wrong". Performance has also deteriorated in line with code bulk, and usually for no good reason whatsoever. There are a few good reasons, but they tend to be a small fraction of the whole problem.
To quote Wirth for the n-th time: "Software gets slower faster than hardware gets faster".
And nowadays, hardware really isn't getting much faster. Meaning we can no longer count on the hardware boys and gals to bail us out for our egregious sins. Software needs to get its act together.
Not if the resulting executable is, say, 10% slower. I could syntax check slightly faster, I suppose, but I already compile individual TUs for that. For testing, I need to test the actual build target. Also, the fastest comparison on http://bellard.org/tcc/ is a mere 9x faster on a real project. I wonder if they're doing better than 30% faster than GCC on the linux kernel since their 2004 numbers.
Also missing: C++ support. I no longer need PPC, fortunately.
And keep in mind: Despite kvetching about build performance, I make it even worse by running static analysis now and then, because that stuff is actually important to me.
> And it hasn't been a priority because in the past performance sins were always covered up by hardware getting faster (by itself, without any extra work). This is no longer the case, increases in single core performance are over.
Still getting wider, and still getting a little faster, but yes. I did get the memo about Moore's law "ending" a decade or so ago.
> Performance has also deteriorated in line with code bulk, [...]
Yes and no. Yes, more programs do more sloppy things that waste hardware performance now for little to no good reason (although I'll argue saving dev time can be worth it.) No, you cannot write a program that will efficiently unfold proteins on an Alto. No, you cannot make general purpose hardware that's as fast as a modern CPU or GPU with the Alto's fundamentally simpler design principles. No, you cannot efficiently and effectively use more complicated modern hardware with a similar line count as compilers and linkers for the Alto. No, really, the little computer in your hard drive really is playing a role in scheduling hardware operations to maximize your I/O throughput.
We're jumping through some really crazy complicated hoops in hardware to try and get more and more performance, and some of it requires hardware and software working in tandem. The minimum SLOC count to achieve our modern, expanded goals - even if you do something crazy like limit those goals to increased performance only - is absolutely rising for very reasonable reasons. Even if we assume most people 'waste' SLOC left and right, it doesn't follow that all codebases do, nor that all 'reasonable' codebases will be small enough to avoid problems.
Look, I get it, lean mean small programs kick some serious ass for a whole slew of reasons. I've sped up linking by a factor of 10x or so on some projects - on par with the 9x tcc factor above! - by switching from BFD to gold, with the latter focusing exclusively on elf binaries, instead of taking on BFD and all it's abstraction layers and non-elf target support. I imagine it's a much smaller program!
But I just told you the tradeoff: Specialization. I wasn't able to do this on all our target platforms, because not all of them even use elf. And, if it weren't for the fact that we were able to ditch BFD entirely, the total SLOC of our build toolchain would have, ironically, gone up from adding another linker into the mix as a result. Fortunately, I don't have to build our build toolchains - just any in-house ones. Our build configs did go up a few more LOC to override the defaults...
Unlike tcc, gold has not specialized itself to the point that it doesn't solve any of my problems, so it gets to join my toolset. I'm sure the reverse has happened to someone else. And plenty more deal with the situation where no specialized tool works for them. To ignore larger codebases requires you to ignore the generalized tools they fall back on.
> [...], and usually for no good reason whatsoever. There are a few good reasons, but they tend to be a small fraction of the whole problem.
An important distinction here: There's a lot of code that's absolutely useless, and has no good reason to exist... for solving your needs. This is very different from code that's absolutely useless, and has no good reason to exist. My pointless misfeature is someone else's core use case. And, it would seem, your pointless misfeature is perhaps my core use case.
And hey, that's cool. If tcc works for you, use it. But when people are using the multi-MLOC LLVM toolchain - it's not because software needs to get it's act together, but because it did get it's act together. I'm absolutely loving some of the tooling they're putting out, and wish I'd had it two decades ago.
And hey, perhaps current hardware performance sins (cough16GB max memory in 2016 for that pricecough) will be covered up by future software optimizations (by themselves, without any extra work on Apple's part) :). I imagine it'll involve more code though.