Did Twitter Just Deliver Third Party Apps A Death Blow? - <AUTHOR> http://idealab.talkingpointsmemo.com/2012/06/did-twitter-just-deliver-third-party-apps-a-death-blow.php

<comment><USER2> Maybe there's a trend here, but maybe its just me being short-sighted. I'll type out what I'm thinking.

I think that the uncomfortable future for a lot of the e-properties that people enjoy happens to hinge on the fact that the way they are the most useful clashes with the ways they can make money. Big time.

Facebook will sponsor stories, alienating users a little for eyeball time.

Twitter will make sure promoted things get their eyeball time by crushing 3rd party (alienating users).

Digg will- well. You know.

All of these moves hurt the utility of those companies. All of the companies know that.

But something happened with Digg, didn't it? The models of the above have to very carefully balance utility/pleasure of use with a certain amount of intrusiveness to make money because they have found few other good ways, though some get credit for experimenting.

And every time a major e-property does this they make a chink in their dam, inviting their sweet sweet reservoir of users to look beyond into a river of startups. Maybe there are more useful options out there for little fish. Cleaner spaces, open air. Let's be honest I'm bad at metaphors. Moving on.

Myspace became ridiculous and thousands (millions) fled to Facebook.

Digg became ridiculous and many fled to Reddit.

Twitter and Facebook are trying to monetize more and will become more ridiculous and less useful in the process. They might survive, but they are inviting others to take their place in the meantime.

And someday those new companies will build dams around users and either try to get them to gawk at more ads and maybe fall in the same way. This model seems to work for a little while, but they still need to solve the large clash of interest brought about by advertising. Search engines still do it best: ads displayed that try to match queries with relevant content aren't necessarily offensive to taste.

Almost everything else is still trading user abuse for irrelevant product. All users wanna do is talk about the kind of sandwich they ate. Nobody wants to "Learn how YOU can help Hyundai make August National Fuel-Efficiency month!" (real ad).

<comment><USER3> The takeaway lesson for me is that _user-generated content is incompatible with advertising._

Now, as a caveat, I'm the sort of person who thinks that modern advertising is 99% toxic sludge in the mental environment: I am firmly in the Kalle Lasn camp. However, here's how I see it working: users come to the site because of the UGC, but advertising, by nature, has to grab attention at some level. You can't design for both "make the UGC, stuff users actually care about, primary" and "make sure that you get ad clickthroughs." Since the latter pays the bills, it tends to win - and users tend to leave because on one level or another, it's obvious that the site isn't about them (and if your site depends on UGC, your users ain't wrong to think that the site should be about them!)

The secondary takeaway is that _advertising is not a long-term sustainable business model._

Advertising has a strong tendency to push startups into this insular turtles- all-the-way-down bullshit: social media with ads for analytics, analytics for ad-based startups, startups about how to reach demographics, and so on. They're as familiar an archetype around here as Punch & Judy. But it's all the tertiary economy, it's all flash: the fundamentals of advertising as a business model only get weaker over time. The effectiveness of advertising _at all, in any context_ is debateable, and participating it is participating in an endless arms race. I argue that this should tell us that advertising is not the way to go if you want to build a lasting company: you need to take money in exchange for goods and services (real goods and services: advertising doesn't count, as I'm in the process of arguing).

That's hard! That's really difficult. PayPal, Square, and WePay should show us how ridiculously, gratuitously difficult the "take money for" part is, and taking people's money once you've convinced them that you've got something worth their money, is the _easy part!_ Before you even get there, you have to build something good, and none of us should have any illusions that that's easy. Then between those two parts, there's "persuade users that your cool thing actually is cool and worth paying money for," and sweet leaping Buddhas that's a lifetime of work in itself (the lifetime of work, in fact, that advertising is doing in such a toxic and commons-destroying way right now).

But: you are a _hacker._ You are a _hustler._ You are an _engineer._

 __ _Solving hard problems is your job._ __

Advertising is not a business model: advertising is a problem to be solved. Advertising is a bullshit legacy of past business models, here to be disrupted. The reason that I hang out on Hacker News is that I believe that its hackers, hustlers, and engineers are the people who can look at the way we do something now, think "that suck! I can do better than that!" and then do the difficult, frustrating, painful work to actually make something better, show people why it's better, and accept the monetary rewards that come from having made something better and proved it.

We can do this.

<comment><USER4> Your arguments about why UGC is incompatible with advertising seem like they could apply equally to all content.

