Arc Forumnew | comments | leaders | submit | i4cu's commentslogin

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[1] 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).

1. Mother Of All Spread Sheets.


3 points by i4cu 43 days ago | link | parent | on: Arc forum GDPR compliance

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.

P.S. I realize I'm kinda hijacking this thread, and this has nothing to do with Arc anymore, but thought that hjek might be interested (or maybe not lol).


2 points by i4cu 54 days ago | link | parent | on: Arc forum GDPR compliance

No one is breaking these laws as the rest of the world is not subject to EU law. Unless you can show the US has adopted the law as a member state then you shouldn't go around stating such things.


1 point by hjek 49 days ago | link

To me, it currently reads more like the GDPR applies when you operate to users in EU,

> The GDPR is applicable to the US entities to the extent such entities process personal data in order to provide a service or a good within the EU territories.

> It doesn't matter if you operate or are established in the EU. If you have EU visitors/users they gain the protections of the GDPR and you have to comply.


2 points by i4cu 48 days ago | link

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.


5 points by i4cu 116 days ago | link | parent | on: List comprehensions in Arc

I don't know python per say, but I don't believe arc supports them. I do know the iterator functions are there for you:


4 points by akkartik 116 days ago | link

Yes, Arc doesn't come with list comprehensions. But it sounds like a fun exercise to build say a collect macro:

    (collect x for x in xs if odd.x)
I think it may be similar to the loop macro in Common Lisp. There's a Common Lisp implementation of loop at (via by malisper)


3 points by musk_fan 112 days ago | link

I wrote a simple version that only works like so (l 0 9) == '(0 1 2 3 4 5 6 7 8 9):

     (def l (start end)
       (let lis `(1)
         (pop lis)
         (while (<= start end)
           (= lis `(,@lis ,start))
           (++ start))
The (collect ...) structure is really cool; I'd forgotten about that; it's been awhile since I touched CLisp


2 points by akkartik 112 days ago | link

Great! A few comments:

1. Is there a reason you start with `(1) and then pop? Why not just initialize lis to nil?

2. Here's a slightly more idiomatic implementation (also more efficient, because it avoids deconstructing and reconstructing lis on every iteration):

    (def l (start end)
      (accum acc
        (for i start (<= i end) ++.i
Read more about accum and for:

    arc> (help accum)
    arc> (help for)
(I'm assuming Anarki in the above example. The Arc version is slightly different.)


4 points by i4cu 168 days ago | link | parent | on: Oldest Arc Forum item - 10 year anniversary

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.


3 points by shader 166 days ago | link

> 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.


2 points by hjek 165 days ago | link

> 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,

That said, there is an Arc package manager, Hackinator by awwx.

Perhaps that is worth a look?

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.


3 points by i4cu 166 days ago | link

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!



3 points by shader 165 days ago | link

> 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? I'm not really sure how the latter would work... Though building a compatible javascript base for arc would be pretty nice. I do like being able to use consistent code for both clients and servers, as in node and clojure.


2 points by i4cu 165 days ago | link

> 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.


4 points by i4cu 173 days ago | link | parent | on: Oldest Arc Forum item - 10 year anniversary

Just 90 more years to go...


2 points by hjek 167 days ago | link


3 points by i4cu 237 days ago | link | parent | on: Poll: What's the best payment system?

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.


4 points by akkartik 237 days ago | link

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: That's too bad; sockpuppet detection is overkill for a site this niche.

Try it now on some other vote (votes on polls seem to be using the same code as votes on stories or comments). If your vote sticks now, that would confirm my hypothesis. (


5 points by i4cu 236 days ago | link

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':

  new-karma-threshold* 2
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.


1 point by hjek 237 days ago | link

Perhaps the vote only got saved in your profile and not in the item.


3 points by i4cu 237 days ago | link | parent | on: Poll: What's the best payment system?

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.


2 points by hjek 237 days ago | link

On #stripe IRC, someone pointed me to this, , a free software replacement for Stripe.js

I've read about Paypal freezing Wikileaks' account. And, it seems that Paypal have closed off their REST API, and only SDKs for various languages -- not including Racket.


3 points by i4cu 237 days ago | link

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?


2 points by hjek 233 days ago | link

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[1][2][3][4], 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>




Also, I'm a bit sad that HN was changed to disallow voting w/o JS, but that's mainly because it means you can't vote from Links or Emacs :-)


3 points by i4cu 233 days ago | link

> 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!


3 points by hjek 231 days ago | link

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.