Ask HN: Is all programming constantly changing or just front-end JavaScript? - <AUTHOR> I've been working on frontend dev for several years now, in the pre and post framework era. React and the other frameworks and ES6 in general, has meant a ton of change to the very basics of how we work.
The way I do basic things has changed fundamentally in the last 4-5 years. Some of that is because I'm no longer a "beginner", but much is because things have just changed a ton.
People who know the JS / frontend ecosystem AND backend stuff as well:
Is this rate of change unique to JS, or is it everywhere?
Is Rails very, very different now than 4-5 years ago?  Django?
I use PHP a bit and I've seen that change a bit, but it feels like mostly for the better, with namespaces in particular. Otherwise, I don't feel like PHP has had near the amt of change that JS has had.
tl;dr:   is it crazy everywhere or just with JS/frontend? <comment><USER3> I've been doing frontend dev for 10 years and had to change my stack & way of working _only_ 3 times:

\- HTML templates (served by Symfony/ASP.NET/Rails/Django) + jQuery + dependencies manually downloaded/updated/deleted/added to the index.html

\- ~2014: Angular SPA + Grunt + dependencies managed with Bower and added manually in the index.html

\- ~2017: React SPA + Webpack/Babel + dependencies managed with NPM and added automatically in the index.html with Webpack.

The last one is by far the stack with which I'm the most productive and I encounter the less bugs. I feel like frontend dev is finally mature and enjoyable.

But anyway, jumping from one stack to another one was quite easy. A few days of learning.

-

I've been doing backend dev for 10 years too and had to change my stack & way of working as often, if not more.

Jumping from one (or several) languages/frameworks/databases/ORMs/web servers/containers/package managers/testing tools/and so on, usually take several weeks of learning.

Imo, the "frontend world is crazy/changes too fast" is way over exaggerated.

<comment><USER4> I wish programming was more like playing a musical instrument. I feel like there is too much tuning not enough playing.

<comment><USER5> I think programming is more akin to developing and/or manufacturing instruments. Playing them would be the users.

<comment><USER6> I think the subparent meant the developer experience - this counts as playing as well.

</comment></comment></comment></comment><comment><USER7> It's all changing, but it seems that front-end JS is changing the _fastest_.

That's (IMO) due to a handful of reasons. But three standout in particular...

1) The state of Javascript's standard library is getting better but still pretty bad. So people continually reinvent new ones.

2) Every company with a frontend (see: Every Company) has to work with Javascript (esoteric compile-to-js aside) on the front-end, so the sheer number of people/companies using JS is larger than basically any other language or framework.

3) Javascript is increasingly the first (and sometimes only) language that new developers learn and tinker with. And we get the resulting ideas/platforms/frameworks/etc/etc that people invent as they're learning.

<comment><USER8> Agree with the first two points, but do you really think "new developers" are the ones who are creating the "ideas/platforms/frameworks/etc/etc"?

<comment><USER9> I do. Maybe not the tools that become popular, but new developers often consider publishing their first side project or personal tool to be a valuable milestone.

I think a lot of green developers' JS tools don't make it to the mainstream, but they certainly do make it more difficult to filter hype from substance. That's not a valid reason to discourage contributions: more people hacking on more stuff and making more discoveries, even at the cost of fragmentation, is far more valuable than putting a chilling effect on contributions (and there are other ways to mitigate fragmentation).

</comment></comment></comment><comment><USER10> From what I could see, the amount of churn in the Javascript world is unsurpassed by anything in software or product, almost to an order of magnitude.

I ended up being a product designer (my main, academic education), a frontend, and a backend with varying levels of expertise in my lifetime, so I have some direct experience.

My current advice as of April 2019 is to keep calm, if you can stay away from JS, do it, if you can't, pick Vue, avoid Webpack, use Typescript, and forget the rest. That should go fine for the next couple years, if you can manage to remove Webpack, even longer.

<comment><USER11> What's the matter with Webpack? It carries quite a lot of advantages, like tree-shaking, code splitting, and lazy loading.

These are real, tangible performance benefits, so I'm going to need some kind of compelling evidence as to why avoid Webpack.

<comment><USER12> Configuring it is a giant time suck. Particularly if you want to do hot reloading and all that kind of stuff.

I'm a big fan of Parcel for 90% of the things I do. It just works.

<comment><USER13> It does just work. Until you want to use something that the core devs don't use.

Like having the most popular front end framework be unusable for at least 6 months: [https://github.com/parcel- bundler/parcel/issues/645](https://github.com/parcel- bundler/parcel/issues/645)

Often you'll need to hope some third party made a plugin or make one yourself, which isn't really any different than using webpack, but the webpack ecosystem is much larger.

I struggled through parcel for a long time before I switched to Webpack 4 and had all of my existing build system and some additional niceties working in <45 minutes (probably 30 min of that was just reading the docs).

<comment><USER14> Looks like that particular issue was closed in July 2018? Also, anybody who considered that feature important enough could have fixed it. It's not rocket science. Certainly 10x easier than when that magical _something_ in the webpack build chain breaks.

<comment><USER13> > Looks like that particular issue was closed in July 2018?

Yes, after being open for 6 months.

> Also, anybody who considered that feature important enough could have fixed > it. It's not rocket science.

First off, maybe- but I was responding to the comment of 'it just works', so that's not relevant. My entire commentary was on 'it just works'. It doesn't really 'just work' if users have to implement their own plugins and fix their own bugs on super popular JS integrations.

Second off, a user did fix it, and it took the devs a month to respond to the PR- so you're still at the mercy of the core devs.

> Certainly 10x easier than when that magical something in the webpack build > chain breaks.

And this I'd just have to disagree with you on. Webpack has way more eyes and as a result I have had one issue (bug) with it which had already been fixed. I had many issues using Parcel beyond the one I linked of the most popular front-end framework not working.

</comment></comment></comment></comment></comment></comment><comment><USER15> I would argue that the frontend js changes are mainly to do with user expectations for what constitutes a well designed user interface. People expect more, and we have to give it to them to survive.

Addressing your specific question => have the backend languages/ frameworks changed? meh. sorta. They've made incremental changes, but the meat and potatoes look the same from 4-7 years ago for the opinionated frameworks.

However, the massive backend change that is probably more relevant to your questions is the shift in how we do infrastructure. Cloud based Version control, Microservices, Containers, Kubernetes, Docker, IaaS, Serverless, CICD systems... all of these things are transformational changes to backend ecosystems- both in scale and in the way that we interact. It has also made it so we write less code which is actually an increase in velocity for what we can produce.

thats my $0.02 anyway

<comment><USER16> Nice comment. I agree - I think innovation in backend development has really been subsumed by DevOps and data pipeline architectures, which have both really changed quite a bit.

<comment><USER17> Java and .Net is steadily improving. But unlike the JS world things are mostly backwards compatible and there exists stable (some have argued too stable) dependable frameworks.

We are starting to see this in the frontend world as well with Angular. After throwing everything away between 1 and 2 it is now mostly smooth (until Google decides to ditch it for something else).

<comment><USER18> > _Java and .Net is steadily improving_

Don't know about that. Java is IMHO about to enter a serious downward spiral as lots of stuff is being deprecated going to Java 9 such as ancient jetty/tomcat versions, JAXB 1, JAX-RS (which people used in the 2000's and early 2010's to create "RESTful" apps/microservices), and being force- obsoleted with incompatible newer versions having features no-one asked for. The Java ecosystem might have worked well under the illusion of multiple implementations for standard core interfaces, and with projects requiring high attention such as Hibernate, Spring, freaking Maven, etc. as long as it was the cool shit (it wasn't really cool IMHO) and had some money behind, but as Java is becoming legacy technology, it increasingly sucks to maintain pom.xml (aka pron.xml) files pointing to obsolete packages on a barren place like mvnrepository/maven central. My experience with younger devs having to maintain Java code: they secretly look for Go and entirely other career choices to get tf away from Java and Maven, and I can't blame them.

<comment><USER17> Yep. And .Net had issues in the transition to Core.

We are still talking about an order of magnitude or more (5-10 years of stability vs months.)

</comment></comment></comment></comment></comment><comment><USER19> * Yes, JS is changing stupidly quickly.

* C++ has changed a lot starting with C++11, and is still changing quickly. However, not nearly as quickly as JS.

* C is still stuck in the age of the dinosaurs. The tooling has gotten a little better with clang, cmake, etc. (though these are as much a result of its close relationship with C++ as anything).

* Assembly is not moving, mostly because it's dying. There's one notable exception: ARM.

