I enjoyed watching the video and thought the speaker did a great job, but I can't say I agree with her.
When you start to have spreadsheets that require even a moderate level of analysis, tooling and refactoring then you need to move to a real programming language and environment where you get the benefits of a development eco system that establish application integrity (i.e. user access control & applied methodologies).
I've been involved in projects where companies create these MOASS apps and no spreadsheet or spreadsheet tooling will solve these problems. You may not spend the 'X' months and 'X" dollars to develop the app, but your spreadsheet app will produce incorrect results often and more easily, which will cost you more in the long run (forget the fact that employees will leave which only compounds the problem).
After responding in this thread I ventured a little further into what GDPR would look like within the apps I am building and OMG the ability to comply could be horrendously challenging.
For example, some of my apps use Datomic, which contains both an append only log file for data storage as well as bulk storage data facilities provided by 3rd party db systems. And that doesn't even take into consideration indexes. So deleting user data would be a non-trivial exercise.
Simply put: modern day data system architectures have grown in complexity to the degree that you simply just can not push a button and remove user data anymore.
Here's some further discussion if anyone is interested.
Well practically speaking it only applies if there is something the EU can do about it and if you're doing business in the EU they certainly can do something. Even FB, for example, needs to conform otherwise all that ad revenue from EU companies can vanish if the EU governing bodies sees fit to do so.
But the most the EU could do about the Arc forum would be to block EU users from accessing the site (which would be a political nightmare for them in censorship terms). And, in reality, this site doesn't hold any real data worth worrying about and I somehow doubt PG is sitting around worried about what the EU thinks (regarding this site).
None of this has anything to do with what I think of the laws they are creating. Frankly from the little that I've read I kinda like what I see, but still the world doesn't abide by whatever the EU says, as a parallel example... just look at how much trump cares about nafta right now and that's an agreement they signed. (I'm Canadian btw).
There's really not much happening in CL that can't be achieved in Clojure (or vice versa for that matter). Just grab a library and write your macros to obtain your desired level of brevity/utility. The first thing I did when moving from Arc to Clojure was port over the web service routing along with the html/json generators & parsers. Since then my server code has morphed into a custom unique hybrid, and now when I look at all of these other examples I think ugh, I'll pass thanks.
I think it is a killer feature in a round-about way. I believe the killer feature is actually generic and robust database integration. There's a whole lot of people who start with data on hand and need to hack together an app from there. The starting point to db integration is racket, which also gets you access to other libraries. Once in place arc libs can be created eliminating a need to even learn racket (just like there are plenty of clojure programmers who don't know java).
IMO doing package integration first is putting the cart before the horse.
> the killer feature is actually generic and robust database integration
That could be a killer feature, but I don't think we have it developed yet. I certainly wouldn't have thought of it. Basically, when I say "killer feature", I'm thinking of the specialization or distinguishing characteristic that we would emphasize in a Quick Start tutorial.
When arc was first launched, the "arc challenge" of building a multi-action website with a form in only ~5 lines of code was the "special feature." Right now, I think hackability and simplicity of the syntax are two of the better things, but we could probably specialize on more.
> IMO doing package integration first is putting the cart before the horse
The purpose for working on package integration is to enable further development. Without the ability to share code easily, it's a lot harder to build on and benefit from community effort. In itself, I agree, a package manager is boring and probably not a killer feature. However, making it really easy to start building something useful by searching for and loading relevant code straight from the interactive console would be a pretty big step.
Perhaps the specialty I'm looking for is exploratory programming, which we've mentioned before. Our interactive help system is pretty good. The only problem others have mentioned before was that Python is arguably better, just because there are already examples and libraries for doing most activities, whereas Arc requires a lot of development effort just to get fundamental components working.
> Without the ability to share code easily, it's a lot harder to build on and benefit from community effort.
I've just been dumping my Arc experiments into the Anarki repository. Akkartik manages it by the policy that pretty much anyone can commit anything, so I haven't had any issues sharing my code. I've recently put a Puredata compiler in Arc in there, https://github.com/arclanguage/anarki/blob/master/lib/pd.arc
The interactive help in Anarki is great, although there are some undocumented functions. A great improvement, which would be very easy to implement, would be to add the documentation from the various Arc sites to the Anarki interactive help.
Well there's that, but honestly... exploratory programming with a tool that can't provide basic functionality will limit how much you can explore. I think you mean 'language design exploration'? - if so I'll stop right there, since, well, frankly... it's not my wheelhouse. :)
> package integration first is putting the cart before the horse
I'm simply saying that features like db integration bring users, users bring manpower, manpower will provide package management in a way that ensures it accounts for more use cases, but again this is moot if what you're interested in is only the language development arena. Though I'm not sure how you could prove out a language unless you can actually use it for real world work.
P.S. If you want users, then killer feature would = todo list mobile app with local db in 30 lines of code!
> exploratory programming with a tool that can't provide basic functionality will limit how much you can explore
Absolutely true, which is why I do think the Racket integration is important, so we can just wrap its many and powerful libraries in lighter-weight arc libs, and also why I think a decent package system is important. It needs to be easy to share code, and to find solutions to problems. Otherwise everyone spends too much time rebuilding the same wheels.
> features like db integration bring users
Absolutely. I think better db support in arc would be awesome to have. Especially if we can build an ecosystem where "intelligent defaults" are the norm, so that 90% of the time the exploratory developer can get a db up and running with 1-2 lines.
> todo list mobile app with local db in 30 lines of code
An admirable goal. That's actually a great idea of something we could work toward as a community project, each building pieces that eventually come together to make a decent modern app.
> Were you thinking a mobile friendly web app, or trying to run it natively on a phone?
The java/js ecosystem has the largest reach making it the easy choice. One could work on a js compiler and target pouchDB as a starting point. That said choosing js also makes Arc go further down the path Clojure has already gone putting the two closer together, and with Clojure being so far ahead in that arena then maybe it's doomed to fail. The other way to go is to do what Clojure is not great at. iOS development? maybe integration with swift? At any rate I'm not a language development guy. I can only tell you what would appeal to me. I mostly use Clojure and a really easy to use arc->iOS app development ecosystem would be really cool.
Why does this poll say 0 points for stripe when I've voted for it. When I originally visited this post and voted the point counter went up, then I revisited and the points went back to zero.... I smell a bug.
We don't have access to the actual code running live on the site, but looking at policies from back in 2009 or so, it looks like you may have run afoul of the sockpuppet detector: https://github.com/arclanguage/anarki/blob/8e330f1242/lib/ne.... That's too bad; sockpuppet detection is overkill for a site this niche.
BTW I'm thaddeus. I check in once in a blue moon, but decided to vote on this and forgot my password so I created another account;).
And it looks as though, because I created the account seconds before voting, I failed at least one test in 'legit-user':
It's possible I failed new-age-threshold* too, but I wasn't all that interested in investigating further.
I dunno; I understand the reasoning, but it still seems like a bad design choice. I'd much rather, circumstantially, be put through a better legit-user test on account creation than to see a forum introduction like that. Oh well, the odds are low for a new user to vote on a poll as a first action anyway. I just seem to always beat the odds :) haha.
Depends somewhat on residency. If you live outside the US PayPal charges terrible currency fees and they also have a reputation for holding your money hostage when your situation/product is non-standard to them. I intend to use stripe, but not with arc. Just thought I'd put my three cents in anyways.
It seems to me that most of the web does not care about a free software option. So why, may I ask, do you?
Personally, I see Stripe as being a trustworthy source and I'd much rather use a non-free version from a trustworthy source than a free version from an untrustworthy source. Yeah you can read the code, but no one is going to do that anyways (besides there's more to it than just looking for something nefarious in the code, you also have to make sure there are no missing parts that lead to vulnerabilities and unless you know what the missing parts are....)
edit: also do a paypal search on HN and you should see their reputation is terrible from a vendor perspective. I think their success is largely due to being the first on the market and establishing a significant base at a time when using cc's on the internet was scary and hard. But stripe, and others, have changed the payment landscape. We can now use cc's for vendor payment with ease. So why Paypal? To cater to people without cc's?
You do have a point there, as probably most people on the web run non-free JS.
I'd of course argue that this doesn't mean that most people don't care -- because plenty people I know get real pissed off about video ads, anti-adblockers, pop-up forms, and all that jazz -- but they don't know that this is almost always non-free JS.
So, even if we were to assume that the non-free Stripe JS code is trustable, and ask people to run it, then I'd never recommend anyone to use a browser that runs non-free JS.
Yes, people can use adblockers, but there's plenty more nasty stuff non-free JS code can do, and does, so I wouldn't ask anyone to do that.
Yes, there could be free/libre JS malware, but like who'd ever do
<script> /* Code to log users' keystrokes before they send their message */ </script>
> this doesn't mean that most people don't care -- because plenty people I know get real pissed off...
Those people you know who get pissed are either A: not representative of 'the web' or B: not caring enough to stop doing what they are doing. So I will stand by "most of the web does not care" (and yes I am inferring you have to care enough).
> I'd never recommend anyone to use a browser that runs non-free JS.
"most of the web does not care"
Unfortunately this is the world we live in and trust is currently a staple of the internet even as scary as that is to some people.
I have to trust that stripe.js is secure - that's what I'm paying them for and if they get a bad reputation like Paypal has then people, including myself, will stop using them and stop paying them. Frankly for a cc payment type script I think their code should be audited by professionals that can see more than just keystroke loggers and if there are any vulnerabilites then the auditors should have the power to shut them down.
If at all you think I'm not on your side I'll suggest you're wrong as:
* I deleted my facebook account 10 years ago.
* I deleted my minimal Linked-in account 2 years ago.
* I don't use an ad-blocker, but I:
* make mental notes not to buy their products because the ad pop'd up.
* don't revisit websites that have ad pop up.
* avoid sites that have ads.
Using an ad-blocker is admitting defeat and I'm not there yet!
First, congrats with getting of Facebook and Linked-In!
Yes, most of the web doesn't care about non-free JS.
However, for me, it's higher priority to do what I think is right, rather than what is popular. If I didn't care about free software, I'd just put stuff on Ebay instead.
That's also why I coded this new event calendar in Arc -- that you can check out in the Anarki repository -- because I'm part of this art collective where everyone have been publishing events exclusively on Facebook, which is super annoying when you don't want to be used by Facebook.
I wanted to make something that was as easy to use but free, because many artists can't be bothered to use FTP to edit plain text files, and all the PHP calendars I looked at were overengineered overcomplex piles of drupal.
Anyway, I might look into Paypals Python SDK, because Hy makes Python acceptable.