joshlemer

I wonder what will happen to all that IP

And the reason that LISP code tends to be reluctant to split things out into multiple forms with variable assignment IMO is because it introduces a new level of nesting. It's too much friction to go from

    (defn foo [] 
       (+ 1 2))

to

    (defn foo []
      (let [x 2]
         (+ 1 x)))

I wish that there were some kind of macro available in Clojure that would provide a local "def" kind of functionality that doesn't pollute the namespace and just creates a binding in the parent scope. So that you could do something like:

    (defn foo []
       (let! x 2) 
       (+ 1 x))

> Suppose you see an area in upward economic trajectory, you buy a bunch of land/properties, then do fuck-all for the next 30 years while the hard work of everyone around that land causes your land's value to increase. You contribute nothing, while benefitting from others' contributions.

In a market economy, if it's a known fact that the area is in an upward economic trajectory, then the future increase in usefullness of that land will already be priced into the land today. You can't just make profit (in expectation) by going and buying land in an area that the market already knows is going to become more productive. Competition amongst investors will drive expected profit to 0.

The only way that you can actually make a profit as a speculator, is by bringing new information to the market. The rest of society thinks this area has no potential, but you have good insight that is costly to figure out, which tells you that the area is going to be more productive. You take a risk and purchase the property. You are compensated for the risk and effort you undertook, and if you're wrong, you are punished by losing money.

> Having those industries subsumed by the US would help us how?

So is your position that only Canadian firms should be allowed to operate in Canada in general? Foreign competition helps us because then we benefit from further specialization and trade which increases everyone's standard of living.

> Imagine that Canadian farmers, much like New Zealand farmers, make a product more efficiently than the US and start taking the US market? How do you imagine that plays out? Hint: It yields new protectionism, because the US can only win in every area.

Well, who else benefits is consumers who get to purchase products of higher quality, convenience, and affordability. Also employees of the dairy sector who face higher competition from firms bidding up their labour. Investors, who have more investment opportunities and therefor higher yield. Government and entitlement recipients who benefit from tax revenues from these incomes and investments.

Well, a lot of the things people lump into the bad deal category are things like allowing us competition in our protected oligopoly industries: banking, telecoms, airlines, dairy, poultry…

True. And if you’re going to carve out oil sold to the us, shouldn’t you be carving out resources sold to Canada? Seems like a lopsided comparison

I guess I don't really get why is Apple App Store forced to disallow apps which violate the YouTube service policy? Surely that is an issue for the app developer and YouTube to sort out, why is the Apple App Store assuming an enforcement position?

And also it's one thing that the App Store doesn't allow YouTube Service Policy violators, but then it's a big issue that they don't allow sideloaded apps. It's only this locking down of our devices so they must go through the App Store that is indirectly enabling YouTube to have a shitty addictive UX IMO. If people had more control, YouTube would have to worry about not being too crappy or else other apps might take market share. Now that they have us all locked in thanks to App Store, they can extract much more attention/money from us than otherwise.

I feel like the core of the problem is that we don't as consumers have hardly any control over the software we run on our devices. People can and have written less addictive YouTube, Reddit, etc clients, but Google Play and Apple App Store don't allow them.

This argument is lacking nuance. Just because there are some instances of paternalism one is prepared to accept, doesn't mean that every possible paternalist policy is always okay. Being in favour of some instances but not all, is not a logical inconsistency. We can talk about each instance on a case by case basis.

I notice that these sorts of justifications for increased paternalism as a consequence of socialized services come up in public discourse all the time but never seems to be mentioned by advocates when proposing these socialized systems. It should be mentioned up front as a significant cost as part of the package, it comes with strings attached like the government telling you how to live your life. Interesting that people don't seem to want to mention that up front.

I think this is kind of misleading. Yes s-expressions have very simple syntax in and of themselves. But s-expressions are not all that's required to get all the control structures in Clojure. You need to memorize all the special forms and all the standard macros that people use on a day to day basis. And they're just as hard (actually IME harder) to memorize as any other syntax. let, cond, record, if, condp, let-if, fn, def, defn, loop, recur, if-some, when-let, for, ->, ->>, as->>, cond-> ...

To this day I have to look up whenever I get back into clojure what the "syntax" is of ns, require, import, etc.

Spinning dwindling adoption as a good thing because it "unburdens community from serving lowest common denominator use-cases" is exactly the kind of of downplaying/deflection of every issue that I'm talking about, which constantly happens in the Clojure community. It's such an unhealthy attitude to have as a community and it holds it back from actually clearly seeing what the issues are and coming up with solutions to them.

Every problem people face is "not a problem" or "actually a good thing" or, maybe if all else fails we can make users feel bad about themselves. Clojure is intended for "well experienced, very smart developers". Don't you know, our community skews towards very senior developers! So if you don't like something, maybe the problem is just that you're not well experienced enough? Or, maybe what you work on is just too low-brow for our very smart community!

Yeah to be honest after trying for many years to understand what is so special about this famous Clojure REPL I struggled to see how it was that different in practice from Python or other languages. In Python you can also highlight a section code and send it to the console to be evaluated.

I think debuggers are just better anyways. When I got into the weeds trying to do this interactive REPL workflow on an actually running webapp it was a big mess. You have to write custom code all the time to basically capture data and save it into global variables, so that you can inspect them (as opposed to a debugger where you can just set a breakpoint and inspect all the variables in the middle of the precise spot in the request-response cycle).

I think maybe this was ahead of its time when it came out in 2008 or got popular in 2010-2015, but nowadays I am not seeing what's specifically more productive about the Clojure REPL than the interactive development experiences available in Laravel, Python, JS, etc.

Yeah, Elixir's Pheonix if anything demonstrates how important a flagship framework/stack plays a huge role in driving language adoption. Despite Elixir coming out after Clojure, and running on a VM that is more esoteric/niche than the JVM, and having a host language which is 1000 times smaller in popularity and library ecosystem size, it still is probably more popular than Clojure at this point and almost all of that is from people picking up Elixir to use Pheonix. And Clojure's use is not just staying where it is, it seems to be in free fall. There used to be dozens of Clojure job postings in Canada, now without exaggeration I don't think there's a single one.

Rich's Simple Made Easy talk is really interesting and insightful and I still love it but I think now the distinction is brought out too often almost reflexively, and used as a crutch. Yes "simple" and "easy" are not the same thing, but nor are they opposites. Just because something is "not easy" doesn't mean it's "simple".

I think there are lots of well maintained Django projects. In fact, if I do a search on AI and on google for what one web stack probably has the lowest overall total cost of ownership including maintenance years down the line, Django usually is what comes up, without even specifically searching for/mentioning it.

> if you're very deep into "frameworks are clearly superior in every case"

This is a mischaracterization of what I have said, and is more like the extreme position that Clojure devs seem to take. The original commenter said that Clojure is wonderful, but it's too bad that [for the people who want it,] there isn't the option of a well maintained, all-in-one, batteries included framework. You deny that this is a problem, saying that actually a well-chosen set of libraries are superior (I guess in every case, because if not then it actually would be a problem sometimes).