The other option was "there's a monad for that".

Because of the sandboxing and no networking limitations.

I own a Mac but I didn't even know what "Mac App Store" was. Why does such a thing exist? The concept of a centralized app store for desktop apps is absurd.

There are plenty of long-standing options other than Stripe if you don't go the "run the store yourself" route.

Here's a cynical comment:

Long term monetization will only work if he can ship version 2 at some point to pull in some more money from the same people who bought version 1 (and the same thing with version 3). The choice of not shipping obvious features of an IDE is in order to have better differentiation between versions.

Though, maybe there is really a good reason for that involving some of Apple's policies. I heard they teach the developers all kinds of lessons when it comes to how a program should be made... who knows...

I like that approach, but there’s no abundance of such cross-platform stacks either. And then you have to convert parts of the model to fit the views, and sometimes you want to use non-view technologies only available on a certain platform (Keychain, …). While it makes sense and the results are very good, it’s still a very non-trivial work, especially compared to a simple native app.

Try installing IHaskell with `stack`. `stack` is fairly new but it's solved all my `cabal` hell related problems. I put IHaskell in Stackage recently so you should just need to install stack, `stack install ihaskell` using a recent Stackage nightly resolver, and then `stack exec -- jupyter notebook` to start. Alternatively just `git clone` and run `stack install` from the resulting directory. If you end up trying it again but still encounter issues please file issues for me on Github so I can help!

They can charge for it on their own web site. No requirement to go through MAS to sell Mac software. If people are having a problem with this, complain to the author of the software.

I believe that it's not intended to be used like that (promo codes are also limited to 100 per application version now).

Also, this would require the developer to find a way to charge people outside of the store. In that case, it's almost half way to setting up a full direct store with a direct version.

There is benefit to having a direct version (all our applications do) but many developers today don't want to set this all up. It's quite a lot of work and perhaps the developer is not interesting in spending time on that. Moreover, he might not even be sure if the app is successful enough to invest time into this work.

> SO I can replicate everything this DOES with off the shelf tooling (maybe). And like any setup for a new language, or development environment I may have to RTFM and fiddle.

You can't, because you can't program yet, or are still working on improving your programming skills by experimenting with functional programming languages. Why else would you be commenting on a starter development environment for Haskell?

> Will these things be a problem? How long before I run up against a wall with this? Am I going to kick myself over the 25 bucks in 2 weeks cause one of these is a show stopper for some common task in haskell?

If this thing teaches you how to code common tasks in Haskell for only $25 bucks, it'll be the best money you ever spent.

If $25 is a large enough sum of money to cause serious regrets over the coming weeks, then certainly you have my sympathies, but I would suggest it's not actually an issue of what the Haskell package does or doesn't do, it's a situation where you need to decide you're just not in the market for commercial software until your financial situation improves. As you say, there are free DIY alternatives.

Like you, I am also sick and tired of people trying to come up with easy-to-use tools for learning Haskell. I love the language, and feel that if someone wants to learn it in a "sandbox", then there's no point. I can't even imagine Haskell without network connections, as we all know that Haskell's main appeal lies in web services and systems-level programming.

This developer better think again before he gets my 20ish dollars!

Haha, you didn't lay it on thick enough ;)

As I sit here in my building with 400 others sitting around me writing code on Macbook Pros. Knowing that in this industrial park alone there are other startups with hundreds of employees doing the same thing. (And this is in Utah - not San Francisco) I'd venture to say that 5% may be extremely off base. I'd say, you take every coffee-shop college student and match them against thousands who are writing code as we speak.

"I'd bet that fewer than 5% of Apple customers want a general-purpose computer"

I'd bet that fewer than 5% of any computer company's customers want a general purpose computer.

It's only $25.

I've been interested in playing with Haskell for a while but I've been put off by the need to setup existing tools. Having an all-in-one package with neat presentation, packaged libraries, and immediate feedback sounds like a great deal for $25.

I think the playground is probably its most unique feature. Other languages have it, but they're either too heavy to be practical (scala worksheets), embedded in a browser (python), or just not languages I care to work with (Swift). I love the idea of being able to throw some quick code together in a window, see immediate results and tweak things until I get what I want.

Haskell is particularly well suited to this king of workflow, everything being immutable and evaluating to a value. You can think of it as the best programmable calculator in the world.

This has little to do with Haskell as a language, and more to do with this specific tool. Your argument is a little like saying about paying for an editor "For example, VIM can do the same thing, too, or even better...".

What you get is a nice looking environment with a built-in playground alá Swift's, that can visualise data, types and even games.

R cannot compile Haskell code.

Yet.

First it was a setting in the preference panel, preventing you from installing non-MAS apps without disabling it.

Next it's the upcoming rootless OS X, System Integrity Protection: it's only a matter of time until the ability to install non-MAS apps is completely removed, buried, or hidden in Recovery mode (as the SIP setting is)

