@john hmm. interesting article, but prima facie a bit over the top, imho. need to study amp more. but anyway: do we really have a choice, other than the 5 horsemen of the apocalypse? last line: "As I've said before the power of the web lies in its decentralization, it lies with its edge nodes – that is, with you and me. If we reject AMP, AMP dies." good luck with that. if you can get rid of the profit motive, the web will be a paradise of free info.

It's probably like facebook. Wise advice for a business might be "don't fully depend on facebook, but go ahead and exploit what benefits it can bring you."

exactly. avoid delusions.

It probably wouldn't be a good idea to build a large portion of your business over AMP

Unless you're just trying to sling random content with ads as fast as possible

and have google run the whole infrastructure for you.

dunno. i guess it depends on your biz. lots of people got rich building businesses on ultra-crappy ms software, back in the day.

A generic news bot serving content over AMP might be an interesting business idea.

well in any case i'll be scrutnizing amp much more carefully, thanks.

if i need to make payroll, and amp helps me do that, the last thing i'm going to do is fret about how open it is. "Sorry we have to lay you off, Joe, but we think internet openness is more important than you."

@mobileink: you're doing a startup now ??

Best use case for AMP is probably click bate fodder. And there's a lotta money in that! Brand sensitive content is probably better served outside of AMP, perhaps leveraging it's optimization guidelines.

@qqq why not? if you're a "self starter willing (scratch: eager) to work in a,fast-paced environment" ... no, I got nuttin.

@john well thanks for prying my eyes open. at the moment i'm just interested in web app optimization. amp seems interesting but naybe not the whole pkg.

lol no prob. Just my 2 cents

well i look forward to resuming this conv. in a few months, after i have had some time to more closely inspect it.

Aye, same here. I'd love to hear your opinion on it

Does someone use a gnu/linux in a vm as main workstation ? I saw the surface pro and I might switch my 2011 macbook for it.

I've tried. Never liked it. You want to do some android dev that for some reason runs better in a linux dev env. Now you're running an android emulator in your vm... all bad. "Ubuntu in Windows" might end up being good though.

anyone watching cavs vs celtics ?

https://blog.appcanary.com/2017/hard-isnt-simple-ruby-clojure.html

https://twitter.com/ZackMaril/status/863915988424589312?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fblog.appcanary.com%2F2017%2Fhard-isnt-simple-ruby-clojure.html

that blog post has insights about a bunch of bad mistakes I've seen startups make

but most of them are not specific to clojure

sorry to see you leave... I've mainly used cljs and it's the best dev experience I've ever had in my life. (compared to the JS ecosystem's horrible tools ofcourse)

I dunno. There’s some good critique in that video and the accompanying article, but my conclusion is not quite the same as the author’s. I’ve done professional ruby and I’ve done professional clojure and there are real pains at dev time and run time in both. I get the sense that the author is discounting the ruby/rails pain because they’ve paid the cost already, and making a bit much of the clojure/jvm pain because it’s unfamiliar.

^ this, I tried selling cljs to a bunch of hardcore JS devs.... it didn't work.

And I mean it’s not an irrational choice to stay with the familiar! Business value is what (most of us) are generating.

I pasted the links from Twitter because I found somehow Clojure stopped growing before I joined Slack. And seeing from Google, like many other non-Clojure programmers, it's very likely Clojure stopped growing.

If you’re faster with the comfortable thing, by all means, that’s probably your best bet.

I've seen a startup waste a lot of time (and the money that goes with it) on a clojure rewrite that was not strictly needed, with a team that didn't really know clojure yet. But that's about what you know and what you've built, not about the strengths of clojure itself.

I tried to cljs to my friends too.. failed most of them

I think clojure has a long life ahead of it and will always be a niche language

....and barely a choice for new programmers

yeah, it's not going to be a good introductory langauge any time soon, that's an intentional choice in the design

didn't know that, strange choice to me

I think it'll keep growing slowly

hahah..

@jiyinyiyong there's a talk where rich hickey compares it to a piano vs. a cello - where the piano is simpler to approach at first, but the cello offers an extra expression and flexibility, and he wants clojure to be like the cello

