Fork me on GitHub
#off-topic
<
2018-09-16
>
henrik04:09:34

@bhauman Are you happy with Stripe thus far?

bhauman15:09:41

@henrik yeah the api is pretty flexible, but it doesn’t seem to provide an additional layer over the api. Like redirecting to Stripe to collect payment details and manage the whole process. Which I would personally prefer, but all in all its a very clean api and there JS libs allow you to create custom secure forms in a relatively short period of time.

bhauman15:09:17

and they support a plurality of payment methods

bhauman15:09:37

So I’d say yes, I’m mainly interested in longevity at this point

bhauman15:09:06

cause nothing hurts subscriptions more than changing providers

henrik15:09:00

@bhauman Well, it seems that Stripe has at least traditionally an interest in being a solid partner to developers.

bhauman15:09:39

it seems so, their interface looks a little sparse and dated, which literally means nothing, but makes worry about where their focus is

henrik15:09:51

I’ve read that you do need to keep an eye on disputed payments though. Stripe’s partners freak out if the disputes climb above 1%, which forces them to put the account under review.

bhauman15:09:21

good to know, that should never be a problem for me

bhauman15:09:46

the bulk of my customers are multiyear relationships

bhauman15:09:45

but good to know so I can emphasize communicating the change to my clients

henrik15:09:17

No, I don’t think so. I’ve seen people have bad experiences with that though, but they’d have 10%+ disputed claims, which seems a bit shady to be honest.

bhauman15:09:38

that does sound shady as heck

denisgrebennicov19:09:35

Is Common Lisp dead? In the sense, no more active development is done No new feature are in development, right?

andy.fingerhut21:09:12

I don't think anyone is working on adding things to the Common Lisp ANSI standard.

andy.fingerhut21:09:37

The language itself has a lot in it, including capabilities to define your own reader macros for new syntax, and macros for new forms.

andy.fingerhut21:09:20

There is a well known open source implementation SBCL that the developers email list shows people fixing bugs and adding performance enhancements.

andy.fingerhut21:09:19

It compiles from source down to machine code for several different processors and OS's, so lots of platform and processor-specific code in that implementation that can have bugs or perf improvements in. Clojure gets lots of leverage from the JVM and JIT compilers there.

denisgrebennicov21:09:23

@andy.fingerhut unfortunately not really supporting OS X. 1.2.11 is the latest for mac, whereby 1.4.11 for linux and windows on amd64/64-bit X86

andy.fingerhut22:09:31

MacPorts has SBCL 1.4.9 available, and it starts up to a REPL prompt, but I haven't put it through any significant testing.

andy.fingerhut22:09:31

MacPorts also has CLISP 2.49 available, but I believe that is lower performance due to being more interpretation-based, not compiling to native machine code.

bronsa08:09:19

CLISP is mostly dead

andy.fingerhut22:09:05

OK, reading slightly further, it looks like CLISP also has some kind of compiler, but it isn't clear from a quick scan whether it compiles to machine code, or something more like some intermediate byte code.

andy.fingerhut22:09:30

SBCL pre-built binaries available for download on http://sbcl.org site are updated by volunteers, and just because only an older version has a pre-built binary doesn't necessarily imply that later versions are not supported on that processor/OS combo.