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!
> It's such an unhealthy attitude to have as a community
How about just "different"? Turtle want to teach everyone to program, that's fine, just another way of building and maintaining a language. Clojure is clearly not trying to cater to the "beginner programmer" crowd, and while you might see it as "unhealthy attitude", I'd personally much prefer to realize having many different languages for different people is way better than every language trying to do the same thing for the same people. Diversity in languages is a benefit in my eyes, rather than a bad thing.
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.
As someone who loves the clojure repl I do somewhat agree with debuggers are better
If it was like a choice, Clojure has my favourite reverse debugger flowstorm which also exposes the runtime information of your program programmatically
So you can code cool visual programs against the runtime values of your first program
Like I built an emulator at work that simulates our program in production as a flowstorm plugin then you can step through the program frame by frame
I love taking the guess work out of production issues, just get the computer to show you exactly how everything went down
It's like a rewindable movie made up of thousands or millions of frames of the execution of your program
To be fair to Clojure, I think it's perfect for rule-engines, where the users supply "business logic" at runtime.
That's where "code is data" shines and you can manipulate it at will. For the rest, I'm glad I have "code as text" in my editor, where I can see and inspect it far more easily than one line at a time.
I think it actually is a pretty big problem. "Once you absorb the ideas of Clojure" takes months or years to fully get. Composing libraries yourself, like your comment says, requires that they are "well-picked". Stitching together separate libraries is really time consuming and a distraction from the project you're trying to build. It also results in pointless thrashing within a team as everyone has become personally invested in their own mosaic of hand-selected libraries for every little thing. By the time a beginner learning Clojure has researched and put together their web stack and got it all hooked up and is ready to start, the Django developer already shipped their project last quarter, iterated on it a few times, and is on to the next thing.
One big library/framework has huge benefits and network effects, from enabling a big 3rd party plugin ecosystem, to a deeper documentation literature (including paid courses, books, and AI). It means that there's less or virtually zero getting up to speed when changing from one project to an other. It means that the upstream framework team takes care of upgrades whereas you have to consider, when a new technology comes up, how to integrate this into your stack. There's a reason that Laravel, Django, Rails, and Spring each have thousands or hundreds-of-thousands of times more websites in production than all of Clojure combined.
At a meta/discourse level, I also find the Clojure community's tendency to constantly deny and downplay any criticism or even just issue that people face to be really frustrating and counter productive.
> By the time a beginner learning Clojure has researched and put together their web stack and got it all hooked up and is ready to start, the Django developer already shipped their project last quarter, iterated on it a few times, and is on to the next thing.
Yes, but this is intentional. Django developers are optimizing for "easy" which makes it fast to spin up project after project, Clojure developers are optimizing for "simple" which means way longer time to get the project of the ground, to nail all the design before things start to actually be put together, which makes it easier and faster to iterate on the same codebase after years of working on.
Ask the Django developer how easy it is for them to add features after a project they've done that approach with for N years, then compare it to a Clojure codebase, and you'll notice the difference.
Sure, I guess this is "downplaying" and "denying", personally I see people who disagree with me as people who disagree with me, that's fine, I thought that was why we were sharing our opinions in this forum in the first place. But anyways, if you're very deep into "frameworks are clearly superior in every case", that we disagree probably matters less. Best wishes regardless!
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).
In my experience, Clojure was a huge pain in the ass to get into, and there's a non-zero amount of community members that talk about it in nothing about aphorisms. I really wanted practical advice, but getting people to talk normally about it was an uphill battle. This made me almost quit several times. But it is a very pragmatic language underneath (which you've already mentioned).
But I'm not sure a framework is really going to change that onboarding process, or help with network effects that much. Elixir has a de facto framework, but it's barely more popular than Clojure. I mean, we had Leiningen starter kits and we have Kit. But what's confusing to me wasn't setting up a project, it was learning how it was wired together. Wiring small libraries together and just passing data can feel surprisingly leaky, and I don't really have to peak into the internals of Laravel the way I do Clojure projects.
I think Biff is a promising step in the right direction. I think the way it has wired things up is easier to follow. But for whatever reason, they made the choice to use XTDB as a default, which is a huge cognitive burden for newcomers. They have an article on how to use something else instead, but this is already getting out of the "it just works" territory if you haven't even learned Clojure yet. But the author is a really nice and talented person, and I am looking forward to seeing where it goes.
> 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.
Having used Clojure, Laravel, Spring, and Django, I wouldn't touch Django again with a 10 foot pole. I don't know what you're referring to by "doing a search of lowest cost of ownership" but it sounds pretty unscientific. Anecdotally, I do legacy apps, and I have picked up people's Django apps, and I've never loved what I saw. It's a classic fast to start, slow to maintain framework. Huge businesses have been built on it, but huge businesses have been built on everything.
> I'm not sure a framework is really going to change that onboarding process, or help with network effects that much
having one commonly accepted and recommended way does improve onboarding, because it collapses the decision space beginners face. right now they are supposed to make decisions (not even directly, but just through selecting one of the many frameworks) about things like:
1. which project templating tool to use? (lein, clj-new, neil)
2. which dependencies management tooling to use? (lein, deps)
3. which build tooling to use? (lein, tools build, boot)
4. which web server? (jetty, httpkit, undertow)
5. which routing library? (pedestal, reitit)
6. which templating engine? (hiccup, rum, selmer)
7. how to deal with javascript and it's build tooling? (clojurescript with a host of it's own decisions, bolt ts/js and wire it yourself, dodge that completely with htmx)
whats worse - most of the alternatives overlap in various ways, so making the "best choice" in order to reduce future headache induces quite a bit of anxiety.
yes, multiple frameworks exist that make those choices for you, but then you inevitably hit the problem that some of the components haven't been updated in a while, so documentation is out of date and when you try updating it just for your project you need to fix the framework plumbing and due to number of frameworks, the corpus of useful information on the internet is quite fragmented and the community help is limited, and on and on.
none of this is good beginner experience.
and don't get me wrong, choice by itself isn't bad, focus on composability of smaller libraries is important, dominant framework is not going to improve anything when it locks people into bad decisions.
what we lack is convergence behind a single "reference stack" of libraries that ought to be good enough for the general case and a minimal framework of plumbing that doesn't require dozens of files just to get started.
there doesn't need to be a single way of doing it, but there needs to be a single recommended way of doing it.
I don't disagree with what you're saying. But by "onboarding process" I mean the effort of getting more people into Clojure, not the experience for a single person.
What I'm suggesting is Elixir has everything you're talking about in Phoenix, yet it's still an extremely niche language most people haven't even heard of. Because come on, it's a totally different paradigm than what people are trained to program in. I understand the mental math of "easier means more people," but I don't think that's really going to cut it for Clojure. I had full projects spun up the minute I started learning, but that wasn't where the difficulty was.
So yes, I think having a solid framework is good for Clojure, but the original person suggested it's not popular because it doesn't have one, and I just don't think that's true.
> the original person suggested it's not popular because it doesn't have one, and I just don't think that's true
i agree that it's not a sufficient condition, but it's an important factor and it would significantly improve the onboarding process by collapsing the decision space beginners have to navigate
even going by your definition of onboarding (the effort of getting more people) - dispersing that effort across multitude of dimensions and directions is certainly less effective than coordinating and converging
not intending to have an argument about popularity, but since you keep bringing up elixir - there's a lot that can be said about elixir/phoenix as to why they aren't more popular than they are, but they are more popular than clojure in every recent ranking i've checked ¯\_(ツ)_/¯
if anything, elixir/phoenix is a good example for how strong default improves onboarding and ecosystem cohesion, even if it doesn't make the language broadly popular
i don't look at it from perspective of "what should clojure do to be more popular than php" - there are fundamental reasons why that just can't happen in this timeline
i look at it from perspective of "what does this ecosystem lack that makes it hard for beginners to get going and stick"
and lack of "single recommended way of doing it" is at the top of my list
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.
The fundamental mistake of Simple Made Easy was how many people interpreted them as orthogonal (or even opposing) qualities, when that's not inherently true.
This led to a lot of Clojure code being simple, but avoiding the hard additional work of also making it easy, and sometimes in even making it complete.
The prime example was tools.deps/deps.edn. It largely supplanted Leiningen for new code, but by being simple and minimal, it led to an explosion of ad hoc, custom tooling for 2-3 years afterwards, as everyone rewrote functionality that Lein already had, but tools.deps was missing. (And I say this as someone who once lost a whole week debugging a subtle maven/lein set ordering bug.)
It's not just the Notwithstanding clause. There's a general judicial tradition in Canada of utterly ignoring or dismissing or excusing blatant, objective violations of the constitution itself. Some examples:
1. in Cambie Surgeries Corporation v British Columbia (https://en.wikipedia.org/wiki/Cambie_Surgeries_Corporation_v...), where a private clinic challenged the province's ban on any private care whatsoever for procedures that are provided by the public system on the grounds that if the province bans procedures but then also rations access to those procedures to the point that they're inaccessible for many patients, it constitutes a violation of our charter right to life and equal protection.
It seems they were able to successfully argue that this does constitute a violation of our rights, but the decision says it's okay because it's done with the intent to preserve the equitable access to healthcare for the general public.
2. Employees in union shops are forced to join the union. This is arguably a violation of our right to freedom of association, but the supreme court says that it's okay if it does because "the objective of this violation is to promote industrial peace through the encouragement of free collective bargaining". https://en.wikipedia.org/wiki/Rand_formula#Freedom_of_associ...
3. https://en.wikipedia.org/wiki/R_v_Comeau, a famous case where a guy bought beer in Quebec and drove it to New Brunswick (for personal consumption) and was fined. His case argued that that's a violation of section 121 of the Canadian Constitution 1867 which states as black and white as can be:
121 All Articles of the Growth, Produce, or Manufacture of any one of the Provinces shall, from and after the Union, be admitted free into each of the other Provinces.
But the Supreme court ruled that it's not enough for provinces to ban goods from entering their province for it to count as a violation, it must be a ban which has no other purpose but to impede interprovincial trade. But that means that this section is completely useless because a justification for protectionism can always be found or made up on an ad-hoc basis.
Basically, Canadians have no rights whatsoever. Our entire legal system doesn't sit on anything fundamental it's all just vibes and arbitrary whims of the justices of the day. Our charter and constitution are so full of explicit holes like the notwithstanding clause, that they're rendered almost meaningless even on their own terms, and then any other violations will be excused on the flimsiest grounds.
#2 - Not sure why you think this is a violation. You join a workplace with a union and gain all the benefits from collective bargaining, so yeah, you should pay for union dues.
You say that I gain all the benefits from collective bargaining but I had no other choice. Maybe I don't even like the contract very much and would have bargained for other things than what the union negotiated for. The union claims to negotiate on my behalf but if they really respected me they would give me the ability to opt out.
Your hypothetical isn't even always the case. When unions form, usually there are employees there that don't want to subject themselves to the union, but are forced to, so they didn't "join a workplace with a union" at all.
(1) we have reasonable limits on all our rights, thanks to Section 1; this is rooted in our history of Toryism and ensures that the rights of the individual are balanced against the well-being of society. This is contrasted against how the USA puts the rights of the individual before the well-being of society, no matter what the consequences are and have been.
(2) Again, we balance the well-being of society against individual rights. In this case, defending collective bargaining is a reasonable action when considering that there is _plenty_ of other opportunities for work. Don't like unions, don't join one and find work elsewhere.
(3) Per the court ruling, Canada does not have a guarantee of internal _unlimited_ free trade; it only prohibits tariffs on internal trade. Whether or not that is a good thing is hotly debated, and a matter of current policy.
> Our entire legal system doesn't sit on anything fundamental it's all just vibes and arbitrary whims of the justices of the day.
It's Common Law, not Civil; and so it's based on layers of legislation and court proceedings.
In practice, we have plenty of strong protections for our rights, but those protections break down when our behaviour becomes harmful to broader society. Whether or not you think that's a good thing probably indicates where you are on the line between classical liberalism and toryism.
Depends on how sticky the prices are. Some things are volatile as hell and swing wildly from week to week, some things are stable until adjusted and then they stay that price for another decade.
Most things are never going to be cheaper than they are today. Some things may be cheaper this time next year but not by more than a few percent at the most.
"Prices take the elevator up and the stairs down" - yes, over time the market pushes no-longer-justified prices back down, but this is much slower than the price increase happens.
You won't get the money back that you overpaid in the meantime.
I just love this idea that corporations just discovered greed during the pandemic and before that had been selflessly dedicated to selling goods for the benefit of mankind at the lowest price they possibly could. Companies always try to maximize prices, and they do that by trying to optimize the price they sell things at to sell as much as they possibly can at the highest price they can get away with. Sometimes you can get more profits by lowering prices and selling more stuff, sometimes by raising prices and selling less stuff. It's a trade off. Prices went up because of a series of demand and supply shocks enabled companies to raise prices. If they had not raised prices, there would have been shortages everywhere.
I think there actually was a lot of surprise from executives coming out of COVID that they could raise prices so high without it impacting consumer demand in the ways they had previously predicted.
The Chipotle earnings calls were pretty much the prime example of this. CEO more or less expressing amazement at how elastic consumers were on pricing, and that due to the increases not impacting sales volume they planned to continue ramping until it did.
I think plenty of companies were operating off the idea that price competition was far more important than it turned out to be. I note the baskets of those shopping next to me in the grocery store and this rings true. Due to a myriad of reasons - consumer behavior being a large one of those - buying behavior based on price just isn’t as much of a thing as it was 30 years ago. Almost no one is shopping multiple supermarkets, buying cheaper alternatives, buying in-season veggies and fruit when it’s cheap, waiting for sales to stock up, buying in bulk and freezing, using coupons, meal planning based on the latest supermarket Sunday circular, etc. only a tiny minority of people have been doing so.
Couple that learned helplessness with the monopoly situation for many (most?) markets in the US and it’s no surprise to me that once the dam broke there is no going back. The price discovery moving forward is going to be much more aggressive. It will take a generation or three to get back to thrifty consumer behavior unless we see something actually painful to the average person on a scale of the Great Depression.
> Almost no one is shopping multiple supermarkets, buying cheaper alternatives, buying in-season veggies and fruit when it’s cheap, waiting for sales to stock up, buying in bulk and freezing, using coupons, meal planning based on the latest supermarket Sunday circular, etc. only a tiny minority of people have been doing so.
I don‘t know where this observation comes from, but here in Austria a majority of people in lower income sectors than IT do all of this?
> I don‘t know where this observation comes from, but here in Austria a majority of people in lower income sectors than IT do all of this?
The observation comes from myself, from a medium to low income background. Think mechanics, janitors, construction laborers, etc. family background. Along with most of my peers and extended family members.
The "old" generation - e.g. my grandparents did all those things. Their kids (for the most parts, exceptions do exist) and my generation (and my kids) do basically none of them. They go to whatever supermarket they go to every week or two, stock up on whatever they usually buy, and that's it. Zero consideration for anything else. It is very surprising to me.
> CEO more or less expressing amazement at how elastic consumers were on pricing
That is because the extra money in the economy also inflated salaries. Inflation is annoying but it basically has no impact on affordability over the long run. Everyone just assumed that their increases in salary were a well earned recognition of their contributions, but the increases in prices was pure corporate greed and corruption. They were both the same thing. People got more money and prices went up.
I think you're mistaking what's happening here. Companies are not discovering greed. People are finally recognizing that greed, and the greed inherent in the system, and recognizing that just because it's "part of the system", it's not OK.
Yeah, that's what I do. Anytime anyone from a company sends an email about whatever, who wants me to help them (for their company) in private with something, I ask if they're willing to pay for my time spent on it, maybe 20% says yes. Most of the time they end up getting redirected to use the same venues the rest of the community has access to too.
Assuming you want to. But if you do, understand that accepting payment for services creates obligation to deliver, and possibly liability for poor performance. You may or may not want that.
Not really. They said in their comment they deleted their whole account and everything. They probably don't want to continue to be ridiculed and to link the identity of that account with this one.
I agree about the marketing. I just heard about this phone now and was confused about if I could just use it as a primary phone. It would be nice if they talked more about what the phone is like to use, show what is the home screen and stuff. I'm wondering if I can use it well with some other utility apps that I don't think I'd want to do without like Maps, Parking payment apps, Podcasts and Spotify.
For the Home Screen, they've announced a collaboration with Niagara Launcher and it appears to be close to AOSP+GServices, so I suspect that'll all work out of the box, but yeah, they really should be clearer. Also has both a NanoSim slot and eSim support powered by a not yet public Mediathek SOC.
Major concern as is often the case with new phone startups is the update policy and more importantly whether they'll be able to actually deliver over the years. Has been literally half a decade since I last used a Mediathek device, so maybe this changed, but back then they didn't have the best reputation for long term maintenance, providing drivers to enable updates, etc...
To this day I have to look up whenever I get back into clojure what the "syntax" is of ns, require, import, etc.