i think a better argument is that _unstructured_ UGC is incompatible with advertising. Pinterest, for example, seems to be doing all right, because their site is basically a repository of things people want to buy. StackOverflow doesn't seem to be having any issues using ads to monetize, because their niche makes their ad-space valuable to advertisers and relevant to users. Where facebook and twitter fail is that they have tons of data about users, but not about what users want _at that particular instant_. An ad for windows server hosting on ServerFault is not competing with the content, it's complementing the content. it's a natural progression that doesn't require me to refocus to be effective. Facebook knows what i like, but not what i'm thinking about. When i'm looking at pictures of friends, any advertisement requires me to refocus onto a different topic.

</comment></comment></comment><comment><USER5> Short answer - no.

There's a lot of people over-reacting to this situation. If you read Twitter's blog post its clear that they're following up on enforcing the API "Rules of the Road" they've had for over a year. [https://dev.twitter.com/blog/delivering-consistent- twitter-e...](https://dev.twitter.com/blog/delivering-consistent-twitter- experience)

Section !.5. clearly lays out the rules clients must follow "Your Service may be an application or client that provides major components of a Twitter-like end user experience (a "Client"). An example of a Client is a downloadable application that displays user timelines and allows users to create and search for tweets. If so, certain additional terms apply, including:"

These rules are actually pretty generous and plainly lay out their expectations for third party applications. It's unclear what led to Tweets being removed from LinkedIn, my guess would be that Twitter attempted to enforce their branding rules, LinkedIn declined and instead said they would remove the Tweets from being displayed entirely. It doesn't sound like Twitter just cut off access to LinkedIn or came up with new restrictions they haven't already been publishing (and compelling 3rd parties to comply with) for a long time.

Any business must deal with existential threats, be it from competitors, regulation or bad investments. Building a business on top of an API is just another potential risk, you need to decide if they company in question is a safe enough bet to play on, just like you have to decide the same thing for all other risks.

<comment><USER6> Wait.. What other uses are there for a Twitter API? What I don't understand is why Twitter can't just insert their ads I to these API requests and be done with it.

<comment><USER7> There are I think over 100000 Twitter apps (don't remember the exact number, but it was a lot). I think those are not all Twitter clients.

</comment></comment></comment><comment><USER8> I think this is a Great wake-up call to everyone who builds on someone else's platform. You are not the master of the house - and can be kicked out at any time.

One way to circumvent this is to have binding legal stuff in place, another is bring so much unique value to the platform that the owners are scared of mass defections should they break your app.

With Twitter I do not see any Third-party app in this category. Only companies of the likes of Apple & Google have the necessary influence to cause Twitter to think twice before making incompatible changes. Others are toast.

</comment><comment><USER9> The little voice in my head just got a whole lot louder - "don't friggin build a business on someone else's business. Do your own shit!"

<comment><USER10> It is ok to build on somebody else's business IFF you have a contract in place protecting you. The problem is, today, there are few contracts signed because that would prevent tomorrow's pivot (that screws all of today's partners).

<comment><USER9> "Tomorrow's pivot" :) I think you summed up all of it with that phrase.

</comment></comment></comment><comment><USER11> "Twitter's applications programming interface (API), the source code that allows the developers to have access to user account information and Tweets."

"Until Favstar came along in 2009, the Twitter star was a little-used and largely ignored feature."

Am I the only one that feels the author has some research to do?

</comment><comment><USER12> I can still see tweets in the iPad LinkedIn app, though possibly from before when the article was published. It would be a dream come true if people stopped being able to import Twitter into their LinkedIn. It's polluting.

<comment><USER13> Yes, the limitation is that new tweets cannot be pulled in, but existing tweets are not going to be deleted.

I agree that seeing twitter feeds on the LinkedIn feed polluted it with garbage, and am glad on a personal level to see them going away.

</comment></comment><comment><USER14> While they keep killing off third party apps, usage is going down in every circle I'm in, and I see myself using FB and Path more and more. I think they're making their own death bed.

</comment><comment><USER15> Honestly, there are a whole lot more interesting problems to solve outside of Twitters ecosystem. Storm, meet teacup.

</comment><comment><USER16> Always</comment>


Simperium announces pricing and open source strategy for new data layer - <AUTHOR> http://blog.simperium.com/post/27092612894/our-pricing-and-open-source-strategy <comment><USER3> Out of interest, is there any research to back the idea of selling your product at the same time as giving it away for free ultimately results in higher sales? A trade-off between exposure and "lost" sales I guess?

<comment><USER4> See: github, dropbox, and probably a thousand others. Both companies claim free accounts are marketing costs for expanding their networks of paid subscribers.

<comment><USER3> Neither of those two examples give away their core software for free though, which sounds like what Simperium are going to do.

I'm absolutely not saying it can't work, and kudos to Simperium for taking this approach, it looks like there is an absolutely great product there and I'm going to be checking it out.

There are of course examples where this does work, RedHat for example (heh - <USER2> do it myself as well!), but I was wondering if anyone has tried to look at it analytically, or is it just a gut feeling that this is the right approach to maximise revenue?

</comment></comment></comment><comment><USER5> I think this is a great call. I'll be investing time into trying your service out now that I know that if you guys ever need to disappear or your pricing model becomes incompatible I'll have another choice.

</comment><comment><USER6> I'm curious: How's Simperium different from Parse.com?

<comment><USER7> For starter, it has great CoreData integration <https://simperium.com/docs/ios/></comment></comment>


Show HN: Maximize your profit with dynamic pricing - <AUTHOR> https://modernpricing.com <comment><USER2> What are the legal implications of doing this based on jurisdiction? There are also ethical considerations. I expect this to be another thing which will be an 'open secret' in the tech/marketing worlds until other people find out about it and will be upset about.

<comment><AUTHOR> There are no legal implications for doing this based on jurisdiction. As one of the other commenters points out, the cost of a Big Mac varies widely depending on your geography. This is an example of McDonald's adjusting their prices to their local market.

As an aside, it is illegal to discriminate on the basis of race, religion, national origin, disability, age, or gender. This product is not considering in any of that information. It simply considers an IP address and a user agent.

<comment><USER3> Correlations may be hidden in statistical data. Don't be so sure.

</comment></comment></comment><comment><USER4> Really surprising that more companies aren't doing this. I did a quick search and saw that The Princeton Review was doing this ([https://techscience.org/a/2015090102/index.php](https://techscience.org/a/2015090102/index.php)) on their own. Of course I bet if this became more common, consumers would start to get annoyed and try to game the system.

Cool website though.

<comment><USER5> It might be common enough already to warrant a VPN in a low income country, if one is perhaps purchasing from Disney or Netflix or seeking college financing (among the examples from the OP)

</comment></comment><comment><USER6> I just installed a VPN to see how this works on the demo site, [https://concorde.io](https://concorde.io). Pretty impressive to see the price changes when I change between various countries.

<comment><USER7> Yeah this'll end up like discount codes. Everyone will VPN in to get a discount.

</comment></comment><comment><USER8> This makes complete sense and makes you wonder why a company like this doesn't already exist. Seems like this company could help startups and unicorns (need scale) that are stuck due to broken pricing and unlock serious value

</comment><comment><USER9> Kinda reminds me of the Big Mac Index.. McDonalds charges different prices for the same thing in different countries. Of course that's a physical product and this is an API and I bet cows in Romania are cheaper than America. [https://www.economist.com/graphic-detail/2019/01/12/the- big-...](https://www.economist.com/graphic-detail/2019/01/12/the-big-mac- index-shows-currencies-are-very-cheap-against-the-dollar)

</comment><comment><USER10> Interesting idea, I assumed a lot of websites would do this via A/B testing in different locations, to determine the highest price a customer will pay in a region. But this is kind of a step further in predicting the price they'll pay.

How much of the persons browser are you capturing? Just the user-agent? I would think screen size would be a helpful metric to segment users... small screen laptops vs massive displays, latest iPhone vs older Android...

</comment><comment><USER11> If you are interested in testing geo-specific dynamic pricing, we have a tool here just for that: [https://www.geoscreenshot.com](https://www.geoscreenshot.com)

</comment><comment><USER12> This looks pretty cool — and I think it is what airlines already do —, but I wonder what the public perception is on something like this?

I do not mind if a company does this — it makes sense to me. But what about other people?

<comment><AUTHOR> There is one precedent for this that spans all people: taxation. People with lower incomes will get better access to products. Meanwhile, people with higher incomes will contribute more, because they're able to.

</comment></comment><comment><USER13> woohoo!</comment>


11 Steps to Fight the "God Complex" - <AUTHOR> http://lifedev.net/2008/07/god-complex/

<comment><USER2> Article was unmitigated crap. (FYI, I don't suffer from a "God Complex", I relish every second of it.)

The author brings up these eleven points and then rebuts each one with a paragraph of contradicting platitudes. Example from number 4:

"Sometimes, ignorance is bliss." ...OK so far, though I don't agree...

"There's absolutely nothing wrong with wanting to constantly learn." ...Still OK so far...

"However, becoming obsessed with knowledge can be damaging." ...Wait. Wouldn't wanting to constantly learn sort of be pretty close to the same thing as being obsessed with knowledge? So, there's absolutely nothing wrong with it, except when there is?

If you think you need to step away from what you're doing and get some wider perspective on things, or rejoin the real world, or whatever, then go for a walk or do a little traveling or something. Don't bother reading articles like this one.</comment>


The Crazy World of Code - <AUTHOR> http://tilomitra.com/the-crazy-world-of-code/

<comment> Su-Shee Well, this kind of insanity made me step back 10 steps and invest some time (almost a year by now) into the "classics" so to speak.

Inspired by Crockford's talks in which he mentioned a couple of times the lack of history and historical knowledge among developers, I suddenly remembered that I got an education in humanities before I even went into programming and really did start with the classics - Greeks and Romans and Philosophy - and I asked myself why on earth I never really considered doing something similar in computing. (Someone called it in some article I've sadly forgotten the Oxford way - you learn Latin and Math and from there you can learn anything anyways ;)

So I decided to ignore all fashions, new things, upcoming frameworks and such for some time until I got what I would consider (totally subjectively) a solid foundation (not there yet, will probably take another year at least) of knowledge.

I personally decided to define "classics" along the lines of "knowing Unix and its history and concepts well" (re-learning shell and commandline wizardry on top), "understand decent C and Assembler", "becoming familar with the influential languages of important concepts like functional and OO programming (Scheme/Lisp and Smalltalk). This includes really understanding SQL (which I suddenly started to really like to my own surprise). Maybe I add some PostScript and TeX along the way. I also found a new appreciation for Perl's text processing capabilities and its influence from the 1990ies on.

Set aside that I constantly have to fight kind-of a "bad conscience" exactly BECAUSE I'm not hurrying along to try out the latest and greatest new fashion, I'm starting to feel a deep change in my programming skills, in my thinking about design and I'm constantly marveling where computing already has been and how much there is to learn from the classics. I also started to get a distinct feeling of "Man, I just don't NEED all this clutter and stuff" and a newly found appreciation of "simplicity" (Watch Rich Hickey's talk about "simple versus easy"..).

I started to slow down, to think more carefully, to read a lot more on concepts and ideas. I've finished recently Christopher Alexander's Pattern Language book for example to get a better feel for the "orginal" idea or read up on the history of "lean production" and Toyota's influence or looked again at Dieter Rams' design principles (I'm German and I basically grew up with Braun appliances, I didn't even realize how influential his designs have been to me..)

All this changed me and my thinking about programming deeply and made me find kind of a "central theme" or "essence" in programming and design I like and I'm starting to strive for.

In the long run, this also gives me a foundation of how I'm judging new tools, ideas, frameworks and programming languages.

On top of that, I'm better able to place myself into a certain "style" or "culture" of programming I'm not going to give upon as long as I can afford it.

Anyways - I personally think there actually is a choice whether one tries to catch up with everything new or peek into new things selectively or just steps back a little and watches how all this will unfold in the long run.

(I also have a long-held, un-proven personal theory that people simply like _writing_ frameworks a lot more than _using_ them - some are just faster to release theirs into the public.. :)

<comment><USER3> We need to rewind computing to 1990 and start again from there.

<comment><USER4> The dream of the 90s is alive in Portland: <http://www.youtube.com/watch?v=TZt-pOc3moc>

</comment></comment></comment><comment><USER5> I myself have reverted back to doing "everything" myself... I don't use frameworks besides my own crap.

The downfalls... 1) stuff can take a LOT longer to develop, 2) sometimes I feel like I'm stuck implementing middleware when I should be developing features, 3) there is more room for bugs to sneak in 4) scaling could be tougher when/if the need arises

The positive... 1) I for once feel like I actually know the full flow of execution and this at times makes certain solutions much easier 2) I don't feel that Im on the treadmill of hopping from learning one framework to the other 3) it grows my skill 4) I feel more like Im chiseling something from one stone rather than tying together rocks