* PHP is changing much faster than it has for a long time.

* I learned rails about 4-5 years ago and haven't done much with it since, but it doesn't seem very different (though this could be wrong).

* Rust, go, zig, and other new languages are all vying to replace legacy languages such as C/C++, even for high-performance, low-level applications. This may be part of the reason some things that didn't change previously are now changing: competition. Ditto with PHP and node.

* One other item of note I haven't really explored: functional programming seems to be the new hipster technology, and as a consequence is rapidly evolving.

It's kind of crazy in many places, which, to your earlier point, does indeed hinder productivity. For many people, more time is spent learning new frameworks, programming paradigms, etc. than actually doing work.

Oh, and I'm only commenting on the parts I have at least some experience with. I'm not sure for other areas. I've also heard a lot about swift on ios, along with cocoa. Even windows has uwp and has really been pushing its modernized c#/xaml ecosystem.

<comment><USER20> > * Assembly is not moving, mostly because it's dying. There's one notable > exception: ARM.

What? Assembly is not moving, because it's complete. You can pick Intel or ATT syntax, and then you just need to handle new mnemonics when your processor or choice ads new opcodes. Certainly, assembly has a smaller market share than in the past, but there's nothing to replace it for critical sections, so I don't see how it's dying, since it won't ever be dead.

<comment><USER19> > it's complete

That might be a better way to phrase it, you're right. I've got nothing at all against it, and appreciate using it for certain applications. I meant less dying in the sense that it will go away entirely and more that it is slowly becoming relegated to critical applications (i.e. very few applications are written in it).

</comment></comment></comment><comment><USER21> Much of JS's turbulence in the past 5 years has centered on it coming into its own as a "real" programming language/ecosystem. Modules, a headless VM, reactive patterns for user interfaces. All of these are things that other languages started out with, whereas JavaScript started out as, well, a scripting language. It was just sprinkled atop HTML pages, not running the whole show.

So my guess would be that things are going to slow down soon. Not completely; JS might remain one of the most turbulent ecosystems. But I think there will be a sharp dropoff in churn.

<comment><USER22> Yeah, Javascript just lived through its "adolescence", with all the changes and hormonal swings such a phase entails.

</comment></comment><comment><USER23> I think much of JS's churn has been the problem that the UI primitives (HTML) are unsuitable to what people want to do. When you can't even vertically center something without reading a bunch of web pages that tell you something like six different techniques, you can imagine that people are going to make a library to do make it easy to do. But since the foundation is crap, and good API design is actually hard, the result is not very good. So someone tries to fix it later, and runs into the same fundamental problems.

I think JS the language is in better shape, but even then it is hampered by poor decisions early on. (Integer arithmetic done with double-precision floating point underneath the hood? And it supports bit twiddling, but only if it is really an integer and not a floating point number? And implicit conversions? What could go wrong...)

But it is also hampered by other problems. I used WebWorkers recently to compute normals to large amounts of triangles on think, rather than transferring them over the network. In any normal language, I'd add a mutex around the data and spin up some worker threads. But in JS I can either copy the data, or give it away and that thread can't access it again. Since I need the triangle data and don't want the hassle of giving it away and then having the WebWorker give it back again (along with the normals), and then having to manage putting it in the right spot, as well as what happens if I need to access triangle data that's currently being processed, this is a major pain. I understand that the WebWorker design makes it impossible for the browser tab to hang on a deadlock or have all the fun threading errors, but as a programmer, JS is the one language that forces poor performance on me. So you can imagine someone like me, but with more influence, saying, "hey, we need a redesign to fix this." But since the previous designers presumably knew how all other languages work and rejected that approach, the redesign probably won't really fix the problem, for similar reasons why we didn't get WebPThreads the first time around.

<comment><USER24> " _I think much of JS 's churn has been the problem that the UI primitives (HTML) are unsuitable to what people want to do._"

I said the same when I wrote "The Problem With HTML":

Just to offer some perspective about where I'm coming from, I'll start by saying that I think of these as tools that made it easy for beginners to be productive:

Hypercard

Visual Basic (obviously I mean the classic versions, before .NET. The stuff in the 1990s was genius)

Adobe Flash

Adobe Dreamweaver

I spent 1995 learning HTML and putting together simple websites. I was thinking this is something I'd like to do professionally. In 1996 my father and I went to a demo in New York City, where Adobe was introducing PageMill, their Web page creation software. My father was impressed. My dad wasn't in the tech industry, but he was pretty smart about technology trends. He said, "Anyone who knows HTML just lost their job. This will replace the need to know any of the underlying technologies." But that turned out to be wrong. Even now, in 2017, most companies building Web software still rely on individuals to hand-write their frontend code. Indeed, from the point of view of business productivity, everything has been going in the wrong direction.