so if there's a design tradeoff that gives you more power, but makes things more confusing for a newcomer, he will probably go with it

(that's a broad generalization of course, but it's a pattern...)

I almost forgot all of that video

The thing I worried is people always need to work in teams, there are always newcomers,

and for teams to try Clojure, all of them are like newcomers.

I may want to program in Rust one day. But I'd rather program Rust in Clojure 😉

there are always newcomers to clojure, and that's fine - but if you haven't programmed at all, learn scheme and ocaml first, then clojure is great!

but without a foundation like those languages that are more beginner friendly and introduce clojure's concepts - it's easy to get lost

Scheme and OCaml are definitely not easy

they are beginner friendly in a way that clojure is not

and I'd argue scheme is probably the best beginner language out there

but I mention them specifically because they are more internally consistent and self-explanatory than clojure, and introduce most of clojure's best features

I was under the impression that clojure was pretty easy to learn because it took a newcomer only 2 days to send a pull request for an issue in a re-frame webapp...

I don't think learning new languages is the only way to solve that problem, you see we have Webpack in the JavaScript world, it's very hard to learn at first, but with a lot of work like guides and scaffolds, now a lot people are using it. It's unlikely we have an only way

and the code was good

@akiroz newcomer to programming or newcomer to clojure? what I'm saying is it's not a good first language

new to clojure

Clojure is super easy when you already know the host language it's built on

Easy to take for granted.

But basic stuff doesn't require interop. Don't you think basic concepts that are taught in scheme could be taught in clojure just as easily?

@john until you make a mistake

then you need to understand the vm before anything makes sense

yeah, maximum understanding requires knowing both.

there are languages that try to enforce the facade of their abstractions over the host, and clojure is emphatically (and intentionally) not that

It would be interesting to see a CinC that is fully built in its own abstractions.

remind me of https://i.imgur.com/er0tV3O.jpg , but didn't find one about Clojure

Haha, totally agree with Haskell and I'm still in the brain-hurting region

But that's the benefit of clojure, IMO, the abstraction. Which can be retrofitted on lots of host environments.

@john but you won't see a CinC that performs at well as clojure on the jvm, because the jvm is an amazing piece of work and clojure simply doesn't have that manpower. But clojure prioritizes the design decisions that let us leverage the best vm we can find as fully as possible with lispy abstractions too. So the fact that CinC isn't around is part of why clojure is so great.

@noisesmith I was more thinking about for educational purposes, like with scheme. Mostly a mental exercise.

I really think racket already owns that - being a lisp made for education

it even has immutable collections and laziness (though not as defaults)

also true when ClojureScript promoted some of the best parts of JavaScript

right - it can leverage the ubiquity of js, and all the great APIs we can tie into it etc. and full access to anything js can do

So if some dev shop can't fall in love with the abstraction, that's not evidence that more people aren't getting into it. Maybe it'll slow down. I'm betting more people will like it.

Like, I wouldn't mind programming in Ruby. I'd just rather do so on a clojure flavored ruby. Maybe there's some genetic thing that makes certain people like certain languages though.

who knows

I heard someone talked about business on the internet: how to attract visits, how to make them stay, how to make value out of it. Somehow I think selling programming languages is not very different from it.

and Clojure is not easy to "stay" for many first time visitors

That's true. I hear a lot of stories of people having to come back to it a few times. Only took one time for me, so I figure folks brains might just work differently. Like spatial versus algebraic reasoning - some are more biased towards one.

what is happening with bitcoins

and other crypto coins for that matter

they’re helping me pay some bills is what

I find the whole business in that blog about 'happiness' really odd. Clojure folks I know site 'fun' as one of the major attributes of Clojure. Then there is this (usual grain of salt) evidence http://www.itworld.com/article/2693998/big-data/clojure-developers-are-the-happiest-developers.html

As for a language for people new to programming altogether - I can vouch anecdotally that people like that engage with it quite readily (3 clojurebridges and several undergrad and graduate students in science, but not compsci)

