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.
Hy doesn't have linked lists or tail call optimisation, but it has pretty cool bidirectional interop, i.e. you can write Python in Lisp, and also you can just import Hy modules into existing Python code, and even use the Python debugger for Lisp code.
I personally find the Python syntax super annoying; the colons after `if` and `else`, the `@` decorator syntax, its whitespace sensitivity, all the __underscores__, etc., so it's nice that someone are doing for Python what Clojure is doing for Java.
> 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!
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>
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.
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.
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?
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.
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.
I figured it out. Arc uses `lambda` from Mzscheme, and that version of `lambda` doesn't support keyword args. Trying to import Racket's `lambda` caused a conflict with the other `lambda`, so in the end I imported Racket's `keyword-apply` to do the job.
I have committed this code to the Anarki repo, so now everyone can use Racket keywords in their Arc programs. Yay!
Racket has very extensive documentation and clear error messages, so Racket is a great for learning (and other of programs -- I'm writing a printer driver in Racket). Arc runs on Racket and has Racket interop.
> If this comment were about cooking it would look the same. We reuse one writing system.
That's true, but the fact that we're both able to make analogies just suggests that analogies aren't a good defense for your system. It isn't self-evident that "eliminating different syntaxes" is always a good thing. You need to actually take the trouble to motivate it.
In my experience the hard part of dealing with polyglot systems is juggling the different semantics. Syntax is in the noise. Should it be the same or different? It just doesn't seem worth thinking about.
Don't get me wrong, I find Lisp's uniform syntax very helpful. But Lisp is helpful also because of its (relatively) uniform semantics. While adding Lisp syntax atop say Erlang seems useful, mixing LFE and regular Scheme would be a nightmare.
> What happens when 2 languages use the same keyword but with different semantics and it happens that a 3rd language embeds them both?
Yes, I can relate to this question. For example, here's a fragment from the Mu codebase where I embed tests containing Mu programs in my C++ implementation: http://akkartik.github.io/mu/html/040brace.cc.html#366. The Mu instruction is `return-if`, but because it's in a C++ file, just the `return` is highlighted. Super ugly.
My take-away from all this: polyglot systems are a bad idea. Mu's implementation being in C++ is hopefully a temporary state of affairs. We shouldn't be picking "the right tool for the job". Software is more malleable than past tools. We should be tweaking our one language to do everything the job needs.
So rather than try to come up with solutions for polyglot programming, I'd just discourage it altogether.
> A classic design principle is that similar things should look similar and different things should look different.
Agreed, but I think context eliminates such a need. If this comment were about cooking it would look the same. We reuse one writing system.
> Imagine a project with both Flow and Project files. Wouldn't it be nice to be able to tell them apart at a glance?
Ah, good point! So far it hasn't been a problem, but I imagine there may be issues as the number of Tree Languages (note--I took the feedback and dropped the "ETN" acronym) and combinations increase. It might emerge that there are some universal best practices so semantics won't change too markedly from one language to the next. But I think it could be that semantics vary a lot. Right now I have some languages where flow goes forwards (top down) backwards (children up), stack based, parallel, synchronous, et cetera. I personally haven't had trouble keeping them straight just knowing the context, but that is not necessarily a predictor of how it will go for other people (or even me), in the future. We shall see.
Another similar problem is when you have a file with both Flow and Project code (something that actually comes up a lot).
What happens when 2 languages use the same keyword but with different semantics and it happens that a 3rd language embeds them both? It might cause some confusion. Or even just the basic problem of doing color highlighting for one language in a node of another--how do you ensure the color schemes don't conflict? Perhaps a border or something would do the trick. Problems to solve in the future.
micoangelo, if you decide to try out Arc, be sure to start at http://arclanguage.github.io rather than the instructions here at http://arclanguage.org. Even if you use the stable branch which is compatible with Arc 3.1, it has a couple of crucial bugfixes that are otherwise liable to bite you at an inopportune moment.
I think "learning Lisp" is Arc's best niche. So yes, try using it and come ask us questions. Feel free to also ping me over email, that is sometimes faster. My address is in my profile.
One caveat: it can be easier to learn from a book if you follow the language it was written for. Land of Lisp is a fine book by all accounts, so if you use it you may be better off just using Common Lisp or whatever. But feel free to come ask questions anyway. Maybe we can show you both Common Lisp and Arc versions of programs.
Whoa, I could have sworn I responded to this one :/
rocketnia is right that I tend to just run Arc from within its directory, keeping it alongside any Arc program I may be working on at the moment. As a result, I'd kinda always assumed you could run it from anywhere and find yourself in the Arc directory once you loaded up. Now I find this isn't the case:
I've always been frustrated with Arc's lack of a standard practice for loading dependencies (although I suppose akkartik might consider that a feature ^_^ ).
If the way Arc's lib/ directory has been used is any indication, the way to do it is:
- Start in the Arc directory when you run Arc, and never cd out of it.
- (load "lib/foo.arc"), or (require "lib/foo.arc") if you want to avoid running the same file multiple times
But I think for some Anarki users, the preferred technique has been somewhat different:
- Invoke Anarki from any directory.
- Ignore lib/ as much as possible. On occasion, load a library from there by using (load "path/to/arc/lib/foo.arc"), but a few libraries may make this difficult (e.g. if they need to load other libraries).
When I started writing Arc libraries, the first thing I wrote was a framework for keeping track of the location to load things relative to, so that my other libraries could load each other using relative paths regardless of which of the above techniques was in use. But the Lathe module system didn't catch on with anyone else. XD
More recently, eight years ago, rntz implemented the current-load-file* global variable that may make it easier for Anarki-specific libraries to compute the paths of the libraries they want to load. Nothing is currently using it in Anarki however.
It's reading the invalid sequence as � U+FFFD REPLACEMENT CHARACTER, which translates back to UTF-8 as EF BF BD (as we can see in the actual results above). The replacement character is what Unicode offers for use as a placeholder for corrupt sequences in encoded Unicode text, just like the way it's being used here.
The Pike maxim "A little copying is better than a little dependency" comes to mind. I think the overhead of dependencies is underrated ("it's just a 1 line import statement!"), and often a little repetition is a good thing.
It's completely normal that you're having issues. The official Arc documentation is...lacking.
The "latest" arc is Arc 3.1, but that came out in 2009. You can download it here: http://arclanguage.org/item?id=10254, and start it up with `racket -f as.scm`. (Note that you no longer need the specific version of MZScheme you used to; you can use racket.) No, this information has not been updated on the official Arc install page. Yes, this is frustrating.
One interesting point here is how he prioritizes choice of language based on relationships. This connects up with my comment on avoiding dependencies at http://arclanguage.org/item?id=20221. The conventional wisdom that the community of a language matters more than its technical attributes is a diluted version of this idea.