Im not entirely sure Id recommend what Im doing - in someways its really stupid but I personally get gratification from it and oddly feel more productive than when Im fusing together multiple frameworks.

<comment><USER6> I do this as well - - everything from the JavaScript framework, to the ORM, to the web-framework is built or assembled by me. I even use my own special databases built on top of Tokyo Tyrant and Redis. It's basically my world where I know every part of the system. This makes me super productive and I can change anything. It's also a great learning experience. This said there is a huge problem with this approach and it's scaling your development team... It's hard for people to figure out how stuff works in an environment where nothing is standard.

My plan to solve this is to open-source my tools/libraries and switch to Flask, so at least some of the stack is familiar. Open-sourcing these tools will force me to isolate them, clean them up and write some documentation - - it can benefit other people and maybe open a pool of developers that know the tools better.

<comment><USER7> " _My plan to solve this is to open-source my tools/libraries_ "

Quick advice: Don't. You'll make it worse.

You're already undermining your thing in that first sentence ("switch it to X so that other people will understand it"). Turning an in-house framework into a "ready for the real world" framework is a ton of work and will invariably need to dull down the sharp edges and general case a bunch of things.

The thing is, those sharp edges are what make it such a good tool. You _want_ sharp edges on your tools. Dull tools might not hurt anybody else but they won't be as good at doing what they do.

