This looks like it's by Manuel Chakravarty. He's a long time Haskell contributor / researcher. His research lab is responsible for a huge chunk of array fusion related research that's happened using Haskell over the years.
Given the baked in support for sprite kit, I presume that this is an evolution of the tools he used to teach his young ones how to write games.
I really enjoyed reading about that learning / teaching process as it unfolded. I think the discussion is at the GitHub repository https://github.com/mchakravarty/lets-program , though a glance doesn't reveal how up-to-date it is (it refers to 3 coding sessions, then numbers them 1 through 7).
As required by the Mac App Store, Haskell for Mac is sandboxed. Consequently, Haskell code executed in a Haskell for Mac playground cannot access any data except for Haskell for Mac documents, the app container, and those system files white-listed by the operating system. Any attempt to access other files or to initiate a network connection will be rejected by the operating system.
This seems unnecessarily crippling. Is this really required of desktop App Store apps?
Yes, it’s required. Only some apps are exempt from sandboxing because they existed before sandboxing was introduced. You can also reach out of the sandbox through some user actions, for example opening a file using the system file picker gives you permissions to access this file. Yes, it’s a big constraint. For some apps it’s a show-stopper. As user I mostly welcome it because of the additional protection it gets me.
Apart from that it doesn't get you any additional protection whatsoever. With all the root OS X exploits floating around that bust you out of the sandbox as well as giving you full system access, as someone that has several utilities on the Mac App Store, it would be trivial to put an app there that gets set off by a timer, exploits root, and wreaks havoc.
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.
>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
As for protecting against incompetence and mistakes, that is far too an extreme of a measure solely to protect against that. Some decent QA will fix that.
So what is the point, really, of sandboxing if it does not thwart highly technical attackers? It severely limits the functioning of apps, makes it far more difficult for app developers (myself included), and for what benefit that could be worth the trade off?
> So what is the point, really, of sandboxing if it does not thwart highly technical attackers?
It thwarts the attackers who aren't highly technical, and frustrating the script kiddies could have flow on effects when beginner attackers don't get the reinforcement to motivate themselves to refine and build their skills.
Secondly, exploits can be patched over time. Ten years from now, is OS X going to be better off for having the sandbox? Do you expect a lot of trivial exploits to be discovered after another century of person-hours are invested in the sandbox?
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.
Which is completely pointless. If a hacker wants to hack your system, the very last thing they want to do is destroy your OS. Who cares about the OS, it's just one re-install away and you got it back. If a hacker were to hack into your system they would want your data, your passwords, your bank account details etc. Or they would want to use your system to do illegal things that look like you did it.
It's in the best interest of the hacker that broke into your system that your system continues to work flawlessly for both you and the hacker. This is why Mac OS X "rootless" is just yet another obstacle for the power user, yet another obstacle when compiling and installing POSIX code from source, and yet another step closer to locking down OS X to be an appliance like iOS.
The point of rootless (SIP) is to prevent malware from being able to embed itself into the system such that it's difficult or impossible to remove. And it's also a completely different technology than sandboxing.
No it doesn't. It should be vanishingly rare for software not shipped by Apple to be impacted by rootless. The whole point of the feature is to prevent files that should never be modified from being modified. The only software that I can think of that's impacted by rootless is Xcode, which is of course Apple's own app. I can't think of anything else that should be hampered by the inability to modify system files. Can you name any other software that has a problem with this?
And if you really want to disable rootless anyway, you can do so. Boot into the recovery partition and there's an option there to turn off rootless.
I'm also completely baffled by the claim that, just because no security solution is 100% perfect, that we shouldn't even try. That makes no sense at all. Yes, security is hard. But protecting you from 99% of all malware, even if there's the rare case of malware that gets past you, is still extremely useful. Besides, it's awfully cynical to declare that SIP is an impossible goal before you've even looked at it.
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".
I don't really know enough to form an opinion one way or the other, I just had recalled seeing it at the time I read your post. I wouldn't have used Asepsis even if I wasn't on El Capitan as I definitely didn't like the sound of how it achieved what it claimed (which you also pointed out).
There really aren't better ways to solve that on a mass scale at this time. I intend no offense but to be honest I care much more about my system's security vs your need to interpose system processes. SIP is a step in the correct direction for security. Is it perfect or a catch all? No of course not but it's another layer of security that helps the situation overall.
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.
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.
It is also the way to go on Android, iOS, Windows 10 onwards. And was on Symbian as well.
If an application get p0wned, it won't be able to access more than what is strictly necessary to perform its duty, instead of free reign over my $HOME.
I don't understand why they're only releasing this through the App Store in the first place.
- Giving 30% to Apple is no small thing
- You lose the ability to maintain a direct relationship with your customers, provide upgrade pricing, etc
- Any updates are gated behind a delay-and-frustration-prone release process.
- There are plenty of services that will handle billing for 5% or less, compared to Apple's 30%. However, in the post-Stripe universe, implementing a webstore yourself is actually super easy.
Swift Playgrounds are sandboxed in about the exact same way. And for pretty obvious reasons, I'd think. (Or have people already forgotten about when Playground files would immediately destroy your home directory as soon as you typed in the code?)
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.
Exhibit A for how questionable this Sandboxing is when it comes to things like programming languages. And exhibit A for how Mac is becoming a household appliance instead of a general-purpose computer that YOU own and do with what YOU want. If you want to own your Mac you need to stay away from the AppStore at the very least, and ideally build all your shit yourself.
I'd bet that fewer than 5% of Apple customers want a general-purpose computer, and it hasn't deviated much from that over time. Apple has always locked down their hardware and software relative to their competitors. The "it just works" philosophy isn't free, and if it seems like it's getting more locked down, it might have something to do with Apple trying to maintain its profits in the face of increasing competition.
The "household-appliance" moniker is a red herring though. Just because they supply an App Store doesn't mean you have to use it, and it doesn't mean you can't do amazing things with it. Are we really comparing something that can help educate, research, run a business, entertain, etc. with a dishwasher or TV?
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.
So "people writing code" == "people who want a general purpose Mac"? And I didn't say Apple customers who buy/own Macs. Keep in mind that a lot of people get an iPhone or iPad first, then want to be more productive with a keyboard and larger screen, or just want to keep buying App Store-enabled Apple devices in general. These are not professional coders and are the overwhelming demographic that Apple is selling to.
Do you think they don't know who their customers are?
As opposed to a sandboxed device? Yes. Someone who wants the freedom to write code, install VMs, test browsers, compile C, you name it, no, they do _not_ want a little sandboxed device. The college student at Starbucks typing a term paper? sure.
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.
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.
And we have heard this for how long already? Doing so would basically be suicide for the Mac. First of all because a sizeable chunk of users are technical users. Secondly, a lot of software is not available in the Mac App store and likely will never be (I think Microsoft and Adobe would rather abandon OS X than giving 30% for each cloud subscription to Apple and being at the mercy of the MAS gatekeepers).
> First it was a setting in the preference panel, preventing you from installing non-MAS apps without disabling it.
Pretty sure the default is MAS + Signed Apps. This setting also doesn't actually stop you from installing a non-signed app. You just have to right click and select open to bypass the warning.
I actually keep this enabled so I know if an app isn't signed. So installing non-signed apps is a conscious decision.
> You just have to right click and select open to bypass the warning.
I think that you also need an admin password, which can be an issue for users who don't control their machines. (My work distributes Macs with users configured to be admins, but on Windows machines only allows standard users, so I assume that it's only a matter of time until they change policies and this bites me.)
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.)
And every single version, including minor version upgrades, this setting goes back to "MAS and identified developers," despite me explicitly setting to "Anywhere." If that isn't obnoxiously bad UI design (that I'm sure some idiot will defend), I don't know what is. I love the hardware, but the software is slowly turning to shit because of bugs (especially core bugs like not supporting many Bluetooth or RF mice/trackballs) and "features" like this. No two ways about it.
Did you remember that when you set it to "Anywhere" it gave you a little warning that if you didn't use the anywhere option for 30 days it would rever to "MAS and identified developers"?
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.
It hasn't happened to me, on any Mac that I use. 7 different OS installs (I develop for iOS and Mac professionally) something is wrong with your profile that you are restoring or something. That's not the standard MacOS behavior.
This setting in Preference Panel is opt-in, not opt-out. Default behaviour does not reject non-MAS apps. Most likely a security setting for companies or restricted environments.
I see the same tendency and I don't like it at all. It seems only a question of time until you will have to decide whether you want a computer or a Mac.
I bought it. If someone (cough)Jetbrains were to offer a full blown IDE with code-navigation, refactoring tools, smart autocomplete etc etc. I would pay them 10 times as much.
All that static typing shoud lead to an awesome IDE experience. Given that this hasn't happened, I wonder if there isn't something wrong with Haskell's design that works against it?
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.
I don't think there's stigma around Haskell, aside from maybe complexity. I think there often is around Haskell programmers; there's a rep for jerkishness. (Both are commonly attributed to Scala as well, though I think, as a Scala person, the rep for jerkishness is much more earned in Scala-land.)
Scala is another one of those languages whose type information should enable a really good advanced experience, but the IDEs are struggling with respect to their peers (heroic efforts from jet brains and type safe not with standing). As parent said, many communities really don't appreciate or understand IDEs, and so what gets done reflects that.
F# has pretty good IDE support, and type providers are really nice as code completion extensions. C++ has excellent IDE support in visual studio, note I'm including the debugger here also, as that is part of the experience!
Then there is objective C, Swift, Kotlin, Dart, Typescript, some versions of smalltalk. Many of those languages were designed specifically for IDE use (dart and typescript definitely).
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.)
It definitely provides some optimism with what is possible in Haskell, nice! I think it might be more of a community thing, many Haskell researchers I know don't have a desire for IDEs (so they don't write or use them as much), but I would also chalk some of it up to the language design and evolution not being very accommodating to the goal.
I'm guessing it works by refreshing the world right now, correct?
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.
Coming from the other side, it seems like "because you should be able to do it manually" seems like a poor reason to not provide the option to have things automated.
The computer is more accurate and faster at determining the type of an expression than humans are. That seems like a big part of the value proposition of static languages. So why not let it tell you the type in the editor instead of having to stop what you are doing to compile it (which may require fiddling with the code to get a meaningful type error)?
So you mean, Haskell has a bunch of people who prefer to use the force rather than their targeting computers? So Haskell's language design obviates the need for good code completion or pervasive display of type inference results?
Also, as the joke goes, well typed programs can't go wrong in Haskell because the debugger just isn't that great.
Most serious Haskell users are most likely using a REPL and when doing this it's trivial to get and think about type information even while checking other stuff. It's also obviously part of the thought process while developing anyway, so I don't see the same value in this as you do. There's a cost to having a full IDE anyway and it's more sensible to get the features you do want (auto-completion, etc.) from plugins and then not using a IDE.
Even if you want these things, there are better ways to go about this instead of making a whole gargantuan interface to get a couple of features.
I'm not usually one to tell people what they should be working on, but time could be spent on this instead:
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.
Donate to Free/Libre/Open projects working on this instead of locked-down proprietary ones. There are two promising projects approaching (not all there yet) exactly what you want: https://atom.io/packages/ide-haskell for Atom and http://leksah.org/
Reading this page, it sounds very cool. It also sounds like it's heavily inspired by Swift Playgrounds, including using SpriteKit as an example.
I am a bit baffled as to why it says the Haskell code can't initiate network connections. Yeah the app is sandboxed, but sandboxed apps can easily request network access. And it seems like that's a common-enough thing to want that it should support it.
You can request entitlements, such as network access, but you need to justify them in the App Store review process. Given that Haskell for Mac is pushing the boundaries of what is available on the Mac App Store, I wanted to err on the side of being too conservative for the launch version.
I will certainly work towards network support in coming releases.
Yeah, that one stuck to me as well. I don't know if they mean anything specific with "network connections" here, cause I see a lot of apps that talk to the outside world on the MAS.
While you are allowed network-connected apps on the MAS, you have to specify the entitlement. I'd imagine that's something you'd have to justify (or at the very least you'd get more scrutiny and a longer approval time).
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 would like to see some demo version, as 20€ is a bit too much to drop.
Looks cool, lots of inspiration from swift playgrounds. Though, aren't there any open source alternatives (I have never tried haskell), probably similar to ipython (jupyter) stack?
I know this is a statement of where the market is going, but boy is it depressing to see people saying that 20 Euros is too much to drop on a piece of software.
<rant>
Sorry, but we are not living in US or well developed European country (Austria, Switzerland, Norway..). In one workday I make ~40€ after taxes and it's almost twice the average and almost thrice the minimum salary were I live. I would've not said a word if I would've been making >50,000 € a year, like in mentioned countries.
Dropping half of my days work on a software, which has limited capabilities, unknown reviews, is closed source (even though is basically bundled open source tools in, I suppose, comfortable package), and can cause some extra bugs from it self. Give me ol' good 14 day trial, or I will not pay blindly.
</rant>
I don't think trymas was suggesting that €20 is too much to pay for a piece of software, but that it is too much to pay for software that you have not been able to evaluate at all first.
As far as I can tell, it isn't feature complete yet. I've got no problem spending €20 on this but I'm not really up for paying €20 so I can be a beta tester.
I'm a heavy iPython user and thought iHaskell would be a good way to try out the language on my Mac. Unfortunately I just wound up in Cabal Hell. I spent a few hours tracking down broken dependencies on GitHub before giving up.
This project looks exciting because it lets you get started with a working distribution. I'm happy to pay for the privilege of ignoring the mess until the language has proven itself to me.
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!
Yes, I totally understand the desire to try the app first. For the launch version, we had no choice, but to go with the Mac App Store.
I have started to investigate alternative distribution channels (which then would allow trials, too), but that will take a while to implement (so, I can't promise anything concrete at the moment).
I imagine that this is a naïve question, but it's sincere: what does this app offer for its $20 cost that the Haskell platform doesn't? Of their five big selling points, three don't seem really convincing: it mentions that it includes 200 libraries—more than HP, but not the sort of thing one needs to pay for; there is SpriteKit support, of which they say:
> We will release the SpriteKit binding under a permissive open source license for general use as soon as possible.
; and "Let the type system help you", which, of course, is just a feature of Haskell, not of this environment.
A drag'n'drop project manager is nice, but doesn't seem like that big a deal; so I guess that the real selling point is the "Immediate feedback". Indeed, that seems to be a huge selling point, and it's something for which I've often wished while coding Haskell. However, their blurb on it is very brief:
> Haskell playgrounds provide instant feedback, displaying types and results of computations, both textual and graphical.
Is there any way to read more about this, and, in particular, to evaluate how much value it adds before buying?
Quoting /u/kamatsu (from reddit): "Some context. This is a very early version released by /u/chak in time for ICFP. There are lots more features planned, so don't view this as the final product."
Comparing it to HP doesn't really make sense; it's a very early stage IDE with some yet-unreleased libraries and Xcode-like features/interaction (see Playgrounds) by a known GHC/Haskell developer.
Indeed, I should have made it clear that I was looking for an appropriate comparison, not meaning to suggest that HP (which was just the first thing that came to mind) was an appropriate comparison. Thanks for the insight!
I'm just glad there's a nice binary of GHC available to download from somewhere. I'm running 10.11, and I had to compile GHC from source (homebrew) on my MacBook air in order to install youtube-dl with rtmpdump support. It took literally all night to compile. Hours and hours and hours.
Another way to get binaries is to install with stack. See here: http://seanhess.github.io/2015/08/04/practical-haskell-getti.... At our first Utah Haskell meetup we had around 30 people manage to get GHC and some libraries installed, then complete a tutorial in less than a couple hours.
I would buy it if it were not sold through the Mac App Store and not sandboxed...
There are applications that make sense to sell in the Mac App Store, a programing environment isn't one of them.
80% of the app's value is Mac-specific UI patterns. Does Linux have a good port of that? I know there was NextStep/GNUStep, but I don't think it's up-to-date with modern Cocoa nibs.
This looks really cool! I tried learning Haskell on the Mac a year or two ago. It was painful having to use command-line tools and text editors. I eventually hacked Xcode to do the syntax highlighting and to run the build commands for Haskell. But that breaks every time Xcode updates, etc. This looks like it solves that problem! Can't wait to try it out.
One thing I'd like to see is how well it works for calling into the OS, or at least calling into or being called from C/C++/Objective-C (and eventually Swift).
It's a pricing problem. To begin with, $25 probably isn't enough to make the project financially successful, as it can't be expected to sell in large volume. Small-volume products need to find a sweet spot in the demand*unit-price curve. If no such spot exists, as may well be the case for software development tools, the developer may as well give it away. The Mac market is particularly low-cost, low-return.
Secondly, if the product were priced at a point where it produced a viable revenue stream - for example, Logic Pro X addresses a very large market and is priced at $199.99 - one could hardly expect the student discounted price for the full product to be less than $25. However, my experience has been that no matter how low-priced the product (greater than $0), students will always ask for a lower price. :)
It's sold through the Mac App Store only right now, so it's limited to what the Mac App Store allows, unfortunately.
Maybe in the future, if it goes well, the developer might consider selling outside the Mac App Store, and this have more flexibility. I have no knowledge of his plans on that matte,r though.
Been a while since I looked at App Store policies, but couldn't they charge a discounted price outside the store and then give a promo code to the app?
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.
Can someone who knows more about Haskell explain to me what the hell I'm getting for 25 bucks here? Cant I replicate all of the features it has with off the shelf tools/editors that are free? Wouldn't that path be less limited than this "sandboxed" app with "access other files or to initiate a network connection will be rejected by the operating system" restrictions?
>Cant I replicate all of the features it has with off the shelf tools/editors that are free?
You obviously get the convenience of NOT having to replicate all these, and the guaranteed experience of those parts working together as soon as you install it, and with a nice GUI at that.
Sounds good but still not convincing. For example, R can do the same thing, too, or even better. And it can be integrated with other programming languages. I would never buy it either until somebody really shows it's worth the money.
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 having to run a VM you don't often use is kind of defeating the purpose of the app.
If you're willing to run a VM for a single app you are probably the type of person who is willing to spend the time to set up a Haskell tool chain and libraries for free.
Although I am most definitely not that type of person, all I care about is playing with the language. Anything detrimental to that is just noise and not worth the time. So I consider the $25 quite a cheap price to not have to think about the extraneous actions required to get a Haskell environment up and running.
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 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.
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.
For 25 bucks, I'm going to get a bunch of limits (including the aforementioned sandbox ones) and these ones too:
"Haskell SpriteKit code can currently only be used in Haskell for Mac."
"can currently not be extended"
"We recommend to only use Haskell for Mac with Cabal files generated by the app itself."
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?
> 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!
Oh yeah.. evil programmer wanting 20 dollars from you. Good thing you saw through his plot and held them safe in your purse. We definitely all know what you know is 100% true, no one ever uses Haskell for anything else than web services and systems level programming.
BTW, a little late here... but my comment was actually intended as pure sarcasm over the fact that anyone would so angrily scoff at the idea of paying $20 to a fellow developer and Haskell enthusiast, who is just trying to help others enjoy the language.
Technically, that's true of course. I myself use the “computer” part only and shun the “AppStore” part as much as at all possible, but Apple is renowned for the deep integration of all kinds of components and there comes a point where you just don't have a choice any more. I seem to see the area of free choice getting smaller with every OS release.
There was no need for the developers to release this on the App Store. Anyone installing a Haskell IDE is perfectly capable of installing an app normally.
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.
Why do we still have platform-specific applications in 2015? Any good software engineering environment should set an example and show that we do not need to live by such artificial restrictions.
In my experience cross-platform means "runs just as badly everywhere". They pretty much never feel like native on any platform.
And what's the advantage to the average user? If I'm a Mac user, I'm interested in Application X working just like every other Mac application. Similarly if I'm a Windows user. I'm rarely bothered that Application X works the same on both Windows and Mac.
Those 'artificial' restrictions are as natural as they can get. Different operating systems have different Shells and APIs, even programming languages. Nothing artificial in there.
Because making a cross-platform GUI is quite the pain, unless you jump into web technologies. And even then you still have a lot of obstacles to go through, like SpriteKit is OS X only.
Because there’s no environment that would give you native-like experience on multiple platforms without extra work. And developers have limited resources, even in 2015.
Although it is possible to write everything, right up to the view model (but not the view) in something cross platform and performant, keeping the GUI/view using only those languages/frameworks which result in native feel (both in terms of look and performance).
Sure, writing the GUI properly for each platform still requires more work, but far far less if all but the front end is cross platform.
However, it very rarely seems to be done, even with modern additions and improvements in C++.
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.
Just a point of etiquette. Does it really make sense to down-vote a question to oblivion when the question has attracted reasonable responses?
In fact, this question contains by implication another seemingly reasonable question: Given that there exists a universally available cross-platform development API, why, in 2015, is anyone writing anything other than a web application?
Given the baked in support for sprite kit, I presume that this is an evolution of the tools he used to teach his young ones how to write games.