So, a lot of what has been said just doesn't fit with what I've seen

I just go back to the git-of-theseus graphs, and compare clojure against anything else; assuming I’m building something I want to last, I know what I want to build atop.

@jsa-aerial So I just read/skimmed the article. It appears the complaints are most focused on tooling.

I think it's fair to say that Clojure definitely has a tooling problem. I do think that deserves some addressing.

Clojure's tooling surpasses that in other ecosystems. I find it significantly better than that of Ruby, Python, etc.

Not so much in the statically compiling scenario. In that area, I think CLJ/CLJS creates fairly deterministic behavior.

There are certain places where clojure tooling is dealing with non-deterministic behavior and tooling errors keep showing up in those areas.

I think around testing and debugging and profiling, there’s a lot to improve there (criterium is great for micro-benchmarks but for whole program you just need to use a java profiler that really doesn’t “get” clojure)

I find the Clojure tooling to be not too great.

Once you get it running, it is pretty good, espeically figwheel

but it took me a while to figure things out

Taking figwheel as an example, I think Bruce has done a great job. But in a live environment, there are simply too many variables for one person to deal with all possibilities.

lein, for example, everytime I want to figure out how to do something, I have to go read the sample lein file in the repo.

that is not appealing to newbies

but once you figure things out, it is very difficult to have the newbie mentality again. It is like the curse of the Monad. Once you understand it, you can’t explain it.

Clojure tooling is very similar. And when someone calls out a weakness in the tooling, lots of ppl don’t take it lightly because they have lost the newbie “feeling”

lein has a massive amount of wiki documentation

yes, but I didn’t find what I was looking for until I read the sample file. And since then, I always just go to the sample file.

also, quantity != quality

to be fair, lein isn’t the only one with this issue. I find that Gradle also has lots of docs, but so difficult to discover things in it.

I’ve used it for years, so I feel comfortable with it, but the docs were very frustrating. And the usual response that just linked to the docs were also frustrating because I didn’t find them helpful.

My difficulty isn't with lein. I've never experienced a bug in lein.

I consistently hear people saying about figwheel though, "why are my errors being printed twice" and other strange behaviors that seem to only show up in live repl environments.

And again, I don't blame Bruce at all. Weasel is far more buggy and has more strange behaviors and does less.

And part of the problem there is you actually have two separate evaluation environments and the local repl is trying to provide the illusion of a single eval environment.

Maintaining that illusion over more and more complex envs will only get more difficult, if the env is fully mutable and you do more strange, previously un-considered things, like using web workers, for example.

I think a company would have to get behind fighwheel and other tools and really iron out the solution in a manner that makes every intended use case fully deterministic.

But it may be a little too early for that. It may just take more time for CLJ/CLJS to actually be used in all these different use cases before we can actually find the bugs that need to be fixed. You can't account for all those scenarios until they actually crop up.

But to circle back, with regard to statically compiling code, which is what most other languages are doing, I think CLJ/CLJS is at least on par, if not better, than most other langs. It provides the same expected behavior every time. Uses a nice, declarative specification.

I'm with @dominicm on this one - having used Ruby a lot and Python now for while, their ecosystems are just not up to Clojure's at all. They 'work' but are quite a bit more painful. Of course, perl is way worse.

If you start bringing up figwheel and friends, now you are in JS land and JS has some of the all time worst tooling out there

Yeah, I may be complaining from a very "first world problem" perspective, in the land of languages.

@john I wouldn't say most of the other languages that have been brought up are statically compiling - none of Ruby, Python, JS do that

Perhaps I used the wrong terminology for that

I mean compiled vs a live repl environment

All three of those have a 'live repl' environment - just not all that good

true

i must say the WTF factor is fairly large in clojure. "principle of least surprise" is not a high ptiority.

e.g. why not (into {} [:a 0 :b 1])?

Wow - I would say the WTF factor is way less than Ruby, Python and especially JS

Yeah, but you could argue allowing (into {} [:a 0 😛 1]) could create another WTF.

JS (like perl) has some of the all time high WTF