You've got something that works _really well for you_. Chances are it's so focused towards your workflow and way of thinking about the world that it just won't be all that useful to anybody but you. That's just fine.

Trying to make it useful for everybody else will only succeed in making it less useful for you.

<comment><USER6> Hey Jason. The general problem is hiring people when you use a lot of internal tools - - as some of them are made in a haste and are hackish, and most of them don't really have good documentation. But maybe you have a point and the first step could be to clean the tools up and write some internal documentation for them.

</comment></comment></comment></comment><comment><USER8> I understand where the author is coming from, and it can be hard to figure out where to even get started on new projects. On the other hand, I am thankful from the _obscene_ amount of great software coming out of the open source community every day.

While things like paradox of choice and project abandonment are worth discussing, let's not forget that thousands of developers have found something that they think is lacking, fixed it, and taken the time to give it to us gratis so that we can use and learn from it. I, for one, am excited.

</comment><comment><USER9> Excellent critique. I feel that HN often blows by rational ignorance with some of it's advice (<http://en.wikipedia.org/wiki/Rational_ignorance>). Sometimes it's best to do it wrong and actually do something, rather than hopping around per someone else's dogma and never actually making anything.

But I think it's also possible that the HN frontpage simply doesn't give a good impression of the average hacker. The average hacker is not welding together the latest js frameworks while tying it all together with node.js and hadoop. Perhaps more articles on "common man" hackers could be beneficial, or at least give some perspective.