[http://www.smashcompany.com/technology/the-problem-with- html](http://www.smashcompany.com/technology/the-problem-with-html)

What is curious is that the companies that have the money and resources to roll out something better than HTML have not done so. The biggest surprise here is Adobe, which owns Flash, which many people thought of as the future of the Web circa 2004. Why didn't Adobe roll out new basic network protocols to replace HTML, and perhaps also replace IP and TCP? I don't know. They had the resources to do it and instead they did nothing but stand around and watch their most important asset die.

</comment></comment><comment><USER25> No, it's not, or at least not as fast as the current churn in frontend JS dev. I started doing Cocoa dev on the Mac in 2005. There have been changes to be sure, the biggest being the introduction of Swift I'm 2014. But I'm still using AppKit. I can (and do) still use Objective-C alongside Swift. And I have a pretty big codebase dating back to 2006 that still compiles and runs fine even with the latest version of Xcode.

(I realize this isn't backend dev, but there are other kinds of programming besides web development :-))

<comment><USER26> >And I have a pretty big codebase dating back to 2006 that still compiles and runs fine even with the latest version of Xcode.

I mean, the same is true for any webpage written using JS + html + css in 2006.

</comment></comment><comment><USER27> As somebody that's in JS all day but rarely touches backend, hearing about go, rust, kubernetes, docker, etc make it feel like backend is similarly fast- changing.

The difference seems to be in the narrative about the older tech. The "rails is still fine" crowd is loud, which is great. There is no equivalent for older JS tech. Though I would be willing to believe that's because things like jQuery are full of dated patterns that lead to bad times.

<comment><USER11> The beauty of React and other frameworks is that it separates the concerns of state and UI.

I don't see it as a tool for making a fancy button or widget, I see it as a tool for guaranteeing that what the user sees is always what's actually going on in the logic.

Too many times I've written something like a "clear" button or a "reset" button in jQuery, added an extra field, forgotten to include it in that clear/reset method and now the UI doesn't match the logic, leading to unpredictable and hard to debug results.

<comment><USER28> React separates concerns but it doesn't separate state and UI. It separates concerns through components but encourages tightly coupling relevant state and UI into components because a UI typically reflects changes in state (this is what JSX is for).

The "Why JSX?" on React's docs covers this with more detail: [https://reactjs.org/docs/introducing-jsx.html#why- jsx](https://reactjs.org/docs/introducing-jsx.html#why-jsx)

</comment></comment></comment><comment><USER29> Been meaning to write a blog post about this, but my 2 cents is this: The degree of change in a programming language ecosystem is inversely proportional to the expected lifespan of the systems being built using that language.

One caveat for the pedantic - yes, as the expected lifespan becomes zero, so does the rate of change. (i.e. you have a dead language)

The lifespan of a system gets longer the closer you move from the UI through the business logic and finally to the underlying data. It isn't uncommon for a business to rebuild its frontend website every 1.5 years or so, whereas their systems-of-record might be expected to last a decade or more.

Since JavaScript is used most frequently on the frontend (for obvious reasons), and new frontend projects kick off more frequently, there is less need for backwards compatibility, fewer risks to trying the new and shiny framework, etc.

I'll probably get internet slapped for saying this, but I would predict that JavaScript never does become the preferred language for the system-of-record type backends no matter how quickly it evolves. In fact, precisely BECAUSE it evolves so quickly. What makes it a great fit in the one niche, makes it a poor fit in the other. Lest this be taken as JavaScript bashing, note that the same thing happened to Java in reverse. It was evolving too slowly for the frontend niches it tried to move into years ago.

</comment><comment><USER30> While I think things have changed a lot since 2012 (when I started) I don't think they've changed that much since 2015. The language and ecosystem went through a lot of churn as single page apps and front-end complexity exploded. In 2012, there were something like 10 different popular JS frameworks to pick from and most of them have been all but replaced by the top 3, which seem to have stabilized: React, Angular 2+, and Vue.

ES2015 brought a lot of changes to the language itself. But recent years have been less dramatic minor syntactic improvements.

Front-end web has unique challenges and constraints that other front ends don't have to worry about as much.

A web app has to download the full payload of the app code and execute in one sitting. Yes, there's a myriad of ways to optimize this (such as caching, server-rendering, etc), but having to understand that just adds to the complexity of web development (and places evolutionary pressure on JS frameworks).

A web app has to look and run well in a huge range of screen sizes and devices and browsers. Android and iOS apps can target minimum versions of an OS or can usually ignore devices older than a few years. Browsers can't break backwards compatibility.

There is no common, prescribed tooling for the web like Android, iOS, and Windows enjoy, for example. This is a trade-off. I think the web sees more innovation and creativity as a result. But there's something to be able to spin up Visual Studio or xCode without having to worry about researching the trade-offs between 5 different approaches to tackle UI development.

Ultimately, I think JavaScript gets a bad rap, but the churn is intimately bound to its role as the universal programming language of the web. The web is no walled garden and it has evolved dramatically over the past decade. We should celebrate that JS has been flexible enough to grow with it.

</comment><comment><USER31> I'm Java developer for the last 10 years.

I learned Java 1.5 back in the day. This knowledge is useful. I added some syntax sugar over the years and Java 8 was huge release with lambdas and significant standard library improvements, but old knowledge is relevant.

I learned a lot of J2EE libraries. Enterprise beans, Portlets. Most of this knowledge is obsolete. But servlets and web services are still relevant.

I learned Spring and Hibernate back in the day. Well, Spring evolved a lot, but basics stayed the same, so that knowledge is revelant. Same about Hibernate.

All my JVM internals knowledge is relevant.

I learned Maven back in the day. Recently I switched to Gradle because it seems to be better system, but Maven is not obsolete and I could continue to use it. Though those systems are extremely easy and it's not a huge investment to learn them anyway.

Recently I added Kotlin to my tool set. But this language is heavily based on Java, so all knowledge about Java, JVM and standard libraries is relevant.

So yeah, Java is pretty stable platform and very few things were obsolete. Most of my knowledge is stayed relevant.

JavaScript is crazy world. I have to dive into it once every few years. Everything changing. My old projects don't have a chance to work with new libraries (especially fun with dynamic typing). JavaScript really needs One Big Architect With Beard who will make everything right for everyone to accept.

</comment><comment><USER32> Been doing back end for 13 years, and I try to visit a programming conference or two a year.

I think on average back end churns slower. Every year I'll hit a conference, and hear about the latest and greatest, but only a fraction of that stuff sticks around, and gets integrated.

I believe most company's won't swap language/framework/libraries until absolutely necessary. So the adoption of new things you might see at a company is much slower than someone who job hops every 3 years.

The company I am at now, had a C++, cout << "..." version of the site for 6+ years. The version that replaced that is a younger language with a MVC, but it's already been 9+ years since that was implemented, and it'll probably be a few more years until anything else supplants that.

Another thing that I think affects front end is the browsers. I don't know the stats, but I believe that Chrome/FF/Edge release more features, experimental features, and bug fixes per year, than your average language, or OS. This cascade of releases in turn effect front end code, and libraries. It's a wave pool, not a ripple in the pond.

</comment><comment><USER33> I think javascript is changing more rapidly because:

1\. It's on the back-end and front-end.

2\. Lots of corporate sponsorship of Node.

3\. Adoption of other languages' functionalities (namely async/await from C#, sets from Python, symbols from Ruby (could be wrong here), hash rocket from Ruby/Scala).

4\. Teams building their JS libraries to serve the unique needs of the team (Uber's fusion.js, React and Redux for Facebook, Google's AngularJs/Angular/Material Design).

5\. Browsers converging on JS spec which allows for arguably more cross platform development.

6\. Node is a "good enough" solution for managing IO when it was introduced (hesitating to say perfect because Ryan Dahl has mentioned that he would have done a lot of things differently and has introduced deno as means to correct what he thought were the warts of Node).

</comment><comment><USER34> I'm 10+ years as a game developer working largely in UI and I'm just learning JS now to make use of a new framework built by Coherent Labs. Previously the main tool set was Scaleform, which makes use of Flash scripting. I don't feel game dev has changed that much. Only very, very recently has it started to change at all.

In game dev land it's just C++ or C# if you're a unity shop, and things haven't changed too much. For a long, long time things weren't different at all, but with the new C++11, and C++14 things are getting a bit different. Right now I'm working in a fairly modern codebase, and it's been a learning experience for many of my coworkers to get up to speed on some of the new features introduced with C++14.

Probably the biggest change is occurring with the way that games are developed, with Object Oriented development practices kinda going away and games being developed in a more Data Oriented way using Entity Component Systems (ECS). Unity for example currently has an ECS system in preview release.

It's been pretty interesting to start learning more of the JS ecosystem. Even though I've only been working at it for a few months I've already had the tea table upended on me by our partners deciding to redo some stuff in typescript, so there's another new thing for me to learn.

</comment><comment><USER35> My intuition is that it's a function of how many people are doing the type of work you're doing and how fast the environment within which your code runs changes.

Front-end JS is where both of these factor are at their peak - it's often the first stack new developers use, and there are a _lot_ of devs doing it. Add in the speed with which the browser landscape changes and the (relatively) recent expansion of JS onto the server ... and everywhere else ... and you kind of have a perfect storm.

The other extreme is probably something like legacy systems development - <USER2> maintaining and expanding banking and financial systems - or embedded environments where the hardware has a long life expectancy and is not easily upgradable.

</comment><comment><USER36> I had primary been a C# dev, then switched to JavaScript/TypeScript for a few years. Lots of change in those years: JQuery, Angular 1, Angular 2, TypeScript, etc. Then I recently switched worked on a C# project. Other than a few Dot Net Core changes, it was basically the same, and easy to switch back to C# land. Not I am back in JS land. This time using Angular elements. When I left, I was getting used to declaring local variable with let instead of var. Now local variables are not let, they are mostly declared with const, which reinforces the notion that nothing is ever really "constant" in JavaScript world :)

<comment> munk-a Aha! And Angular is already one of those tech pieces that's "on the way out".

I've had similar experiences working primarily on the backend where paradigms may slowly shift but the tools for their declarations are _thankfully_ pretty stable.

<comment><USER37> I don't think angular is in the way out - there is still a lot of active development on it with a lot of users. React and Vue have more mindshare sure, but angular2+ is still heavily used as I understand it.

</comment></comment></comment><comment><USER38> It's not really unique to JS. We've had framework churn for a long time in lots of language communities. Look at Java and all the different desktop UI frameworks and build frameworks it has. .NET has at least three, first-party UI frameworks that are _still in active use_ , not to mention the dozens of 3rd party frameworks in the wild. Don't even get me started on Data Access frameworks.

What is unique about the modern era is that A) there are a lot more developers than ever, and B) it's easier to get a niche of other developers into supporting your vanity framework project.

So if there were always going to be X% of developers getting behind any particular project, A means that B hits a critical inflection point of N total developers that make it achieve self-sustainability. Once a project becomes self-sustainable, it looks important.

But going back to point A, all these new developers don't have the experience necessary to evaluate whether or not a project is worthwhile on its own merits, beyond "well, N number of people use it". For a long time, front-end work was denigrated as "lesser" because it was typically done as an afterthought, foisted on designers, not deemed "important" or "hard" enough for "real" programmers (please note my use of weasel quotes to indicate I don't personally believe it to be so, that's just how the development community has treated it over the years). So, being treated as something of a read-headed step child, the front-end community has lacked a certain level of adult supervision that could help guide its growth in a stable, manageable way. The "blind leading the blind", so to speak, out of complete necessity.

I guess it was a little easier in the late 90s and early 00s in that businesses were much more reluctant to use open source code. It was a lot harder to get buy-in on anything that "wasn't invented here". But that doesn't mean there wasn't a lot of "invention" going on.

Your job as a developer growing to become a "senior" is to learn how to ignore the churn of shiny new things and do what is right by your projects. This has always been the case.

</comment><comment><USER39> I program in C, C++, and Python at my day job, and those languages are pleasantly stable.

<comment><USER40> That's good to hear. I was worried that C++17 was a major revision to the language. At least Python hasn't had a major release since 2010 (Python 2, anyway).

<comment><USER41> Most places seem to use very old C++ versions.