could be, but that doesn't mean it's small.

Yes, but in this context we are talking 'relative' - what doesn't have some WTF??

ok, let's say the wtf factor in clojure is surprisingly high. not just "wtf?", but "wtf, that should not be a wtf." 😉

I disagree. I think many of those "wtf"s disappear with experience.

meta wtf. feature?

well, sure, but not helpful for noobs.

Once you start to appreciate the consistencies in clojure, you more appreciate that you can't (into {} [:a 0 :b 1]) by default.

how would allowing that break all of my other expectations of the language?

hm, i think i've started but i still don't see why that into should not work.

same reason (conj {:a 0} :b 1) doesn’t work

Knowing how things work, I know that (into {} [[:a 0] [:b 1]]) will work

and I know there's a reason for that

Actually that consistency is what makes the WTF in Clojure a lot lower than in others

into takes a transducer, imagine how complicated it would be if your transducer sometimes got a key and sometimes a value, all in one series

(almost) anything can be a map key; a vector with an even nbr of entries "should" be easily convertible.

converted when? by what rules?

conj is varargs

Most clojure WTFs have to do with dealing with non-deterministic behavior of the host environment.

on the principle of least surprise at least. mathematically certainly true.

Exactly @noisesmith

@mobileink allowing the flat list input would lead to a bunch of really annoying and surprising special case rules

Actually, again, least surprise is better IME than others

for transducers and conj

and a user can easily convert an even vector into map-entries

and again, because of the consistency and well set up abstractions

i'm not saying there's not a good reason. i'm saying it's a good wtf example.

Its those two things in particular that make Clojure much better to work with than CL or Scheme

for a beginner, sure (re: WTFs around seq abstractions)

a big wtf is the fact that map, rest, filter, take etc. don’t preserve input collection type - it’s done for good reason, but I see it trip people up a lot

but it’s still a widely applied sort of rule, not a special case thing “each function has a preferred output type”

internal consistency is one thing; consistency with well-understood models (math, lambda calc) is what really matters, imho. clojure is very good at the latter, but not perfect, hence some wtfs.

I occasionally believe that lazy seqs were not the best default choice

the fun thing is you can avoid that by not using the lazy functions though - which is very easy now that we have transducers

(once you know which things are lazy at least)

yeah. unfortunately, I internalized clojure before transducers and have yet to actually bother to learn to reach for them by default 🙂

@donaldball “use it with into and provide fewer args” works very often

@donaldball me too! 😢

I do aggressively realize seqs before returning them in my fns though

it’s amazing how many times I took (->> x (f) (g) (h)) and turned it into (into y (comp f g h) x)

@donaldball try considering how clojure would be different without lazy seqs though. Lots of efficiencies are gained that we take for granted.

working with potentially infinite sequences. Which I think is being exploited more often than we usually think about.

i've learned to live with laziness. but it took time and effort.

In an alternate clojure impl, one could imagine lazy seqs being a thing and also that map and friends preserve seq type, possibly giving a simpler dev experience, but it’s really neither here nor there

Clojure rides this fine edge of laziness while still allowing eagerness when you want it. it wasn't entirely clear it was going to pan out as cleanly as it did, when it was being designed and rolled out.

my policy fwiw: ignore laziness. it will complain when angry, then you assuage it.

I'm not sure there are (or were, before) any languages other than Clojure that allowed such a heterogeneous environment of both laziness and eagerness, where both seem to work together cleanly.

another thing is that Clojure (on the jvm) does speculative/optimistic computation - it may retry computations. Such behavior is better served by lazy evaluation, when large cascades of eager evaluation aren't forcing all retries everywhere.

The optional eagerness provided a surprisingly effective and usable compromise.

anyone else use sendgrid and have their unsubscribe stats always show a 0? I can see from the webhooks that people do unsubscribe sometimes, was just trying to figure out if it's happening to anyone else.

accidentally posted a msg to #beginners that belongs here, about blockchain. you might not use clojure to implement bc, but apps that use it are a different story. anyway, it's looking to me like a massively disruptive bit of tech.