<comment><AUTHOR> Completely agree with this. HN is great for technical discussions, but at the end of the day, arguing over technical details doesn't solve any real problem for 99% of the users out there.

</comment></comment><comment><USER10> Love it. Sometimes I feel like we nerds get caught in the weeds and forget to solve real world problems. We have enough JS frameworks by now... Funny thing is most of them are the same given a few differences.

For JS specifically, it's starting to look like there is no "right" clientside model, at least yet. Web apps behave so differently and have different requirements that no one framework will fix it, sort of like rails, or game engines that solve a large class of problems pretty well.

For side projects or "helper apps" (I make a lot of them), I still use rails 238 and prototype because I'm productive with it. Think of all the things you could accomplish if you didn't spend all that time fiddling with 0.0.1 version software.

<comment><AUTHOR> I would somewhat agree with this. I recently wrote a completely client-side app using a variety of different micro-frameworks. I used Parse's JS API for my backend. At the end of the day, I felt that a traditional CRUD system on a LAMP stack would have probably been easier to implement and would have fit the client's requirements just as well

<comment><USER11> I'm in exactly the same situation - will try to finish it anyway though, but in general I regret that I didn't go with Flask and instead went with a client-side + REST framework.

Even if you're doing a client side app, some views are easier to implement in the server-side "full-page reload" style, and you want to have the option to do that.

<comment><USER11> Also, its very funny how sometimes I think I don't need the four CRUD operations for some object ("oh no, this one works differently") but in the end always notice I do need them...

</comment></comment></comment></comment><comment><USER12> This has become a serious problem for me in my search for a better job.

Interviews are nothing short of awkward.

Interviewer: So what do you like to do?

Me: I'm a Python/Ruby guy. I also have worked in Java/C. Currently playing around with node.js, machine learning algorithms, some functional programming and pet project with my Arduino Duemilanove.

Interviewer: Sounds good, you'll hear from us in the next few days.

:(

<comment><USER13> Sounds like you're not applying to the right companies. Any developer that comes to me with an obvious love for code moves to the top of the list. If you're coding in your own time for fun, it's not a job, and I'd want to hire you - in some capacity :)

<comment><USER14> The growing trend that I've seen now days is companies requiring extensive knowledge in "this" framework. It doesn't help that every company requires a different framework.

Interviews are a drag, and none of them like hearing that it will take one month to become fully accustomed (in-depth knowledge) with their framework. They'd prefer someone with limited knowledge who knows their framework rather than one who's well versed in multiple frameworks/languages.