<comment><USER42> The trick towards succcessful C++ development is to be very judicious in picking the features that you use. So not jumping to immediately using all the new features is a good sign.

</comment></comment></comment></comment><comment><USER43> Assuming you're using well-established technologies, your knowledge doesn't become obsolete as quickly. Not even close.

I can take a Rails developer who stopped using Rails 5 years ago and get them up to speed in less than a week.

</comment><comment><USER44> I think the churn rate is higher with front-end stuff, but I don't think it's really due to any special property of the technology. Honestly, I suspect that the rate of change in a given ecosystem is roughly correlated with the number of programmers actively working in it.

The number of front end web developers has been skyrocketing since the late 90s - a lot of people who've been in the industry for a while don't realize how many more of them there are compared to 5, 10 or 15 years ago. There's been growth elsewhere too, but just in the past few years the number of new bootcamp front-end developers I've seen seems to sort of swamp most other sectors.

I suspect that since much of the innovation in that space has been driven by open source efforts, the amount of change is in part driven by the number of eyes on problems and the number of people interested in trying new things. There are a jillion new JS projects on github every month, and some of them catch on, so there are always new options.

</comment><comment><USER45> Basically nothing down in database-land has changed, from what I can tell. Added features, but everything in those languages is designed to be backwards compatible (unless you're talking PL-sql, which has had some major shifts, to bring it in line with the rest of the world). And that's having done database stuff since Paradox for DOS and Access 2.0 (I think - might have been 3, but ... ancient days, anyway).

For the rest of my stack, it's mostly Visual Studio, and it's shifted a bunch over those 25 years: VB5 -> VB6 -> VB.NET until .NET 2.0 -> C#

Whatever changes there have been in HTML & JS, I've gone through, plus some of the DHTML weirdnesses that came along the way.

I'm going to say that, other than databases, there's about the same amount of needed change. And even with databases, those do change, in that you might want to get a bit more of a life and use something other than MSSQL for a change, which amounts to such a shift as the others have been.

</comment><comment> munk-a I think a big contribution to the rate of change of JS is that there is not yet a division between frameworks that do display stuff and frameworks that do utility/heavy lifting - this is partially due to the fact (IMO) that a lot of systems isolate heavy/complicated logic (especially business specific stuff) to a backend which JS queries to source data to operate over.

All of the current frameworks are intimately tied into display logic and that display logic is constantly in flux with shifting trends, device/accessibility support and shifting coupled technologies (css-flex, css-grid...). This lack of an isolation is causing people to jump frameworks to capture support for newer design trends and the like but... I think it's getting better. I'm not a front-end dev but react is the first offering I've seen that seems to really strongly reinforce a decoupling point between display and logic.

Really though, look at the realm of application development, in that realm users are accepting of crazy out-of-date UIs so the sterotypical "Oh this was definitely built with Java" (with substitutions for MFC and Qt) is sort of accepted. So, I may be off base.

All I know for certain is that there was a period in the 00s when I was really hopeful that all website design would be handled seamlessly by my designer coming in and throwing some style-sheets on everything and no changes to markup would be required - that time has passed and the responsive web is baking in a really strong assumption of native-application-like functionality, this isn't bad or good - it just is.

So, in summary, I'm still hoping that the majority of front-end work can shove a crowbar between the declaration of logic and the rendering, but I feel like the rate of UI change and shifting display thingies will forever outpace attempts to provide a unified toolset that actually captures the majority of intended uses.

</comment><comment><USER46> I'm doing Rails now, and I'd say no, it's just JS. Since Rails 4 was released particularly, most things upgrade between versions with only minor hiccups. The changes are mostly adding new modules to have a standard way to do various common things, but the old ways generally don't stop working. You can upgrade to the latest Rails and switch over to the new module, or not, at your leisure. New Ruby versions come out pretty regularly too, and the changes are mostly improvements on speed and memory usage, and addition of new syntax types. I don't think there have been any breaking changes since Ruby 2.0 was released.

I've worked in a few other languages, and I don't think anything else has the vibe of rewriting your whole system around a whole new popular framework every few years.

</comment><comment><USER26> The way of doing things in front end was rather crappy until 5 years ago. Front end development was basically in development and not ready for production yet until the creation of react. I expect it to slow down and behave more like a mature framework / language now.

</comment><comment><USER47> Things are not changing that much faster. What changed was the business model of software companies.

In a distant world the tools took years of closed work to get to version 1 and version 2/3/4 each took a couple of years too. And in most cases what you got was the whole package (Visual C++ with the C++ compiler, the IDE and MFC for example).

Nowadays is all in the open in github or similar. Feedback and updates are faster, community involvement is higher but things are less stable because all the polishing (architecture, interfaces, etc.) is done, from the perspective of the framework writer, "in production".

Basically is the agile business model of release early and often applied to software tools.

</comment><comment><USER48> All programming is constantly changing, but web front-end is probably among the subfields changing _fastest_. It seems to have slowed down significantly since about 2014 or so.

I've been programming professionally since 2000, and I'll say the biggest change is actually that the _market structure_ has changed. Back then, programming specialties were primarily divided by platform: you were a "mainframe programmer" (probably working with COBOL, RPG, DB2, etc.), a "UNIX programmer" (C, C++, awk, sed, perl, shell), a "Windows programmer" (Win32, MFC, later .NET), a "Java programmer", a "Mac programmer" (Pascal, C, later Objective-C, with the Mac Toolbox and later Carbon/Cocoa frameworks), an "avionics programmer" (Ada, C, with a good knowledge of physics), a "scientific programmer" (Fortran, Matlab, later Python/NumPy/SciPy), etc. The idea of a "web programmer" was just getting started, and the technologies (Coldfusion, ASP, JSP, PHP, Flash) were very immature, and largely outgrowths of the platform you used to run the webserver on.

Sometime around 2009 every software system became a distributed system, with multiple clients and a wide range of backend services running on different boxes, and so specialties bifurcated by your _role_ within that ecosystem. So now you have web front-end engineers, mobile engineers for Android & iOS, back-end engineers, data scientists, data engineers, deep-learning experts, infrastructure engineers, SRE/DevOps, security people, scalability/performance experts, etc. You're even starting to get blockchain engineers, though they don't fit into the current distributed systems model.

Some of these fields change less quickly than others; frontend (particularly web), deep-learning, and blockchain have been changing rapidly, while things like infrastructure, backend, SRE, and scalability change a little less rapidly. All of them are changing, though. It's the legacy platforms like the mainframe engineers and avionics engineers that haven't really changed much - but the flip side is that the current hypergrowth in the software industry has largely passed them by.

</comment><comment><USER49> Ive been using Django for almost 10 years, and it is still basically the same. There have been some breaking changes betweem versions but they have all been very easy to pick up. Even the python 2-3 nonsense has been relatively painless.

<comment><USER50> Django has a strong focus on backwards compatibility and has seen steady popularity for a long time.

</comment></comment><comment><USER51> I'm a scientific programmer (not a ton of experience but understand history). It's changed a lot over time but it feels like nothing was _much better_ than writing Fortran / bindings to Fortran until very recently (of course, take my recency bias into account). Yet, still, significant amount of "critical code" are written in Fortran. It's a slow-moving world in part because there is a lot of corner case complexity / significant logic. Parallelism in the form of CUDA / transparent GPU via Python is changing that a bit, but some algorithms are still not parallelizable.

</comment><comment><USER52> Honestly, I don't think it's really changed all that much. I think React/Vue/Angular/etc are confusing for people who don't write a lot of front- end applications but honestly I'm writing the same code I used to write years ago with jQuery except now it's a whole lot easier and more maintainable.

I think what has changed is a lot more people are writing SPAs (sometimes for good reasons, sometimes for bad ones) and are shocked by the complexity. It's like any other type of development: pick the right tools for your job and know them well.

</comment><comment><USER53> It's the result of a language that already had 85% of the tools needed for its domain where the changes in frameworks come down more to preference than anything else.

The same thing happens in PHP world where you have all the tools needed built into the language so most of the frameworks are essentially "arranging stuff".

In other web frameworks for other languages, you tend to see them creating the actual tools you need to use that language effectively on the web so it's easier for the community to coalesce around it than whimsically reinventing things every day.

</comment><comment><USER54> In a lot of areas the tools are fairly stable and progress is more linear. That's what I liked about C/C++ development where you could go deep and really learn details. The JavaScript world feels to me a little like reinventing the wheel every few years and recreating the same thing over and over. Maybe it needs a few more years/decades to shake out issues and reach some stability.

I think part of the problem is that JavaScript/HTML/CSS are so flexible that it's really easy to create new stuff.

</comment><comment><USER55> No, there are plenty of areas of software development that are much more stable. Nearly 6 years ago, I took a new job to develop a Windows desktop application using C# and WinForms. It hasn't changed much since then. There have been a few updates to the C# language to add some syntactic sugar, and to better handle certain niche concerns, but nothing that's had any major impact on how we typically implement things.

</comment><comment><USER56> The biggest change I can think of in my Python/Django development over the past few years is: print "" >>> print("")

<comment><USER35> I don't necessarily agree with that, but it might be a matter of when I started. My first Django projects were done with 0.96 if I recall properly.

Environment management has changed a ton - first with pip replacing easy_install and directly using setup.py, then with a bevy of tools for managing development and deployed environments (Vagrant, Docker, Spinnaker, K8s, etc.), and nowadays with more advanced packaging tools like pipenv or poetry. Along the way we've seen the maturation of CI and all of those supporting tools - linting, style enforcement, and coverage all growing rapidly.

</comment></comment><comment><USER57> It's an illusion.

I think this is just one of the rare examples where people can't arbitrarily roll their own new language because they're unhappy with bits and pieces of C++ or Python. Consider that in the same span of time we have kotlin, groovy, scala, elixir, erlang, r, go, rust, swift, etc., as well as many yearly flavors of C++. Its just that every time someone makes one of these it fractures the total attention paid to the the langauge/framework so they tend to become niche and peter out.

Javascript, on the other hand, is 1) profitable and 2) chosen because no matter what you really cant† choose a different language to do this work in the browser. This has the effect of concentrating all work in a very specific place. Image if instead of some people writing ruby, go, java, etc. you combined all of their equivalents of npm into one giant thing that everyone worked on all the time. I think it would look very similar to npm.