@mobileink you might be interested in http://status.im. They're leaning heavily on CLJS for their mobile app. And I believe they let you build DAPPS with CLJS. The actually "ethereum node" is built on Go though I believe.

Ethereum DAPPS sound similar to blockstack

looks interesting, thanks.

blockchain is pure magic to me.

http://Status.im might actually be one of the largest open source, public facing CLJS project that isn't being talked about much in the community yet. Could be a "killer app" success story for CLJS, if http://status.im takes off.

anybody know of a clojure lib that will let me put more hours in the day? or make me much smarter? i get tired just thinking about all the stuff i need to learn.

speaking of wtf: "With Status your mobile device becomes a light client node on the Ethereum Network..." undoubtedly the "Ethereum Network" is in favor of goodness.

Blockchain's the spooky golden hammer, man.

haha! love "spooky golden hammer"!

I still think the underlying assumptions of all blockchain tech assumes certain democratic behaviours that work if you can guarantee personal identity matches transactional identity one-to-one, but utterly collapses when one person can be fronted by many virtual identities.

a.c. clarke: "Any sufficiently advanced technology is indistinguishable from magic." i have to revise my examples of this every few years. a while back it was public key encryption. now it's BC.

Even the underpinning security and checks-and-balances tech collapses when those assumptions fail.

It has never seemed sufficiently impervious to wealthy or resourceful bad actors, thus annihilating the decentralized aspect it aims to achieve.

Even moreso with Ethereum's 'smart contracts' which require an untampered runtime.

on tooling: TBH, I find lein to be one of the best tools I've ever used. python - what if all dependencies are global and every version is a breaking change? js - what if you need to write a program to build your program? java - what if everything is in XML? C(++) - what if there's no package manager?

@fellshard still makes me nervous. "it cannot possibly be hacked" sounds like a recipe for eventual disaster. but nobody can hack my stash of gold ingots (i wish!).

Especially when we've seen repeated failures and subversions of existing blockchain currencies.

Despite such protestations of 'perfectly safe' and 'failure-tolerance'.

you want amazing? the fact that after all the failures we ("we") still think a secure tech is,possible.

it's a bit like a bubble.

"blockchain is secure" is isomorphic to "the price of tulip bulbs (or real estate) will always rise"

i wanna know how i can short the blockchain craze.

it's kinda terrifying, actually. imagine a big chunk of the economy dependent on bitcoin (or whatever). then it gets hacked. ka-boom goes the dynomite.

Block chain is pretty much just a public ledger on a DHT

a distributed, single source of truth

wait, i thought you just said sth like "single source of truth".

didn't I? 🙂

you can deny it, it's not too late. call it a typo.

lol

you know what I mean

"the entire network agrees, X happened"

i do, but you see what i mean, yeah? "single source of truth" always ends badly. think in engineering terms. if everything goes thru a,single node, you're screwed, eventually.

That's the sell of the block chain. A kind of singular representation of the truth, abstracted over a network.

X happened does not mean X good.

Right, as you said, the model isn't impervious to attack.

it's gonna be great, until it isn't. which imho is inevitable.

If they can dupe Morgan Stanley to build significant investments on it, this early in the tech, yeah. I don't think most orgs are going to trust it that much yet. I mean, China owns most of the canonical blockchain ATM lol

That's the key - distributed trust does not mean absolute trust

heck, if i had some dough i'd get in and try to get out before the crash!

it's all timing.

And it is a matter of trust, the same reason we have certificate authorities, for example. Decentralizing only makes the routes of trust harder to trace, and allows bad actors to hide behind the veil of many smaller actors.

Centralized trust can be centrally and publicly examined; distributed trust, if compromised, can also compromise attempts at public examination, in direct contradiction to its own claims.

I think some magical unicorn might be possible in the future. Threshold cryptography was being talked about a lot when the first bitcoin implementation was released.

threshold cryptography is some magic sauce

Would the parties in the cryptography be arbitrarily selected?

trust is also the foundation of money. a dollar bill is just a worthless piece of paper if people don't trust the "system".