I suspect this will happen within the next one or two major versions of OS X.

This is a totally unproductive (if all too common) attitude toward security. "If it doesn't solve every problem, it's useless."

This protects against a whole host of issues. It safeguards against garden-variety incompetence[1]. It provides some defense against the large number of badly-intentioned people who can write an Objective-C app, but don't have the expertise necessary to weaponize a typical root escalation exploit. It prevents apps from accessing your contacts, reading your emails, determining your location, and accessing the webcam and mic without your knowledge, amongst other things.

Does it protect against a motivated, highly technical attacker? No, not really. But that hardly makes it useless.

[1]: http://www.macobserver.com/news/98/december/981229/bungierec...

I mean I can easily install an app to try it out, then uninstall and be reasonably sure it’s completely gone, without changing the rest of the system by incompetence or ignorance. That’s still pretty good. If the developer wants to harm you intentionally, that’s tough game on any system.

Your logic holds true for things like filesystem permissions and even separate user accounts. Since a privilege escalation exploit could give you root access, might as well do away with limited users and run everything as root to begin with, right?

And yet we do those things anyway. The idea is defense in depth, such that if one mechanism fails then hopefully another will mitigate the damage. Sandboxing isn't perfect, but it's another layer of security and I'd rather have it than not.

Hence https://en.wikipedia.org/wiki/System_Integrity_Protection

Except you have get through Apple's code review and then once you activate Apple can push a button and wipe out all the installs with a single button push.

Yeah, cracking is asymmetric warfare that we have no hope of winning, I think anyone with any knowledge of computers realizes that is true. It doesn't mean we should smugly shoot down anything that makes it incrementally harder.

I think it's just that - the type system gives you so much, most hackers see a text editor with minimal type checking as good enough. Also IDEs tend to be commercial and I don't think any of the big companies see Haskellers as a good chunk of change. There's also quite a stigma many developers carry around regarding Haskell, though I don't understand that.

There is nothing wrong with Haskell. It's just that writing an IDE is a lot of work and nobody bothered to invest that work so far. Haskell for Mac changes that. (I'm biased — I wrote it.)

This sort of assumes that the objective of a language should be to create "an awesome IDE experience", while there's a good chunk of people who think having to have an IDE is simply a flaw in a language.

EclipeFP exists.

The main problem is that there aren't good ways for Haskell analyzers to communicate with a Java/C++ UI in memory. So you get clunky+slow network/IPC APIs (or worse, communication via filesystem) for stuff that ought to be tiny in-process method calls.

And writing the whole UI in Haskell is...not Haskell's strength area.

Atom with the ide-haskell package does a pretty good job.

Depending on how many other dollars you have to spend on things that you might enjoy eating.

I already have the Haskell toolchain and libraries. It merely required the command "apt-get install haskell-platform". However, the Haskell Playgrounds feature that Chakravarty offers sounds interesting enough to spin up a Mac VM.

I'm a little surprised by the downvote; I may have made a mistake, or it may be something peculiar about my configuration, but, when I try to run an application, even if I control-click to bypass the policy, I still have to enter my administrative password. Is this not the way it usually behaves? (As I say, it's a work computer, so perhaps they have some unusual security policy in place.)

No, it isn't. Not even close.

You can do all of those things with OSX. This whole discussion doesn't make sense because you can do pretty much whatever you want outside of the app store ecosystem.

Which languages have better IDE support than Scala?

Java, C# ... and both received probably hundred times more man-power than Scala IDEs.

What else?

My experience: All dynamic languages – probably not. C++? Hell no. F#? No. OCaml? No. Haskell? No.

Which language do you think of?

It wasn't the norm in the past, but that has changed. For those whose memory goes back to the pre-X MacOS, there has been a decline in “respecting your user's decisions” and an increase in inconsistencies. Progress in some areas has definitely cost quality in others.

Nope. Tested it on three different systems and it happens every single upgrade.

Which in of itself is pretty much an impossible goal, and in the meantime, it destroys a litany of use-cases that make computers useful to people.

Oh geeze. That doesn't even have anything to do with rootless. The issue there is library interposing. Asepsis works by interposing itself into every process that links DesktopServicesPriv.framework and replaces several libc calls.

Good catch on finding something that breaks with SIP, but even if you philosophically disagree with the idea of rootless, you should still agree with the notion that library interposing is a serious security threat and should welcome the changes to block interposing of system processes[1].

[1] From the What's New In El Capitan docs[2], the specific aspect of SIP that applies here is "Code injection and runtime attachments to system binaries are no longer permitted".

[2] https://developer.apple.com/library/prerelease/mac/releaseno...

And this is why we can't have nice things.

I recommend that you tally up the revolutionary technologies produced over the last 30 years that allowed us to get to this point (including the web), and then consider how many of them could be invented on Mac OS or iOS today.