Oh and don't forget that framework development is not only driven by new engineering practices and concepts, but by new features that get added by Mozilla and Google like async/await and OffscreenCanvas. There's just much, much more to whole ecosystem when you're dealing with modern javascript than really any other language.

Also, Javascript is just LISP in C-style clothing so you also end up drastically different programming styles (take, for example d3's style versus jquery versus react versus three.js: all valid, all quite different and with different requirements like webpack.) This maps rather directly to when people made scala and groovy, imo. They're just like JSX/ES6+ but we consider them all different languages as opposed to "lots of javascript."

† even here there are some attempts to do this with typescript and rust that compile to restricted javascripts.

</comment><comment><USER58> Clojure doesn't move much at all. Python and Ruby seem to move a little, JS does seem like it moves extremely fast.

</comment><comment><USER59> Well, it's quite clear that JS is seeing a transformation at higher speeds, but a the same time I feel like the backend offerinngs are now more diverse and they do, too, evolve.

Spring in java is pushing somewhat on functional programming and lambdas are now another way to work in java, which means you can achieve a some kind of real func programming.

We have some beautiful newcomers like Elixir which are trying to fill a gab, so yeah: I think the JS world does seem like it's going faster (and it sure does until it reaches a "mature" state), but at the same time we have great evolutions across all the stacks.

Obviously not everything changes, some things stay the same, that's because we're looking at some mature technology and not the bleeding edge, but if we look at the outliers, I think you could easily pick at least an innovator around each backend language.

</comment><comment><USER60> You know, if you look at the current timeline, you'll see that much of the "JS churn" has basically stopped. I mean, yeah - people are trying new things, and products are being maintained. But, the landscape today is really very similar to what it was a year ago.

Yeah, there was a sort of "golden age" of innovation where we went from jQuery -> Angular 1 -> React, with Elm, Ember, and Angular 2+ as sidecars. And, the common libraries and tools have also slowed down in the same way.

We've finally solved a lot of the big problems, I think. Advancement will never end, but I think we'll be able to keep up with it from here on out.

</comment><comment><USER37> Backend has changed hugely with the advent of docker, kubernetes, cloud in general. Languages as well are changing a lot: golang, rust, hell even Java started a new release cadence with new stuff (lambdas, streams)

You don't _have to_ move to the latest way if doing things all the time in either front or backend. You do not have to follow the latest fashions. There are loads of backend frameworks that no one remembers because Django/ruby/spring became "good enough" and won, but back in the day there were many competitor frameworks for what was then frontend development. But we've largely forgotten about them all, as we will largely forget about the current gaggle of js frameworks once something "wins" with a good enough solution.

Tl;Dr - The way we develop frontend has changed from largely server side to now being SPAs. Things will calm down in the coming years as one framework becomes "good enough" and ends up becoming the de jour standard.

The knowledge and concepts never change though. What we're doing today in Vue and RxJs etc is as old as the hills as far as computer science is concerned.

</comment><comment><USER61> Sir, have you ever heard about Common Lisp? Here - please take home this free brochure.

Edit: the "brochure" \- [https://lisp-lang.org/](https://lisp-lang.org/)

</comment><comment><USER62> JS is unique in that it started out as really quite a bad language, but due to external circumstances (the success of WWW browsers) it became the most-used one.

So lots of people work on dealing with its warts.

</comment><comment><USER63> I used to work in .net, and found that it moved really fast also few years ago. But I think the js world is indeed the craziest.

I've went from jquery, to angularjs, to angular2, to polymer and now for my latest project I'm going no-frameworks JS. I've had enough.

Using Custom Elements (HTMLElements) is good enought for me, the latest ECMA makes it easy to do string formatting in the render function. It's not perfect, but I dont have to deal with all the pains of npm or webpack or any other distraction.

</comment><comment><USER64> Front end javascript really hasn't changed. The newer native stuff is great but you cant really use it without dropping support for anything Microsoft, or writing a bunch of shims not good.

SPA is an anti-pattern, don't buy into the whole craze to learn hottest new SPA framework which fixes all the problems with the last framework. They are all trying to make an anti-pattern work, it wont and no gimmick will fix that.

Stop learning gimmicky front end frameworks and start learning front end design patterns.

</comment><comment><USER65> Most of the languages are constantly changing but the JavaScript world is way faster than anybody else moves.

Although might be over-hyped, I personally believe it's more a good thing which moves the community even the industry forward. React was kind of enlightened the functional and reactive patterns to the mainstream developer community.

In contrast, most of the back-end communities still struggle with data synchronization between microservices, while all modern front-end frameworks are able to update all of the view or other read models almost magically.

If anyone wants a more specific example, I think it's quite shocking to me that there are only very few back-end architectures knows clearly how to design a whole large scale architecture push WebSocket notification for a given user -- just like typical google suite stuff. WebSocket has been there for years, there are so few people know how to develop and operate a stateful service... unbelievable.

I agree with that shipping business functionality is the most important value in technology. However, I feel most of the back-end communities worries about the problems they are encountering too much. And they don't really care about the art of the programming itself, yet advanced architectures indeed require language or platform level construct, for example, immutable data structures are much easier to be concurrent safe, or just the computation should be pure to be safely rescheduled on other core or machine, etc.

In the front-end world, I think for example React and Mobx which I'm using are pretty much taking care of most of the accidental complexity of software development. In the back-end world, I can imagine something similar to a full- blown framework like Rails but built on top of something like Orleans or Lasplang would help us get rid of all the accidental complexity, and just expressing the domain itself instead. We're still too far from there.

A quote from SICP lecture: [https://youtu.be/2Op3QLzMgSY?list=PLE18841CABEA24090&t=81](https://youtu.be/2Op3QLzMgSY?list=PLE18841CABEA24090&t=81)

"And the Egyptian who did that, geometry really was the use of surveying instruments. Now the reason that we think about computer science is about computers is pretty much the same reason that Egyptian thought geometry was about surveying instruments."

</comment><comment><USER66> My professor in school (2008) said if you want a chill job in Technology you should be a DBA because that changes the least compared to the other stacks.

</comment><comment><USER67> Prolog proceeds at a stately (not to say glacial) pace.

</comment><comment><USER68> > a ton of change to the very basics of how we work

I do data work on Python (20%) and R (80%). Of these,

\- Both base Python itself (2 -> 3 -> 3.6) as well as the major data libraries (e.g. pandas) changed a lot.

\- Not base R but the major libraries (e.g. dplyr, ggplot2, knitr) changed significantly.

So, for me, yes, a ton of change to the very basics of how I work happened when using Python and when using R's newer libraries.

</comment><comment><USER69> Using the terminology of Hardware, firmware, software where changes are slowest in hardware and fastest in software. I suspect JS introducing something which is even faster than software. May be called Slipperyware. By the time one grasp it slips out and take form of yet another framework.

</comment><comment><USER70> It's just with JS/frontend.

In 20 years, the change I've seen is very little. Pointers became 64-bit. C99 brought nicer initialization and the ability to declare variables after statements. Optimizers got cruel, particularly with aliasing. Vectorization and SMP can be put to use.

</comment><comment><USER71> I've been in Java shops and .net shops and PHP shops and the only constant is js. I think ubiquity comes with turbulence

</comment><comment><USER72> I'm not sure, I just want functional programming to become widely adopted <3

</comment><comment><USER73> it seems to me that the devs who been at it for a while, sees the frontend landscape as huge chaos.

but the newcomers coming into the scene, seem to either love or embrace the fast pace changes.

i'm not really sure what to think of this situation.

</comment><comment><USER74> Every 15-20 years everything changes, the new generation ditches the old, repeating the same mistakes nth time but making some progress.

<comment><USER75> 2 steps back, 3 steps forward. Sometimes, during spring cleaning, you have to make a bigger mess to get to a cleaner state than when you began. It's a timeless issue. Continue to patch existing codebase with known flows that are so severe that it will never allow for full completion, or scrap the whole thing and start over using $newHotness that has the potential to get you where you need to go?

<comment><USER74> Yup. Rewrites are tricky but doable. I think the best way to rewrite is to do it inside out, sorta like DNA replication or gradually move things into micro services of sorts.

Porting however is more difficult IMO, like rewriting everything in Rust or from jQuery plugins to React.

</comment></comment></comment><comment><USER76>
        Every programming language consistency is
        inversely proportional to the scale of adoption.

And by adoption i mean how popular it is with actual companies using it and pushing delivery over code-quality, with an ever growing pool of junior devs. Adoption as hobby languages or slim startups full of very experienced devs doesn't count.

> PHP PHP is in usage decline (by the demographic outlined above). So it is > getting more consistent (take a look at it during the 3->4->5 timeframe, you > will think JS is moving slow)

> [ruby on] Rails This is even on a steeper incline than PHP today. So expect > more consistency i guess.

> everywhere or

Java is always popular (it's the bread and butter of the demography defined above!), and people make money selling IDE plugins (something hard to grasp out of the java world) which accelerates the inconsistency. So it is always a crap shot. A pile of incompatible concepts every time a new senior dev passes trhu the project. Not to mention in the last years every project moved full steam to scala and then back. So every 4yr you can see the same project and not have any idea what is going on because they moved from ant to maven or gradle, or rewrote half (only half) the project in another jvm language, or now every method and class is full of never seen before toolkit annotations, etc.

GoLang started as a nice perl/bash script replacement and is becoming the new web application server as it gains adoption. Which was first bringing consistency and parallelization to what used to be done with perl or bash, is now full of weird ways to manage packages, which are mostly implementation of web authentication and what not.

erlang is in sweet spot. Some bigCo uses it as hiring bait, and there is lot's of smaller companies using it. There still isn't a mass of jr devs pumping out features on erlang projects, so consistency is at an all time high. With frameworks that actually add to the ecosystem instead of flipping everything on its head for silly syntax sugar.

Cpp had a bump in adoption recently because of CND related projects and more focus on ssl and things like that. So the new standard bodies are busy at work churning in new things nobody asked for, but that so far everyone is loving.

</comment><comment><USER77> Just the front end in general and JS.

I have code I wrote in TCL in 2001 that still works and runs in production today.

</comment><comment><USER78> I have impression that other way round, changes in js are one of the slowest amongst programming languages.

We have lots of js in our project, and it's mostly the same js as when I first learned it in early 2000s. No ES6, because it's completely unsupported in Android Browser and IE. Why bother with transpiling for just shorter syntax for functions? We had Sprockets and I'm not sure if there's adequate transpiling of ES6 for it. So, browsers are stuck with ES5 forever, does that mean that JS is evolving fast? And ES6 itself is ancient, it was released when iOS still had skeuomorphic UI.

On the other hand, while playing with IoT project I had to use C++ recently, and it feels like entirely different language than 10 years ago. Even Ruby had syntax changes in last few years, and lots of small standard library changes.

Maybe fashion and "best practices" in js world change frequently, but not the language itself. Featurewise it's still on the level of Python 2.2.

<comment><USER79> Obviously if you are deliberately avoiding new language features, you're still going to be writing the same JS as you were in the early 2000s. I could write Python 2.7 and it would be pretty much the same thing.

However, a lot of ES6+ features offer more than just syntactic sugar. For example, arrow functions remove a lot of weirdness regarding 'this'.

<comment><USER78> There's two javascripts: one that really works in browsers, and it's still ES5. And other javascript, that works on abstract virtual machine implemented inside Babel. And only the first one is "real" javascript.</comment></comment></comment>


Andreas Osiander: The greatest villain in the history of science? - <AUTHOR> https://thonyc.wordpress.com/2015/12/19/the-greatest-villain-in-the-history-of-science/ <comment><USER2> >the ad lectorum (to the reader) that he added to the front of Copernicus' De revolutionibus that one could regard the heliocentric hypothesis as a mere mathematical model and not necessarily a true representation of the cosmos

But choice of reference frame _is_ arbitrary. Modeling the solar system or even the universe with Earth fixed at the center is just as valid as with the sun fixed at the center. Even today the ad lectorum is not wrong per se!

<comment><USER3> [http://www.preposterousuniverse.com/blog/2005/10/03/does- the...](http://www.preposterousuniverse.com/blog/2005/10/03/does-the-earth- move-around-the-sun/)

See also [http://physics.stackexchange.com/questions/10933/why-do- we-s...](http://physics.stackexchange.com/questions/10933/why-do-we-say-that- the-earth-moves-around-the-sun) with several good answers.

</comment></comment><comment><USER4> One 'scientific villain' that occurs to me: Ronald Fisher. He used his considerable influence in the statistics community to suppress Bayesian inference research because he disagreed with the premise of prior probability. Set Bayesian research back decades. He was a strong proponent of the p-value causing some of the reproducibility crisis in scientific publications.

See: "The theory that would not die" by Sharon Bertsch for a very entertaining read of the entire conflict.

Full disclosure: I've published papers in Bayesian statistics.

<comment><USER5> Without specifically disagreeing with you, the real advance that led to the bloom in Bayesian statistics was fast computers. MCMC and Gibb's sampling, and variational interference are what got the intractable-when-useful field of Bayesian statistics back on its feet.

<comment><USER4> I think you are certainly right that computation has really permitted Bayes to shine. But I think the stigma against the study persisted for decades: we had Metropolis-Hastings in the 70s, after all.

And as the book argues out, Bayes, even when limited to non-sampling techniques such as conjugate priors, was still useful for a variety of interesting problems in cryptography, search theory, etc.

</comment></comment></comment><comment><USER6> TL;DR: No.

<comment><USER7> Yeah, that title belongs to Andrew Wakefield.

<comment><USER8> Thomas Midgley Jr. is also a good contender: [http://www.psychedelicporcupine.co.uk/2010/05/thomas- midgley...](http://www.psychedelicporcupine.co.uk/2010/05/thomas-midgley-jr- the-worlds-most-destructive-man/)

"Something had to be done, so Midgley took it upon himself to hold a demonstration where he illustrated just how harmless he believed lead to be. He did this by pouring tetra-ethyl lead over his hands and then holding a cup of it under his nose and inhaling it for sixty seconds. Whilst performing this deadly demonstration he was assuring reporters of how he could repeat this practice daily without harm. He did this whilst knowing full-well the dangers of lead poisoning due to having been over-exposed to the substance a few months previous to the demonstration."

<comment><USER9> Although the TEL seems inexcusable, I'm not convinced that the second point about CFC's is fair.

Yes, they destroy the ozone layer, but that wasn't known at the time Midgley invented them, and they replaced refrigerants that were corrosive and poisonous.

I also question this line: "Beneficial ozone is not terrible abundant, however. If it were distributed evenly throughout the stratosphere, it would form a layer just 2 millimeters or so thick."

How would evenly distributed ozone create a layer? Something seems wrong with the research here.</comment></comment></comment></comment>


I Am Tired of Hearing Programmers Defend Gender Essentialism - <AUTHOR> http://meloukhia.net/2014/02/i_am_tired_of_hearing_programmers_defend_gender_essentialism/

<comment><USER2> As someone about to implement something this is relevant to, I'd like to know what's wrong with just having a gender choice of: "Male", "Female", "Neutral". Your profile on some web site doesn't need to be a precisely accurate description of the real you. Those three options should be considered not what you are, but what you're okay with the web site referring to you as. If you identify as neither male or female, I don't see how you can be offended by choosing the option that remains neutral on the issue and identifies you as neither.

</comment><comment><USER3> It's not that people are defending gender essentialism, they are just stating certain facts about bodies and brains based on the radically different hormonal profiles found in female bodies and male bodies. Just to give one example, typically female forms of ideation tend to be more holistic and integrative, whereas male forms of ideation tend to be visual, analytical, and reductionistic. Does this mean that women can't be mathematicians? Of course not.

Same thing with bodies - men tend to have greater upper body strength and develop muscle more easily, whereas females tend to have greater difficulty developing muscle and find it easier to develop adipose tissue. Does this mean that no women can get good at bench press? Of course not, but it does mean that men are more likely to be the outliers in any competition of strength.

None of this is to say that one sex is 'better' or 'worse' than the other. People who take these proven sex differences to mean that get offended for no reason.

</comment><comment><USER4> Once you open your self up to all the conceivable permutations of identity, your logic starts to get really hairy. Consider the GenderBread Person: [http://itspronouncedmetrosexual.com/wp- content/uploads/2012/...](http://itspronouncedmetrosexual.com/wp- content/uploads/2012/03/Genderbread-2.1.jpg) That shows 8 axises of identity determination, compared to the traditional binary. Does a FTM 2-spirit pansexual want to buy tampons? Beats me but I know women might and men probably don't. Where do you draw the line? FB added, like, a million different options and it seems that there is a new identity every day. There is no clear way to model this data. Some identities are exclusive, some are not, some are contradictory... Whats worse, it seems that many identities are purposefully vague! For example, many people identify as 'queer' yet 'queer' is perhaps the least useful label possible! AFAIK, it paradoxically labels those-who-do-not-want-to-be-labled. I need something that fits into a relational database, is relevant to my work, minimizes the risk that my app will offend somebody... oh and I have to convince my boss that it's worth the investment in time. The best answer I see is an optional "Male, Female or Other." I agree that making the gender field (or any other field) mandatory is a poor idea.

Frankly, I'd like to side-step the whole issue by not asking the user at all.

<comment><USER5> That people link all sorts of preferences to 'gender' and make charts is not necessarily important to others. Even in a civilized society, I have no obligation to accommodate your fantasies, or even be polite to you.

The gender question, I think, is useful only when it is actionable. If it helps to choose an honorific (Mr, Ms etc) then fine, whatever. Probably safer to just leave both out.

<comment><USER4> Actually, that's exactly what living in a civilized society means- being polite, to some degree or another. I would also recommend that you not call your users' identities as 'fantasies.' It may not matter to you but it matters to them and you should respect you users if you wish to keep them.

<comment><USER5> It means civil discourse, which gives everybody a voice. It doesn't mean having to pretend everybody is right. It definitely doesn't mean being polite, not by a far margin.

I'd be glad to recognize any distinctions that don't require an entirely new dictionary. Especially if they are actionable. Mostly, it'd be nice if folks kept private things private.

<comment><USER4> But these things are not private and they are actionable. And they update the dictionary every year, because language changes. If you dismiss them out of hand, you will lose a lot of opportunity.

If greater concern, though, is that your contempt for non-normative identities is rather poorly concealed. Trust me- you do not want to speak to your users as you have spoken to me.

</comment></comment></comment></comment></comment><comment><USER6> For someone supposedly upset about generalizations, busting out "brogrammer" in the first paragraph is not a good look.

<comment><USER4> I'll never understand how some will advocate equality and sensitivity and in the same breath and with no irony, drop a derogative like "neckbeard." The venomous way some spit the word "bro" just reeks of hypocrisy.

</comment></comment><comment><USER7> This whole argument seems extremely petty. Gender is such a basic category that in most cases I think users appreciate it's differentiation. This is like getting angry you got credit card advertisements because you started college. Seriously, how can anyone consider this a 'privacy' concern?</comment>


Forget Early Adopters: These People Are Happy to Be Late - <AUTHOR> http://www.wsj.com/articles/forget-early-adopters-these-people-are-happy-to-be-late-1453827437?mod=e2fb <comment><USER2> Pay/subscribe wall. No fun ;-)</comment>


Portland Police Bureau latest in U.S. to encrypt radio communication - <AUTHOR> https://www.oregonlive.com/portland/2020/09/despite-push-for-police-accountability-ppb-local-agencies-latest-in-us-to-encrypt-radio-communication.html <comment><USER2> It's absurd that they didn't.

Of course it would be nice to get the audio published after the shift ends. Data can be made public without endangering an ongoing operation.

</comment><comment><AUTHOR> Original title was too long: "Despite push for police accountability, PPB, local agencies latest in U.S. to encrypt radio communication"

<comment><USER3> Is there a law enforcement carve out for using encryption over the airwaves?

If not, I smell an opportunity for a regulatory challenge. Likely ineffectual in the long run, but who knows, maybe other people are on board with resolving governmental self-referential inconsistencies.

</comment></comment><comment><USER4> Does the encryption used protect the Portland police from DHS eavesdropping?</comment>


Elixir as an Object-Oriented Language - <AUTHOR> http://tech.noredink.com/post/142689001488/the-most-object-oriented-language <comment><USER2> "Object Oriented" is as loosely defined a thing, in practice, as "Functional". Per the article, Alan Kay has given a definition of Object Oriented, that Erlang arguably nails in a solid way, but while he was the founder, he's not the only voice. Others have touted the importance of inheritance, and other such things, which can be far harder cases to argue.

That said, I think the real value of Erlang is the actor model, and specifically, the way it causes you to model things and concepts (or objects, but without the baggage) as isolated processes. This is a direct parallel to the kingdoms of verbs and nouns, but, many OO languages provide isolation for their objects/things/nouns, but not for the processes/verbs. Or rather, the process is not naturally related to the noun, but rather almost an Aspect Oriented programming approach. The actual execution crosses the boundaries of the objects/things/nouns (i.e., a single object's instance being accessed by multiple threads, all contending to modify it; the verbs span the boundary of the noun). But in the actor model, that doesn't happen; you have proper isolation of state (the thing/noun/etc) in the actor, but also isolation of execution (the process/verb) in the actor. That is, one actor = one isolated chunk of both state AND execution.

It's this model that people are looking at when they say it's better at object orientation. I think that's a bit misleading (per other comments), but there's real benefit to it.

</comment><comment><USER3> This sort of article and the sort of thinking underpinning it is a betrayal of the uniqueness (relative to the more ``mainstream'' choices) of languages like Elixir/Erlang. In fact, part of the point of using a language like Erlang or Go (besides more production-relevant claims to fame like reliability or build times respectively) is to break one's thinking out of the object-oriented lens.

Not every abstraction is object-orientation. The notion of not caring about the internals of something (as with the article's mention that "This is possible because Elixir doesn't care how the process works internally") is something that goes deeper conceptually and further back in time than objects as we know them.

It might be neat for weaning someone off an overwhelmingly OOP mindset, but that's not what it seems to be trying to do. Instead, it's just demonstrating how to use a new language without it forcing you to think differently, and that's worrying. If every language is a fantastic object-oriented language, why bother using any given one?

</comment><comment><USER4> This entire article is about Elixir, not Erlang. Can someone fix the submission title?

Also this fits with my experience with Elixir. I can apply all my OOP baggage very well in Elixir; one active process maps beautifully one object.

The only thing I miss is a clear _terminology_ distinction between the Elixir versions of an object and a class. Both are called processes, which is a bit messy. Strictly a process is just the runtime thing (the "object") and the "class" is just a function (or, in practice, a module that follows a certain convention). But I've heard many people refer to the latter as "processes" too and I'd love a better word.

<comment><USER5> Sooooo

A process is a function running in its own context.

A module is just a namespace to group some functions. But there is no real link to what an object brings.

At best you could try to compare an OTP behaviour to a class but even that...

<comment><USER6> A process is an object. It accepts messages and sends messages. It encapsulates state.

<comment><USER5> Sure. But... Then you enter the place where you get overloaded semantic. In particular... the fact that "Object need Classes !" or "Objects are a thing that encapsulate Functions with hidden state"

I have some ideas for post about the fundamental difference beetween RPC and message passing. And how it impact how you think about your code (Java/Cpp vs Smalltalk/Erlang). I think it is the main point.

<comment><USER7> > In particular... the fact that "Object need Classes !"

That could hardly be less of a fact though.

</comment></comment></comment></comment></comment><comment><AUTHOR> Alan Kay, When he first created his OO language, SmallTalk 72, It didn't have classes, or Inheritance. That development came later in Smalltalk 80. The only thing that Kay cared about was encapsulated code that could pass messages around to other encapsulated code.

Kay's thoughts on the matter are in the link below.

[http://programmers.stackexchange.com/questions/46592/so- what...](http://programmers.stackexchange.com/questions/46592/so-what-did- alan-kay-really-mean-by-the-term-object-oriented)

I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind

\-- Alan Kay, OOPSLA '97

</comment><comment><USER8> I gave a talk on OOP and what I think Alan Kay was really talking about WRT OOP [http://brianknapp.me/message-oriented- programming/](http://brianknapp.me/message-oriented-programming/)

<comment><USER5> You sir are doing the talk i want to keep doing for the Elixir Community. I sometimes wonder if we do not need a way to talk about this type of thinking more publically...

</comment></comment><comment><AUTHOR> Also who ever changed the title, It's "Erlang - The Most Object-Oriented Language," as per the quote in the article! \-- "Joe makes a comment about Erlang being "the most object-oriented language.""

If you are going to Change it At least change it to "Elixir - The Most Object- Oriented Language"

</comment><comment><USER9> Somewhat related, there was a fun Lightning Talk at ElixirConfEU, "Advanced OOP in Elixir" \- [https://www.youtube.com/watch?v=5EtV2JUU0Z4](https://www.youtube.com/watch?v=5EtV2JUU0Z4)

</comment><comment><USER10> I feel like stepping the reader through creating a whole Mix project was a little bit excessive. Was a simple code snippet demonstrating a process or two (and maybe a module or two) really insufficient for that?

Otherwise a good read. The idea of Elixir/Erlang being "object-oriented" by way of their application of the actor model was one of the "eureka" moments in my transition from procedural languages (in particular, Ruby).

</comment><comment><USER11> This is of course not true, but PR. Here's what Joe wrote once:

"When I was first introduced to the idea of OOP I was skeptical but didn't know why - it just felt "wrong". After its introduction OOP became very popular (I will explain why later) and criticising OOP was rather like "swearing in church". OOness became something that every respectable language just had to have.

As Erlang became popular we were often asked "Is Erlang OO" \- well, of course the true answer was "No of course not" \- but we didn't to say this out loud - so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully)."

[http://web.archive.org/web/20020413132000/http://www.bluetai...](http://web.archive.org/web/20020413132000/http://www.bluetail.com/~joe/vol1/v1_oo.html)

<comment><USER12> Well, Armstrong may have been exposed to C++-style OOP like many (most?) programmers, which would of course lead him to believe that Erlang was very different from C++'s OOP. But languages that really orient toward object orientation rather than a thin semantic layer over procedural programming look a lot more like Erlang. Take Smalltalk for example: Smalltalk objects talking to each other looks almost identical to Erlang threads talking to each other.

<comment><USER13> Erlang uses asynchronous message passing. Smalltalk models method calls as synchronous message passing. Therein lies an enormous amount of difference.

<comment><USER14> Question about elixir: In the article's example, it looks like the HTTP.get function call is turning the asynchronous message into a blocking call. Is that common in elixir/erlang, for libraries to provide blocking utilities?

<comment><USER15> Yes, it's quite common for Elixir libraries to provide blocking calls. If your program is well-designed though, the calling process will be "blocked" but other processes will be executing at the same time. So having a process waiting on a HTTP call has no impact on the overall performance of the system. This is one of the big reasons why Erlang/Elixir's model of having many processes is awesome.

It's also very easy to use the async/await pattern if you want to make a call, do other work, and get the data from the call at some later point.

</comment></comment></comment></comment></comment><comment><USER16> Looks unreadable [https://i.imgur.com/MTJziXw.png](https://i.imgur.com/MTJziXw.png)

<comment><USER17> Works in Safari Technology Preview 12 on Mac OS 10.11.6: [http://i.imgur.com/cdN7ky2.png](http://i.imgur.com/cdN7ky2.png)

<comment><USER7> Seems to work just fine on all OSX browsers (latest stable Chrome, Firefox and Safari)</comment></comment></comment>


Martin Scorsese Says Streaming Algorithms and Netflix Are Ruining Audiences - <AUTHOR> https://www.vanityfair.com/hollywood/2020/01/martin-scorsese-streaming-algorithms-moviegoers <comment><USER2>
      At the Palm Springs International Film Festival,
      the director of The Irishman praised Netflix for
      giving him the resources to make the emotional
      gangster epic, but then he said companies like
      that could be harming moviegoers by force-feeding
      them too much of what they've already seen.

Oh, the irony in that... he is not self-conscious about The Irishman. Also he's right of course and it's exactly the reason why Netflix picked up The Irishman.</comment>


Feature Literals + Enhancements + Blocks == Properties++ - <AUTHOR> http://guidewiredevelopment.wordpress.com/2011/06/05/feature-literals-enhancements-blocks-win/

<comment><USER2> That's a pretty creative use of reflection, really liked it.</comment>


Apple Store in Amsterdam evacuated after iPad exploded - <AUTHOR> https://twitter.com/BrandweerAA/status/1031154040560918528 <comment><USER2> I'd really appreciate if these were flagged not English. This is the fourth copy I've seen of this story on the front page of 'new' here, and none of them are English, and none of them are marked not English.</comment>


I Used to Believe - <AUTHOR> http://www.iusedtobelieve.com/selected/best

<comment><USER2> ..I was going to be a rock legend. Fail</comment>


Human Git Aliases - <AUTHOR> http://gggritso.com/human-git-aliases <comment><USER2> In case the OP is reading (or if anyone else tries it).

The "graph" alias is missing a "%Creset" near the end, so your terminal will be stuck in red text after running it.

Add %Creset immediately after %Cred%d (before the closing single quote) to fix the issue.</comment>


Richard Stallman, Ultimatist - <AUTHOR> Richard Stallman is an Ultimatist. He pushes the boundaries, creating more room for more diversity. Think of The Overton Window, http://en.wikipedia.org/wiki/Overton_window . Without Stallman and others staking out the far position, the entire dialog is constrained.
Stallman's job isn't to "win". It's to defend a certain form of expression's right to exist. There are no half-measures, no room for compromise.
Agree or disagree with Ultimatists like Stallman, I really don't care, because this isn't about you. Just know this: if the push for free software (as in speech, not beer) was gone, your range of options would be diminished, and then you'd care.
Ultimatists tend to be outside of the mainstream, mocked. Makes them easier to dismiss. Kudos to David Winer for standing up for Stallman, because haters suck.
Other contemporary Ultimatists you may have heard of, and mocked, are:
Glenn Greenwald, defense of human rights, civil liberties, the US Constitution.
Bev Harrison, opposition to touchscreens, internet voting.
Greg Palast, investigative reporter.
NARAL, defense of abortion rights.
Earth First, others, defense of the environment.
NRA, defense of gun rights.
EFF, defense of privacy rights.
ACLU, defense of civil liberties.
In conclusion, I hope that anyone who reads this thinks twice about the role Ultimatists play. <comment><USER2> So few people understand this. Every critique of Stallman that begins with "...but I think we need someone more reasonable" can usually be dismissed right away because it's already missed the point. I'm grateful that he's taken it upon himself to take the criticism for the sake of the rest of us.</comment>


Spotify for movies - <AUTHOR>

Does this exist? It should! <comment><USER2> It's called netflix :P

And spotify might enter the movie business itself. [http://techcrunch.com/2011/04/28/spotify-lands-major- studio-...](http://techcrunch.com/2011/04/28/spotify-lands-major-studio-deals- prepares-to-launch-movie-service/)

<comment><AUTHOR> I disagree about netflix. Reason being is they don't have the same caliber movies as spotify has songs. The Amazon Prime Instant Movies is getting close, but someone has to lock down a deal already!

Awesome post with the techcrunch article :) I guess if spotify can make deals with major music labels, the same or similar applies to movie studios.

<comment><USER3> The problem is that licensing is a lot more complicated than for music, as films themselves are subject to a large number of licences (from the music they use to individual actor contracts) trying to verify every licence involved in the movie allows for online distribution in a flat-fee manner is a non-trivial task. And that's if you can persuade all the movie studios that it's a good idea.</comment></comment></comment>