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.
This seems unnecessarily crippling. Is this really required of desktop App Store apps?
Source: https://www.google.com/search?q=os+x+root+exploit&gws_rd=ssl
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.
- 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.
We have started to investigate other distribution channels. However, adding that option will take some work (= time).
If not, there's your answer.
Wow... based on the sandboxing thing I had assumed it was an iOS app for learning Haskell on your iPad or something.
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?
What can a great IDE add to the experience of learning / using Haskell?
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.
I will certainly work towards network support in coming releases.
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?
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>
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.
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).
Also, this book is supposed to be a good intro to Haskell: http://learnyouahaskell.com/
If you'd like to just take a look, go to try.jupyter.org and select the "Welcome to Haskell" notebook!
> 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?
http://blog.haskellformac.com/blog/from-the-read-eval-print-...
The author also had a blog post on it here:
http://justtesting.org/post/103422773731/why-are-playgrounds...
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!
[1]: http://leksah.org
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).
Looks pretty cool though.
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. :)
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.
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.
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?
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.
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++.
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?
