[yogthos]

The reality is that there is very little actual innovation happening in programming. Most of the ideas in use today have been discovered decades ago. The big reason for churn is that people don't bother learning about what's been done before, and keep reinventing the wheel.

You don't see in other disciplines such as physics or chemistry where people spend years learning about existing research before actually starting to contribute.

With programming the barrier to starting to write code is much lower than to actually learning the background research. People don't bother looking at what's been done already, and just start "inventing" things.

More often than not this result in half baked ideas because the authors of projects don't really think about the full scope of the problem. Then once the project starts hitting limits in practice, people start kludging things on top of it, and eventually it becomes unwieldy to use. Then somebody comes by and does the same thing simplistically again, and the cycle repeats. Nothing new is learned in this process, and you get churn for the sake of churn.

[umvi]

> Most of the ideas in use today have been discovered decades ago. The big reason for churn is that people don't bother learning about what's been done before, and keep reinventing the wheel.

But on the other side of the coin, do you really want to be locked into a decades-old solution to a "solved problem" forever? Or are there still improvements that can be made to reduce friction and human error?

"Machine/human readable data exchange format? Yeah, that's a solved problem - we use XML for that. What's that? You want to reinvent the wheel? JavaScript Object Notation, are you insane? Didn't you bother seeing which exchange formats are already out there? XML can already do everything JSON can do and more! Plus, JavaScript is the exact opposite of what we value here, get that crap out of my face; like I said, XML is the one true solution to data exchange and forever will be."

[yogthos]

XML and JSON are both examples of the problem actually. S-expressions have existed since the 50s, and they solve all the same problems with a much saner syntax. In fact, if Mozilla marketing execs didn't insist on Java style syntax for Js, and it kept Scheme style syntax we wouldn't even need HTML and CSS today. We'd have a single syntax that would cleanly express code, styling, and layout.

[marcosdumay]

S-expressions do not have typed standards for serializing dates and booleans like JSON. They also can't distinguish numbers from text.

S-expressions also have no standard for comments, and can't distinguish maps from lists.

A S-expression based serialization standard would be a bit cleaner than JSON, but it's enough of a change that it's worth redoing anything.

[yogthos]

All of that and more is available with s-expressions in Clojure https://github.com/edn-format/edn

[kkarakk]

Your contrived example falls flat because JSON is flat out better for most use-cases and anyone having a discussion about it will probably fit into those use-cases.

People don't discuss solutions in a vacuum. Ideally they'd think about what the potential fallbacks of using XML alternatives are before jumping into a new tech. Which they will, unless they're really really new

[tonyedgecombe]

The funny thing is there are developers[1][2][3] out there who would like to turn JSON into XML.

[1] https://json-schema.org [2] http://www.jsoniq.org [3] https://www.p6r.com/articles/2008/05/06/xslt-and-xpath-for-j...

[umvi]

> Your contrived example falls flat because JSON is flat out better for most use-cases and anyone having a discussion about it will probably fit into those use-cases.

Easy to say with hindsight now that it is massively popular and has a huge ecosystem of parsers for every conceivable language. At the time it was invented though, it was yet another data exchange format and I'm sure there were a lot of grey beards pooh-poohing it.

[DocTomoe]

Back in the day, XML was almost universally hated by the people you describe as "greybeards", mostly because it was a convoluted "one size fits all" approach, hijacked by business, that ate bandwidth for overhead with none of it's promised benefits actually materializing (because everyone created their own, quasi-proprietary XML Scheme).

[wolco]

I remember a .NET developer using it in place of json. That was the slowest system I've ever seen.

[Ididntdothis]

I would say JSON is a little bit better than XML in some areas but also worse in a some. XML could easily have been extended with a few attributes. there was no real need for doing something completely different.

[nradov]

JSON is worse than XML if your use case requires namespaces.

[kickopotomus]

Tangentially, this is one of the reasons that I am a fan of EDN[1] over JSON.

[1]: https://github.com/edn-format/edn

[Ididntdothis]

I totally agree. But how do you balance this with the need for looking good on the job market? If you want to stay employable you are almost forced to participate in this craziness.

[oreglio]

+1 where I live the jobs with the highest pay grade are for some fancy frameworks. If I've been doing PHP for 5 years on an 10yo framework in a company that didn't feel the need to upgrade to anything. The day I want to find an other job I'm going to be confronted with opportunities that required mastering the latest technologies and I won't find something within my pay range because of this. That is the reality where I live Futhermore, how am I supposed to learn and practice all this new stuff when my company doesn't allow time to learn anything ? Is home projects enough to fill professionnal requirements for mastering a technology ? It's not easy to stay away

[snazz]

Aren’t personal projects how most people learn new technologies?

[Ididntdothis]

I used to do that. But right now I am in a high pressure job that sucks up a lot of energy but I don't learn anything new. When I come home these days the last thing I want to do is to spend more time on the computer. I need to do something active or just sleep to maintain my health.

[yogthos]

I've been working with Clojure for the past decade, and haven't had to deal with any of the craziness.

The job market is smaller, but so is the pool of developers. Companies tend to be more flexible because of that and are often open to remote work. I'd much rather work in a sane niche market than deal with the mainstream churn.

[cutler]

Isn't it fair to say, though, that you're not the average Clojure dev? I mean you have a book and a web framework to your name so that puts you way ahead of the pack. As an average Clojure dev I've found it very difficult to find work.

[yogthos]

That's just a result of me having been working with the same tech for a long time. When I was starting out with Clojure it was a lot more niche than it is now, and finding jobs was much harder. The whole reason I published a book was due to lack of beginner resources being available. So I don't think there's anything special about me, it's just that I was stubborn about wanting to work with Clojure and didn't get dissuaded until I made that a reality.

We have local Clojure meetup in town, and when I first started going there pretty much everybody was using Clojure as a hobby. Today, we have a bunch of companies using it in production, and all of them are actively hiring. The last three coop students I had all ended up getting Clojure jobs. I imagine this varies based on where you live of course, but another option is to simply introduce Clojure at a place that's using something else. That's where Clojure jobs come from in the first place at the end of the day.

[Ididntdothis]

It's nice to have found a niche you like. I thought I had a found one with the medical device I work on but it turns out the work is rather unpleasant and the hiring situation is not great either.

[collyw]

Sadly I agree as well. Instead of mastering the tools we have we need to make half arsed versions of everything because we don't have a mastery of this years trend.