macOS deprecating scripting language runtimes, including Python, Ruby, and Perl - <AUTHOR> https://developer.apple.com/documentation/macos_release_notes/macos_10_15_beta_release_notes#3318257 <comment><USER2> Not surprising at all. It's become clear that what they've been doing with iOS all along is bootstrapping a new operating system. They started with Unix, not because Unix was optimal for what they wanted to do, but it's what they had and it worked well enough. Copland and Taligent and the rest failed because of Second-System Effect, which Apple was smart enough to avoid.

(As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.")

Whereas such features as "background tasks" were simply a natural consequence of the architecture of Unix, Apple didn't expose that on iOS. Now they've finally gotten around to designing the background task subsystem they really want, and it's not just an emergent property of the generic Unix way. It's built for protecting battery life and privacy. It happens to be built on Unix processes (right?), but that's just an implementation detail for them.

They've been gradually deprecating Unix for 20 years, and designing the OS they want. iOS and its App Store allowed them to kill off large sections of the old interface at once. I fully expect inside of 5 years for all of Apple's operating systems to drop "UNIX" certification and become almost unrecognizable as "Unix". They've got enough market clout now that people will port Ruby/Python/Perl to a non-Unix macOS, just as they port them to Microsoft Windows.

<comment><USER3>
        They've got enough market clout now that people will
        port Ruby/Python/Perl to a non-Unix macOS, just as
        they port them to Microsoft Windows.

Ruby on Windows is a nightmare.

To be specific, Ruby itself (the core language and core libraries) are pretty good on Windows. Great choice for a scripting language, or whatever else you want to do.

But libraries like ActiveRecord, Rails and their myriad dependencies are very very hit or miss on Windows and there's not a lot of support when things go badly.

A lot of the issues are simple - like dead simple. Lot of gem authors don't bother to make things like file paths (forward slash vs. backslash) system agnostic. Or the gems depend on compiled binary stuff like Nokogiri or ImageMagick and those are always a bit of an adventure on Windows.

If MacOS drifts farther away from Unix they will cease to be the platform of choice for many developers currently using it today.

<comment><USER4> The funny thing is I have been a rails dev for years and didn't even know it didn't work on windows because I have never tried and don't know any dev ever using windows.

<comment><USER5> That just proves you live in a bubble :) I never got into RoR because it sucked so much on windows and every single tutorial was OSX focused. I just sticked to alternatives that worked.

<comment><USER6> So which companies are actually doing RoR development on Windows? Do they also deploy to Windows Server (?) in production? I guess I live in multiple bubbles because I've worked for tech companies in several different major metros and I've never heard of this as a mainstream thing.

<comment><USER7> It is not like that. My point is that there's a barrier to entry to RoR that you should own a Mac. I gave up because my home setup is Windows based and I won't change it for the sake of a hyped framework or tool.

But none of this is surprising considering where RoR is coming from, I'm not sad or upset about it either :)

<comment><USER4> You don't need a Mac. RoR works perfect on Linux as well.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> With brew as the de-facto package manager for macOS this is a great move. Having Python and Ruby bundled with macOS is confusing when trying to install "regular" versions of the software through brew or other methods. Because the default installation can't updated without updating the OS, the system versions are not useful for most developers.

<comment><USER9> The down side to that is that ruby is currently required to install Homebrew.

<comment><USER10> There will be a .pkg for that, if there isn't already.