<comment><USER15> It's a pretty stupid trend too. Let's face it, the best programmers will learn "this" framework quickly, get up to speed etc. Not only that but the programmers you really want to hire are going to be those who love learning, thinking, and critiquing their own code, not specialists in Framework X NG.

It seems to me that a better approach would be to put new hires into code maintenance first with a mentor who can help them get up to speed.....

But most of us know that HR departments are not always the best judges of talent.

<comment><USER10> This is exactly what we do where I work - a lot of our programmers don't know Ruby when they walk in the door but that shouldn't matter if you choose the right people. I'm scared of choosing language or framework 'specialists' because they have a limited view on what programming is, and a cemented view on what it should be. The only exceptions I can see are when the specialization is language specific to the problem domain, IE C for high performance server or system code.

Programmers who advertise themselves as "Ruby programmers" or "Python hackers" or what-have-you come off as inexperienced and one dimensional. The best hackers have used the right tool for the task at and, and the best hackers have solved a wide variety of problems to require different tools.

</comment></comment></comment></comment></comment><comment><USER16> As frustrated as I am with what seems like an unnecessarily immature software industry, I am grateful for the plethora of wonderfully crafted free frameworks that I have at my disposal ([http://www.jmolly.com/2012/07/01/the- wide-landscape-of-java....](http://www.jmolly.com/2012/07/01/the-wide- landscape-of-java.html)).

I want to solve problems that need solving. I don't want to reinvent wheels. As you grow in expertise, you get better at picking the right framework for the right job. If you're not there yet, just make your best pick and move forward. In the end you can make anything work, you can refactor, you can replace. Software is malleable.

<comment><USER17> > As frustrated as I am with what seems like an unnecessarily immature > software industry,

Could you expand on this?

<comment><USER16> I didn't really phrase that right.

I often feel that the software industry should be much 'further along' than it is. It's 2012 and most software interactions are through kludgy, blocky web interfaces, its not uncommon for rather basically behaving systems to be backed by millions of lines of code.

I know this is rather a soft lament, but it doesn't feel right. It feels that with all the years we've been at this practice we should have progressed further than we have.

<comment><USER3> We spent the 90s and 00s rewriting the 80s again and again. The 10s look like they're going the same way. Same concepts, same functionality, different syntax only, no progress.

I'm having a lot of fun right now doing 68000 ASM for my personal projects. Going to try to figure out where we _could_ have been if we didn't get stuck in a rut in the late 80s.

<comment><USER17> As someone with an interest in this subject, where did we go wrong? Plenty of people say *nix. But I'm not old enough to have witnessed any of that firsthand.

<comment><USER3> The issue is as much psychological and cultural as it is technological.

The 80s were a period of great diversity and hence progress. In that decade I used 6502 (BBC Micro), 68000 (ST), ARM (Archimedes), there were also Z80 and early x86s. There were many approaches to systems design, many competing ideas, what you might call a Cambrian Era (<http://en.wikipedia.org/wiki/Cambrian_explosion>).

By the 90s, things settled down. People (as in, "end users", the people who ultimately pay for software) had figured out what they wanted to do, which is forms (screens for entering data into a database) and reports (screens for getting it out again, nicely formatted). Messaging, as in email/IM, is just a special case of this (and today, FB et al are just forms and reports). What was "good enough" for this was an x86 (which happened to be running Windows, but that's irrelevant IMHO) and that became the lowest common denominator. The diversity was still there in the form of the Unix workstation market but they spent all their strength competing with one hand and trying to standardize with the other. Meanwhile the relentless march of hardware continued on, Intel was swimming in cash and none of the Unix vendors noticed, they were all preoccupied. Now there is one architecture to rule them all (tho' ARM still clings on).

And we the developers are to blame. We fell into a comfort zone. The users wanted forms and reports, and that's what we gave them. Then the hardware gave us more power and we gave them bells and whistles too. But really, that is solved, has been solved for 2 decades now. Nearly everything we do with computers now, could have been done in 1990, and what they did then, we do the same now, except arguing over syntax, which of a dozen functionally equivalent "frameworks" to use, which ALGOL-derived language to use, which desktop to use with slightly different-looking widgets that do the same thing, etc etc etc. All this is just procrastination. None of these things matter. But comfort zones are, well, comfortable. It's like we climbed a small hill and stopped to enjoy the view because we are afraid of the mountain we have to climb still.

There are a few tantalizing glimmers now, of the "next level". But we wasted 20 years dicking about.

</comment></comment></comment></comment></comment></comment><comment><USER18> If you start your day by reading your favorite software development news aggregation sites, containing news about interesting libraries, frameworks and how different people have succeeded with them; you can get disillusioned about the importance of technology choices.

Your project is not the framework you use, nor does it matter which language you chose. It is a non-issue if Facebook or Google uses the same stuff you do. Your projects value is not a combination of buzz-words.

Choose technology based on what gets the job done, and all the better if it makes the project fun to do. Don't be paralyzed by the choice, focus on solving the problems of your project instead.

Off to write a Clojure compiler in Haskell which can run natively on iOS and translate itself to HTML5 for live development with SocketIO backing the Closure optimized Javascript using node.js for the concurrency model.

PS. The last bit is a joke

<comment><USER19> No doubt you've heard of this? <https://github.com/jspahrsummers/cocoa- clojure>

</comment></comment><comment><USER20> Just make little things. Backbone is fun, make some little backbone views/models, they'll work perfectly with any other JS you have. Want to try rails? Do another little project in rails. Is it too much? try the next one but only use sinatra. Like javascript? Do your next project in Node.js. (and remember jifasnif!) Felt like you're in callback hell? (remember use flow control and streams!) Try out gevent in python on the next project.

See my point? It doesn't mater what you use as long as you're making things. Pick something and do something. Iteration can only come after you've completed projects. Eventually you'll figure out what you prefer, and even then it wont hold a candle to what you've made.

<comment><AUTHOR> Completely agree with this. However, when I talk to developers who aren't based in tech hotspots, they often tell me they are lost because they dont know what they should learn, because there's so much out there. The side effect of this (which I have seen) is that people write off every new OS project that comes out, because they feel by the time they learn it, something new will be out there. I don't agree with this philosophy but it's something that I have seen with my own eyes.

<comment><USER15> One of my views is that you should figure out what you want to make before you figure out what you want to learn. Once you have a functional idea of what you are doing, then it is easier to pick something similar, or look to library repositories (CPAN, gems, etc) and decide what you want to do.

If you aren't in a tech hotspot and you aren't chasing jobs, it doesn't matter what you learn. It matters what you make and how you can sell yourself.

</comment></comment></comment><comment><USER21> I agree that no single person should be jumping around between all of the languages and frameworks out there, but the diversity is a sign that there is an active community that is experimenting with new ways of doing things. If one of them is especially useful for your problem, then you should learn it as a matter of practicality (mind the cost of transition though). If you enjoy language development, then you should definitely switch to a .01 language framework, that is where the interesting research is being done. If you come up with something good, and work out the kinks, then mainstream languages will start to use it.

</comment><comment><USER22> This article is probably appropriate: <http://www.joelonsoftware.com/articles/fog0000000339.html>

And a quote from the same article:

>>Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don't have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby.<<

Except that in this case the wounds are self inflicted.

</comment><comment><USER23> Just use what you enjoy.

I recently had a similar experience - on a whim I decided I would learn python by taking a asp.net mvc app I built and have maintained for the last 3 years and port it. So I just needed to choose a python web framework right? omg. So many, micro, mini, full stack, no stack, template engines, wsgi, uwsgi, whoa! My head was spinning

You can be completely overwhelmed just trying to make a decision, I haven't even looked at storage yet but I'll probably just use sqlite (the old .net one used db4o, which ended up being a huge mistake, great tool, pitfa to do maint on)

on a side note, loving python, and I settled on bottle, but I wrote my own template framework called canvas, inspired by the seaside component/tag/canvas classes.. essentially it's all just python code, no html.. example usage is <https://gist.github.com/3087622> (i'll push it to github once I'm happy with it, hah!)

<comment><USER24> That looks pretty neat: the use of context managers seems very nice.

But is "canvas" (and "HtmlCanvas") meant to refer to the HTML5 <canvas> element? If not, I can see that being a point of huge confusion.

<comment><USER23> no it isn't, and you raise a good point, I'll change it

canvas.canvas() would definitely look weird

</comment></comment></comment><comment><USER25> Quite a few years ago, I decided I would simply not invest my learning efforts into MS tech due to their acronym/framework spinning. It was a waste of my time. Of course, this limits me in some ways, but frees me to study more deeply into other areas.

It also happens with other tech areas. So I simply take the road around them unless it looks like I need to use one.

My personal work is done with Common Lisp, and I would prefer to keep it that way, by and large. It's a sufficiently extensible language that I can feel comfortable that (1) needed features will be programmed in, using CL, and (2) it will be stable for a _long_ time.

But I guess that's a bit eccentric of me. :-)

</comment><comment><USER26> I think this post is missing the point a little. Being a good programmer, despite what recruitment ads like to portray, is not about being proficient in dozens of frameworks and languages. No, it's about learning the skill of learning new frameworks and languages.

Getting into a new platform or familiarizing with a new tool is something you get better at the more you do it. Learning your eleventh programming language will be easier than learning the third. Getting familiar with yet another framework is easier if you know a few already and can compare the similarities and differences.

And let's not forget about the fundamentals. Having a strong background in web plumbing, understanding http and html, etc well is the key to being a good web programmer, not which frameworks you know by heart. Knowing a little theory about programming will make it easier to grok new languages faster.

If you're tired of constantly learning new frameworks and languages, go learn C and systems programming. That stuff is going to stick around for a long time and will provide secure jobs for the foreseeable future.

</comment><comment><USER27> Pretty awesome distillation of the history of software tools since, oh, no later than 1980.

Back in the dino days, the rate of change was tiny compared to today's daily delta V. We mostly had monthly and a few weekly rags to tell us about the next big thing; there weren't that many next big things, anyway. Hey, it was a really big deal when cartridge tapes came out and we didn't have to thread a 1/2 inch magtape by hand anymore... Geez, who could forget 1-base-T networking? or 9600 baud modems? Whew.

Don't get me started on software innovations like Oracle SQL\Forms! ManOhMan! Fergit CICS!

 _Seriously - the barrier of entry is so low now, that the least of us can throw something up on the wall and if it sticks or even just leaves a little residue, the flies are all over it, preaching it up, "This is the best shit ever."_

There _really_ isn't much new out there, mostly it's just lots of new flavor wheels. Think "Hudsucker Proxy" at times like this...

</comment><comment><USER28> oh, JavaScript you say? I stopped on jQuery! Everything else sort of flutters by... too much! Especially since .NET is going insane right now with kick-ass magic! So I'm still trying to catch up on .NET stuff and the JavaScript is sort of passing in another lane, but I'm like the old lady who won't take my eyes off of my lane beacuse I'm too scared to let go of the wheel that I'm barely hanging on to.

Exhausting as it may seem, its far cooler than 10 years ago! As another reason pointed out, use what you like.

ASP.NET MVC - check LINQ - check EntityFramework - <USER2>

next step, SignalIR!

next next step: Metro! :)

<comment><USER29> I've used .NET from the start and since 3.5/4.0 its just ramped up. Feels like every day there is a new acronym to master!

ASP.NET MVC 4.0 projects now include knockout.js by default. So that may be around for a while if only to support .NET devs who are just using out-of-the- box technologies.

</comment></comment><comment><USER3> This is a phenomenon limited to the frothy world of webdev. See <http://prog21.dadgum.com/140.html>

</comment><comment><USER30> Could not agree more.

At the end of the day, what is important is to deliver a piece of software that works according to the customer requirements.

If the customer dictates the operating system, language, etc. Then it is already decided what to use.

If some technology liberty is given, then it should be something that is working as desired at the given deadline, regardless of the technology.

</comment><comment><USER31> In marketing, there's something called 'the paradox of choice.' The theory goes (and there's some decent research to back this up) that if you give people too much choice, it decreases the probability that they will make any decision.

<comment><AUTHOR> Actually, there's a theory very similar to that in UI/UX design. Menus that are too large often intimidate the user and cause them to bounce out of the site.

<comment><USER31> And here I thought I was creative for applying it to UX...thanks for this! :)