otherwise you just have your own suite of parties collaborate and ignore the democratic whole

I'd personally take BC over a couble of important guys (what we have today) anytime.... atleast BC trust is backed by computational power which you can't pull out of thin air.

But one person with enough cash can make an invisible central authority with zero accountability; that's worse than a known, public actor.

i wonder what the badass econimists have to say about digital currency. i doubt very many of them have much tech competence, tho.

If only we could get Friedman's analysis on it. You can still analyze it in terms of the parties involved and their interactions, I think, without needing to understand the mechanics that provides those guarantees.

think nation states, which have (effectively) infinite resources. Fredonia has switched to BC. Altonia doesn't like Fredonia's attitude. In the old days they could counterfeit the currency to destroy the exonomy. Now they can just hack the algorithms.

nothing ever changes under the sun.

or maybe they don't need to hack the algorithms, i don't know them. maybe they just need to infiltrate the minting farms.

that's what i'd do if i were the nsa/gsb/whatever. why spend millions cracking sth when you can bribe somebody to give it to you for a pittance?

If you control 51% of the network, you can own the network. They need to resolve that. They need stronger guarantees in the face of untrusted participants. And transactions are too slow to accommodate a global economy.

homomorphic encryption is also magic sauce

oh yeah. that's the other bit of magic!

somebody turned me on to that a few months ago. more firehose. 😢

Oh weird, that's an awesomely bizarre mechanism

Is it an actual mathematical transformation, or just a monadically wrapped atom, effectively, where the actors don't get access to the actual state?

it's math

the computations are obfuscated by being translated into a different computation

@john: proposition: nobody can ever "own" the network. that would imply that attackers could never succeed.

https://media.giphy.com/media/26ufdipQqU2lhNA4g/giphy.gif

yup 🙂 MS published a major improvement, making it within a few orders of magnitude of maybe usable performance wise

who is that guy? is,he ok?

But now they're saying neural networks may provide a shortcut to homomorphic encryption.

I dunno but I keep thinking Gene Wilder for some reason, even though it's not

No mathematical proofs are ever likely to be forthcoming with that method though

I think that's a guy from an old apple commercial, right?

It's some comedy show on adult swim iirc

or some apple presentation

Tim & Eric

ah

I was disappointed when I looked it up, lol

does look a bit like wilder, but i think gene's eyes would get bigger.

https://en.wikipedia.org/wiki/Eric_Wareheim

the thing about proofs: in the wild, they're not really proofs. they do justify an increase in confidence, but that's different.

the obvious (and well-known) problem: how can you prove that your prover is good?

and if you have a prover prover, how do you know it is good? etc. ad infinitum.

there's some truth to that. Like with whole operating systems. How invariant are your invariants, really?

😉

plus: big data doesn't care about (formal) proof. which opens a whole 'nother can of worms. instead if truth and validity (logic) we have reliaibility and validity (stats).

One interesting insight about proofs and programming. Every program is a theorem. An execution of that program is its proof.

or is a proof

@john close but not quite. "execution" is not relevant. programs are proofs, not theorems.

(+ 1 2) = 3 is a theorem. The evaluation (or execution) of (+ 1 2) proves it.

Usually, in math, the theorem in question is talking about an infinite sequence, which makes naive evaluation problematic. So proofs seek to to leverage some other evaluation path that proves the behavior.

no

So proofs often provide some additional execution path that corroborates the expected behavior

But, fundamentally, a program is a specification of some behavior and the execution of that specification is a standing proof of the specification, as it maps that specification to some specific behavior.

right, the specifiction is the theorem (proposition), the program is the proof.

the execution and result are the proof

(+ 1 2) = 3 is not a theorem. you could call it an instance of a theorem, i suppose.

no. you need not "execute" a program in order for it to be a proof.

think about the definition of "+".

Every proof is an execution path between some initial conditions, some rules being applied in a stepwise fashion, and some result.

you must define it without refering to "+" on pain of circularity.

no. proof != execution. these are completely unrelated ideas

I disagree 🙂

Could be a difference of terminology though