Arc Forumnew | comments | leaders | submit | i4cu's commentslogin
3 points by i4cu 18 days ago | link | parent | on: How to handle Racket types?

I think the problem might be that Arc doesn't support some of data types that you are getting from the json response. For example Arc does not support booleans true/false it only has 'nil' or not a nil value. That's why, in the past, I used Andrews library [1].

That said I haven't had a running install of arc in many years so I could be off base.

1. https://github.com/awwx/lib/blob/master/fromjson2.arc

reply

4 points by akkartik 18 days ago | link

Looking through the Anarki logs I think I'm seeing signs of our first edit war. It's been very gradual so we haven't noticed until now.

Anarki used to use Andrew's library from http://awwx.ws/fromjson (perhaps an older version of your link, i4cu) I switched it out back in 2009 for a faster replacement (https://github.com/arclanguage/anarki/commit/dad4dc6662), not realizing that I was breaking the read side in this rather obvious manner. Since then a bunch of work has happened on emitting JSON, but apparently nobody tried parsing JSON until now.

We could retrofit these bugfixes, but I think it would just give up the speed gains to parse things character by character. May be worth just returning to Andrew's version.

But I'll try working with the existing version first, just in case it's still fast.

reply

4 points by i4cu 17 days ago | link

Just my two cents, but if I were using Arc today I'd consider doing what could be done to conform to the edn spec [1]. It was born out of Clojure, but is not Clojure specific. Also, as I understand it json is actually a subset of edn thus the two would not collide. But for now I think just getting a json parser running would be a win.

https://github.com/edn-format/edn

reply

4 points by krapp 17 days ago | link

Possibly a silly question but... could we just add support for those types in Arc?

I mean, as long as Racket interop is going to be a thing, maybe using the boolean type isn't a bad idea.

And by "we" I mean "probably you," of course.

reply

2 points by hjek 9 days ago | link