</comment></comment></comment><comment><USER32> Getting blown from one framework to another so easily means you're not doing a good job of getting traction on your project. Build some positive momentum and then staying the course will become natural.

</comment><comment><USER33> It's an abstraction all the way down. Somewhat related: <http://xkcd.com/676/>

</comment><comment><USER34> The article had all Buzz words(Positive sense) except Python.

</comment><comment><USER35> Just use mod_perl. Duh!</comment>


No, Kaggle Is Unsuitable to Study AI and ML. A Reply to Ben Hamner - <AUTHOR> https://medium.com/@mostafab/no-kaggle-is-unsuitable-to-study-ai-ml-a-reply-to-ben-hamner-27283878cede <comment><USER2> This guy is just trying to tout his own product. That aside, Kaggle can be quite useful for learning... at least it used to be. Kaggle got me into machine learning 2-3 years ago and now it is about 50% of my job in consulting. Problem is, Kaggle is running too many deep learning, image based comps and they are lucky to get a couple hundred competitors each. The wider user base engages much more heavily in transaction based competitions, and these are much closer to the real world problems you are likely to encounter as a professional.</comment>


Read BBC TV, Radio and Film scripts - open-source-ux https://www.bbc.co.uk/writersroom/scripts <comment><AUTHOR> Fantastic! This sort of access usually requires something like WGA membership ;)</comment>