<comment><USER11> They seem to package a portable ruby already. [https://twitter.com/MacHomebrew/status/1136249501252038662](https://twitter.com/MacHomebrew/status/1136249501252038662)

</comment></comment></comment></comment><comment><USER12> This has been a topic brought up internally at Apple many times over the past decade. Glad to see it finally moving forward. Although I see the benefits to having a system-version of these packages.. if you're doing anything serious for production then the environment should be containerized.

<comment><USER13> Python and pip just being there is a huge advantage for newbies. I really think that part of programming is constantly ignored because all the decision- makers are not newbies.

<comment><USER14> It's honestly terrible for newbies. If they try to use it, there's no pip included. So then they easy_install all their libraries which installs things into different places than most python devs will be used to. Or they easy_install pip first. But even still, everything is installing to system paths, so when they try to install things it fails with permission errors. They find a stack overflow post that says just "sudo" everything and they go to town. And there's no way to reset anything when it gets borked either because it's the system install.

Compare that to "brew install python". Now you have the most up to date version, with the right permissions for your user, that you can always brew uninstall and reinstall later if you need a different version or a clean install.

<comment><USER15> _you can always brew uninstall and reinstall later if you need a different version_

That is the wrong way to do it. Just install pyenv/pipenv to manage different Python versions. It's dead simple to maintain system Python, Python 2.7x, and Python3.7.3 that way.

<comment><USER16> Wrong way? I've used this method successfully for years.

<comment><USER15> Sure you can do that, but why would you want to install and re-install different versions of Python depending on what you needed at the moment? Pyenv manages all that nicely. You can have 2x and 3x side by side without having to reinstall and uninstall anything.

<comment><USER17> > You can have 2x and 3x side by side without having to reinstall and > uninstall anything.

You can do that anyway, `python` is always Python 2 (except on Arch where `python` is Python 3 and the Python 2 executable is `python2`) and the Python 3 executable is called `python3`. `pyenv` is more for keeping multiple minor versions of the same major version (e.g. Python 3.6 and Python 3.7) around at the same time.

<comment><USER15> _`pyenv` is more for keeping multiple minor versions of the same major version (e.g. Python 3.6 and Python 3.7) around at the same time_

Actually, it doesn't have to be multiple minor versions, it can be any version–major or minor. It can even be Iron Python or Jython. Anyway, the point is that it's smart not to touch system Python on macOS. So when I run:

`$ pyenv versions`

My output is:

`system

`2.7.16

`* 3.7.3 (set by /Users/wyclif/.pyenv/version)

Dead simple and easy to use. Much better than overwriting and reinstalling when you need a different version for a specific project.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> I think this is great, but at the same time, auto-installing homebrew ought to be an option (perhaps enabled by default) when installing the "XCode command line tools".

Better yet, offer a "developer setup" app that sets up the command line tools, homebrew, iTerm2, updated bash/zsh, and more.

Apple would do best to pave the cow paths developers have already worn into macOS, especially when it comes to command line utilities. A dev setup app would just make it quicker/simpler and pave the way for newbies to get into development.

<comment><USER19> I think the second you start auto-favouring one particular tool you're in trouble. Why iTerm2? Why not Alacritty? iTerm2 is more popular now, but 5 years down the line when someone else has come up with a iTerm2 replacement how is Apple meant to decide to switch? Where does Apple draw the line on which tools to add and which to leave out?

It sounds like what you're really asking for is something like Ninite for mac, which I think frankly is safer to stay as a 3rd party thing, rather than Apple getting super-involved in choices that are going to be very user taste specific.

<comment><USER20> Yeah I don't see the need for any of this to be provided by Apple. I want the platform I'm working on to be minimal and agnostic, and let me worry about what tools I'm using and how.

If there's really demand for some kind of base developer toolkit, why not leave it up for a 3rd party to put together some kind of installer to set it all up for you?

<comment><USER18> > why not leave it up for a 3rd party to put together some kind of installer > to set it all up for you?

Because a potentially interested 4th grader likely won't ever know such a thing exists.

And even if she did, the teacher likely won't let her download and install it from the internet. But if she asks for permission to run a "Install Command Line Tools" app in /Applications/Utilities/ and check the "Install homebrew" option (or "Install MacPorts" \- I really don't care either way... perhaps provide options for both), that's far more likely to get a "yes".

<comment><USER20> In my experience kids are very tech-savy. I don't think the 4th grader who can't discover homebrew without a system setting for it is going to be able to do much with it once they've got the terminal open.

<comment><USER18> Kids can only get savvy with exposure. Those lacking certain privileges (like having a computer at home) likely haven't had any of that exposure.

I was only able to learn BASIC and the DOS command prompt because I was in a multi grade classroom, and an older boy (5th grader) whose mother paid for him to have programming lessons taught me on the classroom computer.

The teacher had no clue about any of that... she only knew I started spending "too much time" on the computer.

</comment></comment></comment></comment></comment></comment><comment><USER21> I'm trying to understand how these two points reconcile. "Future versions of macOS won't include scripting language runtimes by default" and "Use of Python 2.7 isn't recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won't include Python 2.7. Instead, it's recommended that you run python3 from within Terminal." If Catalina is the last version with any scripting languages at all, why bother with the second point? Or will python3 still be available in the future despite point 1?

<comment><USER22> As I understood it, scripting languages will still be available to the user, they just won't have ancient versions preinstalled. Of course that also means you can't rely on them being installed at all as a developer.

Which means you should start bundling the stuff you need to run your app, and, they'd like you not to use the same ancient batteries as they have previously made available, because, well they are ancient.

<comment><USER21> Ok, I guess it's worded vaguely enough to allow for the possibility of optional installation ("by default"), even though they don't outright promise that they'll offer a way to install it. (I interpreted it in the same way as "macOS doesn't include Photoshop by default".) Having it come from the app store doesn't seem totally appropriate since it would need to do more than dump a bundle into /Applications, like making some /usr/local/bin symlinks. Maybe they'll allow themselves that exception.

"they'd like you not to use the same ancient batteries as they have previously made available, because, well they are ancient" \--> Right, I couldn't figure out if that's all they meant. Valid point or not, it doesn't seem appropriate to make it in the context of those notes. If you're going to make me bundle the language anyway, don't _also_ give me a lecture about which version to use. :)

<comment><USER23> I suspect they plan to distribute the scripting languages the same way they currently handle the command line developer tools package, where the OS offers to download and install the package the first time you try to run one of those tools.

<comment><USER21> I just don't see the win of that over supplying the thing with the OS in the first place, _unless_ the commands to do it are a nascent versioned ecosystem along the lines of brew, apt, etc.. It seems like the whole point of not supplying them with the OS is to make the versions less tied down. If there's some opaque command to get an arbitrary version, that's not going to help anyone.

</comment></comment></comment></comment></comment><comment><USER24> Probably the right call - many of them don't have abi or api stability guarantees, or in the case of python needlessly broke backwards compatibility that is still causing pain today.

Apple used to ship an incredibly old version of OpenSSL because people used its API which was not ABI stable. Even getting rid of it was a nontrivial amount of work.

The lack of care about API&ABI stability in developer facing open source projects (interpreters, libraries, frameworks, _commandline arguments_ ) is still bizarre to me: why make your work hard to use/update? People ship out of date libraries because updating requires changes beyond just pulling a new binary requires more work than the gain will give them.

It's part of why companies like Apple and Microsoft care so much about backwards compat: they want people running the most recent OS possible, and they don't want people to avoid updates. Every time an update breaks something for anyone, they hold off updating in future.

On the other side, developers don't want to invest time and money into a feature that they don't think will work/cause their app to crash in future.

<comment><USER25> _It's part of why companies like Apple and Microsoft care so much about backwards compat_

Compared to (former) Microsoft, I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility.

You can create a single .exe that will work on any Windows starting from Windows 95 - nearly 25 years. In that timespan, Apple changed CPU architectures twice, and their OS architecture once. If you're willing to restrict yourself to 32-bit Windows, which can run Win16 and DOS apps too, then it goes back to the early 80s.

<comment><USER26> Completely true. Apple only cares about back-compact down to a few older major versions. So often the big projects (like modern apps, Windows 10 S, etc) Microsoft does fail or struggle to gain traction IMO because of the blessing and curse of their back-compat requirements.

<comment><USER27> I think Apple has the right formula. The do put the effort in to maintain back compat to a certain point, but they also aggressively deprecate and remove within a few years of the arrival of a replacement technology. So you get the benefit of things not suddenly breaking, with the benefit of the whole ecoystem moving forwards. If that means old unmaintained software is left behind, then so be it. The right balance I think.

</comment></comment></comment></comment><comment><USER28> Seems like a good move. Less cruft and don't have to deal with managing versions between the one you want and the one already on the system.

<comment><USER29> I can't recall using the built-in version in ages, it is pretty much always homebrew before you even start. So I think this is a great move.

<comment><USER30> How is homebrew installed?

<comment><USER31> [https://brew.sh](https://brew.sh)

<comment><USER32> Right...

         /usr/bin/ruby -e ...

<comment><USER11> Homebrew comes with a portable Ruby in the install script. [https://twitter.com/MacHomebrew/status/1136249501252038662](https://twitter.com/MacHomebrew/status/1136249501252038662)

</comment></comment></comment></comment></comment></comment><comment><USER33> Fucking _finally_! Between this and deprecating Bash [1], I'm glad macOS is dropping all these obsolete packages it's been including (Emacs soon?). Their antiquity mean they're more of a hindrance to proper development than help.

Now, if they'd officially endorse one open-source packaging solution as an alternative, I'd be fully satisfied.

[1] [https://news.ycombinator.com/item?id=20090193](https://news.ycombinator.com/item?id=20090193)

<comment><USER34> MacPorts has or had semi-official status. It was hosted by macOS Forge, which was an official Apple site that included other projects such as XQuartz. I'm unclear on the current status.

<comment><USER35> Its a shame MacPorts kind of died on the vine. It just seems so much cleaner and less hacky than Homebrew.

<comment><USER33> It's not dead! [1] I use it daily, and it's working just fine. For example, check out the (centralized) list [2] of Ports files that define the packages. You can see it's pretty lively

But your perception that it's dead is certainly symptomatic of an issue for the project.

[1] yes yes Monty Python

[2] [https://github.com/macports/macports- ports](https://github.com/macports/macports-ports)

</comment></comment></comment></comment><comment><USER36> I don't understand why everyone is so excited about this. I don't like using brew. I use a Mac because things just work. It was annoying that the system versions were old, but most of the time they were still workable. To me, this is another (admittedly small) thing I liked about the Mac that's going away.

<comment><USER24> The problem is accruing security flaws (increasingly difficulty to back port fixes), and also the problems that come up when you install a different version (lots of Software just assumes it can use the same system python, which causes issues when it isn't the archaic version).

<comment><USER36> I'd prefer if Apple took care of security fixes instead of some third party. And they could ship newer versions if keeping the old ones secure is harder.

<comment><USER24> The problem is that updating to a new version isn't possible if it breaks existing software - what happens is that the end user experience is "I installed these updates and Apple broke my program" so don't update in future, and tell others not to as well.

The only way to stop the OS from including out of date software and libraries is to not ship them if they don't have stable abi.

That's what Apple is doing: it can't reasonably ship them and keep them up to date, so it is going to stop.

<comment><USER37> Doesn't removing them have the same issue? "My software dependent on this ancient python no longer works - because there's no python anymore"

<comment><USER24> Yes, the difference is that now Apple is shipping a new version that will have the same problem in a years time, so instead of one compatibility event there's a new one.

The app developer also now has a problem - their binary only works on one OS revision so they have to start shipping the same code, just compiled separately. The only safe solution is to ship with their own embedded version. Which is also the correct solution to the interpreters not being part of the platform.

</comment></comment></comment></comment></comment></comment><comment><USER38> Does this include AppleScript and the Javascript runtime for AppleScripts? They reference Script Editor in the section above, so I'm assuming they're safe.

Also, what's the best way to install homebrew if you don't have a system-level ruby? The current installer is a ruby script. Is it possible to get some sort of ruby-bootstrap that can install homebrew and a homebrewed ruby?

<comment><USER24> No - the problem with the misc other interpreters is that they don't provide sufficient binary stability for Apple to simply include the newest one in every update (which I suspect they would happily do).

They're not removing the commandline (although moving to zsh? :-/), or banning interpreters.

They're just not including them built into the os anymore.

As for the AppleScript and JavaScript questions:

Apple makes the runtimes for those, and makes sure they remaining binary compatible. Take a program that linked to (and used) the javascriptcore api to add js support. Something compiled 10 years ago will run without recompilation. Thats the bar for stability.

<comment><USER38> I think you read more into my question than what I meant. I was asking literally about the best way to install it was without a system level ruby. Once you have homebrew, you can install ruby; but what about before that? Download and install ruby from ruby-lang.org, install homebrew and a brewed ruby, then uninstall the one from ruby-lang.org?

<comment><USER39> I'm guessing home brew will end up creating a packaged installer than includes a home brew upgradable ruby

<comment><USER40> I'd think a script that you pipe into a shell with admin privileges is more likely ;)

<comment><USER41> Same difference, really.

<comment><USER40> No: you can sign and notarize packages.

</comment></comment></comment></comment></comment></comment></comment><comment><USER42> Good thing, python2.7 is deprecated and no longer receives security updates, and a lot of Linux distributions (Arch and Fedora for example) plans to remove it from the main repositories at the end of this year, so having it installed doesn't make sense.

Even the perl and ruby version installed is old, and nearly nobody uses perl or ruby at this day. Maybe perl is still used by some programs and scripts, for example TexLive relies on perl, or ruby is used for brew. But you better installing more updated version yourself so removing it is not a big deal.

There is no meaning to keep old script interpreters installed, if you want to use them you probably want to install a more modern version, if you don't need them it's better to not have them.

<comment><USER43> _> python2.7 is deprecated and no longer receives security updates_

Let's not go overboard - 2.7 will get security updates and patches until the end of December.

 _> nearly nobody uses perl or ruby at this day._

Well, except for homebrew of course, the Ruby-based package manager nearly "everybody" uses...

<comment><USER44> Homebrew (after installation) uses its own, bundled ruby runtime and will finish removing any dependency on system ruby long before Catalina is publicly available.

[https://twitter.com/MacHomebrew/status/1136249501252038662](https://twitter.com/MacHomebrew/status/1136249501252038662)

<comment><USER43> I know, but this wasn't the case when it started. Besides, I believe the parent's point was that nobody uses ruby or perl for _anything_ anymore, regardless of whether it's preinstalled or not. Which is obviously silly when looking at homebrew's internals.

</comment></comment></comment></comment><comment><USER45> I think that's ok, most everyone installs homebrew

<comment><USER46> How do you install homebrew without Ruby?

<comment><USER45> Pkg file...

<comment><USER47> encoded and embedded in a bash script, more likely.

</comment></comment></comment></comment><comment><USER48> It's interesting to me that this is happening in the same month that Microsoft made installing modern Python as easy as typing Python and then clicking "install". One more piece of evidence that Microsoft cares about developers more than Apple does.

<comment><USER49> > It's interesting to me that this is happening in the same month that > Microsoft made installing modern Python as easy as typing Python and then > clicking "install".

You still need admin rights and an internet setup. Linux is still king.

<comment><USER50> On what system can you install python without Internet access?

<comment><USER49> On Linux you don't need to install it it is there by default on all major distros.

</comment></comment></comment></comment><comment><USER51> Most of my Python/Ruby stuff requires additional packages to be installed and so would need to be bundled anyway if I wanted it to be easily transferred to a vanilla machine so I don't see what the big deal is. I got into programming through wanting to automate something really boring with AppleScript and I got into Ruby (wow that was amazing compared to AppleScript) through wanting to program sketch-up which has a bundled interpreter. When I wanted to use Ruby for other cool stuff, the Ruby website recommended I installed my own so it didn't mess with the system install. I doubt there are very many people who get into programming by accidentally typing Ruby at the command prompt. Most will come to it via a the getting started page for the language they are interested in or because it's bundled with the software they use for their job.

</comment><comment><USER52> Not a big deal. Anyone doing serious development at scale would mirror production anyways (12factors principle). Plus, who uses Apple's obsolete junk anyhow? For a very long time, homebrew and macports has solved Apple macOS not rolling releasing terminal-based packages. Teapot tempest.

</comment><comment><USER53> Of course; why would they want to maintain this crud and its dependency hell. If the slightest thing is wrong, this or that application breaks. An application should include the correct version of everything it needs to do its job, period.

Only problem is security: with multiple applications including their own dependencies, some of those dependencies will lag behind in their security updates. You can't just get a single fix for your Python run-time and fix it in all applications at once.

</comment><comment><USER54> In the mean time, ARM publishes educational C code that requires 3 different scripting languages to compile...

(Eralier versions of mbed build system needed python, JavaScript and one more)

</comment><comment><USER55> Interesting that some version of Python will still retain a default status, while Perl and Ruby are both being removed from the default install.

Congratulations, Python 3!

<comment><USER56> That's because no ruby developer ever depends on system ruby. It superfluous, not a vote for python.

</comment></comment><comment><USER57> I did like being able to distribute an entire app with a download of just a few _megabytes_ , relying on a highly stable system Python (literally worked for 10 years).

And these days with smallish SSDs, I find myself desperately freeing up disk space surprisingly often. I'd rather not have every single app be 100+ MB when I know deep down that the things should be tiny.

</comment><comment><USER58> I think people are reading more into this than is there. They're just not going to ship their own (outdated) versions of these anymore because they're not needed in the core OS. You can just "brew install" them, which most people who actually use them do anyway because the stock versions are too old.

</comment><comment><USER59> I guess it is the macOS way for every app to be self-contained and include all of its own libraries.

But I miss the idea of shared libraries; not only can they potentially save memory and disk space, but it makes bug fixes easier because you can fix the shared library without having to update every app separately.

</comment><comment><USER60> Sounds like these runtimes will still be available via a separate download, similar to how Git and other CLI tools download when you first try to use them. Not a big deal. Makes it easier for folks who want newer versions and avoid any strange behavior with coexisting with the built-in runtimes.

<comment><USER19> Yeah, one of my pet peeves is logging in to a new system and being like "Which version of Python am I going to have to try and avoid invoking today".

<comment><USER61> Nothing quite like a bit of snake dodging to start your day.

</comment></comment></comment><comment><USER62> Wait.. So I'll have to install Ruby before I can install Brew? Ok. Ruined 2 minutes of my day.

<comment><USER63> I expect homebrew to switch to installing their own local ruby via a zsh.

They already install their own local ruby today, but use the system-ruby as an entrypoint.

</comment></comment><comment><USER64> It might be nicer if they curated more up to date versions instead, but of course it's easier to remove things than to carefully manage dependencies.

I'm not a big fan of brew however. Last time I checked it didn't seem to work well when switching between users.

</comment><comment><USER65> And I have a 4+ year old Perl script I use daily. Yeah, yeah, I know I can install Perl myself but when I distribute it I was expecting it, Perl, to be there—never mind that it is an out-of-date version—I wrote it accordingly.

</comment><comment><USER66> Not that Apple even supports Widgets anymore beyond their continued vestigial existence, but it was always nice back in the day to have the power to call out from widgets to scripting languages for more power.

</comment><comment><USER67> I thought it is reasonable. IIRC, my MacOS 10.14.5 has python 2.7.10 built-in (I've install home-brew on it, but I guess it is the Apple built-in version), it is too old (Release Date: May 23, 2015).

</comment><comment><USER68> Oh, please remove them ASAP or include the most recent version of them.

</comment><comment><USER69> Ok, this means homebrew needs to be compiled to a native binary!

<comment><USER70> Or a shell script.

</comment></comment><comment><USER71> Civ IV will never work again. RIP.

<comment><USER72> It uses the system python? I doubt it.

<comment><USER71> It absolutely does and macOS has already broken it several times. This I guess to some extent demonstrates the folly of having one. [https://forums.civfanatics.com/threads/how-to-get- civ4-bts-w...](https://forums.civfanatics.com/threads/how-to-get-civ4-bts- working-on-el-capitan-and-sierra.549923/)

</comment></comment></comment><comment><USER73> They were often outdated anyway, so it's no big loss.

Gives other languages a better standing too :)

</comment><comment><USER74> So what about shell scripts?

<comment><USER40> Apple will have to ship with a POSIX compliant shell if they'd like to keep their UNIX® certification.

</comment></comment><comment><USER75> brew install python

problem solved?

</comment><comment><USER76> So, what's the point of using Macs as a better Linux, if they are continuing to strip out the parts of Linux that are useful? Might as well use WSL or Cygwin and save a bunch of money.

<comment><USER77> You do realise that the reason these things are being stripped out is because macOS includes hideously _old_ versions for backwards compatibility with older software that depended on them, right?

There is no real loss here; no sane users would use the built-in versions due to their age. It has been preferable to download and install newer versions for a long time, this changes nothing.

And if it's fine to spend a tiny amount of effort to install WSL or Cygwin on Windows, then it's surely also no effort at all to install Homebrew or MacPorts (or other) — with the benefit of not working in a contrived, separate environment.

This comment betrays a fundamental lack of understanding of modern developer workflows in macOS and feels just slightly like a troll comment from someone who likely doesn't use macOS to begin with.

<comment><USER78> > And if it's fine to spend a tiny amount of effort to install WSL or Cygwin > on Windows

Well, plenty of people use macOS precisely because it was like a more consistent Linux out-of-the-box. Apple will lose a ton of mindshare; indeed, they _are_ losing a ton of mindshare. They've been slowly deprecating things for years, now, and leaving the rest to rot, and open source developers are increasingly drifting away.

About 10 years ago macOS and Apple hardware started becoming the preferred kit for open source developers, and this showed--Apple kit was seen everywhere in Silicon Valley and eventually became the default kit given out by big software companies. That was all because of macOS' Unix personality. That's all going to change over the next several years.

I was surprised when WSL 1.0 debuted. By making Linux _native_ on Windows, it solidified Linux' position as the dominate server-side platform. I'm not at all surprised they're ditching it for WSL 2.0, which is just Linux in a VM with a networked filesystem, precisely what people have been doing for about 15 years, keeping it solidly second class--like running Windows on macOS.

<comment><USER79> I personally believe that the reason why Apple is losing mindshare among some software developers, particularly in Silicon Valley and in academia, has less to do with particular choices regarding macOS and has more to do with Apple's hardware situation, particularly regarding the keyboards on Apple's recent laptops. The keyboard situation has led some developers to consider alternatives to the MacBook Pro, which often necessitates needing to consider non-Mac alternatives. PC manufacturers have been offering some really compelling alternatives to the MacBook Pro such as the Microsoft Surface line of tablets, the Lenovo ThinkPad X1 Carbon, and the Dell XPS 13 and 15, among other computers. Those frustrated with Apple's long delays in releasing updated Mac Mini and Mac Pro models have also considered switching to PCs, if they haven't already.

On top of this, the introduction of WSL in Windows 10 has made Windows a compelling option for many people who use macOS as a Unix that doesn't have the driver issues of Linux/*BSD and happens to support Microsoft Office, Adobe Creative Suite, and other commercial software packages. Provided that they are not hardcore Unix systems programmers, if they want a Unix-like userland with support for Microsoft Office and Adobe Creative Suite, why not try WSL? Despite my preference for macOS, I've used WSL on my work-issued computer as well as on my personal Dell XPS 15, and I must say, I'm very impressed with it. No more having to mess around with PuTTY or with virtual machines to do Unix work on Windows. While I am personally more productive in macOS than in Windows even with WSL, I know quite a few former Mac users who are very happy with Windows 10, thanks to WSL.

Now, software engineers who primarily work with Apple frameworks and technologies probably won't be satisfied with Windows. But software engineers who use macOS primarily as a convenient Unix with support for commercial software packages might want to give Windows 10 and WSL a try. Now, personally I'm still turned off by certain lingering "Windowsisms" (insert gripes about telemetry, ads, mandatory updates, and the UI here), but for many people Windows 10 is now a compelling alternative to the Mac.

</comment></comment></comment></comment><comment><USER80> How deep you are willing to go with conspiracy theories ...

If one was planning to kill off all non-approved software on an OS, what would you do first? Remove all the runtimes that can execute unapproved software of course. Then you are free to impose signing as a requirement for applications and a mandatory app store, and reap the 30% rent tax forever more.

Is Apple doing that? Of course, we can't tell. There are lots of good reasons to do this that aren't evil. The best evil plans are indistinguishable from good plans but just happen to have evil outcomes that are in your interest.

<comment><USER40> It is trivial to package a scripting runtime with an App Store application; so trivial, in fact, that a number of apps _for iOS_ do this already.

<comment><USER80> That doesn't really contradict anything above. It still remains true that if they were planning on removing ability to run unapproved applications from OSX, the first step would be to take out the ability to do that which is installed by default. Restricting what App Store applications can do would come later (and be controlled by policy rather than technical limitations).</comment></comment></comment>


To Be - <AUTHOR> https://to.be/ <comment><USER2> I feel like someone spent a lot of money on the domain and then subsequently tried to work out what the hell to do with it, "pivoted" a number of times, and somehow ended up with... whatever the hell this is.

<comment><USER3> It looks stupid now, but in retrospect twitter and instagram looked stupid as well. It's the kind of startup that either fails horribly or explodes in usage inexplicably.

</comment></comment><comment><USER4> Myspace and Geocities had a baby? But they're both dead?

<comment><USER5> More like Google Wave and Google Docs had a baby.

</comment></comment><comment><USER6> This is interesting, but the front page is rather cluttered and makes it hard to pay attention to the core message.

</comment><comment><USER7> AdBlock Plus blocked this entire page, if anyone is seeing an entirely white page like I was.

<comment><USER8> So did noscript.

I temporarily allowed the domain and it was well worth the click.

<comment><USER9> Don't you expect most pages to be broken when using noscript?

<comment><USER8> Yes, but most are at least visible.

<comment><USER10> If I only have to allow one page, it's all good.

But then the first page wants to load from another 10 pages. I allow the non- tracker ones, usually two or three. Reload.. and they want to load from another 5 pages. I usually give up here since I'm not that interested anyway. Why the heck do you need code from over 15 external pages?

<comment><USER8> It is truly amazing how bloated most webpages are these days.

</comment></comment></comment></comment></comment></comment><comment><USER11> Completely white page with NoScript, please add a <noscript> tag

<comment><AUTHOR> That's a good idea. Why would someone downvote this?

<comment><USER12> Because it's silly to ask web developers to cater to a specific extension used by a marginal minority of people. Much better to use a more general method for when JS is unavailable.

And people using noscript or similar tools (like myself) should know by now when a page fails to check that first.

<comment><AUTHOR> But the comment applies to anyone who's not using JavaScript in their web browser.

Although I like programming in JavaScript, there's many people I know that consider JavaScript itself to be a silly extension of what a web browser should do.

<comment><USER13> And many people, including those who made this website, consider Javascript to be an integral part of what a web browser should do.

Would you complain about a free video game if it only worked on playstation, and you had only an xbox but still refused a free playstation?

<comment><USER14> Hackers news work perfectly fine without JavaScript.

JS should be an enhancement to improve UX, but not a doorstopper for search engines, web scrappers, and blind people.

<comment><USER15> Hacker News is a fairly simple site for this use case. It works. However I would not say that it is perfectly fine.

Try upvoting with js disabled. The page has to do an entire refresh. That could be a doorstopper for people with limited data plans or with spotty network coverage.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I'm thinking modern art, make no sense, have fun, be "strange", create something raw and unique... yeah. Some people will have fun with this I'm sure. Not for me at this moment in life though, but that shouldn't matter to anyone.

Cheers

</comment><comment><USER17> What exactly is this? It looks to me like a multiplayer vaporwave-inspired shirt maker.

</comment><comment><USER18> My advice is the demo video should show something compelling being created not a bunch of completely random nonsense that does nothing to evoke any kind of connection with anyone. Presumably you created this with this Hamletesque title to create memorable "Internety" experiences. Show one. Otherwise I think it is hard to understand. Sure, someone else could probably create something much better than is in that video but if even the creator can't create something compelling ... its a bit weird. Just my advice. It is an interesting drawing tool, otherwise.

<comment><USER19> I thought the same thing. Was wondering why the lack of anything substantial created. They made a video. Could have made a more complete project with their product for the video. :)

Regardless, cool idea.

</comment></comment><comment><USER20> Target group:

[https://en.wikipedia.org/wiki/Seapunk](https://en.wikipedia.org/wiki/Seapunk)

[https://www.google.com/search?tbm=isch&q=%22seapunk%22](https://www.google.com/search?tbm=isch&q=%22seapunk%22)

</comment><comment><USER21> It's like a hipster Web 2.0 version of YTMND.

</comment><comment><USER22> Maybe I'm overreacting b/c this aligns with my interests pretty directly but this is outrageously cool + well-executed. And better yet looks like there's already a bunch of interesting users on there.

Completely eliminates the technical barriers to creating this type/genre of net art so it's gonna be interesting seeing the effect that has alone

How long has this been around?

<comment><AUTHOR> to.be has been around since 2012 / 2013\. I'm glad you think it's cool.

<comment><USER23> The domain to.be has a long history in Belgium (.be is the CcTLD for Belgium). Before and around 2000 it was one of the most popular websites there, it was literally the place.to.be. I always liked the domain name, it was clever and with lots of potential. At one stage it was a well-known chat site, but a succession of pivots and different owners led to a obscure existence. And now it somehow resurrected as a t-shirt printing company based in the US.

</comment></comment></comment><comment><USER24> The concept was a lot more interesting to me than the implementation. I thought I would end up being able to view a and click bunch of masked, active HTML items, instead it seems to bake it down into a single image. Editing tools looked neat, but "print on a T-shirt" was the last thing I expected, and a disappointment.

<comment><AUTHOR> Hmm, I'm not sure what you mean by 'bake it down into a single image'. You should be able to drag around the HTML elements on the field, if you've made an account and are working on your own field, or pulled it from someone else.

</comment></comment><comment><USER25> I haven't had a chance to read through some of the source, but does anyone know how the photo editing is done? Are there libs to handle those effects?

</comment><comment><USER26> Safari 7.1, no extensions: blank page. Firefox 34.0.5, clean install: blank page. Chrome 39.0.2171.99, clean install: blank page.

</comment><comment><USER27> Looks like a great site to make dank memes with.

</comment><comment><USER28> Love it. A free form virtual world. Been wanting to build one of these for a long time.

</comment><comment><USER29> Somehow, I'm not sure how, you've crippled the scrollbar on my browser :S

</comment><comment><USER30> || !

<comment><USER31> or not (to be)?

</comment></comment><comment><USER32> Could be used to create "mood boards" for games, stories, art

</comment><comment><USER33> Who owns the content?

<comment><AUTHOR> The terms are here: [http://to.be/terms](http://to.be/terms)

There's a long section on "Ownership" that I don't fully understand, but you can interpret if you're interested.

<comment><USER34> IANAL, but seems like a typical clause. Essentially you hold the copyright, but you agree to give them a perpetual license to do whatever they please with the stuff you submit (including allowing other users to incorporate it in their own works).

</comment></comment></comment><comment><USER35> Tumblr will love it! ;)

</comment><comment><USER36> Well done! _clap_

</comment><comment><USER37> I don't get it.

</comment><comment><USER38> No snide. The fact that most here don't get it makes me think this project will be, at least, moderately successful.</comment>


Moving Fast on Hardware with io.js - <AUTHOR> https://tessel.io/blog/112888410737/moving-faster-with-io-js

<comment><USER2> <<we had built a custom minimal runtime that "transpiles" JavaScript code to Lua and runs that Lua code on a Lua VM.>>

What's the point? Why not just write Lua instead of JavaScript? It's a better language anyway. This 'JavaScript everywhere' fad is just pandering to people who are too lazy to learn another language.

<comment><USER3> Did you read the article? It's about how there _isn 't_ a Lua VM anymore on the new hardware

<comment><USER2> Did I read the article _I quoted from_? Yes. "Anymore" is the key word. I'm questioning the need to have JavaScript at all when they started out with a perfectly good language. Their problem wasn't that there was anything wrong with Lua; the problem was in transpiling JavaScript to it.

<comment><USER3> Don't have time != lazy, but that's a different argument. One of the cool things on this new one is it runs Rust, arguably the best language for this purpose, so you don't have to use JavaScript if you think it's stupid

<comment><USER2> What do you mean by "runs Rust"? Rust compiles to native code. The old one could run Rust code too.

<comment><USER4> Rust will be supported by the tools the same way JS is. `tessel push` will run the cross compiler, and Rust libraries will be provided to access the hardware and modules.

Yes, you can get to the underlying Linux system and run anything you want (including Lua), but the point is to abstract away the OS so you only have to think about your code and the hardware.

</comment></comment></comment></comment></comment></comment><comment><USER5> I'm hoping the server that stashes binary builds will be accessible to not just Tessel users but everyone who is running Node on a MIPS architecture (for example, wrtNodes).

</comment><comment><USER6> It seems io.js is taking over. This doesn't happen often, but it has happened before, with Mambo and Joomla, and Hudson and Jenkins. I expect it will happen more often as open source projects mature and the goals of the community diverge from the goals of the organizations that own the trademarks.

<comment><USER7> I think there has been some talk about reconciling the two projects though...

[http://readwrite.com/2015/02/27/node-js-io-js- reconciliation...](http://readwrite.com/2015/02/27/node-js-io-js- reconciliation-near)

<comment><USER6> I'm aware of that. I think it's unlikely to happen.

</comment></comment></comment><comment><USER8> It's interesting how power, not compute, has become the new limiting factor in what developers can do.

<comment><USER5> It seems like high powered devices are becoming almost as cheap as low power devices, almost purely as an artifact of the rise in mobile sales. So, to your point, the thought process of which microcontroller/microprocessor to pick lies almost solely in whether or not it's connected to wall power.

</comment></comment><comment><USER9> I'm ridiculously excited about this. The original tessel was an amazing step away from the dichotomy of Arduino | Embedded Linux, allowing you to focus on what makes your project different instead of fiddling with breadboards or operating systems. Sound familiar, Rails / Django devs?

The coolest thing is that it's a fairly modular product, instead of being some custom monolith that tries to solve every problem for you. It hooks into npm and the command line, and runs JavaScript.

Unfortunately, the Tessel1 ran Colony, a custom implementation, which didn't do well with things like Bluebird promises (Q promises worked, but slowly) or generators or observables. Most hardware projects are actually reactive systems, and those are difficult to build with an Arduino. Coordinating callbacks is very painful.

I can't wait to get my hands on a Tessel2. Hardware has been needlessly hard for too long. Glad to see hardware hackers adopting more hard-won solutions from the past 6 decades of software engineering.

</comment><comment><USER3> Excited about this!</comment>


Regular Expressions in 100 lines of Scala - <AUTHOR> http://rcoh.svbtle.com/no-magic-regular-expressions

<comment><USER2> It's not so easy to see in the linked article, but the article is actually in 3 parts:

Part 1: [http://rcoh.svbtle.com/no-magic-regular- expressions](http://rcoh.svbtle.com/no-magic-regular-expressions)

Part 2: [http://rcoh.svbtle.com/regular-expressions- part-2](http://rcoh.svbtle.com/regular-expressions-part-2)

Part 3: [http://rcoh.svbtle.com/no-magic-regular-expressions- part-3](http://rcoh.svbtle.com/no-magic-regular-expressions-part-3)

It's really well done!

</comment><comment><USER3> There is a similar chapter [1] in the book _Beautiful Code_ in which Brian Kernighan explains how to implement a regular expressions matcher using code written by Rob Pike in C.

[1]: [http://www.cs.princeton.edu/courses/archive/spr09/cos333/bea...](http://www.cs.princeton.edu/courses/archive/spr09/cos333/beautiful.html)

</comment><comment><USER4> see also parser combinator approach:

reg exp engine in 14 lines of python [https://news.ycombinator.com/item?id=3202313](https://news.ycombinator.com/item?id=3202313)

</comment><comment><USER5> Btw, is Scala still relevant with the coming of Java 9?

<comment><USER6> I definitely think so. Why wouldn't it be? Do you think Java 8 or 9 would be able to solve OP's problem with as much expressiveness as Scala?

<comment><USER5> Not completely, but there was/is a line of advising to use Scala as a better Java. Java is getting better and better with subsequent versions, so at least this line of Scala loses strength I believe.

<comment><USER7> Scala is still a much better java than even Java 9. Even if you don't want to go FP crazy, it still makes sense to at least try scala.

<comment><USER8> Sean, you've written in the past that you tried Scala 7+ years ago; any reason beyond working for M$ that you don't give it another look? It's certainly improved a ton since your explorations during the stone ages of Scala ;-)

For example, you probably were never able to take advantage of type classes, (G)ADTs, value classes, recursive types, exhaustive pattern matching, etc., etc. back in the day.

Would be nice to have an OO expert/advocate on the Scala side of the fence to provide a counter point to the FP wave.

<comment><USER7> I have nothing personally to write for the JVM...or I would use Scala. That's what I meant by "better Java." Besides, the Scala community might not be a great place for an OO advocate, Dart and Typescript, or maybe Swift, are more of the future for us.

<comment><USER9> The Scala community is, and always has been, quite heterogenous. There's a vocal, and sometimes quite abrasive group of fundamentalists on HN and Twitter. But the Scala community is much more diverse than what you would hear from them.

<comment><USER7> There is a bit of difference between OO people who use Scala and OO people who influence it (through implementation work or design input); I'm not seeing much of the latter these days as an outsider, but I admit I might not be looking hard enough.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> The title is a little misleading - perhaps better would be "A very limited subset of Regular Expressions in 100 lines of Scala".

While the code is concise, this is more a case of "it implements A and B of an X" than "it implements an X, apart from A and B".

Still, all three parts of the series are a good read, and definitely helpful for learning about parsing and about Scala.

<comment><USER11> Regular expressions just need 3 things: sequence, alternatives (|), and repetition(*). Everything else is an extension.

<comment><USER12> And the empty versions/identities of those operations

<comment><USER13> Right, those three things plus three times nothing. 3 + 3*0 = 3</comment></comment></comment></comment>


Behind the scenes of the Google #HTML5-based book - <AUTHOR> http://googlecode.blogspot.com/2010/11/html5-browsers-and-books-twenty-years.html <comment><USER2> It's technically interesting, but made bad impression on me by using broken User-Agent sniffing. It supports Opera 10.6, but serves Opera 11 version without JavaScript along with passive-aggressive message.

Same happens on iPhone when you use iCab (exactly same engine as supported Safari, just different UA string).

Such modern site spoiled by bad practice from '90s :(

</comment><comment><USER3> What I really dislike about HTML5 'offline storage' is that there's never any indication of what exactly the website wants to store on my computer, so I always click no. UX Fail.

<comment><USER4> What would you like it to show? There's no way to ensure that the code is doing whatever the message would actually be showing.

</comment></comment><comment><USER5> Seems to be broken (in Chrome beta). It always just goes to the Credits page when trying to view any section. Or maybe the creators just have really big egos.

<comment><USER6> That's odd, it seems OK in 9.0.587.0 dev

</comment></comment><comment><USER7> I'm using the latest version of Chromium on Ubuntu and the book is too broken to read

<comment><USER8> same here - it was working yesterday though</comment></comment>


The next great format for out-of-home advertising and we're here to bring it - <AUTHOR> Hi there,
i'd love to get your advice on our product, so we don't build the wrong thing.
Company: Gifbox offers full-motion advertising on Smart Delivery boxes mounted to Delivery bikes. Each box is integrated with three LED Displays (20x20Inch), covering three sides of the box to get maximum views.Businesses with a limited budget for marketing will get great exposure to their brands.  We also provide an online solution that makes it easy for businesses to Create, Upload, schedule and  geo-target ads, enabling advertisers to push advertisements directly to our Smart delivery Boxes.
Website: https://www.gifbox.io/
Please let me know your thoughts on our service. Thanks! <comment><USER2> There's already more than enough visual pollution and distractions out there don't you think?

<comment><AUTHOR> i'm from india, the city i'm targeting has imposed ban on billboards because here there are way too many, taking up too much space and more importantly they are not authorised by the government.

To avoid distracted driving we only allow Gif's instead of videos.

<comment><USER2> > the city i'm targeting has imposed ban on billboards

If people were so fed up with billboards to the point of banning them, why would you do something similar even though it's hated by enough people to pass a city-wide ban on it? And why do you think the city can't ban your solution just like they did with billboards?

<comment><AUTHOR> Sorry i was not clear on my previous comment, it was not a city-wide ban.

The ban was imposed by the govt because they were installed in restricted zones and No billboards at all during the monsoon.

The only competitor i have is [https://www.adonmo.com/](https://www.adonmo.com/) They Raised 3 Million dollars led by BAce Capital this January, and the fact that it is backed by the government.

I feel that my product has much to offer, because of its ad delivery mode (using a delivery box).

 _Three advertising Sides._ More Advertising space _Online Portal to publish._ Also it is at eye-level compared to their roof-top advertising.

<comment><USER2> Okay, maybe I was being too subtle so let's be more direct: billboards were banned for a reason, people don't want garbage polluting their vision. Your business plans to reintroduce this... maybe find something else to do that doesn't involve pissing people off?

<comment><AUTHOR> you dont think this idea is worth pursuing?

<comment><USER2> Honestly, no. I'm pretty sure there are plenty of other opportunities out there where you can make money providing a service that people are happy to pay for and that isn't a net negative for society. Your current idea basically means a few people (including you) benefit from it while society at large is now forced to deal with the extra visual pollution produced by these mobile billboards.

</comment></comment></comment></comment></comment></comment></comment><comment><USER3> Have you talked to actual advertisers or agencies about it?

<comment><AUTHOR> i sent out emails to marketing heads of 200 companies, but they would not check.

How do i proceed?</comment></comment>


Wikileaks To Leak 5000 Open Source Java Projects - <AUTHOR> http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-5000-open-source-java.html <comment><USER2> In a global header long time ago, a friend of mine (and big "C" lover) did this to his best buddy once (a C++ and especially boost lover):

#define class struct

#define private public

#define protected public

<comment><USER3> continued "fun" (read dangerous) redefines:

      #define true false
      #define false true

      #define true 0
      #define false !true

      #define if while
      #define continue break

:)

<comment><USER4>
      #define true false
      #define false true

Did you know that if you do both of those, they cancel each other out? True story.

<comment><USER5> My head hurts. Explanation, please?

<comment><USER4> There's a rule in the preprocessor to prevent infinite recursion: only replace each symbol once. The first time it encounters 'true', it's replaced with 'false'. The first time it encounters 'false, it's replace with 'true'. It's already seen 'true', so it throws up its hands.

The consequence of this rule is that cycles of #defines don't do anything. Edit: Well, that's only true if there aren't other symbols introduced during expansion. Here's a counterexample that prints 3:

       #include <stdio.h>

       int x = 1;

       #define x 1 + y
       #define y 1 + x

       int main(int argc, char *argv[])
       {
         printf("%d\n",x);
         return 0;
       }

<comment><USER5> Ah .. Makes sense. Thanks.

</comment></comment></comment></comment></comment></comment><comment><USER6> "If I buy you a house and put the title in your name, but I mark some of the doors 'Employees Only', then you're not allowed to open those doors, even though it's your house. Because it's really my house, even though I gave it to you to live in."

Love it!

<comment><USER7> This actually reminded me of Apple...

<comment><USER8> The difference between phones, and all other products, is that phones don't _work_ unless you're currently in a business relationship with some telecom or another. It's a bit more like selling someone a nuclear reactor—they're beholden to your rules as long as they have no other source of fissile materials.

<comment><USER9> In 15 minutes, with 15 euros, I could be out the door and have a new 'business relationship' with a different telecom provider. It's not that big a deal: you just pop in a new sim card.

Sure, in the US people have all these locked up phones, but that's the price you pay for getting subsidized hardware.

<comment><USER10> Not to mention the higher rates, thanks to virtually zero regulation of the telcos here in the US.

<comment><USER11> Higher rate my foot. Cell phones in Switzerland and Germany are crazy expensive. It costs people like 0.20 cents to call someone with a phone, and I pay like 0.25 cents or something. When I used to have a phone in Germany, I used to spend upwards of 90 euros a month calling like I was used to in the states, where I basically have as much calling as I need for $50 (including tax and all that sneaky bullshit). Cell phones in europe are a little cheaper if you don't talk much, but if you really want to use it as a primary phone, they are insane expensive. Thats why everybody texts like crazy here, but even texts are expensive.

<comment><USER12> Is that 0.25 cents (as written) or 25 cents ?

<comment><USER11> I hate it when I do that! Obviously 25 cents. [http://verizonmath.blogspot.com/2006/12/verizon-doesnt- know-...](http://verizonmath.blogspot.com/2006/12/verizon-doesnt-know-dollars- from-cents.html)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> _...run through a Perl script that removes all 'final' keywords except those required for hacking around the 15-year-old Java language's "fucking embarrassing lack of closures."_

This guy feels my pain! :)

</comment><comment><USER14> I like it, but making fun of Java (and Java's "thought leaders") is just too easy. It's like shooting fish in a barrel. With a grenade launcher.

Eclipse is another matter: far more ridicule is called for. Far, far more.

<comment><USER15> Exactly: Or Smalltalk or Ruby for that matter, which both facilitate information hiding via private access. It's great to feel superior, isn't it?

<comment><USER16> Yeah except in Ruby (I don't know about smalltalk) private access has the loophole of the send method. FreeHouse.send(:open_employees_only_door)

Matz would never deny us of our right to snoop around where we don't belong.

</comment></comment></comment><comment><USER17> Christ, this guy never ceases to amaze. His talk at I/O a couple years ago was absolutely fantastic: <http://www.youtube.com/watch?v=BttI-y9VzXQ>

<comment><USER18> One of the points he makes is that VMs are obvious for the purpose of language interop. Seems like C and Lisp (and D, another language he mentions) have been interoperating with each other without a VM in common for quite a while.

<comment><USER19> But it's not a many to many mapping, that's the point he was making. Lots of languages interop with C, but you can't just import a ruby module into a python script very easily. In fact if you want to link to C libraries from D you have to modify the C header files to turn them into D modules.

<comment><USER20> I think Microsoft actually did a reasonable job with the "original" COM (ie OLE 2.0 - the stuff that let you put an Excel 95 spreadsheet into a Word 95 document).

It had a bit too much bolted on, probably due to its origins in OLE, and I think "dynamic OLE" was a tragic mistake. And its reference counting approach was a lot more appropriate in the early 90s than it is today (where a compacting GC may be the smart choice, performance-wise). But for making calls between objects in C, C++, VB6, Delphi, and pretty much every other language that lived on the Windows platform, it worked really well.

<comment><USER21> For a compacting GC, you'd have to hunt down a complete set of references from running programs written in unknown languages, with strange errors if the set is underapproximated even once. I'd rather have reference counting.

</comment></comment></comment></comment></comment><comment><USER22> It's interesting to see how important compiler-enforced access specifiers were to C++ and Java. It seems they are going out of fashion. In the Python world they were always considered a bit silly.

<comment><USER23> The languages have fundamentally different goals.

If you explained Unix file permissions to a Windows guy, he'd probably think it was silly. They exist for a purpose though- just not a purpose the Windows guy has spent much time with.

</comment></comment><comment><USER24> This reads to me as "let's make all state mutable and remove all indication as to which bits of the code are the interface, and which are implementation details". I like immutability and minimal interfaces, they make it easier to reason about what the code will do, freeing brain cycles to work on more interesting things than "but what if someone modifies foo between invocations of bar".

If you need access to a library's private or final fields, the library API is badly designed. Or, if you're that keen on wanting to change how the library works, fork it. That's kind of the point of open source.

<comment><USER25> You've got a point, but I think final class modifier which prevents extension often hinders Unit Testing and never adds much value.

<comment><USER26> final class modifier is pretty useless.

private final member variables? Invaluable.

</comment></comment></comment><comment><USER27> Can someone please explain what this means to people not familiar with Java? I'm confused because I thought open source meant open source, as in "all of the source-code is available." What does 'open source' mean in this context, if not "open'??? When I read the title I thought it was a joke. Thanks and sorry for my ignorance, I'm a lowly perl hacker.

<comment><USER28> A big part of OO languages is encapsulation. Private fields encapsulate state and private methods encapsulate implementation details. The intention there is to make the code more robust to restrict the way collaborating classes can interact with it.

Example, if you have a type representing a game score, you may want to implement a public Increment() method instead of letting other types access the score value directly.

The author of the post is pointing out the irony of people saying "this code is totally open" yet forcing you, ostensibly for your own good, to interact with it in a prescriptive way.

<comment><USER27> Thanks for the response, but can you not see the source code of these private methods? And wouldn't that allow you to re-write them yourself to behave however you want?

<comment><USER29> A sign of experience with open source: You become incredibly reluctant to hack directly on the source of a popular library. With great power comes great responsibility.

In Drupal, for example, there is a saying: "every time you hack core (or a module you didn't write) god kills a kitten." In the spirit of open source, we probably borrowed that saying from some earlier project, because it is generally true.

The standard Java String library is the same for everyone. [1] If you download Random Java Library X, and X works with the String library, you can probably be assured that X has been tested with the standard String library. As soon as you change one line of the library this is no longer the case. You must now face the possibility that your "minor" change will lead to side effects when combined with other things, and the responsibility for finding those side effects is now entirely yours.

Plus, the sheer mechanical tedium of preserving your patch, making sure to apply it to every new version of the library as it comes out, relearning how the patch works every few months, porting the patch when it fails to apply cleanly to a new version, figuring out how to distribute your personalized package to others because they can no longer simply `apt-get` your package from the canonical repository, dealing with the fact that the standard docs and the published books might not cover your variation...

Tools like Github have made all this stuff much easier, but it's still a bad idea to tinker with others' libraries without a good reason.

The more typical advantage of open source is that you can read exactly what your library is doing, which makes it easier to figure out how to work around it without actually editing it.

\---

[1] Until it isn't. But at that point it will generally get a different version number, and an official release notice, and it will have a community that is aware of the change and will promptly coordinate to find and fix any new incompatibilities with other libraries.

</comment></comment></comment></comment><comment><USER30> I sympathize, yet encapsulation is appropriate for some projects. Not all users of a library want to frequently update to their own code. Forbidding encapsulation and deprecation would increase this cost. Also, it's comforting to be able to refactor the guts of a class without harming users.

<comment><USER31> The issue is less about encapsulation and more about _language-enforced_ encapsulation. Encapsulation is good, but encapsulation that's enforced by the language is debatable.

<comment><USER28> If the language isn't enforcing the encapsulation, how is it encapsulated?

For me, encapsulation comes down to "What I hide, I can change. What I expose, other types may couple to in an inappropriate way."

<comment><USER32> > If the language isn't enforcing the encapsulation, how is it encapsulated?

What do you mean by "enforce"? Java's private modifier doesn't enforce encapsulation. Javascript's objects do not have a private modifier, but still _provides_ encapsulation via closures. It's hard to have a meaningful discussion when loose terms like "enforce" are thrown around.

<comment><USER28> Sure, the private access modifier doesn't strictly "enforce" encapsulation. Perhaps the term should be "language supported".

I guess, for me, that the point of private is to clearly communicate the intent of the interface (small "i" interface) of a type. That intent is generally "don't use this, use this other part instead" or "if you couple, to this, it may break on you".

There are other ways of expressing that intent, I just really like having the compiler help me and my collaborators from making stupid mistakes.

</comment></comment></comment></comment></comment><comment><USER33> Some context:

WalterGR commented on reddit that this rant is actually in response to this tweet by Marco Tabini:

\</comment><comment></comment><comment></comment><comment></comment><comment>-

"@ijansch Private has absolutely no useful role in open-source code." ( <http://twitter.com/mtabini/status/18867470296> )

\</comment><comment></comment><comment></comment><comment></comment><comment>-

Marco is the co-founder of "a consulting firm that specializes in information architecture, code and security auditing, large-scale deployments and optimization".

More information:

[http://www.reddit.com/r/programming/comments/cusyw/wikileaks...](http://www.reddit.com/r/programming/comments/cusyw/wikileaks_to_leak_5000_open_source_java_projects/c0vfj1w)

</comment><comment><USER34> First note: I have never dealt with the internal workings of the Java VM, so this is just speculation. I also haven't tested any of this, but its still fun to speculate.

In java private variables and functions are not accessible from outside the class. This means that the compiler would be able to make some assumptions about the nature of these members in the effect of optimization. When calling a public function of another class in java, I suspect that the name of the function is mapped to the actual bytecode at invocation time after being looked up in some sort of trie/tree/hashtable. So, for every function call or varaible access, there would have to be a lookup. On the other hand, if the members were declared private, the compiler could directly link a caller to the function and skip the lookup. If this is the case, then setting all these projects' sources to use only public would mean a substantial performance loss.

I would love to be corrected if this is not the case, as I haven't taken a course in OO compilers yet.

<comment><USER35> _In java private variables and functions are not accessible from outside the class._

Not quite - using reflection you can dig into private fields and do your worst to them, you just need to tag each private member's Field object with with field.setAccessible(true) before accessing it reflectively.

The only hitch is that you might get a SecurityException, but you can avoid that if you're running your code on your own JVM (by default, it should work just fine, it's if you're deploying applets or something like that where you might get the exception due to the different sandboxing rules).

</comment></comment><comment><USER36> Clojure has tools to make it easy to bypass private/protected :

[http://richhickey.github.com/clojure-contrib/java-utils- api....](http://richhickey.github.com/clojure-contrib/java-utils- api.html#clojure.contrib.java-utils/wall-hack-method)

<comment><USER32> Granted it's just using Java calls (no magic), but still fun.

<comment><USER37> Are those called wall-hack for the reason I think they are? If so, awesome.

<comment><USER38> It's a spoof alrticle -a joke - and "private" and "protected" were never about the legality of letting other parties access things - they were just conveniences for the developers and the tools to make it clear what could be optimized how, and what should and should talk to what.

<comment><USER37> Hm? I was referring to the Clojure link in the comment above. (And they're the functions linked are no joke)

</comment></comment></comment></comment></comment><comment><USER39> I have to say, for me private methods and fields are not a security thing. They are a way to keep the public interface clean and only confront the user with the information they need.

<comment><USER40> And that's the problem.

<comment><USER39> Why? It conveys a piece of information. Would you feel better about it if instead of writing "private" in front of it, I would write a comment "it is probably a bad idea to use this method in your own code"? What would be the gain - it is simply more verbose?

</comment></comment></comment><comment><USER41> The doubly great thing about this article is that maybe Steve Yegge will start blogging again. :)

</comment><comment><USER42> Personally I would prefer a script that made all variables private and removed setters, but I suppose that would be more useful than funny.

<comment><USER19> The problem with blocking the intended side-effects in side-effect-driven programming is that the programs will break. A script to re-write all Java into Clojure would be useful, too, but really kind of not the point.

</comment></comment><comment><USER43> Awesome. Tweaks Java, Agile _League of Agile Methodology Experts (LAME)_ , Wikileaks, Oracle on one short non-steve-yegge-length post.

</comment><comment><USER17> It wasn't until I re-read this that I noticed the two fake 'more news' entries.

</comment><comment><USER44> If you really try to make the OO as beautiful as humanly possible, you neither make the member variables public nor do you offer getters and setters. Everything is realized by functions which have a meaning, you really give the class the power to manage itself, not be managed from the outside with getters and setters! If you successfully adopt this thinking pattern then you have so many problems less...

</comment><comment><USER45> "If I make something private, it means that no matter how desperately you need to call it, I should be able to prevent you from doing so, even long after I've gone to the grave."

I am pretty sure this can be defeated without taking private out. Reflection will get you there with the security checking turned off.

</comment><comment><USER46> I can't decide whether this is serious or not. Don't doubt the actual wikileaks announcement just the comments from the various sources seem too funny to be true.

favorite: "But use it exactly how I tell you to use it, because fuck you, it's my code. I'll decide who's the goddamn grown-up around here."

<comment><USER47> Really? Why would wikileaks care about the source to open-source java applications

</comment></comment><comment><USER48> For a second I was actually hoping someone leaked Google's internal stack and all of it was GPL.

<comment><USER47> Even if it was GPL, it doesn't mean they would have to give anyone the source code.

</comment></comment><comment><USER49> I think this could be a good example for making a program that creates jokes for programmers. In essence, substitute words

Goverment => Java Privacy => Private Method Public Alarm => ...

</comment><comment><USER50> This is the best thing to happen to Java. Hopefully, this gives that community a ladder to catch up to the innovation around true open source communities.

</comment><comment><USER51> "and turns all fields without getters/setters into public fields."

Why not all fields perid. Even those with getters,setter?

</comment><comment><USER52> Does Java have something similar to .Net's reflection?

<comment><USER53> Considering the history, don't you mean "Does .NET have something similar to Java's reflection?"

<comment><USER54> I don't understand the up-votes on this. He asked a reasonable question and phrased it with respect to his knowledge base. Your reply assumes he knows the answer to the question he's asking. Huh?

<comment><USER53> My comment was a joke. (Which I thought appropriate given the root of this thread.)

</comment></comment></comment></comment><comment><USER55> This reads like an Onion article.

<comment><USER56> Modulo the funny.

<comment><USER57> You don't think the Onion is funny?

<comment><USER47> he's saying this reads like the Onion without the funny.

</comment></comment></comment></comment><comment><USER58> Ahhh... That was the sigh of vindication after reading this post and confirming my opinion of Steve Yegge.</comment>


Apple Delays AirPods Wireless Headphones - <AUTHOR> https://www.bloomberg.com/news/articles/2016-10-26/apple-delays-airpods-wireless-headphones-announced-with-iphone-7?bcomANews=true <comment><USER3> I remember a comic strip with two highways: one pointing to road deprecated and other sign says "not ready yet"

<comment><USER4> Kind of only tangentially related, but I see this sort of thing all the time.

KeyboardEvent.keyCode: [https://developer.mozilla.org/en- US/docs/Web/API/KeyboardEve...](https://developer.mozilla.org/en- US/docs/Web/API/KeyboardEvent/keyCode)

> Deprecated, please use KeyboardEvent.code

KeyboardEvent.code: [https://developer.mozilla.org/en- US/docs/Web/API/KeyboardEve...](https://developer.mozilla.org/en- US/docs/Web/API/KeyboardEvent/code)

> Internet Explorer: No support

> Microsoft Edge: No support

> Safari: No support

</comment></comment><comment><USER5> I have tested at least a dozen Bluetooth-headphones for sports (running, gym, etc.) and they all died due to sweat after max. 2 months. Anyone has a good suggestion? (was really looking forward to buying the AirPods even though not sure about sweat-resistance...)

<comment><USER6> Just get a clip-on BT receiver and use cheap wired headphones. I sweat a LOT and many options e.g. Apple earpods stay in my ear and have not died due to sweat yet after years of workouts (they die for other reasons like me stepping on them).

<comment><USER7> Any recommendations for which receivers to look at? My search-fu has failed me repeatedly.

<comment><USER8> Griffin recently released a new Bluetooth adapter called the Griffin iTrip Clip. Initial reviews for it are positive.

</comment></comment></comment></comment><comment><USER9> What are the odds they just cancel the product? I haven't seen much excitement for them (since they're pricey and can be so easily lost), and if they're having trouble making them, I could see them just cancelling them and going back to the drawing board.

<comment><USER10> .

<comment><USER11> All iPhone 7 units ship with earphones and an adapter.

</comment></comment></comment><comment><USER12> You can't ship them if you keep losing them ....

</comment><comment><USER13> Is this why Dr. Dre stopped tweeting at the end of April?

</comment><comment><USER14> Would this be a manufacturing or software issue?

<comment><USER15> The Beats sport earbuds that use the same chipset went on sale today - <USER2> presumably it's a hardware issue.

<comment><USER16> The PowerBeats have the same W1 chip, but they don't have the same motion sensors, beam forming mice, IR sensors, and other hardware and software that goes in to making the EarPods. There's a lot of software involved in tweaking all of that stuff that goes way beyond the W1 chip.

</comment></comment></comment><comment><USER17> Bluetooth headphones are a solution in search of a problem.

<comment><USER18> I disagree. I work in a lab (biology), and I listen to podcasts, books, and music for a large part of most days. I currently use wired headphones, but the cord tugs at them all day. In addition, wires get caught. Just today, I was stooping down to put something on the bottom shelf of a freezer, and when I started to stand up, the cord caught on my knee and yanked the headphone right off my ear. This kind of thing happens to me daily.

If there were a good, long-lasting (battery-wise), decent sounding pair of headphones, I'd gladly jump on board.

<comment><USER19> Run the cable down the back of your shirt, secured at the collar with a bobby pin.

<comment><USER18> I have to take them on and off a lot for various meetings and encounters. There is probably some solution, but wireless is likely to be the most simple, in my opinion.

</comment></comment></comment></comment><comment><USER20> Jack coming back in 3, 2, 1...

</comment><comment><USER21> Can someone explain what this means for their share price?

<comment><USER22> Sure: Mainly it means that Apple is struggling with their supply chain, which for a hardware manufacturer isn't great. But since this is a brand new product it doesn't impact current revenues, but it does impact outlook.

<comment><USER23> > Sure: Mainly it means that Apple is struggling with their supply chain

They haven't clarified if it's a software or hardware issue yet, so we can't say that for sure.

<comment><USER22> On a higher level, software is part of the supply chain. The only difference is that the vendor is a internal business unit.

<comment><USER24> Well then I guess hamburger is vegan because it's made of cows which are made of grass.

<comment><USER25> No, consciousness is crucial. It's like, as the German media theorist Kittler says, "there is no software". From a certain perspective. A perspective that ignores conscious experience.

(I realize that you were joking)

</comment></comment></comment></comment></comment></comment><comment> UVB-76 Hopefully the delay is a chance for the product designers to go back to the drawing board.

I simply cannot fathom why anyone would want to own a pair.

<comment><USER11> You don't see any merit to beam-forming microphones for noise cancellation, seamless paring experience, Siri access, other-earphone awareness, or lack of tangled wires?

You don't remember how iconic the white earbuds have been as a status symbol?

It's fine, and even expected, to say, "This product doesn't fit my use-case." But to be unable to fathom why any person on the earth would want to buy the product... that takes a total disconnection from headphones as a category of device, and I'm not willing to believe that's true.

<comment><USER26> My biggest complaints is that they are in-ear. I really wonder how they will stay in place outside of a desk chair or a couch. At least with a cable you had a chance to catch it when it fell. An ear-clip version would be great.

<comment><USER16> Then perhaps you should read any of the many reviews by people who have had preproduction units... They pretty strongly lean towards them being comfortable and hard to dislodge - to a surprising extent. Tests in reviews I've seen have included running, dancing, headbanging, and jumping up and down intentionally trying to dislodge them.

Seems that the fact there's no cord to pull on them, and all of the mass is inside your ear makes them pretty stable.

<comment><USER26> I didn't see preprod reviews. I'll dig for it.</comment></comment></comment></comment></comment>


Show HN: A real-time collaborative drawing canvas made with Elixir and Phoenix - <AUTHOR> https://remote-draw.herokuapp.com/ <comment><AUTHOR> Hi, everyone – wanted to get a sense of how many simultaneous users this setup can handle using with a single Heroku dyno. State management is far from ideal (and very unstable), but was something I could hack away pretty quickly. Let me know your thoughts, and I'd be happy to share the codebase if anyone has interest :)

Thanks!

</comment><comment><USER2> You mention that the state management is far from ideal. How did you choose to manage state in this project (or is there a GitHub repo to have a look at)?

</comment><comment><USER3> Interesting project. Congrats! Can you link to the GitHub repo?</comment>


The Disease That Turned Us into Genetic-Information Junkies - <AUTHOR> http://nautil.us/blog/the-disease-that-turned-us-into-genetic_information-junkies

<comment><USER2> At first glance, it'd also be a good argument in favor of intermarriage.

</comment><comment><USER3> tl;dr Tay–Sachs disease</comment>


Global Village Construction Set: Open source tools and machinery - <AUTHOR> http://openfarmtech.org/wiki/Global_Village_Construction_Set

<comment><USER2> So how do we franchise this startup ?</comment>


The Flare-On Challenge 2019 Started - <AUTHOR> https://2019.flare-on.com/ <comment><USER2> For those not initiated, this looks like reverse engineering challenges.

How far have folks gotten? I'm on Challenge 3.

<comment><AUTHOR> I'm working on Challenge 5.</comment></comment>


Man keeps same Manhattan parking spot for 11 years, feeds meter $36/day - <AUTHOR> http://www.nypost.com/p/news/local/manhattan/parking_squat_LwA3wlvBMZXHOeDYl7quUJ

<comment><USER2> Say what you want, but he's making more than Groupon.

</comment><comment><USER3> $11 years?

<comment><USER3> Heh, title changed, my comment makes no sense anymore. :)</comment></comment>