Arc already supports Racket booleans:

    arc> (if $.#f 'foo 'bar)
    bar
    arc> (if $.#t 'foo 'bar)
    foo
They work, so what is the problem?

Also, I don't get why the Anarki repository contains a JSON parser implemented in Racket, when the built-in Racket JSON parser works just fine with Arc:

    arc> ($ (require json))
    arc> ($.write-json (obj foo "bar"))
    {"foo":"bar"}#<void>
    arc> (w/instring in "{\"foo\":\"bar\"}" ($.read-json in))
    #hash((foo . "bar"))
I fail to see the problem with the Racket built-in JSON parser here. Would anyone care to explain?

reply

2 points by akkartik 9 days ago | link

Thanks! I think you're right that the existing JSON parser is unnecessary. But there's still an open problem about translating to Arc:

    arc> (w/instring in "{\"foo\": true}" ($.read-json in))
    #hash((foo . #t))
We'd like this to translate to:

    #hash((foo . t))
Perhaps what we're looking for isn't related to JSON at all, but a general shim for translating the output of Racket functions. That could be broadly useful.

reply

2 points by hjek 9 days ago | link

Why do we need to explicitly translate #t to t? Arc has no problem handling Racket booleans.

I'd like to see perhaps a specific brief example, where using Racket booleans within Arc actually is a problem, because I haven't encountered any myself.

If I try to use the hash from your example in actual Arc code, it works fine:

    arc> (if ((w/instring in "{\"foo\": true}" ($.read-json in)) 'foo) 'yes 'no)
    yes
    arc> (if ((w/instring in "{\"foo\": false}" ($.read-json in)) 'foo) 'yes 'no)
    no

reply

2 points by akkartik 8 days ago | link

Wow, that's kinda mind-blowing. I had no idea. Thanks!

Ah, here's perhaps the only special-case we need to handle:

    arc> (= x (w/instring in "{\"foo\": null}" ($.read-json in)))
    #hash((foo . null))  # expected: #hash((foo . nil)) or #hash()
    arc> (if x!foo (prn "error"))
    error

reply

2 points by rocketnia 8 days ago | link

For round-tripping between JSON and Arc, I would expect the JSON values {}, {"foo": null}, {"foo": false}, and {"foo": []} to parse as four distinct Arc values.

I recommend (obj), (obj foo (list 'null)), (obj foo (list 'false)), and (obj foo (list (list))). Arc is good at representing optional values as subsingleton lists:

  ; Access a key that's known to be there.
  t!foo.0
  
  ; Access a key that isn't known to be there.
  (iflet (x) t!foo
    (do-something-then x)
    (do-something-else))
Using my `sobj` utility, you can write (obj foo (list 'false)) as (sobj foo 'false).

Meanwhile, I don't think there's any big deal when we don't have Arc-style booleans....

  ; Branch on the symbols 'false and 'true.
  (if (isnt 'false x)
    (do-something-then)
    (do-something-else))
  
  ; Alternative
  (case x true
    (do-something-then)
    (do-something-else))

reply

2 points by hjek 8 days ago | link

> ; Branch on the symbols 'false and 'true.

We do already have booleans that work in Arc without any conversion. Please see http://arclanguage.org/item?id=20492

There's absolutely no need to convert the booleans to symbols and other hackery.

reply

3 points by rocketnia 8 days ago | link

I liked it when it was returning #f.

But now that I look closer at the ac.scm history (now ac.rkt in Anarki), I realize I was mistaken to believe Arc treated #f as a different value than nil. Turns out Arc has always equated #f and 'nil with `is`, counted them both as falsy, etc. So this library was already returning nil, from Arc's perspective.

There are some things that slip through the cracks. It looks like (type #f) has always given an "unknown type" error, as opposed to returning 'sym as it does for 'nil and '().

So with that in mind, I think it's a bug if an Arc JSON library returns 'nil or #f for JSON false, unless it returns something other than '() for JSON []. To avoid collision, we could represent JSON arrays using `annotate` values rather than plain Arc lists, but I think representing JSON false and null using Arc symbols like 'false and 'null is easier.

reply

2 points by hjek 8 days ago | link

Having nil represent both false and the empty list is also what Common Lisp does.

Really, #t and #f are not proper Arc booleans[0], so it makes sense that Arc can't tell what type they are.

You can configure the value Arc chooses for a JSON null with the $.json-null function, which I think is fine as JSON APIs might have differing semantics.

[0]: http://arclanguage.github.io/ref/combining.html

reply

2 points by rocketnia 7 days ago | link

That documentation may be wrong. On the other hand, it may be correct in the context of someone who is only using Arc, not Racket.

There are a lot of ways to conceive of what Arc "is" outside of the Racket implementations, but I think Arc implementations like Rainbow, Jarc, Arcueid, and so on tend to be inspired first by the rather small set of operations showcased in the tutorial and in arc.arc. (As the tutorial says, "The definitions in arc.arc are also an experiment in another way. They are the language spec.") Since #f isn't part of those, it's not something that an Arc implementation would necessarily focus on supporting, so there's a practical sense in which it's not a part of Arc our Arc code can rely on.

(Not that any other part of Arc is stable either.)

reply

2 points by i4cu 7 days ago | link

> Really, #t and #f are not proper Arc booleans[0], so it makes sense that Arc can't tell what type they are.

Really, #t and #f are not proper Arc anything, but the language apparently handles them so IMHO Arc should also be able to know what type they are. Otherwise, I fear, this will become a Hodge Podge language that will lose appeal.

Personally I don't care if Arc supports booleans. I only care that it can translate booleans (when need be) to a meaningful Arc semantic. That said, if we're going to support booleans then let's not create partial support.

reply

2 points by hjek 8 days ago | link

Nice example. (So much easier to tell what's going on when you have these brief examples)

Actually the Racket docs[0] clarifies the situation with null in JSON:

    (json-null) → any/c

    (json-null jsnull) → void?
      jsnull : any/c
> This parameter determines the default Racket value that corresponds to a JSON “null”. By default, it is the 'null symbol. In some cases a different value may better fit your needs, therefore all functions in this library accept a #:null keyword argument for the value that is used to represent a JSON “null”, and this argument defaults to (json-null).

If you set the JSON null to nil before running your example, it works as you'd expect:

    arc> ($.json-null nil)
    #<void>
    arc> (= x (w/instring in "{\"foo\": null}" ($.read-json in)))
    #hash((foo . nil))
    arc> (if x!foo (prn "error"))
    nil
I think we should get rid of json.rkt and use the Racket built-in. It's way better documented, and we should use that one. (But I'm not going to delete json.rkt myself, particularly when I know someone is working with it.)

[0]: https://docs.racket-lang.org/json/index.html

reply

3 points by krapp 8 days ago | link

I got an error saying #t was an unknown type when I tried to do a boolean check on it, as it was passed from a JSON response. It's the reason I started this thread to begin with.

reply

2 points by hjek 8 days ago | link

Would you mind preparing a simple code example to show this issue? I'm not sure exactly what you are doing.

reply

2 points by krapp 8 days ago | link

Sure... the if statement in verify-captcha is where the problem occurs.

It currently works but that's only because json.rkt has been modified.

    (def post-getjson (url params (o port stdin))
      (fromstring (post-url url params) 
        (read-json (port))))

    (def recaptcha-response (s r)
      (post-getjson "https://www.google.com/recaptcha/api/siteverify"
      (list 'secret s 'response r)))

    (def verify-captcha (req)
      (do
        (= resp (recaptcha-response recaptcha-secret* 
        (alref (req 'args) "g-recaptcha-response")))
      (if resp!success 
        (pr "success") 
        (pr "failure"))))

reply

2 points by hjek 8 days ago | link

> when I tried to do a boolean check on it,

Can I ask how you did a "boolean check" on #t?

reply

2 points by i4cu 9 days ago | link

$.#f means you need to add a handler on a value, that's not handling the value as it's supposed to.

reply

2 points by hjek 9 days ago | link

Is the $ the handler you are referring to?

You don't need to add any $ handlers to handle Racket booleans. They can be passed directly to Arc functions.

The $ is just there to get some Racket booleans.

reply

2 points by i4cu 8 days ago | link

sorry I don't have an install. I've been assuming:

  (if #f 'foo 'bar)
 
would error.

edit: and now I have and install... :)

reply

1 point by hjek 8 days ago | link

> sorry I don't have an install.

http://tryarc.org/

reply

3 points by akkartik 8 days ago | link

In fairness, tryarc.org it isn't always up lately. evanrmurphy has broached the subject of someone taking it over, but it hasn't happened yet.

reply

2 points by hjek 8 days ago | link

Yes, looks like it's plain Arc 3.1.

reply


You're pointing to a repository that was created 6 years ago and has had no work done on it - at all.

Just my two cents, but maybe you should do some work + commits and get the ball rolling before putting out a call for help on a untouched dead repository of your making. Or even better, pick some of the items from here [1] and start by contributing to Anarki as a community member.

1. http://arclanguage.org/item?id=20449

reply

2 points by noobie 19 days ago | link

You're right! I am working on it.

Just have a bunch of things to juggle at the same time. I just thought I'd give a shoutout first.

Thanks for the link - and the comment about discourse.

reply


By PR I assume you mean Project? Any interest in providing details?

P.S. I read your post and had a flashback. Eight or nine years ago I was working at a mega corp and couldn't get the company's shared resource team to do any work. At the time I was a BA and had been learning arc in my spare time (as a first language). Long story short I ended up coding an ETL via arc to load annual budget data (template data) from spreadsheets.

The good news was that it worked (no bugs), the bad news was that it was a hack. I lacked two core libraries; One was a spreadsheet-parsing-api library and the other was an oracle DB library. If I remember correctly I created a defop service where people could copy/paste data from the spreadsheet to an input box. Upon submitting the form the data would go through a validator process and return with feedback indicating errors in the data. When successful it would embed the data into a generated SQL string that would be run from my machine via a command line call. All this coded in like 2 days or so.

LOL. Companies have processes, but when things can't get done by the standard process watch every manager in the company thank you for saving the day. Sadly I think I got a bigger bonus than anyone on the dev team even though they probably would have done it right. I guess life rewards results over all else.

reply

3 points by akkartik 30 days ago | link

Can you link to the post you are referring to?

PR = Pull Request.

https://github.com/arclanguage/anarki/pull/99 https://github.com/arclanguage/anarki/pull/100

reply

3 points by i4cu 30 days ago | link

Ahh, well my whole comment is completely off topic; sorry. That's what 10 years of being a BA does to the mind :)

> Can you link to the post you are referring to?

I guess I should be using the expected terminology, that being a 'comment' not a 'post'. In my mind he 'post'ed a comment, but I understand I should have been more clear.

reply

2 points by akkartik 29 days ago | link

Oh I think I understand now, thanks :)

reply

3 points by krapp 29 days ago | link

Yes, sorry, I meant pull request.

Although I do consider it a personal project to fix the forum as much as I can and eventually spin off a lightweight, anonymous fork.

The most ambitious coding I've done was writing a custom CSV parser to add parts catalog data to the web backend of a lawnmower parts store, but that was in PHP. This is my first practical experience using a lisp, though.

reply

3 points by i4cu 29 days ago | link

Well if you're going to make fixes to the forum fix this one too:

http://arclanguage.org/item?id=20272

One thing to consider is that the code is really, really old and was built before cloudflare became a thing. Even the auth code is now fairly outdated (no captcha, no CSRF, etc. etc).

Don't get me wrong it's still useable, but depending on why you're doing this it may not be worth it. If it's to learn arc then swing away, but if I was looking to set up a forum today I's sooner look into installing the open source version of discourse.

edit: also check out shaders post on "Next Steps" [1] and more specifically [2]. Some of these items might overlap with your plans and if so maybe you can put a call out to others already doing the same thing to share in the workload.

1. http://arclanguage.org/item?id=20319 2. http://arclanguage.org/item?id=20324

reply

3 points by krapp 27 days ago | link

CSRF and captcha are definitely on the list, since i'm working on the forms anyway.

I do like reverse engineering the new features from HN in principle, although it's a shame that it's even necessary.

reply

3 points by hjek 9 days ago | link

CAPTCHA sounds interesting.

Would be seriously cool if the CAPTCHA was implemented in Arc and generated the images locally instead of relying on some Google SASS.

(I twiddled a bit with Racket's image manipulation functions in img.arc in the Anarki repo, if that's any help.)

reply

3 points by krapp 18 days ago | link

...speaking of which, I just now managed to correctly send and verify a recaptcha request.

Just have to figure out how to parse the JSON response and then integrate it into the forum and recaptcha should work.

I really should have checked that there was already an http library before trying to get it it work with Racket's, though.

reply

2 points by akkartik 18 days ago | link

What's the thinking behind implementing captcha? I really, really hate ReCaptcha. For most sites the payoff to a spammer isn't really worth even the simplest robot test. A new site that throws ReCaptcha is an instant bounce.

reply

3 points by krapp 18 days ago | link

>What's the thinking behind implementing captcha? I really, really hate ReCaptcha.

It might be useful if it only shows up on the login/signup page after failed attempts, but it might also be overkill. Personally, I prefer overt solutions to opaque ones like shadowbanning and throttling IPs. But mostly it seemed like a good way to figure out some basics (managing keys, how the app server manages the form loop, API responses and JSON.)

I could finish the test I have, push that and leave integration for later.

reply

2 points by akkartik 18 days ago | link

I agree with overt vs shadowbanning. My tendency is to just add tools for moderation. Let bots sign up and spam, but make it easy to take them down and ban them at that point. Arc is reasonably decent there.

reply

2 points by i4cu 18 days ago | link

If the content is publicly accessible and free then that works, but otherwise it doesn't help.

reply

2 points by akkartik 18 days ago | link

I don't follow the connection.

reply

3 points by i4cu 18 days ago | link

Sorry, my comment was rather lazy. Let me try again.

I get the impression many of the people who want to start a HN like clone are considering using it as a content delivery platform. For example http://arclanguage.org/item?id=20452 notes a revenue sharing model for specialized content. Now, if that's the case these site owners will have both spammers and content scrapers to contend with. So my initial comment was also referring content scrapers too.

However there's another thing to consider: Session storage costs. About 6 months ago I went through a process to reduce the cost of data held in memory for session storage (redis in this case). The session data was continually analyzed for determining both who the bad users were and for knowing what value the good users are getting out of the app (feature planning etc). It was an interesting process, where just by reshaping the session data, thousands of dollars per month could be saved in db fees. Now I realize the someone starting a HN clone is probably not dealing with that, but I'd be willing to bet that part of the reason Captcha was implemented in HN proper was to reduce fees associated with the volume of requests, session costs and even network load. It's my feeling that, generically speaking, adding captcha functionality is a good Option to have.

reply

2 points by i4cu 17 days ago | link

> I'd be willing to bet that part of the reason Captcha was implemented in HN proper was to reduce fees associated with the volume of requests, session costs and even network load.

Let me add some info to that.... I'm not sure if anyone noticed, but HN has implemented new session management strategies. You can see this as your login is now maintained across multiple devices, where the arc code (that we have access to) logs you out upon logging in elsewhere. I also believe that when pg handed over the HN code significant changes occurred including how session data is stored and how that data is utilized to integrate with cloudflare. Obviously I'm making big guesses, because I don't have access to the code, but I'm willing to bet the changes HN has put in place would surprise everyone here.

Sadly everyone who sees HN today will come here and look for the source code not realizing what's available here is not modern nor comparable.

reply

3 points by krapp 17 days ago | link

>Sadly everyone who sees HN today will come here and look for the source code not realizing what's available here is not modern nor comparable.

One thing I noticed when Arc gets brought up on HN is that everyone seems interested in the language but not so much the application. People seem to cargo-cult the forum for some reason.

reply

2 points by akkartik 17 days ago | link

Fascinating, thanks for that war story and perspective. That makes a lot of sense.

reply

2 points by i4cu 18 days ago | link

> For most sites the payoff to a spammer isn't really worth even the simplest robot test.

Maybe I am missing something.... Isn't captcha just a fairly simple robot test (and thus preventing spam)? Or are you suggesting something even simpler? Because I've run a few sites and had tried implementing very simple programmatic obstacles and it really didn't stop the spammers.

Maybe the better question is - what would you suggest?

reply

3 points by akkartik 18 days ago | link

Simple captchas are totally fine. My problem is with Google's ReCaptcha in particular, where the problems have gotten so difficult that I mostly can't prove I'm a human.

reply

2 points by i4cu 18 days ago | link

Hmm... That's not my experience. 90% of ReCaptcha tests are invisible if not a simple checkbox. Only a small optional subset requires introducing a problem solver.

https://developers.google.com/recaptcha/docs/versions

I do agree though, the text ones can be a pain, but that doesn't happen too often. Sadly HN seems to push those more often.

reply

1 point by akkartik 18 days ago | link

I don't get either a checkbox or text anymore. I get to identify pictures with cars and signs and whatnot.

reply

2 points by i4cu 17 days ago | link

I've never failed a cars or signs test. It's only the text scribbles that kill me :)

I have to wonder what you're doing that make google zero in on you.... lol. Tor? maybe proxy IP's?

reply

3 points by rocketnia 12 days ago | link

One time I spent a good 20 minutes identifying cars, signs, and storefronts before it would let me in, and that was with no VPN or Tor or anything. At some point they oughta be paying us. :-p

reply

3 points by hjek 8 days ago | link

Someone tried to take Google to court already, arguing exactly that :-)

https://arstechnica.com/tech-policy/2016/02/judge-tosses-pro...

reply

3 points by rocketnia 8 days ago | link

"Plaintiff has failed to allege how these numerous benefits outweigh the few seconds it takes to transcribe one word."

A few seconds is qualitatively different from 20 minutes, I'd think. :-p

reply

1 point by i4cu 12 days ago | link

This is probably going to sound super crazy, but I have to say it...

I know you (akkartik) have a google account, because I remember when you moved your blog over to google's services (I think they call it 'circles' or some such). I also remember you created a news aggregator application that scraped content. Yes, I know, it was a long time ago in a galaxy far, far away..., but still...

I'm thinking that google identified your scraping work and deemed you a risky robot type, but they also probably correlated your IP from the scraping to your IP from your google services login and tagged you that way. So now, even if your IP changed, they'll continue to have you in their cross-hairs for, like, ever.

Any takers? If you'd like I can also look into who killed JFK...

reply

3 points by akkartik 12 days ago | link

Lol, no.

Other possible reasons:

a) My cookie acceptance policies are non-standard. (I no longer even remember what they are anymore.)

b) I'm often behind a VPN for work.

c) I'm often on my phone, or tethering from my phone.

Complaints about ReCaptcha are fairly common if you look on HN and so on. You don't have to have run a scraper to hit it, I don't think. I think you may be a robot from the future for never having problems with the pictures of signs and cars :p

Final minor correction: I've played with Google+ in the past (I actually worked at Google on Circles for a year) but I never moved my blog there. I just linked to my blog posts from there.

reply

2 points by i4cu 12 days ago | link

> Complaints about ReCaptcha are fairly common if you look on HN and so on.

Yeah I'm aware of the complaints, but in my mind HN wouldn't be the best resource of information for such an assessment. By default HN members are non-standard in most ways that would matter to ReCaptcha.

It's an interesting dilemma and one that I'm coming up on soon as I plan to release a new app in a few months time. In my case the intended audience for the app is very widespread and not specific to a tech audience. It could be that the vast majority of my users (if I get any - lol) would never have a problem, because the vast majority of people using the net don't know what a VPN is or how to change a cookie setting (just as examples).

I'll have to give it some more thought, but in the mean time, are you aware of any resources on the matter that would be more reflective than HN?

edit: I often find info like this [1]:

  "Different studies conducted by Stanford University, Webnographer and 
  Animoto, showed that there is an approximately 15% abandonment rate when the 
  users are faced with CAPTCHA challenge."
1. https://www.infosecurity-magazine.com/opinions/captcha-fraud...

But really I do expect to take some loss when using reCaptcha. The question really becomes is it worth it? After all spam can also cause users to leave and content scrapers can also de-value your product.

reply

3 points by akkartik 12 days ago | link

Certainly, it's an issue only tech-savvy people will have.

However, every step you put users through is a place where your funnel will leak. So in your place I wouldn't turn on captcha until I actually see spam being a problem.

Also, independently, since I am personally ill-disposed towards ReCaptcha I have zero urge to help maintain it in Anarki :) You're welcome to hack on it, though!

reply

2 points by i4cu 11 days ago | link

> So in your place I wouldn't turn on captcha until I actually see spam being a problem

agreed.

> I have zero urge to help maintain it in Anarki

It's really only a few line of code (probably smaller than a unit test) and it has already exposed json bugs, so I consider it a win all around.

At any rate it's probably verging on discussion overkill for such a small item. :)

reply

2 points by krapp 11 days ago | link

I think it's less important to have Recaptcha or not than it is to have a working POC for interaction with a remote JSON API, and for parsing JSON in general, since that opens up a lot of possibilities. Recaptcha itself is just the low-hanging fruit for that, since it's so simple.

As far as integration goes, we could just leave it up to whomever wants to do the work or make it easily configurable with the default being not to use it at all.

reply

3 points by krapp 10 days ago | link

... well, it's up[0].

I don't know why the tests keep failing, though, it works locally.

[0]https://github.com/arclanguage/anarki/pull/102

reply

3 points by rocketnia 10 days ago | link

It's great to see a JSON API integrated in Arc. :)

I took a look and found fixes for the unit tests. Before I got into that debugging though, I noticed some problems with the JSON library that I'm not sure what to do with. It turns out those are unrelated to the test failures.

I left details about these in comments on the closed pull request, which might not have been the best place: https://github.com/arclanguage/anarki/pull/102

reply

2 points by krapp 10 days ago | link

The JSON solution is a quick and dirty hack by a rank noob, and I'm sure something better will come along.

And in hindsight the problem with the (body) macro should probably have been obvious, considering HTML tables are built using (tab) and not (table). I'm starting to think everything other than (tag) should be done away with to avoid the issue in principle, but that would be a major undertaking and probably mostly just bikeshedding.

reply


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

https://www.reddit.com/r/Clojure/comments/8gfpb3/making_a_da...

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

https://www.quora.com/Does-the-GDPR-apply-to-US-companies

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

https://news.ycombinator.com/item?id=16661323

-----

3 points by i4cu 79 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).

-----

2 points by i4cu 127 days ago | link | parent | on: Clojure and Common Lisp web app comparison

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

https://arclanguage.github.io/ref/iteration.html

-----

4 points by akkartik 147 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 https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/... (via http://malisper.me/loops-in-lisp-part-2-loop by malisper)

-----

3 points by musk_fan 143 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))
         lis))
The (collect ...) structure is really cool; I'd forgotten about that; it's been awhile since I touched CLisp

-----

2 points by akkartik 143 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
          acc.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 199 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 198 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 196 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, https://github.com/arclanguage/anarki/blob/master/lib/pd.arc

That said, there is an Arc package manager, Hackinator by awwx. http://awwx.ws/hackinator

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

Cheers.

-----

3 points by shader 197 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 196 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 204 days ago | link | parent | on: Oldest Arc Forum item - 10 year anniversary

Just 90 more years to go...

-----

2 points by hjek 198 days ago | link

http://www.paulgraham.com/hundred.html

-----

More