Advice to my younger self: become allergic to the churn - <AUTHOR> https://lambdaisland.com/blog/2019-08-07-advice-to-younger-self <comment><USER2> The piece reads like a Unix pastor's pulpit preaching

"Great nutritious technologies to use: Make, Emacs, Lisp, CLI"

"Bad unwholesome technologies to use: JavaScript, Ruby, IDEs, Graphical User Interfaces"

I personally hate Make, it's burned me too many times. Now I use CMake, and I haven't been burned in years.

And is it candy or an olive that I like VSCode and not Emacs (not that I've ever tried Emacs, I just don't feel like investing in that ecosystem)?

I agree the front end web framework churn is out of control; hopefully it will stabilize over time. But come on, don't just rip on random scripting languages that have been around for 25 years

<comment><USER3> I mean I haven't been a professional for multiple decades but I've written professionally in a very wide range of fields in C, Matlab, Java, Python, Verilog, Assembly, Fortran, and Javascript, and, there is no language that I've seen that has more hair pulling, braindead I just learned to program yesterday type programming nearly as much as I've seen in Javascript.

(I've worked intimately with decades old scientific programming codebases where the scientists didn't give a single damn about writing cleanly and even that was an order of magnitude more readable than the willy nilly, consistency be damned crap I've been seeing in Javascript)

(I feel like I could describe a small portion of hell for me and it would include Javascript)

<comment><USER4> I have a similar set of experiences but have a feeling that it's at least partly down to the sheer number of people writing Javascript and the very public nature of much of that code that so much of it is a mess. I don't think there's anything inherent in JS that make is produce messy code other than the fact that it's easy for amateurs to get results (thanks to the fact it runs in a browser and there's lots of easily available code samples).

<comment><USER5> I'm a JS dev and I love it, but JavaScript is to programming languages what the electric guitar is to musical instruments.

It's the thing that attracts a lot of new beginners who may or may not be interested in the more serious theory that makes programming what it is.

<comment><USER3> Have you worked in other languages for substantial amounts of time?

<comment><USER5> I did Objective C for about 1-2 years, and a bit of java over the years. But no, not really.

<comment><USER3> Fair enough. Thank you for taking the time to a question that, in retrospect, sounds antagonistic (apologies for that).

<comment><USER5> Nah, I didn't take it that way

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> >> The Churn is losing a day debugging because a transitive dependency changed a function signature. The Churn is spending a week just to get a project you wrote a year ago to even run. The Churn is rewriting your front-end because a shiny new thing came around.

If you think the churn is that then you're lucky. To me, the churn is working for the man. Everything I ever do is for the man.

If I could ever reach a point where I could say, fuck you, the man, well, that'd be the day, wouldn't it? That'd be The End Of The Churn that The Man invented.

<comment><USER7> There are many many organizations and Institutes that aren't the man. You don't have to work for a soulless corporation. You can do work that helps the greater good of humanity.

<comment><USER8> Under the current version of American Corporatism, no, you cannot work for a company that isn't soulless. A Corporation is legally required to work only to increase the value of a share, nothing more.

Maybe you can work for a non-profit if you're lucky, but how many are there out there that pay market rate?

<comment><USER9> > A Corporation is legally required to work only to increase the value of a > share, nothing more.

No. That's a misconception. Corporate directors are required to act in the interests of the shareholders, but they have a lot of discretion in determining what those interests are and how they are to be served.

Here's a reference from a decent law school: [https://www.lawschool.cornell.edu/academics/clarke_business_...](https://www.lawschool.cornell.edu/academics/clarke_business_law_institute/corporations- and-society/Common-Misunderstandings-About-Corporations.cfm)

<comment><USER8> That reference cites the Hobby Lobby case where they got to opt out of providing insurance for contraception and a Facebook video of an expert explaining how the current corporate system produces sociopathic entities (corporations). I don't believe either fundamentally debunks the idea that the agents of corporations are required to attempt to increase the value of a share.

I agree that there's still a lot of lee-way in that, like giving an employee a bonus might hurt shareholders directly in the short-term but you can claim it increases productivity and so is a good decision. You still have to justify all decisions in terms of value to the shareholders though. If you (as CEO) decide to just stop all work and spend every day at Disneyland until the coffers are empty you can be sure you'll lose that suit. And when every single decision has to be viewed through that lens, you aren't able to directly do real good for the world, just indirectly.

</comment></comment></comment></comment></comment><comment><USER10> I recently cut a technology out of my life that was causing a lot of churn, and I'm much happier as a result.

That technology was TeX, even though it's on the author's "good" list.

It's somehow got to a point where every time two people got together to work on a document, we had three different incompatible header files; package X doesn't work with version Y of package Z; what order you import packages in matters on my computer but not on a colleague's (still not sure why); the order of macro expansion and character class redefinition in some packages causes hard to track down bugs ...

80% of what I need to do, I can do in markdown and then run through one of many document-generating tools. Currently for some projects I'm using gitbook- cli and I'm both more productive and much happier. I even wonder whether I want to make a fork of gitbook-cli, it's something I'd trust myself to be able to contribute to.

For the other 20%, I use word. Yes it's a WYSIWYG interface but for short documents (max 20 pages) where layout and design is important to get right, I've found myself being able to save time and frustration compared to TeX.

Editor-wise, I use vim or vscode depending on the task. I've tried emacs, we two are not really compatible.

<comment><USER11> Have you tried ShareLaTeX/Overleaf? I have had better luck maintaining header compatibility with it.

[https://en.wikipedia.org/wiki/ShareLaTeX](https://en.wikipedia.org/wiki/ShareLaTeX)

[https://www.overleaf.com](https://www.overleaf.com)

</comment></comment><comment><USER12> Accept the churn or be left behind, imo.

The best thing you can do to insulate yourself from the pain described in the post (trying to remember how code worked, etc) is to brain dump important things you learn along the way. I've recently begun keeping a TiddlyWiki[0] for every major project I undertake. In it, I keep unexpected things I learned, cheat sheet items, command-line snippets, and longer form entries about structure.

The best part is it was all written by me, so the communication barrier is as low as it can possibly be. Reading one of these TWs allows me to pick up a project again extremely quickly. It's also useful on large projects where different areas are like their own projects unto themselves.

Tools, not closing yourself off, help you overcome your limitations.

0\. [https://tiddlywiki.com/](https://tiddlywiki.com/)

<comment><USER13> The more experience I gain, the more dubious I grow of the "being left behind" concept. It's rookie bait. With experience, you instinctively know when it's time to move on from a technology (it no longer serves its purpose well or at all) vs. jumping on the hype train to get some breeze in your hair.

<comment><USER12> There's a difference between jumping on the hype train and being stubbornly stagnant. You will definitely be left behind if you refuse to adapt to new "industry standard" tech, even if all of that new tech is 90% old concepts with slight changes, repackaged.

That's not to say you should jump on every new half-baked hackathon- originating javascript framework. But it does mean you should have your finger on the general area of the pulse of where the industry is moving, and start learning that tech. For example, pick up Rust for systems programming, instead of C.

I know a web developer who refuses to learn or use any web tech besides PHP. Finds cloud-based hosting confusing as well. "I can do anything I need in PHP." Everything, except find good paying job that isn't maintaining gnarly legacy codebases. Doing PHP is his bread and butter, and unless he decides to learn some of the newer (stable) webdev tech, he's going to find himself with no marketable skills in the future.

</comment></comment></comment><comment><USER14> Agreed. And I'm a rubyist!

I think ruby has actually gotten a LOT better at minimizing the churn (both core/stdlib, and the ecosystem, specifically including Rails itself), as a result of people learning from the experience. The ecosystem still doesn't prioritize it as much as I'd like.

I also think this points out the benefit of sticking with a platform/ecosystem for a while. Many people didn't realize the danger of backwards-incompat churn until they saw it through experience over years.

You notice it when you work with the same code for a while -- if you are always abandoning a codebase and coming to a new one, you abandon before it gets painful, and either have a new one that isn't yet painful or a legacy one where you can blame the pain on your predecessors making bad decisions.

If you are always abandoning a platform for a new one -- the dangers of 'churn' aren't apparently in a less mature platform, you never pay the price at version 1.0, only after it's been around a while. But they _will_ be if it lasts long enough and you stick with it long enough -- if when it starts hurting you abandon it for some other new thing thinking the other new thing will be better and not realizing it's better in that respect only cause it's _newer_... you never learn.

<comment><USER15> Agreed, working on my own codebase for over 4 years taught me more than anything else about how to design and write decent code. Its easy to blame someone else for crap design / code but when its your own it forces you to think of how it could be done better.

</comment></comment><comment><USER16> Unfortunately doing this tends to lead to being unemployable because too many people associate being immersed in churn as "productivity." This spreads philosophically and suddenly people doing the hiring want these kinds of people who can "solve" these kinds of "problems."

At the same time, finding something that works and sticking with it perpetually sounds wonderful - perfect, even. But breaking things and doing hard things also leads to innovation and new ideas.

So ultimately I think there needs to be a balance and everyone should embrace _a little_ churn while eschewing it in the broad form.

<comment><USER17> "Unfortunately doing this tends to lead to being unemployable because too many people associate being immersed in churn as "productivity." This spreads philosophically and suddenly people doing the hiring want these kinds of people who can "solve" these kinds of "problems.""

Totally agree. Sticking to things that work can hurt your job prospects seriously. You are quickly an "outdated dinosaur".

</comment></comment><comment><USER18> Thinking you can label the churn as something it's possible to avoid by single choice upfront about dependencies is not realistic enough to be useful. Churn is not just about the dependencies- but also about the project ...

Projects which are updated often have a forcing function on them - they need to become updateable ... that can mean tests, that can mean reasonable build tools, and that can mean dropping individual dependencies that are too painful to update.

Obviously some ecosystems make all these things easier than others — typed languages with reasonable consistent build processes help more than anything. Good codebases that isolate and wrap usage of most dependencies next and reasonable automated tests probably next most useful.

It is definitely the case that some codebases are easier to update than others even given the same ecosystem/dependencies. When is the pain of "churn" most reasonably considered my fault instead of yours? Those are the situations can be fixed and they can get you pretty far — much further than "ahh, this codebase has javascript and webpack i shall rewrite with make and closure" can get you on average ...

<comment><USER19> Maleability is a very important concept, but this article is not about it.

This is not about your code not breaking while you change it. It's about things breaking when you change nothing. I've learned the lesson long ago by using PHP software, some ecosystems just break much more often than others.

</comment></comment><comment><USER20> "Examples: Clojure, Common Lisp, HTML, Make

Counter-examples: JavaScript, Ruby, React-Preact-Vue-Angular-"

OP does not give any reason as to why these are churn and why stop them ? This makes no sense...basically to op's point we should just never adopt new technology because it's just a new shiny thing. This makes no sense at all.

<comment><USER21> He didn't elaborate but I agree with him. I've seen too many examples of junior devs having to work on some small feature or enhancement, and their idea becomes rewriting the entire code base in whatever new framework of the month happens to be for the time. Yes there are plenty of reasons to adopt new technology, but you have to balance the pros and cons with keeping your business running and most importantly not disrupting your customers.

At the end of the day, honestly, how many frameworks do you need to build webpages? And 95%+ certainly are not operating at a Google or Amazon scale.

On a side note, I recently saw a dev spend a few days wrestling with dependency issues - he was trying to wire in Spring into a Java application and running into configuration issues with decorators. At the end of the day, this was a tiny, tiny application that periodically ingests messages from a topic and forwards their payload to an email service. These are 5-10 messages a day and the emails that are generated go to internal business customers as a courtesy and not less of a mission critical notification. It's worth thinking about what was the business value vs the cost?

The take away isn't that you should never use new technology - rather, understand that new technology or change in general comes at a cost. Your job is to balance that cost considering several factors - code quality (cost of time spent), flexibility and extensibility, features (the stuff valuable to whatever function responsible for your pay check), cost of on going support and maintenance (operational load). Disregarding those factors and over indexing on latest and greatest is usually the wrong approach.

<comment><USER20> Agree with everything you said...but remember all the issues you listed are not new to junior dev and also not new particular technology. Same debugging issues were being worked on in c and c++. Your observation is correct but applies to not only to all technology but life in general.

</comment></comment></comment><comment><USER22> Another name we often use is "Business-As-Usual" (BAU) or "Technical Debt". Although some business-as-usual and tech is a necessary evil and in some cases, a good thing, I have also wasted many hours to tasks that create little to no value.

Another way to spot "The Churn": When you're done, what new value did your effort create or unlock? Are users better off? Is the system more resilient and reliable? Or did you just get it back to the way it was working before everything went sideways?

Find more ways to create and unlock value and you'll find you move forward much faster.

</comment><comment><USER23> > These are the olives of technology. Olives aren't candy, and tasting them > the first time isn't always pleasant, but soon you will develop a taste for > them. They have been here since ancient times, and they will remain for > centuries to come. They are good for you, solid, reliable, nutritious. Eat > less candy and more olives.

For what it's worth, olives are basically inedible from the tree and require a considerable amount of processing before they are actually edible.

</comment><comment><USER24> Churn can be all of the things the post describes, and I think it's good to be skeptical of churn--always looking for ways to avoid it.

But it's also hard to tell the difference between churn and _maintenance_ , and I think one of our modern world's blind-spots is a de-prioritization of maintenance.

</comment><comment><USER25> I'm sorry -- you lost me at UNIX, LISP, The Web, Emacs, TeX. There is a reason UNIX and Linux is so fragmented - it was the thing that was churning for so long! In some respects, it continues to churn (I'm looking at you, Linus Torvalds).

<comment><USER26> What are you referring to? Linux never intentionally breaks userspace code.

<comment><USER27> Linux as narrowly defined as the kernel is very good at not breaking things. Linux as used in common speech to mean a Linux distribution and associated libraries undergoes constant churn.

I maintain a cross platform desktop app for Windows, macOS and Linux.

Windows is the best, 32 bit versions going back 15 years still work no issues. macOS is next, 32 bit don't no longer work, but 64 bit versions still work going back 5+ years. Ubuntu is by far the worst, some library I depend on changes it's API pretty much every year, and the old version is removed, breaking my app.

The solution appears to be Flatpak which bundle up the app with all it's required libraries. However I'm not sure how to make this work for plugins. Would each plugin need to be in it's own Flatpak? It's insane.

</comment></comment></comment><comment><USER28> Clojure's reduced churn is a consequence of sitting at a local maxima in programming language design. If it were not a local maxima, there would be churn as we search for it.

UI has no such minority consensus for local maxima and is very much not solved, which is why React-Preact-Vue-Angular is churning while the humanity hivemind iterates towards a solution.

Here is the relevant Rich Hickey quote: [http://www.dustingetz.com/:rich- hickey-web-frameworks/](http://www.dustingetz.com/:rich-hickey-web- frameworks/)

</comment><comment><USER29> Relevant (arguably overblown) talk by Jonathan Blow: [https://www.youtube.com/watch?v=pW- SOdj4Kkk](https://www.youtube.com/watch?v=pW-SOdj4Kkk)

<comment><USER30> Thank you for sharing, I really enjoyed this talk. I somehow missed it when it happened.

<comment><USER29> No problem, I loved it too.

</comment></comment></comment><comment><USER31> > The Churn is spending a week just to get a project you wrote a year ago to > even run.

How much effort would it be worth avoiding to spend a week every year ?

Sure the weeks can add up, but so does the time spent on low level abstraction, and refusing to adopt better tools when the whole environment in changing around (e.g. there is no mention of native mobile environments. Would it be churn use to Swift instead of non-ARC ObjectiveC ?)

<comment><USER27> I find Swift very bad for churn. Swift has had 5 versions in 5 years, with breaking api changes each time.

Every answer on Stackoverflow about Swift has several answers, one for each api version. Any time you grab some Swift code from the web or an older project, it's not going to work.

Avoiding the churn isn't an option since new Xcode versions drop support for old Swift versions. And only the two latest Xcodes will run on latest macOS. They even drop the support for the conversion tools. So if I go back to an old Swift project now, it won't compile in my Xcode, nor will my Xcode help convert the code to modern. My only option is to run an order version of Xcode in a VM to convert the code.

If I'm writing a library I want other people to use or share between projects, I'll still do it in Objective-C. Apps I do in Swift but I find it annoying.

I still have 15 year old non-ARC Objective C libraries. Why spend the time updating them when the are debugged and work fine?

Every time I have to do a Swift version update I introduce bugs.

<comment><USER31> That's part of my point.

Cutting yourself from new frameworks and hardware features just to cut churn would be a horrible tradeoff in most cases.

There are some niches where churn can be mostly avoided, but I think churn is usually a fact of life we could just embrace at a healthy pace.

From the opposite angle, a field with extremely low churn would seem suspicious to me. For instance I would expect any language with no significant update in the last 10 years to have abysmal unicode support.

</comment></comment></comment><comment><USER32> Important code needs love, it needs to be improved, made more robust, have security issues handled, consolidated if it starts to bloat, to be cleaned and kept legible even for whitespace so you or the next guy can easily see and continue to look after all the moving parts.

If it's important, it needs and deserves all those things; they are not "churn" but maintenance.

<comment><USER19> Important code needs to become stable so it can be improved instead of fighting constant degradation.

Churn kills important code, making it unfit for purpose.

</comment></comment><comment><USER33> I'm not sure his list of technologies is accurate to the general coding population. Nor would anyone else's list be accurate. The more general idea is to learn the tech you use... learn it well and deep enough to avoid the kind of churn the article describes. If you can do that with modern tools, fine. If you can't and want to stick to older tools, that is also fine.

But draw your own line in the sand as to which tech you are going to use in your production systems, and move to new tech only when both your skills are sufficient, and there is a matching business need driving the change.

</comment><comment> 1-6 I frequently bite into olives only to find pits that did not get machined out.

<comment><USER34> Unless they're stuffed olives, I'd recommend just buying them with pits in. There's quite a lot more variety that way at my local grocery store.

(I know you didn't mean that literally)

</comment></comment><comment><USER35> Just this morning I've spent an hour trying to get a well-known Http library to work in my project, cos the developers keep completely refactoring all the classes and methods. Stop it!!

<comment><USER25> The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automatic unit test execution -> signals if the build is ready

<comment><USER17> Until your CI pipeline causes churn because something doesn't work anymore....

<comment><USER2> We use GitLab CI, and it's been working maintenance free for 3 years now. We configured the test runners in 2016, and haven't touched them since and they have never randomly broken - even across GitLab updates (of course, YMMV depending on if you like to be on the bleeding edge all the time; we are always 1 cycle behind the bleeding edge).

<comment><USER36> What an awesome compliment for our team. Thank you!

</comment></comment></comment></comment></comment><comment><USER37> The first thing that came to mind when I read the opening paragraphs regarding churn is developing mobile applications. I find myself losing a day or two just to get my apps to compile if I ever go a month or two without spending any time on them. It's brutal how quickly things can break and dependencies need to be updated.

Is it possible to do modern mobile dev without churn (coming from a situation where my clients often go months without requesting features)?

<comment><USER38> I only know of iOS, but here's what I try to do

\- Reduce the use of dependencies to the minimum (I'm bad at this) \- set version compatibility in my Cartfile / Podfile \- when new breaking versions of Swift came out, suggest to my client a 2 / 3 mission solely focused on upgrading their app and it's dependencies (otherwise it will probably make their next last minute super-urgent-right-now feature needlessly long and complex to develop)

But I'd also willingly take any advice on this

Edit: also, semi-solved this for my JS work using automated dependency update services, like dependabot, coupled with unit / integration tests, but still haven't found a similar service for Swift

</comment></comment><comment><USER39> I mean, sure. But at a certain point, LISP was Javascript in terms of bleeding edge no? As someone who has built multiple things using React Native I can absolutely relate to the churn, but each time I willfully wade into it and each time I get better at handling all the pains that come along. I also can't think of a better way to improve debugging skills than to use a tech stack that gives rise to issues not easily solved via StackOverflow.

<comment><USER40> Lisp was theory before it was code.

Javascript was a fashionable imitation of another popular language dialect.

<comment><USER41> > In 1995, Netscape Communications recruited Brendan Eich with the goal of > embedding the Scheme programming language into its Netscape Navigator.[16] > Before he could get started, Netscape Communications collaborated with Sun > Microsystems to include Sun's more static programming language, Java, in > Netscape Navigator so as to compete with Microsoft for user adoption of Web > technologies and platforms.[17] Netscape Communications then decided that > the scripting language they wanted to create would complement Java and > should have a similar syntax, which excluded adopting other languages such > as Perl, Python, TCL, or Scheme. To defend the idea of JavaScript against > competing proposals, the company needed a prototype. Eich wrote one in 10 > days, in May 1995.

<comment><USER42> Perl, Python, Lua were not ready for embedding (unsafe FFIs, OS-dependent APIs) and would have been flash-frozen in early bad states. See [https://news.ycombinator.com/item?id=1905155](https://news.ycombinator.com/item?id=1905155). Better that JS got the early bad state freezing and thawing (ES3 helped; ES5 was constructive and ES6 made JS pretty good).

In early 1996, John Ousterhout stopped by to pitch Tcl/Tk, but it was too late. VBScript was coming, but JS in 1995 Netscape betas got on first and saved us from that dystopia.

</comment></comment></comment></comment><comment><USER43> > Examples: Clojure, Common Lisp, HTML, Make

> Examples: UNIX, LISP, The Web, Emacs, TeX

1\. Or just computer science.

2\. Churn is not a problem. If you keep accepting the churn, you will learn them faster and faster, until you scan the doc and know most of the things, if it is churn. If it is not, it's something new (eg: Coq), then you have the ability to identify 'new but not churn', instead of just learning 'old and not churn' from a half-century ago (eg: Lisp).

3\. Among the churns, there would be 'meta churn' like Haskell, Lisp, Erlang, and Rust. There are countless languages stealing Monad from Haskell, and Kubernetes patterns are very similar to Erlang OTP patterns.

4\. Editors and IDEs are really irrelevant, I used Emacs a lot, I'm very fluent with Vi, but for some languages, I prefer Intellij and VSCode. Just use tools you feel productive.

</comment><comment><USER44> In The Churn this week, a colleague wanted to improve a query for a widget on a dashboard. The query was perfectly fine but now I'm stuck getting the wrong results debugging everything I can find.

<comment><USER45> If it can be made faster then it's fine, BUT that colleague needs to write a test first if it wasn't there yet (and I think it was given how you're fixing wrong results / debugging).

</comment></comment><comment><USER46> This is the main reason I haven't picked up the new shiny languages after using Python for a decade. OK the Gil is not cool but I'm OK with multiprocessing (one example among many)

I look at Julia (for HPC) and think, sure if I were a grad student and had time to burn. But now, I need to get an idea to figures live coded in the space of minutes, NumPy and matplotlib are boring and just fine.

Research is one domain where churn is a very much a daily thing. Careers are made on churn, in research.

</comment><comment><USER47> > The Churn is losing a day debugging because a transitive dependency changed > a function signature. The Churn is spending a week just to get a project you > wrote a year ago to even run. The Churn is rewriting your front-end because > a shiny new thing came around.

These forms of churn are hardly related besides that they are often self- inflicted. The first 2 examples are really just technical debt, and perhaps they can be referred to as the "grind" rather than churn.

Rewriting your code base to use the _framework of the now_ may happen because of the industry changing to a point where using old-reliable.js is making it difficult to hire new talent, whereas elon-musk.js is the hot new thing that tons of programmers are interested in. Companies can feel obligated to follow this trend because they think they'll become obsolete if they don't. The company I currently work for is going through this at the moment, actually.

The churn that this causes is more novel than the grind because, as an engineer, you are learning to do the same job in a different way. Avoiding the grind isn't likely to fundamentally change the nature of your job, as writing documentation and reducing the number of dependencies aren't very radical ideas. But taking someone from one language and having them learn another, or having them transition from one framework to another, can effectively demote an engineer to junior grade until they've had experience with their new tools. With the churn, your expertise can lose its meaning.

Even if you learn to solve the grind, solving the churn can be difficult even if your loyalties remain to a single tech stack. With the exception of purely personal projects, the industry will continue to shift its own loyalties to different tools, so you've got a few different games to play when looking for jobs:

\- Be the one who knows the legacy tech and can make sense of other people's horrible legacy code. (Which the company will inevitably decide to have rewritten in something like React out of the belief that all their problems are being caused by the old technology.)

\- Be the one who knows the hot new thing and can write code that, whether or not the code under the hood is atrocious, will make the bosses believe that they can be like the Googles and the Facebooks.

The vast majority probably pick the latter. But if one wants to avoid the churn as much as possible, the probably need to not only stick to tried and true tools but also find a good company and stay there indefinitely, rather than hopping companies every few years. Of course, that may come with a harsh penalty down the road.

</comment><comment><USER48> "Churn" is definitely an issue. And JavaScript does have its own complexities. It feels weird singling out Ruby and JavaScript (and any other individual technologies), though.

I wonder if part of this is a human instinct to "other" people who are different. Someone feels superior because they use Lisp, and looks down on people using JavaScript. Or vice versa.

<comment><USER49> I think it's less about languages and tools than the culture around those languages and tools. I think it's centered around the the answer to the question: How many customers, developers are we willing to toss to make this change? For the ruthless and stodgy Microsoft the answer was zero. For Linux close to zero.

</comment></comment><comment><USER50> Remember the last time you were supposed to fix a bug, but the code was so "bad" that you rewrote the entire application?

IMO this is why churn is not going away. It's much easier to achieve flow- state from zero than working up to it in a codebase that you're unfamiliar with.

</comment><comment><USER51> Watching people fight Javascript never gets old. Keep yelling at those clouds, fogies.

<comment><USER52> What properties do you think make modern JavaScript a good language, rather than a (now, finally) barely passable language being actively ruined by its own ecosystem?

</comment></comment><comment><USER53> I'd have told my future self, moments after he said the word "churn" \- wait wait wait, you're from the future and you have a time machine and you are giving me programming advice. You realize if you give me stock picks none of that will be relevant right?

</comment><comment><USER54> Like all industries we can't just stay still. Curiosity and creativity are important. The "olives" are a fruit of some sort of older technology that has matured. Maybe this technology was the "shiny new some some time back then" Some people try to fix the the shortcommings from yesterday's technology with their own ideas and view of things and nobody can prevents this. This is just basic, human creativity at work.

Maybe what's important is not making people belive that yesterday's technology is obsolete and should be burried or abandoned. The shiny new thing is just an other tool in the toolbox and it's not because I created a new shape of screw that all the other screws are worthless. There is still plenty of screws all over the world that need to be unscrewed, we need those tools to do that, people to know how to work with them and some of these screws still need to be made. Maybe people don't talk about these screws as much ? They don't make the news anymore because they've been there for so long ?

Maybe the point here is that social media thrives on the shiny new thing, it's the core concept of it. An old news paper is worthless, no one ever sold an older news paper. So they need to grab some attention to live and the shiny new thing is a way to accomplish that.

But it's not because there is lots of articles about all those new frameworks that the older ones are worthless. We need both. Maybe for some projects we will not choose an architecture based on 10 years old concepts and frameworks and some other projects need stability and a whole tested and stable toolchain and documentation for the years to come.

What kind of work do you want to accomplish ? Small projects where you work alone ? Where you just serve a few people ? Or big projects with a huge infrastructure that needs to deliver to millions with great economic impact ?

I bet you don't use a hammer only when you want to build kitchen furniture. And then tools that are needed in a factory that build kitchen furniture are not the same that the ones that needs to be used for home. They need a whole supply toolchain, some testing & quality checking. Whereas the worksman in his own workshop is going to have less tools ...

We need all kinds of software and technology, maybe what's hard is to be able to identify the right ones and defining precisely what we want and where we think we will go. People are always going to want to try to use the shiny new thing. We all need novelty, enhancing the shortcommings of your current tools.

<comment><USER55> 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.

<comment><USER17> 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.

<comment><USER55> 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.

<comment><USER56> 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.

<comment><USER55> 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.

</comment></comment></comment></comment></comment></comment><comment><USER57> Damn, if I was making a time machine to go back to 1999 I would have told my younger self, "Sell all your Tech stocks, right now." :-)

</comment><comment><USER58> You are the problem. Not the tools.

</comment><comment><USER59> javascrip is an amazing language- get over yourselves

<comment><USER51> HN is full of this stuff. These people don't even understand what modern JS is.

</comment></comment><comment><USER60> > Counter-examples: JavaScript, Ruby, React-Preact-Vue-Angular-…

Great programmers can find virtues in all tools. Hate the player, don't hate the game.</comment>


A Better Way To Travel - <AUTHOR> http://www.onthewayapp.com/

<comment><USER2> This was a fun week's worth of work for Team TeachStreet. Felt good to get everybody working on a single project (we've spent many months working on lots of different areas of the site, and working with different partners). It was really refreshing, and you could almost 'feel' morale climb, as we all had a chance to just have fun for a few days!

</comment><comment><USER3> As a lover of road trips, I really dig what you're doing.

If I may offer two observations:

1) I would appreciate some sort of filter to hide multi-location stops like Sub-way, Exxon, etc. If you are going to have such data at all, I would appreciate the ability to hide it. I can find a gas station by reading the highway signs, but it's not as easy to find the super unique and interesting stops.

2) Scaling the page to see more of the map makes the text very difficult to read.

Anyways, pretty darn good for a week. Thanks for sharing!

<comment><USER4> @schultzy: thanks a ton for the feedback. here are my responses to each observation:

1\. that makes a ton of sense. adding filtering in the future was something we were thinking about and we'll add this suggestion into that list.

2\. you can always zoom the window in closer, but we'll look at making the text on the map more readable.

thanks again. :)

</comment></comment><comment><USER5> Hmmm. Well, the "places of interest" it suggested to me didn't look interesting, but it's _nearly_ useful. What it _really_ needs is just to have a "time" column estimating how far each stop is from the last one.

Maybe I just grew up watching too many NSW RTA ads, but I'm a firm believer in the principle that for safety you should stop and get out of the car every two hours. So if it could suggest stops which were spaced roughly two hours apart, it'd be useful to me.

<comment><USER4> That's funny you say that. The "time" situation was something we struggled with to find what the best experience would be. The questions we had were:

\- Do you stop 1 hour all the time when you stop at a restaurant? What if you take it to-go?

\- What if you stop at a stop like the World's Largest Frying Pan for just 5 minutes? Should we allow users to add custom time limits for each of the stops?

\- Would we be complicating things adding custom times?

All great questions and things for us to think about. Thanks a ton for the feedback.

<comment><USER5> I'd only want an estimate of the travel times between destinations, not an estimate of how long I'd actually spend stopped at each (which I wouldn't attempt to estimate in advance anyway).

For me the use case is this: I want to drive from (say) San Francisco to Denver, and want to plan out a schedule which involves stopping every two hours for a break.

<comment><USER4> Ahhh...got it. Thanks for clarifying that.

</comment></comment></comment></comment><comment><USER6> Cool idea, but I'm not driving 10 miles out of the way to get to KFC/Taco Bell.

I don't think this should feature restaurants but rather "things to do", hiking trails, look outs, maybe specific food places (local legends, etc) but specifically things that "make up communities" (I think of like college football towns, etc)

<comment><USER4> Totally agree. Our first pass was to pull in location information from Google Places and Foursquare, but we feel the beauty of something like this would be the unique locations like you mentioned above.

Thanks a ton for the feedback.

</comment></comment><comment><USER7> Very nice project! And this is the kind of thing I always want to do: stop at weird little fun places on the way. I wish I had it when I did a cross-country trip. Looks like I had missed a few scenic drives and what not!

<comment><USER4> that's exactly what got us super excited about it. we didn't want to miss any of those cool unique place when we were going on a drive anywhere.

</comment></comment><comment><USER8> FYI, when there are multiple possible routes (e.g. the second when going from Dallas, TX to Surprise, AZ) and you choose one that isn't the default, the "Featured Stops" still show for the default.

<comment><USER4> @kodablah: thanks for finding that bug. a couple of folks have notified us about that, and we're working to resolve it as we speak. cheers!

</comment></comment><comment><USER9> You should try pulling from <http://www.roadsideamerica.com/> That's my go to site to road trip info.

</comment><comment><USER10> I'm getting an error when going from Seattle to Yakima, it says: "Your geographic boundary is too big. Please search a smaller area."

<comment><USER10> I'm actually getting that error 100% of the time. I tested Seattle to Redmond, and then I tested a specific address to another specific address, both in Belltown.

<comment><USER4> @zacharycohn: thanks for letting us know. we're looking into it as we speak. hold please. :)

</comment></comment></comment><comment><USER11> This is really cool - I can totally see using this!

<comment><USER4> thanks! we're looking to add more unique location data to make the experience even better.

</comment></comment><comment><USER12> "Featured Stops Starbucks (Coffee Shop) In-N-Out Burger (Burgers) Chevron (Gas Station / Garage) McDonald's (Fast Food) Jack in the Box (Fast Food) Los Pinos Mexican Restaurant (Mexican) Six Flags Magic Mountain (Theme Park) Westfield Valencia Town Center (Mall) Chick-fil-A (Fast Food) Porto's Bakery & Cafe (Bakery) Universal Studios Hollywood (Theme Park) IKEA (Furniture / Home)"

First page of results. LA to SF. Next page includes "IN THE MIDDLE OF F#%~*?¥! NOWHERE!!! (Farm)"

<comment><USER4> @porfirio: Thanks a lot for trying it out. We're currently pulling in data from various sources like Foursquare, Google Places, etc. -- but we do add unique stops as well. Currently we've filled out unique stops for the PNW (since we're based here), but CA is definitely one we'd like to tackle soon.</comment></comment>


Smaller U.S. businesses fear freeze from EU privacy ruling - <AUTHOR> http://www.reuters.com/article/2015/10/08/us-eu-dataprotection-idUSKCN0S12TL20151008 <comment><USER2> "The larger U.S. companies may face a problem of perception that they have abetted U.S. government surveillance. They say, however, that they have broken no laws."

They probably mean to not having broken US laws. However, if they complied to US government requests they have certainly broken laws of several EU countries (at least German ones) and as well broken the Safe Harbor agreement.

<comment><USER3> That's basically the core of it. If you want to do business in the EU, you have to obey EU laws. That they are incompatible with US laws is unfortunate, but from an EU perspective mostly an American problem.

</comment></comment><comment><USER4> It seems the ECJ has plenty of room to invalidate the invalidation [1], but I find this case fascinating in that the courts may be put into an impossible situation of reconciling civilian privacy law against foreign intelligence activities that will likely never formally be acknowledge.

My take away was that the main point against safe harbor is that EU citizens have no legal standing or other access to recourse against US companies accused of breaches, so it does not provide an equivalent level of protection as the charter is supposed to provide.

</comment><comment><USER5> "leaving some U.S. companies concerned that they will be frozen out of the market or replaced by EU competitors."

Let's hope so. Europe needs this.

<comment><USER6> The world needs this - there has to be something that stems the excesses of the US and the world needs that changes happen in that direction.

<comment><USER7> As long as European intelligence agencies continue to cooperate with the NSA expect all change to be decorative.

</comment></comment></comment><comment><USER8> Is anyone even slightly surprised that the actions of the US government would directly hurt US businesses?

<comment><USER9> Small business yes. Large business owns the government, so nope.

</comment></comment><comment><USER10> > called for a quick fix

Can we not do that? I would like a comprehensive reform, not a "quick fix". If that means US companies can't offer their services in the EU in the meantime, so be it. Take it up to the U.S. government and the NSA.

<comment><USER11> The ECJ didn't leave all that much room for a quick fix. Any new agreement will have to consider state access to data, which safe harbour left as a huge gap, and yet guarantee the privacy rights of EU citizens.

Those rights are incompatible with what US intelligence seems to be doing. The ECJ judgment even said it explicitly, "In particular, legislation permitting the public authorities to have access on a generalised basis to the content of electronic communications must be regarded as compromising the essence of the fundamental right to respect for private life".

Any form of self-certifying to the FTC is going to be inadequate from now on, as I read it. But it isn't just about safe harbour being poorly enforced, and completely unreviewed, the point is we now know what US intelligence does to EU consumer data. So, the ECJ gave a set up for the Irish High Court to find that data transfer between Facebook Europe and Facebook Inc is illegal. It will be interesting to see what happens when that shoe drops.

<comment><USER12> They not only set it up for the Irish High Court, but also set it up for two separate avenues of appeals on human rights grounds if the Irish High Court still decides it's ok:

The Charter of Fundamental Rights of the European Union covers privacy in article 7 and data protection in article 8 [1]. The European Convention on Human Rights [2] covers privacy (in article 8).

It's noteworthy that the ECJ made the statement it did, because the ECHR has national security exceptions that would make it easy for them find differently, whereas the Charter does not say a single word about whether or not there are legitimate exceptions and it'd be easy enough for the ECJ to infer exceptions without any uproar (on the contrary, in Europe both the ECJ and ECHR tends to cause more uproar when they expand peoples rights than when the curtail them).

But instead they explicitly referred to "access on a _generalised_ basis" (my emphasis) which makes it fairly clear that they accept the exceptions of the ECHR but believe the exceptions can not be stretched this far, and at the same time they it might be seen as drawing a line with respect to the Charter as well.

So they've basically put everyone on notice that it's not only the EU Data Protection directive and associated national laws that are in play, and that surveillance must be considered, but that there may be legitimate claims under both the Charter of Fundamental Rights and under the European Convention on Human Rights as well.

This is going to make it extra fascinating to watch, as while the ECJ is the final arbiter of EU law, including the Charter, the final arbiter of the ECHR is the European Court of Human Rights.

If this goes to the ECHR, and ECHR agrees with the above statement from the ECJ, then that has effects far outside the borders of the EU, as the ECHR is binding on members of the Council of Europe, and the CoE includes most European states outside the EU as well. Including Russia.

[1] [http://www.europarl.europa.eu/charter/pdf/text_en.pdf](http://www.europarl.europa.eu/charter/pdf/text_en.pdf) [2] [http://www.echr.coe.int/Documents/Convention_ENG.pdf](http://www.echr.coe.int/Documents/Convention_ENG.pdf)

</comment></comment></comment><comment><USER7> It is weird to have the article call Adobe and Autodesk mid-size companies. In Europe they would be considered giants.

<comment><USER3> Well, they're no Googles, Facebooks, Apples and Microsofts. Those are the real giants, and I don't think Europe has a lot of those.

</comment></comment><comment><USER13> This knee-jerk reaction would directly harm competitive corporations that have already expressed their disdain for unregulated surveillance by American intelligence agencies. Instead of taking this up directly with the American government, of course they would simply go ahead and enforce regulations against private corporations instead.

How much manpower and money would be necessary for small companies to make sure EU user data stays in EU servers in an age where big data analytics and storage are crucial to remain relevant.

<comment><USER14> Who is "they" that should be taking this up with the American government? You seem to think this is a new policy, but it isn't.

Twenty years ago, the EU wrote the Data Protection Directive, which said that companies handling personal data of EU citizens much abide by certain rules. The US Department of Commerce developed a process that would supposedly allow US companies to comply with these rules even if they copy data to the US. Recently, the European Court of Justice said that the mentioned process, considering what is now known, is not enough to ensure those rules are followed.

I'm not sure what you expected the court to do. It's those corporations that should take this up with their government, not the EU court, which has no business with the US government.

<comment><USER13> I never said that it was a new policy.

Let's not pretend that current generation of companies have suddenly become incredibly incompetent in maintaining privacy. This entire development was the result of Snowden's work and the general public sentiment that all their data is at the hands of the NSA. It was born out of one Austrian man's visit to SF where he was convinced going against Facebook will somehow fix everything.

Penalising corporations by imposing regulations which are implicitly directed at intelligence agencies serves no real purpose. Facebook will continue to use private data to sell ads. NSA will continue to spy on EU citizens and the rest of the world. My concern was that this namesake rebuke will only lead to more mundane work for a couple engineers in large corporations and small startups being forced to use their puny funds and grappling to deal with this new development.</comment></comment></comment>


FFmpeg Zero-Day Lets Anyone Steal Files Remotely by Playing Special Video - <AUTHOR> http://news.softpedia.com/news/zero-day-ffmpeg-vulnerability-lets-anyone-steal-files-from-remote-machines-498880.shtml <comment><AUTHOR> I wonder if windows codecs built on FFmpeg source are affected or if it takes the whole package?

Probably the whole package with network support.</comment>


It's Okay to Not Learn How to Code - <AUTHOR> http://sonyaellenmann.com/2015/12/its-okay-to-not-learn-how-to-code.html <comment><USER2> I applaud the author's decision not to invest effort in learning that doesn't fit her goals. Perhaps one day in our future coding ability will become a requirement in society, in the same way that literacy did over the course of history. Or perhaps the ability to code will forever remain a niche professional skill, like the ability to solve partial differential equations, or read music. It may even go the way of carving stone tablets. In today's world coding is not a requirement, and the author should definitely focus on things she finds fulfilling.

I take particular exception, however, to the reasoning within the article which says, essentially, "If I were the kind of person who does X, I'd already be doing X". Substitute for X any skill you yourself picked up later in your life, and personal experience should show how false this is. Running, Singing, Public Speaking, dancing the tango at your wedding. We humans are not born fully formed is all facets of our personality, but we have to earn the shape of our lives through effort and experience.

<comment><USER3> "I am not the kind of person who does X" is perfectly valid even though as we get older it tends to become "I am not the kind of person who does X now."

Sometimes the "now" is "anymore". Sometimes it is "yet". Other times it is "right now". Our concepts of wisdom overlap a lot with γνῶθι σεαυτόν [know thyself]. At fifty, though, probably it's a bit of common sense rather than any sort of wisdom.

</comment></comment><comment><USER4> >Here's the thing: if I were the type of person who would be good at coding ...

I don't like this sentiment. Programming (at least the basics, no monads here) is really simple, and the perception that it's difficult seems damaging. What can we as programmers do about this? I'm almost as dejected hearing people say programming is hard as hearing "oh I can't do math."

<comment><USER5> But there certainly is a difference on how easy people pick up coding. This has a lot to do with attitude, but also how talented they are. As with all other skills, you're given a set of cards to play with.

But then again, practice beats talent any day of the week.

</comment></comment><comment><USER6> "Sure, programming languages are cool and useful, but so is geometry, and I don't spend my free time on that either."

:D - I'm spending this sunday afternoon learning abut geodesic grids ([https://en.wikibooks.org/wiki/Geodesic_Grids](https://en.wikibooks.org/wiki/Geodesic_Grids)) as part of a project to teach myself d3.js.

Otherwise - I agree with the author. It was strange seeing programming become a huge thing about 2/3 years ago, but realistically, most people don't have the mathematical/logical abilities to ever get really productive. Which is fine, they should focus on what they're good at, rather than beat themselves up for not mastering a quite specialised skill.

I gather the growth in coding bootcamps has lowered the demand for junior devs, but there's still a huge demand for more experienced people.

<comment><USER7> I don't buy into the idea that you need some set of innate talent to be able to program. Logic and reasoning is a skill, and it can be trained just like any other.

</comment></comment><comment><USER8> Personally, I think if every manager, marketing person, art designer, UI designer, web designer etc. spent just a day or two learning to program, it would give them an order of magnitude improved understanding of what happens on the coding side and would help them make better decisions. Likewise, programmers should try to learn a little about the domains of other teammates to understand each other better.

</comment><comment><USER9> Don't. More for the rest of us.

Also, ditch maths, music, drawing, cooking, learning (thats a skill), accounting, and survival skills.

And that will be the absolute limit of my attention this kind of thinking gets from me.

Farewell and good luck.

</comment><comment><USER10> Troll article. The article states that the author already does know basic coding, which is the idea behind the "everyone should learn to code" movement.

</comment><comment><USER11> It is.

But it's not in certain contexts. Like in areas where a basic understanding of technology apply like on a tech blog or high profile position in politics or company where you make decisions that steer the tech sector, you'll do best with some basic programming knowledge.

Nothing serious is needed either, just a few weeks of learning Python and just read up on the rest of the programming world and you should at least have some understanding on how everything works.

Because I see more and more people in areas where programming knowledge can apply say "It's okay to not learn how to code" and people where it doesn't apply never go out of their way to say that.

Knowing how to code isn't always about getting a great job, sometimes it's just about making yourself better at your existing one.

<comment><USER12> Agreed, but in this context "knowing how to code" is not the same as "being able to code".

I know _how_ to code. I understand it, and can hack at basic programs written by other people. That doesn't mean _I can code_. That would require years of practice and, like the author, it's just not my thing. I'm better at other stuff.

<comment><USER13> You are coding, just likely that you aren't doing it "well". "Doing it well" is very subjective and depends a lot on the context.

</comment></comment></comment><comment><USER14> It's okay not to learn how to cook too. Not everyone is going to be a world class chef, but learning to cook is still worth doing if you don't want to always have to ask or pay others to cook for you.

People who can't cook still get through life without that much trouble though.

<comment><USER15> Pre-made meals exist as well that can be reasonably healthy if you search hard enough as well as things like Soylent, which is specifically made for people who don't want to cook ever again. You won't of course get the fun out of Chef Watson recipes, but maybe you use that spare time to do other geeky things you enjoy instead.

</comment></comment><comment><USER16> _There's nothing in particular that I want to build that I can't already hack together using basic OSS or otherwise freely available tools._

I think that shows she _does_ know "How to Code" enough to solve the problems she faces, but isn't interesting in going beyond that; and I agree, that is a perfectly fine and already far better position than what many others are in. IMHO society doesn't need more professional programmers (who are just going to build more things we probably don't need); it needs more people who know enough about how computers work to be able to control them better and make them do what they want.

<comment><USER17> Maybe the problem is that we, as the computer scientists of our age need to make it easier for people who are not coders to build things and make machines work for them as well? Like you said its about solving problems. In that respect, coding is like a plier, much like any other tool in the box, except its one thats (mostly) incomprehensible to a majority of people--and thats partially our fault.

To scratch my little sunday morning dystopian itch, it makes you think that in the future what may happen is that society will be further divided into classes, except it will be the ruling, technical class and the non-technical class.

Just playing a little devil's advocate cause I'm a bit bored this morning...

</comment></comment><comment><USER18> She's right, except that the criterion "browsing Twitter is more fun, and if I really wanted it I would have learned it long ago" is probably flawed. These days, everything is an uphill battle against the temptations of the internet at first. Applying that logic, nobody would ever learn anything anymore.

<comment><USER19> No kidding. I spent most of yesterday boning up on basic math skills that I haven't used in years, and I did that after turning off the computer, with a short break to watch The IT Crowd on Netflix. Now that my breakfast is done, I'm getting off again and back to the books in a few minutes. Gotta keep the old neurons alive. Sitting and passively reading the internet is killing my brain.

</comment></comment><comment><USER20> "I want the high salary a programmer can command in today's labor market" \- yeah, guess why that's the case... ;)

<comment><USER21> Isn't this the case for almost all professions though? Take cosmetologists for instance. In the town where I live, a person who cuts hair gets about $15 for about 20 minutes of work. Guaranteed job (because people always have hair that they want cut or dyed), a flexible work schedule, and more social cachet than being a stuffy programmer, since they are "hair stylists".

Or consider doctors. $200k+ is a pretty standard salary for a doctor, plus people look up to them in an almost godlike way. In my state, nurse practitioners are also allowed to call themselves "Dr. X", so the social cachet applies to them as well.

Can you imagine the reaction if there were "Everyone should learn to cut hair!" or "Everyone should learn basic medicine" movements? Then why code?

[Tangent] If anything, I think there should be an "Everyone should learn how to _cook_ movement" in the US. Might help with the rising obesity and related complications.

<comment><USER10> Subtract rent and supplies and taxes and downtime from that $60/hr. Being a non-celebrity "hair stylist" doesn't have much cachet.

Cutting hair is a once a month need, and it is physically very challenging to cut _your own_ hair. Almost everyone learns how to shave themselves, though, they don't rely on a pro every week.

</comment></comment></comment><comment><USER22> Wow, I've obviously been sharing the wrong kind of content on Hacker News. I need to start a blog that discusses all the things I'm not interested in learning.

My next article will be "why I'm not interested in learning knitting". Can't wait to get to the HN front page!

</comment><comment><USER23> Just like it's okay not to learn how to read.

<comment><USER24> How is coding an essential life skill?

Most consumer items - including computers - don't have the interfaces you need for useful beginner-level coding.

Experts can always pull the cover off something and get inside, but consumer products - including web sites - make that very difficult for non-experts.

<comment><USER25> Do some Googling around the idea of "procedural literacy".

Coding _is_ like reading, maths, other sciences, in that while you don't need to be very good at it, you really do need to know what computers are and are not capable of and how they solve problems. You need to be able to do this to do all sorts of things; be a judge in a courtroom and not fall to the CSI effect, to not worry about "hackers stealing your credit card" over SSL, etc. etc. It's simply not OK in this day and age to look at a computer like a magic box.

Everyone should learn to code. Not everyone should be a coder.

<comment><USER26> Learning how to code is not the same as computer literacy. There are plenty of people who code for a living who have little understanding of things like network security.

We work in an very complex field where it is impossible for one person to have in depth knowledge of all aspects. I offer up all the security vulnerabilities from companies like Microsoft and Google as evidence of this fact.

Yes, a person should have basic computer literacy; but unless they plan to code in a regular basis, teaching them to program is a waste of time.

<comment><USER27> "Coding" has nothing to do with network security or the intricacies of programming languages or using computers. At its core it is simply a extension of logic operations (if...else, loops, recursion, etc.) with variable manipulation (moving data around). It SHOULD be a fundamentally taught disciple, NOT because people need to code but because most people should have enough recognition in their lives to understand when something could or could not be managed programmatically.

Learning math in school is not something most people use everyday, that is true. And most people forget all of the formulas they memorize. BUT, if I am trying to figure out which peanut butter is cheaper per ounce I can do some simple math to figure it out. If I am trying to figure out the height of a tree I remember "oh there is some geometry formula for this" and can go look it up. What we need in the modern era is more people to have that base level of knowledge so they can say "rather than doing this spreadsheet every month, can't we just hire a programmer to automate it?" because right now a ton of repetitive crap work is being done simply because no one knows any better.

<comment><USER26> What you are talking about is a cost/benefit analysis, which does not require knowledge of programming.

You are also making an assumption that tasks are not being automated because business people do not how to write a line of python/ruby/Java/whatever. Maybe they have limited funds and they are focusing their expenditures in revenue generating work. Maybe the RoI is far in the future that it does not make sense. Maybe they need to be able to change formulas on a moment's notice, so they don't want to be beholden to a developer.

A CEO needs an understanding of their business and a high-level understanding that computers are capable of automating tasks. If coding skills are needed, the CEO can hire a CTO in the same way they hire a CFO to provide accounting skills.

</comment></comment></comment></comment></comment></comment><comment><USER19> It's a win for Sonya, and more opportunity for Kentucky coal miners!</comment>


IE 8 Passes Acid2 Test - <AUTHOR> http://blogs.msdn.com/ie/archive/2007/12/19/internet-explorer-8-and-acid2-a-milestone.aspx

<comment><USER2> ... and Duke Nukem Forever will be released.

The end of the world must be near!

</comment><comment><USER3> Now they must realize how important it is to force-upgrade everybody to IE8 via Windows Update mechanism.

</comment><comment><USER4> This is great news for developers, thanks.

</comment><comment><USER5> Related? From <https://bugzilla.mozilla.org/show_bug.cgi?id=289480#c172>

"It looks like an object element that's pointing to a non-existent page (<http://www.webstandards.org/404/>) should be falling through, but that page is now returning a response status of 200 (success) instead of 404. Was it previously correctly returning a 404 response?"

</comment><comment><USER6> I just hope there's an easy way to run IE7 and IE8 side-by-side. Opening a virtual machine just to do IE6 testing is a pain.

<comment><USER7> <http://tredosoft.com/Multiple_IE>

</comment></comment><comment><USER8> Now lets hope that avoiding IE8 quirks mode will be intuitive enough to make this announcement _pure_ godsend.

</comment><comment><USER9> I wonder how this will affect Opera now they've filed a complaint with the European Commission....

</comment><comment><USER10> Do you think Opera's filing a complaint with the EU against Microsoft had anything to do with this announcement?

<comment><USER11> No. Better standards support has been on the IE roadmap for a while. They aren't exactly breaking any speed records doing so, but this is consistent with the direction set by IE7, IMHO, and what MS has been publicly saying for quite a while.

</comment></comment><comment><USER12> Any hope of application/xhtml+xml support for IE 8 as well?

</comment><comment><USER13> Anyone knows if Firefox passes the same test?

<comment><USER14> Firefox 3 will, current versions do not.

Opera and Safari have passed the test for a while.

</comment></comment><comment><USER15> Praise [God|Jesus|Allah/|Turkey Baster]!</comment>


Interview with Rich Hickey, creator of Clojure - <AUTHOR> http://www.simple-talk.com/opinion/geek-of-the-week/rich-hickey-geek-of-the-week/

<comment><AUTHOR> One really provocative and insightful comment that is independent of clojure itself:

" _I think programmers have become inured to incidental complexity... when they encounter complexity, they consider it a challenge to overcome, rather than an obstacle to remove.

Overcoming complexity isn't work, it's waste._"

This is a useful maxim for me. I have definitely been attracted to complexity that was really incidental in programming.

<comment><USER2> This is the secret of Java's success. Overcoming incidental complexity is predictable, measurable and rewarding to the average naive programmer. Solving real problems is challenging and risky. Java dilutes the latter with the former, and to those who can't tell the difference, this looks like productivity.

</comment></comment><comment><USER3> _RH: Productivity comes from being able to focus. Interactive development environments (REPLs etc) help you focus, by letting you try things immediately._

This couldn't be more true and becomes clearly apparent when moving from languages that require compile-deploy-run cycles.

<comment><USER4> Well, there's no reason not to have both optimizing, heavy-analysis compilers, and light, interactive REPLs. For the same language. Best of both worlds.

<comment><USER3> _"being able to focus"_

I like the fact that he chose the word "focus" here, the main reason for my comment. People usually use the general term "productivity". Focus is a really important and usually overlooked advantage of the interactive style of development.

</comment></comment></comment><comment><USER5> Clojure is fast becoming one of my top favourite languages.

Lisp and the ability to use Java to "get things done" is not to be underestimated I think. Not to mention it's hugely useful as a java repl. Just being able to play with java classes from the repl helps me in my day to day java development.

<comment><USER6> How is clojure useful as a java repl in comparison to groovy, which is much closer to the java mindset?

<comment><USER5> not having used groovy I'm not really qualified to give an opinion.

But part of clojures value is that it isn't the java mindset. Boilerplate just melts away in clojure. That might not be relevant to its use as a java repl but it greatly enhances your productivity as a jvm programmer.

<comment><USER6> With Groovy the boilerplate code "melts away" too. Most java code is valid groovy code, but not the other way around.

</comment></comment></comment></comment><comment><USER7> Met the guy at the Clojure user group here in NYC, apparently there are a couple of financial firms in the city already using it. Stuff is pretty cool. Rich looked like a total hacker dude ;o) Actually all the clojure developers were all bearded long haired hacker dudes. Definitely my kind of place

<comment><USER8> it's really worthwhile to read the IRC logs on the day he's active: cells are "single thread guaranteed , multi-thread capable mutable datatypes " (quote fr feb 17</comment></comment>


Ask HN: Working through SICP. Did you make it? - <AUTHOR> For a variety of reasons, including an excellent comment about CS pedagogies from a few days ago, I've decided to learn scheme and work through SICP this summer. I remembered a thread (http://news.ycombinator.com/item?id=428248) where a bunch of HN people were going to work through it together and I'm curious about your experience.
Did you make it? If not, why? What resources did you find particularly helpful? I've got the pdf book and links to the old MIT video lectures and newer berkeley video lectures. What else should I have? What version of Scheme/Lisp/other language did you use? I'm trying to decide between MIT, UCB (STk), and PLT Schemes. Did the group experience work and was it helpful? What was the most difficult part?
Here's some further explanation about my language options. Tell me if you think I'm off base here. I listed those three Schemes for the following reasons. MIT because SICP uses it. UCB because the berkeley video lecture series uses it. PLT because I'm going to take a languages class in the fall from Matthew Flatt who is one of the members of the core PLT team. Another goal for the summer is to play with Impromptu (http://impromptu.moso.com.au/), so something that will ease that learning curve would be nice.
Thanks! <comment><USER2> Yep. The boss at the end is really hard. :)

I worked through the videos plus the book. The videos are essential, IMO. The Berkeley lectures were not as inspiring as the original MIT '86 ones.

</comment><comment><USER3> The google group is still active: <http://groups.google.com/group/hacker-news- reads-sicp>

Next meeting is on May 24, covering the end of chapter 2, exercises 2.73 - 2.97.

Here's the log from the last meeting: <http://inimino.org/~inimino/projects/2009/SICP/logs/20090510>

</comment><comment><USER4> At the time that I took 6.001 (the MIT version of the SICP course), PLT Scheme lacked several libraries that the book requires. Since so many students wanted to use PLT, the staff put together the extra modules for us, but I'm not sure if PLT is now "SICP-compliant" or not. Check with someone who works on PLT (they're very nice) to find out.

For what it's worth, I really enjoyed SICP, though I still can't say that I understand every line in it.

<comment><USER5> There is an effort[1] to create a SICP language inside PLT.

The docs say it's not yet ready for the masses, but the author was asking for feedback[2] some time ago, so I guess it's good enough to start working.

[1] <http://www.neilvandyke.org/sicp-plt/>

[2] [http://groups.google.com/group/comp.lang.scheme/browse_threa...](http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/95abec3b1e55ec7f)

</comment></comment><comment><USER6> I worked through the first chapter slowly, and then quit and focused on school. Now I've bought the book, I'm still in chapter 2. Did I make it? No, I'm still working on it.

Advice: Ars longa, vita brevis, so work fast.

The only tool I found useful is the web browser in counter strike source, so I can combine two kind of stimulation at once... this is probably not of interest to anyone else.

</comment><comment><USER7> There's a book called "Simply Scheme" that is meant to serve as an introduction to SICP. So, you could "prep" yourself for your pursuits if you first go through this book. Good Luck, Shubham Harnal.</comment>


Becoming a programmer in a week; I'm working on it - <AUTHOR> http://grumancik.tumblr.com/post/62629101246/my-name-is-genny-and-i-want-to-code <comment><USER2> Your enthusiasm as great. But be aware by saying you think this is something you can do in a week you are telling the world you think programming is a semi-skilled job.

I learned to weld when I was 7. I can make art or patch up a broken plow. A real welder can make a boat because all his seams are water tight, and cam patch body work because his seams are so smooth. 27 years of welding as a hobby or for bits of maintenance and I am not a welder.

<comment><USER3> I don't think we need to be so inflexible about language -- there are plenty of people in the world who would like to pay someone to make straightforward websites (patching up broken plows?) rather than work on, say, a new in-kernel memory allocator (building a boat?). It would be pretty ridiculous to claim you have to be able to do the latter before you get to call yourself a programmer.

I think the truth is that programming is a field with work available for people of disparate skill levels and experience -- [http://www.aeonmagazine.com/living-together/james-somers- web...](http://www.aeonmagazine.com/living-together/james-somers-web- developer-money/) is a good article explaining some of why that is. It describes a friend of the author who went from being a law student to being a programmer with an $85k/year salary in six months; does that make programming semi-skilled? Where's the boundary?

<comment><USER4> Be careful with that analogy: a lot of simple sites need zero code, or at least zero code that you need to ever see.

</comment></comment></comment><comment><USER5> I started programming (professionally) this year after transitioning from a completely different career. I lucked into my current gig by basically impressing my future employer with enthusiasm for programming. I also am kind of a rarity, as there are probably less than a handful of professional programmers in my rural Texas town of 15k people, and seemingly no one else was interested in Rails. So I've gone from Michael Hartl's tutorial to an actual job with customers in less than a year, without a CS degree or anything like that.

I honestly think the best way to learn programming is to make yourself by having a project. I'd been dabbling in online courses for a year and a half beforehand, but I don't think I learned much until I had a customer that said "I want something that does this, can you do it?", and just having to figure it out.

</comment><comment><USER6> Your excitement and story are really compelling! It's wonderful seeing someone adopt a new passion. There are so many benevolent people willing to root for you if you show them who to root for. I wish you luck on your journey! You're off to an amazing start.

</comment><comment><USER3> Good luck with it! Portland's a great place to be learning. I don't want to imply that women have to learn programming in women-centric spaces, but I bet you might enjoy checking out PyLadies and Flux too if you haven't yet:

[http://www.meetup.com/PyLadies- PDX/events/140264752/](http://www.meetup.com/PyLadies-PDX/events/140264752/)

[http://fluxlab.io/](http://fluxlab.io/)

</comment><comment><USER7> I understand your problems with finding jobs in the German-speaking countries without having great language skills. I once naively started a Master in Banking and Finance at the University of St Gallen (20 min by train from Zurich). Came home within a few months as my language skills were nonexistent, at the time hiring banks were looking for native German speakers with English fluency and at least one other European language. That was a few years ago, and soon after I began my adventure learning programming.

Best decision I ever made, and I'm shocked I didn't get into programming earlier. I can't imagine returning to corporate finance or accounting type jobs -- and hope my programming skills prevent me from ever needing to.

Good luck to you! :D

</comment><comment><USER8> Good luck. Don't let anyone kick you down. I learned how to program in a week in 1988 (and I'm still learning to program).

</comment><comment><USER9> Quote: "I'm really excited about coding. There are so many cool things happening in tech, and I love the idea of being able to work with smart people no matter where I am. My goal is to learn enough to be able to find a job that would allow me to reunite with my love in Zurich… but the journey there suddenly seems really fun, too."

I should tell you that if you actually become a programmer, in the real sense of that expression, your priorities will completely change and your goal will become more programming, not more relationships.

For a normal person, programming is a means to an end, which is meaningful relationships. For a programmer, relationships are a means to an end, which is meaningful programming.

<comment><USER3> That doesn't match my experience as a professional programmer; there are many types of programmer out there. :-)

</comment></comment><comment><USER10> You probably don't have time for blogging.</comment>


No one cares about your website - <AUTHOR> http://jasonlynes.com/2010/02/22/no-one-cares-about-your-website/

<comment><USER2> An interesting title to pull me into a blog that confused me, was it about design or content. Jason seems to be saying content is the most important factor of a web site, i'd agree, but we live in a world that enjoys sleek and sexy.

I think Jason is wrong, people do care about design, it just depends on what site you are on. I for one definitely care about design of the Twitter pages I set up for people, and one's I look at. I appreciate the time people have put into the look and feel of a web site.

<comment><USER3> Sure people care about design, but they care about it most in a negative way, when it gets in the way and prevents them from getting to what they want. To me, the point of the article was that people notice bad design much more than they notice good design, and usability should come before shiny.

<comment><USER4> but some of us designers think usability and good design are the same thing! therefore, one cannot come before the other (in some hierarchical sense).

<comment><USER3> I think that's what he's actually trying to say there. In my own terminology, I agree good design is equivalent to good usability, but design is too often understood as "looks good", which is what the article is arguing against as less important.

</comment></comment></comment></comment><comment><USER5> doesn't a lot of a/b testing refute what jason is saying here? I agree that if design gets in the way of the user, then of course it is going to have a negative effect. But it is my understanding that effective use of colors, borders, etc. can influence the actions your users take on the site.

</comment><comment><AUTHOR> don't confuse the post to say you or your design shouldn't be sexy. sexiness is a huge part of content. but what's underneath the shininess? people don't care unless there's something legitimate, and usually only if there's something that will help them personally..</comment>


Ask HN: What are the differences between the major free software licenses? - <AUTHOR>

This has been a recurring question. Where can I learn about the differences between commonly used licenses (MIT license, BSD, GNU GPL, and so on) in a clear way?
I've taken a look at the actual statements, and they were not as daunting as I had supposed. However, it is still a little difficult and time-consuming to process the unfamiliar clauses, translating them into normal English and simplifying them into basic points. Do you know of a website or guide that has done this already?
Update: I have found the following chart, but it only gives two items: "Link with code using a different license", and "Release changes under a different license".
http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses <comment><USER2> First of all, let me start with the disclaimer that no summary substitutes for reading the licenses in question. The MIT and BSD licenses require almost no effort to understand. The GPL (v2 or v3) makes for fairly easy reading, and seems intentionally written in a way that non-lawyers can easily understand and apply. The same mostly goes for the LGPL and Apache licenses, though the use cases for the latter don't become immediately evident at first glance.

For a quick overview of the most popular licenses, I really like this diagram: [http://paulmillr.com/posts/simple-description-of-popular- sof...](http://paulmillr.com/posts/simple-description-of-popular-software- licenses/)

That diagram rather effectively captures the most important differences between the licenses: copyleft of various strengths (GPL versus LGPL versus BSD/MIT), the added protections in the GPLv3 and LGPLv3 versus the v2 licenses, the rationale for the Apache license rather than MIT/BSD, and the subtle difference between BSD3 and BSD2 that you mostly don't need to care about.

If you want a more extensive analysis, I'd suggest reading the FSF's license list, which provides a rather comprehensive list, including specific issues with various licenses, and links to more information about common license features: <https://www.gnu.org/licenses/license-list.html>

One critically important disclaimer about that list: ignore _everything_ it says about the GFDL (GNU "Free" Documentation License) and stay _far_ away from that license. Always license your documentation under the same license as your code; don't use a separate, incompatible license.

You may also find the rather extensive and provocatively titled essay "Make your Open Source Software GPL-Compatible or Else" useful: [http://web.archive.org/web/20110718154125/http://www.dwheele...](http://web.archive.org/web/20110718154125/http://www.dwheeler.com/essays/gpl- compatible.html) . (Link to the Internet Archive because dwheeler.com seems down at the moment.)

Hope that helps.

<comment><AUTHOR> Could you explain what you mean by this, please?

> ...Ignore everything it says about the GFDL (GNU "Free" Documentation > License) and stay far away from that license. Always license your > documentation under the same license as your code; don't use a separate, > incompatible license.

I am about to open the essay you gave a link to. Also, for those interested, here is the discussion linked below the diagram:

<http://news.ycombinator.com/item?id=2501536>

<comment><USER2> Sure, happy to elaborate on that.

The GNU project repeatedly talks about documentation and other works as somehow separate from software, and makes comments like this: "However, for manuals and textbooks, or more generally any sort of work that is meant to teach a subject, we recommend using the GFDL rather than the GPL.". See this FAQ entry for a more extensive example: [https://www.gnu.org/licenses/gpl- faq.html#WhyNotGPLForManual...](https://www.gnu.org/licenses/gpl- faq.html#WhyNotGPLForManuals) . (Disclaimer again: I disagree entirely with just about everything said in that entry, as do numerous other FOSS developers.)

In general, the GNU project doesn't care much about things other than software. In particular, they've said they don't care much about the ability to modify data (such as media for a game), and they actively oppose modifiability of non-technical writing (such as their own essays, which allow unmodified copies only).

Among other things, the GFDL allows manuals to contain extensive unremovable and unmodifiable sections, such as the GNU Manifesto (which many people mostly agree with and find inspiring) and "Free Software Needs Free Documentation" (which many people strongly disagree with due to it propagating many of the same advocacy of the GFDL). The GFDL also contains very particular requirements about text placed on the front and back covers of a printed book (beyond just attribution), which also does not permit modification. (That requirement seems particularly hypocritical given the FSF's own essay about the GPL-incompatible 4-clause BSD license with advertising clause, <https://www.gnu.org/philosophy/bsd.html> .)

Most importantly, the GFDL and GPL remain incompatible licenses, which means you can't copy anything between documentation and code.

All of the above contributes to my recommendation that you ignore anything the GNU project says about the GFDL, and anything they say about not using the GPL on manuals.

All that said, I do actually consider almost all of the GNU project's "philosophy" section (<https://www.gnu.org/philosophy/>) well worth reading; it certainly inspired me when I first started learning about Free Software. Just take some of it with a grain of salt, particularly when it comes to anything other than software, because the GNU project really doesn't care about anything other than software.

Fortunately, the most recent update to the GFDL provided a way for Wikipedia and other large wikis to transition away from the GFDL and to the Creative Commons Attribution Share-Alike (by-sa) license, which doesn't have the issues with Invariant Sections and Cover Texts. Creative Commons licenses remain GPL- incompatible, which can cause practical problems for anything that might mix with other FOSS work, but not for Wikipedia and other similar wikis. Many people avoid them for software documentation for that reason, but they seem like perfectly reasonable licenses for almost any other work.

Recommendations for non-software: For documentation or other bits associated with a software project, use the same license as that software project. (For instance, X11 documentation uses the all-permissive MIT license, and the documentation for most non-GNU GPLed projects uses the GPL.) For any other work, use the GPL if some clearly identifiable "source" form exists that you want to preserve access to, use CC-by-sa if not but you still want a copyleft, and use CC-by or a simple all-permissive license like MIT otherwise.

<comment><AUTHOR> That is a lot to take in, thank you for another extensive response.

</comment></comment></comment></comment><comment><AUTHOR> This seems to have died out very quickly without any visibility.</comment>


Top 10 Unethical Psychological Experiments - <AUTHOR> http://listverse.com/science/top-10-unethical-psychological-experiments/ <comment><USER2> Both the Milgram and Standford Prison experiments, while ugly, are seminal works in psychology and extremely important. One of my best classes while pursuing my MBA was an ethics elective where we discussed Milgram and the Stanford Prison experiments and their implications in modern business. Enron happened because people followed too readily, and the impacts of these issues should be understood by anyone looking to build and lead an ethical business.

</comment><comment><USER3> Wow, you know you're in for a hell of a list when the Milgram experiment is only #3....</comment>


Brake dust may cause more problems than blackened wheel covers - <AUTHOR> http://exactlyscience.com/archives/10988.html <comment><USER2> Blogspam of

[http://www.news.gatech.edu/2017/03/02/brake-dust-may- cause-m...](http://www.news.gatech.edu/2017/03/02/brake-dust-may-cause-more- problems-blackened-wheel-covers)

with author credit stripped out (Josh Brown).</comment>