Finance Pros Say You'll Have to Pry Excel Out of Their Cold, Dead Hands - <AUTHOR> https://www.wsj.com/articles/finance-pros-say-youll-have-to-pry-excel-out-of-their-cold-dead-hands-1512060948 <comment> d--b Finance dev guy here.

Excel's dominance in the field is because it is an _application container_ that _non_ dev people can use.

The workflow is this:

\- old trader guy says to his junior guy: "hey can you look into xxx."

\- junior trader guy says: "sure I'll make a spreadsheet for it"

\- old trader guy: "great your model is all I need, let's trade"

\- several weeks later, IT guy says: "hey you're running a $100m book out of a spreadsheet, we'll make you a nice system for it, cause your stuff will blow up."

\- several months later the IT guy comes back with a web app that does the same thing as the spreadsheet.

\- old trader guy says: "hey I can't copy shit around, my shortcuts aren't working, I need to be able to do basic maths on the side, I can't save my work, etc."

\- IT guy: "ok I'll make you an export-to-Excel button"

Seriously I've seen this happen over and over again.

The issue is not how to get rid of Excel, it's how do we make a better spreadsheet...

<comment><USER2> At a former job I had to build a reporting system. And had the trust to build it however I wanted. But it was my job to make it sufficiently useful that everyone would use it.

The smartest thing that I did was make it accessible from Excel. You could build a spreadsheet off of my report. Refresh the spreadsheet, the report ran, you got updated data.

I got essentially 100% adoption, and the rest of my job was spent finding people who needed data and adding it as an option to the reporting system.

Usually you expect a complex reporting system to have features like graphing, pivot tables, etc, etc, etc. My answer to all of that was, "You can already do that in Excel. I could spend a lot of time on it but I'm not going to do it as well as what you already have."

<comment><USER3> This sounds an incredibly useful capability to have. May I ask which data connector did you used to pull data, and how did you made it available in that format from the app side?

<comment><USER4> Excel has a feature for pulling data stored in HTML tables into a sheet called "Web Queries"[0]. It also has a feature for automatically building these in the form of .iqy files. When I worked at Abbott Labs, it was a big deal to be able to offer export-to-Excel in a way that Excel could refresh automatically (or manually). This made it a breeze since we could register an .iqy serializer for a dataset and just give a download link to it in place of a CSV, JSON, or XML file.

[0] [https://support.office.com/en-us/article/Get-external- data-f...](https://support.office.com/en-us/article/Get-external-data-from-a- Web-page-708f2249-9569-4ff9-a8a4-7ee5f1b1cfba)

<comment><USER2> That was exactly how I did it. The only major downside was that I had to be sure to keep the html consistent, and couldn't require login.

Since it was a system for internal use, that was deemed acceptable.

</comment></comment></comment></comment></comment><comment><USER5> Watch some youtube vids of Excel pros moving around the UI quickly. There's no other UI I can think of where so much is being done so quickly except maybe a bash pro.

America's favorite villain Martin Shkreli was pretty amazing.

[https://www.youtube.com/watch?v=jFSf5YhYQbw&feature=youtu.be...](https://www.youtube.com/watch?v=jFSf5YhYQbw&feature=youtu.be&t=5199)

<comment><USER6> I'm ok with vi, and ol' Martin 'wurmtongue' Shkreli is pretty good, but what is more amazing is that he has people watching him stream. When you try telling your uncle at thanksgiving (who 'dabbles' in finance) that someone like Grimma there would stream his analysts, let alone that people would watch him, they look at you like you have 10 green heads. Shkreli there is a _perfect_ example of a generation gap.

<comment><USER7> Not a generation gap. Just the general end conclusion of culture that rewards greed.

</comment></comment></comment><comment><USER8> The issue in finance is the speed of change in demands. No formalized system platform with proper change control can keep up. The ability to play with data, the ability to break your work is valuable in end user computing and the type of thing that is hard to recreate in a formal financial system that must pass internal and external audits.

edit: I entire a whole.

<comment><USER9> > hard to recreate in a formal financial system that must pass internal and > external audits.

This should also be the reason for getting rid of Excel, it is basically inauditable. But then again I guess all the auditing firms (e.g. Deloitte, KPMG, EY) probably have a vested interest in keeping it that way, not to mention all the persons who use this deniability for fudging numbers. I guess we'll always have ethics to fall back on /s

<comment><USER8> I've worked in global banking environments (where one holding company contains a traditional banking arm and a securities firm) with a slight lean towards securities operations, although I've serviced both the banking and securities operations.

Your exact comment happens constantly in global banking firms. If the banking arm happens to be in a stronger management position, they push towards locked down system with tight development cycle controls. Typically the bankers have low risk tolerances and their systems (ex. savings and payment client account ledger systems, ATM ops, etc.) reflect it. That said, even in a true banking company, the closer the department is to the interest rating trading operations the more the banking environment looks like a securities operation. You will find critical on-the-fly modeling taking place, data integration, data reintegration all happening in Excel spreadsheets and these XLSX will be driving business decisions.

In securities operations the pace of change (demands originating from regulatory bodies, external clients, and internal trading operation, etc.) inevitably push the boundaries of what the bankers can support. If your securities side regulatory body says the firm must implement X in order to report Y, the firm is obligated to do it, regardless of what banking IT risk and change control framework the bank thinks should be followed. If the regulatory body says X should be in place by Z date, and banking assessment / change control procedures can not be finished by Z date, guess what X gets implemented by Z date. There is no choice. Same goes for client system demands. Woe be the IT staff who tries to tell a securities side broker their client demand can not be fulfilled by some change control / risk assessment procedure. Do such a thing enough and the desk's profitability will take a hit. Which means the trader's bonus will take a hit. Which means IT will take a hit.

If a proprietary / quant / interest rate trader can't respond quickly enough to market change X because it took 3 days for a revised real time report to be created and then vetted by a formal change management process, the IT staff pushing those processes will be replaced.

Looking at the situation another way, having these time sensitive demands in Excel instead of in trading systems is actually kind of smart. Try to integrate the rapid trading desk decision making that happens in Excel into the trading / transaction ledger / transaction settlement system will just endanger the smooth operation of the those systems. Fewer changes the better in these core systems.

<comment><USER10> And I am sure that like me, you have witnessed multiple production systems used for critical missions that are simply too old or expensive to update, or that have been marked legacy but never replaced. These systems are as problematic as spreadsheets.

<comment><USER8> Yep!

These ancient systems are one more reason why Excel spreasheets exist. The Excel file backfills missing functionality in the ancient system to permit the end user to do their job as defined some 30-40 years after the legacy system first came online!

</comment></comment></comment></comment></comment><comment><USER11> Everyone talks about trying to create a new type of programming environment, something intuitive and visual and that lets you think in new and creative ways. Excel is exactly that. It's easy and nonintimidating to nonprogrammers. It's visual, intuitive, and with a basic understanding of math and an idea of cells you can do a large number of tasks that would otherwise require a program.

Yes, it's a problem when it gets expanded into massive, ridiculous spreadsheets-from-Hell, but most spreadsheets are a tool that let everyone program. People keep talking about some magic new visual programming REPL-like tool that will revolutionize programming, but I think we already have it: it's Excel.

<comment><USER12> "Everyone talks about trying to create a new type of programming environment, something intuitive and visual and that lets you think in new and creative ways. Excel is exactly that" \- yes, it is, except it is a way too old already though all the notable competitors seem dedicating all the efforts to reproducing its legacy as closely as possible. I'd love to see an attempt to design a brand-new spreadsheet from scratch, built around a modern programming language (like Python instead of fossil VBA), modern practical file formats (like HDF5 and SQLite instead of obscure and clumsy xls, xlsx and ods) and all the experience and advances in the UX science accumulated during the recent years. Good news are some projects are heading this way already, e.g. pyspread and jamovi (they can hardly be taketn too serious at this moment but at least they illustrate there are people that see the problems of "classic" spreadhseets and have viable ideas on solving them).

<comment><USER13> How do you mean it's "way too old already"? If it works, it works. You're guaranteed to introduce problems every time you introduce change so there needs to be a strong reason to do. Why change what works?

<comment><USER12> > How do you mean it's "way too old already"

I mean many obvious ways it can be improved have been discovered during the time passed.

Although it obviously makes no sense to give up the whole thing just because it has been introduced long ago it still is not a bad idea to consider minor and major improvements or even rethinking the whole idea occasionally. We could still be using good old typewriters/teletypes if the fact they worked was stopping us from thinking about inventing tools to do the same job with less labour and more fun.

</comment></comment></comment></comment><comment><USER14> Former finance developer: 1\. Without Excel, every finance company will need another 100 developers, BA's, managers and QA to do programming and updates. $$$$.

2\. Most of the data sources I've seen are heterogenous or very expensive. It comes in from big companies via secure FTP overnight, small companies via pdf. Big companies won't change their rules for you, small ones don't have the staff to do it. You can quietly and immediately export to excel from a terminal at 5pm, or be charged an extra 200K a year for the overnight deluxe data export package and still not get the same bond valuation you need to reconcile. (looking at you, Bloomberg!).

3\. Every rockstar portfolio manager has their own models, and not even the VP of IT dares tell them what to use. There's no "bog-standard model" that everyone uses. That's the expensive PM's edge.

4\. Speed. Requirements, test cases, test server, scheduling personnel, project planning, testing, promotion to prod, signoff, takes a month for trivial stuff if you're lucky. Trading opportunity long gone. Analysts grab a spreadsheet, do it in half a day, make or reject the trade.

5\. Capability. Pivot tables. Compact, resizeable, color-coded, read/writeable grid, notations on the side, instant recalc, reorientable text. Row inserts. Printing. Ugh.

6\. Risk. Analyst does the spreadsheet, IT hands are clean. "Not our fault if you screw up".

7\. Resumes. What developer wants to spend 10 years coding models and reports that are regularly modified or discarded with each new analyst and PM's whim?

8\. Time. FO spends 16 hours a day trading or researching under immense stress. Asking them to find, let alone spend, 2 hours a day explaining workflows to devs is... unrealistic.

9\. Education. Devs know development, not financial instruments and regs. SME's who understand both software design and finance are rare and expensive therefore used on major projects. This may hurt egos here but most devs are some combination of untrained/low social sensitivity/ESL/fragile egos/tend to start explaining a solution instead of first listening to the problem.

Devs do major dev stuff where it's warranted. Analysts can keep Excel where it's not.

<comment> UK-AL "untrained/low social sensitivity/ESL/fragile egos/tend" I don't think that's dev's problem.

I think it's more like how society likes to treat devs. I'm telling you now, fund managers are bigger prima donnas than devs. But they make tons more money for the fund and so everybody steps inline.

<comment><USER15> Fund manager: profit

Developer: overhead

If you do not believe me, go _ask your manager_.

It is not different from food service

Customer => profit

Restaurant staff => overhead

The job of overhead is to enable making of _profit_. Without profit, developer would be out of a job. Without developer, fund manager will not be out of a job - he would be using Excel.

<comment> UK-AL Exactly, it's not negative personality traits that makes developers less influential. It's their role.

</comment></comment></comment></comment><comment><USER16> Excel is sort of like PHP. The people who want it dead are very vocal. But those who use it, use it to get the job done.

<comment><USER17> (At least php usage allied with miscondonct never made a bank lose 7.2 billions: [https://www.theregister.co.uk/2008/01/30/socgen_hack/](https://www.theregister.co.uk/2008/01/30/socgen_hack/))

</comment></comment><comment><USER18> I think this whole thread is too strongly biased to assuming that millions of analysts know what the ideal skills and tools for their job are, rather than they started with Excel and they continued with Excel.

The other thing is that people here are comparing moving from Excel to some sort of webapp/db or general purpose language, when actually they should be comparing to numerical computing tools.

R is a far more robust tool for numerical computing than Excel. It doesn't hide errors in formulas not copy-pasted enough, or references that have subtly shifted to an unrelated cell, or the garbage data from a sort that missed a few columns. The entry barrier is higher, but for the complex spreadsheets and models we're talking about, the investment in skills is similar.

<comment><USER19> And RStudio is an incredible IDE that can help ease that transition.

My boss is an incredibly smart guy, but he worked in consulting for 15+ years and sometimes cannot view data from outside of an Excel perspective. It can be frustrating to have him think that every problem is a vlookup and pivot table from being solved. I think it's easy to become a bit myopic with Excel. It's like if the only tool you have is a hammer, then every problem looks like a nail.

<comment><USER18> Yes, and after all, it's not as if learning R will prevent you trying out some models in Excel. In a life-time career, a 40-60 hour commitment for a new string to your bow that is as powerful as R is not a big investment.

</comment></comment></comment><comment><USER20> Since were all finally praising Excel for the marvel it is, I think it's also time for the OSS community to realize and acknowledge that OpenOffice/LibreOffice is quite crappy and should really see some serious improvement.

Calc is basically a toy compared to Excel, and this is quite evident once you step out of the basic things.

Anecdotally: a while ago i wanted to live-update a cell in my spreadsheet using python . Nothing fancy, just update the cell with the latest price of bitcoins and see if it's time to sell (at the time bitcoin was at 500$).

I wasted a morning on that thing and I managed to get it working but oh boy I am so ashamed of the code i wrote... Also OpenOffice/LibreOffice APIs are arcane and basically undocumented. Examples are basically non-existing.

<comment><USER21> I actually abandoned all Libre/Openoffice and I moved on Google Sheets. The number of add-ons is growing and I enjoy working in the collaborative mode with my partner.

</comment></comment><comment><USER22> Slightly related: NPR's Planet Money ran a show called "Spreadsheets" that gives brief history of Spreadsheets.

[https://www.npr.org/sections/money/2017/05/17/528807590/epis...](https://www.npr.org/sections/money/2017/05/17/528807590/episode-606-spreadsheets)

There's a World Championships for Financial Modeling in Excel, it's mentioned in that episode.

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

</comment><comment><USER23> One interesting aspect of Excel is how a sheet can be shared in a way that a compiled executable can not.

Even with all the various viruses floating around, opening a spreadsheet is a common and allowed task as opposed to downloading, installing, and running software.

Edit: I suppose this point is mostly about the ubiquity of Excel as a platform. The interesting thing to me was that even otherwise prorietary models are more accessible distributed as Excel sheets than better-secured inside a custom tool.

<comment><USER24> Well, Excel is interpreted, so a better comparison would be made against interpreted languages…

<comment><USER23> Few are willing to run random programs in interpreted languages. Most wouldn't have the required runtime(s), and things like PowerShell have a stigma that an .XLSX does not.

<comment><USER25> Everyone has a javascript-interpreter installed.

<comment><USER23> If you are talking about the browser, they are all locked down to prevent JavaScript execution from local files.

If you are talking about WScript on Windows (I doubt it), it has an even worse reputation than PowerShell.

<comment><USER25> Yes, browser.

Are you talking about Same-Origin-Policy? This shouldn't prevent a script being executed local. It only limits what it can do. Because of security, there is heavy sandboxing with javascript.

Anyway, it wouldn't be hard to transform browsers in full fledged local scripting-engines, without dismanteling security.

</comment></comment></comment></comment></comment></comment><comment><USER26> Most people who haven't used Excel for anything more complicated than their tax returns seriously underestimate its capabilities. I've seen people use Excel as essentially a poor (and impatient) man's MATLAB, doing things like surprisingly sophisticated and responsive, albeit low-resolution, physics simulations.

<comment><USER27> Indeed, I've seen people who were power users in the more sophisticated computational software, yet still used Excel when they found it to be useful.

The hard thing for me in Excel is visualizing the data flow. Long ago I wrote a VBA macro that would return the formula contents of a cell, and I'd just put that next to each formula cell. That way, I could see what all of the formulas were doing. My sheets were hideous, but if I was working through something complicated, it helped me troubleshoot mistakes.

I now prefer Jupyter/Python, but still can't claim that it's quicker for the smallest jobs.

</comment></comment><comment><USER28> Excel is functional, free form and fast. It ain't going anywhere. MS need to fix multi user workflow and add versioning.

<comment><USER29> I've heard Excel mentioned as the real reason for the Microsoft Office lock-in and cash cow.

Word and PowerPoint can be easily replaced.

<comment><USER30> PowerPoint can't easily be replaced actually... because how it links up with Excel!

</comment></comment></comment><comment><USER31> Yes - Excel is deeply embedded in actuarial modelling.

<comment><AUTHOR> Modeling yes, which makes sense given that it's a tabular math tool.

Using it to handle all the pricing structure for a few thousand clients on the other hand is another issue by having underwriters plug in values that they got from an online application, though, not so much.

</comment></comment><comment><USER32> Wasn't [http://witheve.com/](http://witheve.com/) supposed to solve this? I love Chris Granger and his team, but at this point he seems inclined to pivot ideas every 2-3 years, instead of following through with an industry-workable solution to some of these programming problems...

See also: [https://www.theatlantic.com/technology/archive/2017/09/savin...](https://www.theatlantic.com/technology/archive/2017/09/saving- the-world-from-code/540393/)

<comment><USER33> That's not similar at all though. When you're working with rows/columns of numbers, the sort of tabular data people are working with, excel is an insanely efficient UI solution. Widget based solutions can't compete with that.

<comment><USER32> I was talking about thing he was working on in 2014 - 2015, which his website described as:

> On the surface, Eve is an environment a little like Excel that allows you to > 'program' simply by moving columns and rows around in tables. Under the > covers it's a powerful database, a temporal logic language, and a flexible > IDE [Integrated Development Environment] that allows you to build anything > from a simple website to complex algorithms.

Now, I guess they're doing something completely different.

</comment></comment></comment><comment><USER34> I'm surprised the use of BI tools that integrate with Excel has not come up in this discussion. For example, Oracle EssBase (part of Hyperion) is comparatively inexpensive, and it is used in Excel via their SmartView plugin. You get all the power of Excel with live data, and flexible data models driven by an OLAP datastore. It has revolutionized our month-end and commissions process (now takes a fraction of the time), while still allowing the flexibility of Excel.

</comment><comment><USER35> The world - rightfully - has a love-hate relationship with spreadsheets. As many of the comments here point out, it is a much more nuanced subject than the referenced article suggests. For those interested in a little deeper dive I recently wrote this three-part blog series on the origin and nature of spreadsheets:

\- Spreadsheets are programs: [https://medium.com/@hjalli/3-things-you-dont- understand-abou...](https://medium.com/@hjalli/3-things-you-dont-understand- about-spreadsheets-part-1-7dfd6b3759cb)

\- Spreadsheets made the PC market: [https://medium.com/@hjalli/3-things-you- dont-understand-abou...](https://medium.com/@hjalli/3-things-you-dont- understand-about-spreadsheets-part-2-43a4fb7b6a45)

\- Spreadsheets are everywhere: [https://medium.com/@hjalli/3-things-you-dont- understand-abou...](https://medium.com/@hjalli/3-things-you-dont-understand- about-spreadsheets-part-3-eed2162d0628)

</comment><comment><USER36> It seems like I've heard that every year for the last 10 years, at least... Who wants to take excel away from them? the same ones that like to change programming language every year?

</comment><comment><USER37> Excel+PowerQuery is and will continue to be the most capable and accessible scratch pad people use. That is: get data out of your central system(s), crunch it in Excel, feed the results back to your central system and reference the spreadsheet as a record of your calculations.

The big problem is when people promote it to collaboration and workflow management software.

</comment><comment><USER38> I have a smart colleague of mine who has a story about "How Excel Saved the World." He talks about how Excel was used so extensively during the Ebola outbreak in West Africa, it was the most responsible software for analyzing data to stop the spread of the disease.

Excel certainly has limitations, but it has many features and is widely used.

</comment><comment><USER39> It's as likely as them giving up their HP-12Cs.

</comment><comment><USER40> My brother, a Business Analyst implements the prototype in Excel and hands it over to engineering team to develop it in SQL.

</comment><comment><USER41> Aside from macros, keyboard shortcuts, and .xlsx files, why else would someone be compelled to stick with Excel?

Seems like the rest of the tabular data stuff could be done in Google Sheets or some other product and yield the same results.

<comment><USER42> People are wedded to Excel because they've spent a lot of time learning it and don't want their skills to become obsolete.

The resistance is rooted in psychological / political reasons, not technical ones.

<comment><USER43> Have you ever been a power user of Microsoft Excel? And then tried to replicate that functionality in Google Sheets?

Or is your aversion mostly to the M- word?

I find it funny that when it comes to vi vs emacs (or any such similarly geek- approved thing), fans of each will jump up in arms about the precise reason their platform is better, but the same kind of people would not want to take hundreds of thousands of business professionals at their word about why they like using a particular piece of software.

<comment><USER44> Probably because the geeks can consider the virtues of making a spreadsheet vs an application while the office workers are incapable of understanding more than half the equation.

Also office workers can't always be trusted to even plug things in let alone properly assess what an optimal solution looks like.

<comment><USER45> Geeks aren't as smart as they think they are. Particularly when it comes to business requirements. I'm guilty of that as much as anyone.

</comment></comment></comment></comment></comment><comment><USER46> Let them eat Emacs?

</comment><comment><USER47> One huge reason why Finance pros in general, and Fund Managers, Brokers, Traders in particular, love Microsoft Excel is because all your formulas and calculations update almost instantly (unless you explicitly disable this feature).

So they can apply their business and process knowledge to create tables and formulas, pull data from various sources, and create something that is self- contained, stored locally (inside the lan, security reasons), is blazing fast, and helps them make money and generate profits for the company.

I've seen very sophisticated OMSs (Order Management Systems) built completely using excel workbooks, with 1 sheet containing orders and formula's to pull realtime pricing from bloomberg, reuters, another sheet for pre-trade analysis, another for the actual trades, and a summary sheet with pivot tables and charts to show the trade progress and summary.

As and when the last_price changes, the formulas update, so the trader is looking at a real-time view of his situation.

The same excel workbook that let's the traders do their job would take months / years to convert to a web app, and even then, the speed may not match up.

I know devs hate Excel, in part, because you are the "IT guy" they call (been there many times) when the spreadsheet gets out of hand, or slows down, or keeps crashing excel after a certain inflection point.

<comment><USER48> > The same excel workbook that let's the traders do their job would take > months / years to convert to a web app, and even then, the speed may not > match up.

Sorry but I have to call nonsense on that part. I've seen recently a whole trading operation converted to a system very close to a web app within 6 months. The hard part of the job was untangling the mess they created. And knowledgeable quants who actually program told us it's typical.

The financial pros have horrible, horrible stuff in their spreadsheets. They are used to it and they want (perhaps unconsciously) to keep their dirty hacks out of sight. Lest they fall from heaven.

<comment><USER49> Except excel is a generic solution. If you have to build a specific solution for each processes your costs skyrocket and people lose the ability to quickly implement something on their own. Everything takes forever to get done because you're constantly haggling with development and writing requirements instead of just opening excel and getting work done.

<comment><USER50> I've never seen two consistently created Excel workbooks. There is a lot of wheel inventing going on in the Excel world. It's possible that a more formal system would have less duplicated effort. It's also possible that doesn't matter.

"Everything takes forever because you have to write requirements" is a feature of software development. At the end you get software that does something that you (presumably) understand. Excel is a gold mine of undocumented terms, processes and functionality.

It's fast to build but don't pretend it gives any of the benefits of proper software development processes. The value proposition is in fact that it has none of those guarantees.

<comment><USER51> > There is a lot of wheel inventing going on in the Excel world.

There's usually more people who know Excel than people who can create systems. Meaning, the inefficiency is not that important. Some things just cannot wait or depend on a much smaller amount of people.

<comment><USER50> On the other hand I spent a lot of time as a data analyst explaining to business folks who "know excel" that their spreadsheets don't match because they used a different definition of week, or revenue.

</comment></comment></comment></comment></comment></comment><comment><USER52> Every time I (as a finance supposed "professional") comment on finance article on hn I get downvoted to hell.

Note to self - stick to IT stuff when interacting with IT crowd.

Yes dear IT crew, in the IT world virtualisation is in this month and docker next and kubernetes the month after. Finance side it's excel as swissknife this year and probably the next 5 years too. Get over it.

Anyway - see also djtriptych's post and associated video. Notice the complete lack of macros, programming logic, containerisation, automation, APIs or well really anything hn loves. It's just a digital hybrid scratchpad/calculator with a ton of shortcuts that are muscle memory for everyone.

Boggles my mind that HN can understand the whole vim vs emacs wars but not grasp that finance guys like their Excel for the exact same reason. It's disappointingly narrow-minded.

<comment><USER9> Not to belabour the editor comparison, but what comes out of an editor is plain text that anybody else can check with any other tool. Excel, not so much.

So what's disappointing is the amount of 'finance supposed "professional"' that think that continuing to use Excel is acceptable.

For a profession that forces everyone else to dot the i's and cross the t's and leave an auditable trail, unsurprisingly they're willing to let standards slip when it suits them. I'm sure we can rely on them to do the right thing though...

<comment><USER53> I don't necessarily agree with this. If you audit finance, you break open their speadsheets and step through it all. It's even got some basic tools for this - Formulas > Formula Auditing in the ribbon. The spreadsheets become an auditable artifact.

Your objection seems to be more that it's proprietary and you can't crack it open with any tool you like. Finance doesn't really care about closed ecosystems though (case in point, Bloomberg).

</comment></comment></comment><comment><USER54> The original article seemed to me basically an advertisement for the companies looking to replace excel. It also included a wonderful vignette where an executive sitting on a plane could check whether laying off his employees would affect his profits. The article was basically a satire disguised as an advertisement disguised as a criticism of excel.

</comment><comment><USER55> With arrogance to irrelevance!

</comment><comment><USER56> How do finance folks deal with decimals? Doesn't Excel use binary floats? Do they switch to integers?

<comment><USER57> What? Excel handles decimals just fine.

<comment><USER58> It's an amazingly pervasive myth taught in CS 101 courses that "you should never use floating point types for currencies, or you might go to jail". In reality floats are fine for most financial applications, and for almost all those that would find themselves in a spreadsheet.

<comment><USER59> It's all fun and games until you realize that adding a large set of numbers in different orders gives you significantly different results.

Floats are fine for a lot of things, but you have to be really really careful not to overstep into the situations they can't adequately handle.

<comment><USER10> Even in accounting a certain rounding error is accepted depending on the size of the company. And for pricing financial instruments, prices pretty much always get rounded on the execution (you will never communicate a price with 20 decimals to a client on the phone). Excel rounding is a non problem in finance. Except when you are making exact payments. But payment systems aren't run in excel anyway.

</comment></comment></comment></comment></comment><comment><USER60> Finance pros should be careful what they wish for... Refusing to change will give management a great reason to sack them for AI.

<comment><USER61> I think "management" that think AI will be a viable replacement for financiers should be more afraid of being replaced than "finance pros."

</comment></comment><comment><USER12> IMHO all the people who claim having intelligence and education sufficient for a finance job should be able to use at least basic SQL and/or R and/or Q to work with up-to-date information straight from the databases without importing it to a spreadsheet first. Perhaps I am terribly wrong but my intuition suggests entrusting a company finance to a person unable to learn some SQL/R may happen to be a questionable idea.

<comment><USER62> But... why would they waste time doing that when they COULD just do it in a visual format they're already familiar with? IMO writing excel formulas and having the constant visual feedback is pretty useful and I much prefer it to SQL even though I am very familiar with SQL and not so much with Excel.

No need to make an assertion about intelligence and learning programming languages in your comment here either. Everyone has their own workflow.

</comment></comment><comment><USER52> Told hn exactly that a week ago and got downvoted

[https://news.ycombinator.com/item?id=15759644](https://news.ycombinator.com/item?id=15759644)</comment>


Why Is Object-Oriented Programming Useful? With a Role-Playing Game Example - <AUTHOR> http://inventwithpython.com/blog/2014/12/02/why-is-object-oriented-programming-useful-with-an-role-playing-game-example/ <comment><USER2> Since this is aimed at new developers, I would encourage anyone who falls into that category and is reading this to also look at alternate programming methodologies. The key component of OOP is the mixture of code and data into "objects". This can be very useful for physical simulations such as games, etc., since the real physical world is actually made of objects.

However, many feel that applying OOP to software that is not for physical simulation has led to a huge amount of wasted effort over the previous decades. The problem is with code reuse. The only real form of code reuse that OOP addresses is direct object inheritance. If you want to reuse a piece of code, the way to do it is to make an object that is a 'subclass' of an object that has the code that you want to use. The actual relationship of these objects is often not that simple, and people often create baroque inheritance trees to force their logic into the OOP pattern. Worse, is that OOP is built into many languages, which leaves you no choice.

An alternate pattern is functional programming, where a program is modeled as a series of data transformations, instead of a universe of interacting 'objects'. To write the code, one looks at what data will go into the software, and what data will need to come out. After all, if the right data is coming out of the program at the right times, it works.

Instead of breaking code into objects, you write functions that process the data correctly, and assemble them into larger structures, often resembling pipelines. The nice thing is that a lot of these functions are very reusable across projects and within a project. Avoiding the messy mixture of code and data allows you to identify the common patterns in your code, and refactor and reuse more easily.

EDIT: Here are a couple of libraries which have really facilitated functional programming for me in node.js

\- [http://ramda.github.io/ramdocs/docs/](http://ramda.github.io/ramdocs/docs/)

\- [https://github.com/dominictarr/pull- stream](https://github.com/dominictarr/pull-stream)

<comment><USER3> Like you say, the main benefit of OOP is that it matches the way we perceive reality. That can make it intuitive to design software. However, this often comes at the expense of performance since the hardware that executes your system bears no resemblance to the way we perceive reality.

Take your physical simulations, for example. You may have a game scene with hundreds or thousands of entities. It's natural to try to model these as objects. In every frame you will then call a method on each object that applies a translation to its position. Very intuitive and simple. But unfortunately extremely inefficient for a computer to execute. You will likely pay a number of cache misses while jumping to each of your objects. And once you get there, the rest of the cache line where your coordinates are is full irrelevant stuff and therefore wasted (the other fields of your object).

For performance, you would want to have all your entities' coordinates in continuous memory one after another, and then apply a function to translate them all at once. Pretty much the opposite design from where OOP naturally leads you.

<comment><USER4> It's debatable whether OOP "matches the way we perceive reality". Many have come to believe this, but is it true? I don't perceive all of reality as a strict hierarchy of things constructed out of templates, with "is a" and "has a" relationships between them.

I don't think the main problem with OOP is performance, either. The problem is that it's not always the right or the most natural _design_ approach, regardless of any performance considerations.

<comment><USER5> > It's debatable whether OOP "matches the way we perceive reality". Many have > come to believe this, but is it true?

No, it isn't true. But neither do we perceive all of reality as a collection entities that never change but are used to create new unchanging entities by a series of idempotent mappings from domains to codomains.

But both abstractions are useful as ways to organize your thoughts, or as languages we can use to describe processes in an organized manner. Which one is more useful is often case specific - with the case covering not only the problem space but also the individual psychology of the person doing the work.

Many find that neither is so useful that they would be comfortable using it to the exclusion of the other, which is why there are so many functional languages with object-oriented features such as Caml and why so many major object-oriented languages such as C++, C# and Java have been acquiring increasingly many functional features over the past decade.

<comment><USER6> I'm not sure why immutability is being lumped into OOP alternatives, seems orthogonal (to me). You can have immutable AND mutable versions of OOP after all. Similarly, you can have immutable and mutable composability. To me the main issue with OOP not matching reality is having people put things into hierarchies instead of thinking of common elements found in them. For example, to me thinking about composing objects in Go and its nice-auto-applying interfaces is similar to Haskell's data with typeclasses, despite one being totally mutable and the other immutable (obviously these feature sets are quite different, my point is in how you think about "the world", i.e. a circle in both Go and Haskell doesn't inherit from anything but may abide by a contract thanks to either interfaces or typeclasses, getting you to talk about things in terms of its features and not its inheritance).

<comment><USER7> Inheritance is not necessary for OOP.

For example, if you have:

      struct Cat {
        meow: String
      }

      impl Cat {
        fn talk(self) {
          println!(self.meow);
        }
      }

      fn main() {
        let bob = Cat { meow: "Mroowwwww!" };
        bob.talk(); // Prints "Mroowwwww!" Good job, bob.
      }

Cat lumps the data and its associated functionality together into an object. This is object-oriented programming even if you never bring inheritance into the picture.

Both Go and Rust have objects, they simply go by the name struct. Haskell does not follow the object-oriented approach.

I think the confusion surrounding OOP is that people associate OOP with a particular implementation of it, like Java.

<comment><USER6> Sure, but with that wide a definition its really hard for a programming language not to be object oriented. C can be just as object oriented with structs, unless you consider bob.talk() to be just completely conceptually different from talk(bob) where talk's definition expects a Cat struct. Similarly, under your example, Haskell is also object oriented since you have data types with fields and functions that can only operate on that kind of data (Again at this point you'd really be arguing that the order of function/caller is the "OOP differentiator" since (ignoring inheritance), there is no difference between Cat's talk method and a talk function that takes in a Cat).

In other words, I don't think anyone is ever arguing against organization of data and functions into more abstract "types". Pascal does this with Records, C with structs, Haskell with data types, C++ with classes, JavaScript with prototypes, etc etc. So if thats all it takes to be "OOP" (in other words, not forcing you to only use ints and floats), then I guess I agree that OOP is a better representation of the world. But now I'd argue that the more interesting discussion is between the has-a and is-a versions of this.

<comment><USER7> You have to draw the line somewhere. The structure of a typical OOP language program such Go, Rust, Java, C++, C#, etc. are not comparable to that of a typical Haskell program.

All of the languages that are considered OO rely heavily on the binding of data and functions into objects.

Others will have deeper ideas of what an OO language needs to have, but the basic definition is about objects. That is, the binding of data and functions into an object.

In modern OOP discussion, it seems many already have come to the conclusion that inheritance is something to be used very sparingly, and can be done away with in favor of composition in most use cases.

<comment><USER6> I agree that you have to draw the line somewhere, but I believe the is-a/has-a dichotomy more accurately separates the different modes of thinking. To me the structure of a Go program is completely indistinguishable from one in C++ (precisely because of the lack of inheritance). When I look at the design of a C++ program (or say Obj-C), its all about class hierarchies. The docs are all about the class diagrams, step 1 of most those programs is usually "subclass ___". It immediately drops you into that view of the world, and I believe that with that view comes the guiding hand of your program's design.

Compare that to Go, which focuses on the _traits_ of objects instead of their incidental ancestry. In go you'd define a function or method applying to an abstract interface that has certain properties. For example, I would say "give me an object that has a show method", not "give me something inheriting from Printable". This is completely analogous to the very abstract typeclass-style programming you do in Haskell ("give me something that derives Show"). Haskell object architecture is all about defining an abstract typeclass and reasoning about what you can do given these existing methods. You then supply an implementation that fits the type class definition, exactly the same abstract analysis of fundamental properties divorced from their specific owners as inheritance-less interface/protocol programming in a language like Go.

Again, there is quite _literally_ no difference in "binding" a function to an object through the dot syntax vs through type. If in haskell you say the meow function applies to the Cat data type its not any different than having a meow() method on a Cat in C++, neither can call that on anything else, its quite bound.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Unfortunately for the OP, when it comes to game development, it's widely understood that OOP only ends up painting the developer in a corner eventually. Yes using Objects, Inheritance, and Polymorphism works well for a long time, but the more objects and deeper the inheritance tree grows, the more inflexible the system becomes. You also run into problems with reality. When the code hot path calls across multiple object types and a invokes a bunch of polymorphism every frame, the code is going to be slow and there's no obvious bottleneck. The code is slow because the CPU is constantly waiting for its cpu and data cache to catch up.

Game development today is moving quickly towards components, composition over inheritance, and Data Driven Design techniques. Check out the myriad of posts on Entity/Component systems that have sprung up over the past 10 years. It can be harder to grasp at first but has huge wins over the traditional OOP model.

<comment><USER9> This "huge win" depends heavily on what you're making. If you're making simple games where performance is not that much of a problem (like most indie games) then moving to entity/component systems makes no sense and tends to make everything more complex than it needs to be. A good middle ground in those cases is to just stick with normal OOP with shallow trees (no more than 2-3 levels) and favor simpler types of composition like mixins whenever needed.

<comment><USER10> As someone who has made indie games with both traditional OOP and component systems-- I vastly prefer component systems. I disagree that they make things more complex. I found that they made things much simpler. Although, it does require learning about and possibly developing a component system.

If you are talking about very very simple games, it would perhaps not be worth the effort, but at that level basically any architecture will work.

<comment><USER11> Entity component systems are just another form of OO that rely heavily on ontology and named object instances. Unless you mean OOP must be Java, then of course, it's not.

</comment></comment></comment></comment><comment><USER12> I feel like a lot of the problems OOP solves are working around inadequate type systems. If you can make a distinction between Int @@ CharacterHP and Int @@ WeaponDamage such that you simply _can 't_ subtract one from the other without going via the appropriate function, then the argument for having private member variables and object methods to mutate them (which is the controversial part of OOP, I think everyone agrees with having data structures and some form of polymorphism) goes away, doesn't it?

<comment><USER13> Right, but you should also include notions of immutability and ownership in your explanation. OOP is partly about managing complexity. If the mutation and sharing in your data is managed by the type system, private data is much less important.

That being said, OOP is also about managing interfaces between the different parts of your code. Adding a little more type info to your variables doesn't help you if you need to drastically change how a variable is accessed and mutated (memoized, retrieved from a service, persistence layer, etc.) while avoiding a running a giant find/replace across your entire project.

<comment><USER12> > Adding a little more type info to your variables doesn't help you if you > need to drastically change how a variable is accessed and mutated (memoized, > retrieved from a service, persistence layer, etc.) while avoiding a running > a giant find/replace across your entire project.

I feel like if you have a generic "context"-like notion then you can have a lot of this pass directly through. E.g. I recently changed where a Scala report gets most of its data, making it use an (async) web service rather than a database call, and I only really had to change the "top and bottom" \- all the intermediate code handles any kind of context as a generic "F[_]", sometimes requiring particular typeclasses (Applicative, Comonad) depending on what it does with it.

</comment></comment></comment><comment><USER14> The problem is that object oriented programming is a premature optimization that has outlived it's usefulness.

Object oriented programming _enshrines_ mutation.

Mutation is a good optimization when memory is expensive and fast relative to computation. Memory is now cheap and slow relative to computation. You can execute 100's to 1000's of operations in the time it takes to chase a pointer that is not cached.

<comment><USER15> If OOP encourages mutation can you explain to me why the String class in java is immutable?

<comment><USER14> It's a holdover from when Java was supposed to be a language for small machines.

However, if you're being snide, let me retort "So why does everybody in Java immediately recommend that you use the StringBuilder class instead of String?"

</comment></comment></comment><comment><USER16> So yeah, in games OOP makes perfect sense but I have a hard time applying it in other code. I mostly build applications that make some API calls, save the result to a database etc. What is an object in that context?

The same goes for the classical Car and Animal OOP examples. Yeah, that makes sense but how often do you have such entities in a real code base?

<comment><USER17> The problem with object-oriented programing is that it makes objects the most important abstraction, which it's not. I'd say states are the most important abstraction of a program.

I think I've grown so much as a programmer since I started thinking more about states and less about objects.

</comment></comment><comment><USER18> I was talking to a friend who started doing web development transitioning from game development. I came from a JavaScript background heavily based around Lodash and 'nearly' functional paradigm. I was discussing my interest in more purely functional languages like Haskell and Clojure. Kind of rattled of my distaste for OO programming and how it just doesn't make sense to me, it seems like a lot of fluff and boiler plate when our most common use case is moving data from a form to a data store.

He made a lot of good points that with game development OO makes a ton of sense. I kind of agree. OO works amazingly with game development but with application development I'm really finding the functional paradigm so much more logical.

<comment><USER19> Functional programming in JS is possible, ramda / wu (others?) make it very easy to get started, of course it is not as great as with functional programming languages, but still, it allows you to do pretty cool stuff, it's like lodash but with the callback moved to the first argument, turning something like this:

var isMultilanguage = function(field) {

      return field.multilanguage === true;

};

var isNotMultilanguage = function(field) {

      return field.multilanguage !== true;

};

var getMultilanguageFields = function (fields) {

      return _.filter(fields, isMultilanguage);

};

var getNonMultilanguageFields = function (fields) {

      return _.filter(fields, isNotMultilanguage);

};

into this

var isMultilanguage = R.where({multilanguage: true});

var isNotMultilanguage = R.not(isMultilanguage);

var getMultilanguageFields = R.filter(isMultilanguage);

var getNonMultilanguageFields = R.filter(isNotMultilanguage);

[https://github.com/ramda/ramda](https://github.com/ramda/ramda)

[https://github.com/fitzgen/wu.js](https://github.com/fitzgen/wu.js)

<comment><USER20> The current stable version of Lo-Dash supports _.curry. In 3.0 Lo-Dash will add support _.rearg, _.ary, & _.curryRight. Using a combo of them you can easily create auto-curried functions.

      var where = _.curry(_.rearg(_.where,1,0));
      var isMultilang = where({multilanguage: true});

</comment></comment></comment><comment><USER21> The weird thing is, many if not all of the arguments apply to C with structures, unions, and function pointers... and I don't know that consider that properly object oriented.

</comment><comment><USER22> <unrelated> Al, could you made the fonts on your site bigger, make styling via css not on each element and introduce some nicer Google fonts? Also, if you could use `<code>` and `<pre>` tags that'd be a solution where you could ignore the rest of what I said.

Reason being that I save these articles for later to show people who I try to teach programming and my attempts to save this page were unsuccessful.

</comment><comment><USER23> Wow I haven't seen that character record sheet in 30 years. So mewhere I have a 10th level elf fighter with 18's for every trait (17 for charisma just to break it up.)

Translation for non-D&Ders - I was so nerdy I made my own characters for my own games I was DM for with completely invented characteristics rather than rolling dice for traits like the rules say

</comment><comment><USER24> The author should really consider some proper way of displaying code, instead of a textbox.

Also, for some reason, on safari the code is in one line, while on chrome it's in multiple lines, like it should be.

<comment><USER25> The highest priority rule is the in-line which specifies white-space: nowrap; which doesn't preserve multiple whitespace. Firefox and Safari does what he says. I'm not quite sure why Chrome is displaying it differently..</comment></comment>


Show HN: Online Inventory System for Individuals & Businesses - Want Feedback - <AUTHOR>

While working as a Unix Systems Administrator (I still do, just with much more limited hours), I use a horrible piece of software called Netdoc (by Brady) for network documentation. It always confused me how something so expensive could be so horrible, so I set out to make something better.  After a bit of development and research, I realized inventory software in generally was pretty horrible, so I changed tracks a bit so my software could be useful to everyone from IT professionals to those wanting to keep track of their personal book collections (And be at a price book collectors can afford).  A year later (ie: now-ish), I released a free public beta of my better solution to both network documentation and inventory in general. So now, I'm looking to get as much feedback on it as I can to make it even better.
The software is called Flextory, and you can create a free beta account at http://flextory.com, as well as find out more about the software.
Whether you like to just play with and break software or are interested in finding a new inventory solution, I'd absolutely love any feedback you can offer.  Also, general feedback or comments about Flextory or even the state of inventory software in general would also be greatly appreciated.  I'd like to make Flextory my full-time job one day.
EDIT: I just wanted to point out the Getting Started/Intro guide at http://docs.flextory.com/flextory_introduction , which also has a lot of screenshots and gives an overview of the ideas behind Flextory. <comment><USER2> One point of emphasis should be on your front-end, which is pretty weak right now. Heres a few tips.

Use a framework like <http://twitter.github.com/bootstrap/> or the under rated <http://foundation.zurb.com/>

If you're looking for something a little more complete, spend a few bucks and grab a theme from <http://themeforest.net/>

Something like this [http://themeforest.net/category/site-templates/admin- templat...](http://themeforest.net/category/site-templates/admin-templates) will make a HUGE difference on your products design and usability.

Lastly, I would recommend reading <http://designforhackers.com/> and get a better understanding of general design aesthetics like font, spacing, color etc.

Good luck! You're off to a great start! If you want to chat about front-end, Im happy to help. You can email me through my profile

<comment><AUTHOR> Thanks for all the great resources. I will admit that design is not my strong point, but the backend and features are all there, that it's pretty easy to revamp the entire design. I'm going to look into twitter bootstrap and maybe paying for a theme or even finding a designer.

Also, I may very well send you can e-mail later on. Thanks a lot!

</comment></comment><comment><USER3> Doesn't seem to be working for me, I get a 'sorry you can't do that' error.

Once it's up again I'll take a deeper look, inventory needs help and i look forward to seeing your solution.

<comment><AUTHOR> You need to log in first. Click log-in in the upper right hand corner. However, thanks for mentioning that, as you are the second person to point out a bit of confusion with that. In fact, I'll see if I can push out a quick fix to clarify that error.

<comment><USER3> Logged in now, thanks for the clarification.

<comment><AUTHOR> No problem. Also, I just pushed out an update that automatically brings you to the login screen if you are not logged in. Hopefully that'll clear some confusion.

<comment><USER3> Ok, I have to agree on the front end, and I can enthusiastically endorse bootstrap as a great start. The UX is rough, and I would recommend a lot of 'mom testing'.

Explore visual representation of the inventory, lists can be overwhelming, and push a new user right back to their excel spreadsheet.

I find that I'm really wanting clearer, and more compelling calls to action.

I recognize it isn't your target market, but I would suggest going to a small business owner that does regular inventory like a restaurant and take a look at what they use, there might be some interesting learning there.

I did it for many years using excel, and the constant need to catalog and maintain inventories is a legitimate pain that needs solving.

Good luck!

<comment><AUTHOR> I'll definitely be revamping the UI in the near future. Also, a random note, but there are a lot of subtle features such as no pages (you just keep scrolling), easy category exploration (items show up immediately on the right as you browse categories), auto-completion, table headers that always stay at the top, and other little UI things that don't show up until you have at least a few items in the system. It's many of those things that make it much more enjoyable to use compared with other solutions (at least, in terms of what me and a few others who have used it a bit more extensively think). I think the overall UI may be discouraging people before they even realize that all those other features exist. On that note, do you think putting a public demo that's populated with much more data would be a good idea? The biggest problem is that public demos are a bit outlet for spam and other abuse.

"I find that I'm really wanting clearer, and more compelling calls to action." -- I was wondering what you meant by this.

Also, I have been reaching out to small business owners and I actually have a restaurant owner who is interested. Whether he ends up using it or not, I hope he'll be able to provide some good feedback.

EDIT: Also, I was curious if you have any further thoughts about the representation of the inventory. Right now, it displays items as tables with the ability to customize what attributes you see while browsing (this can be changed by clicking your name in the upper right hand corner). When you say to explore other representations, are you saying to work more on just the displaying of the tabular data or coming up with some sort of hybrid-list- table thing?

<comment><USER3> Get in touch by email, I can help more by sending over some excel files of example restaurant inventories that are currently being used by the industry.

Restaurant inventory has clear needs that i can go into further, if you're interested in pursuing that market of course. I'm not sure they'll pay for it, and they're not the best early adopters, so I would hesitate to build a business model around them. That being said, take a look at <http://www.scanitinternational.com> as an example of one group trying to solve it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> Add a "Show HN:" to the beginning of the title of this thread, and you will be more likely to get feedback. I will give proper feedback when I get more time to test it.

<comment><AUTHOR> Thanks for the tip! I made the change.</comment></comment>


Why We Threw out All Our Code (And Why You Should Too) - <AUTHOR> http://blog.nowjs.com/why-we-threw-out-all-our-code-and-why-you-sho <comment><USER2> Throwing out all your code and rewriting it from scratch is like demolishing your building and constructing a replacement from scratch. It's usually not the right thing to do, it occasionally and rarely _is_ the right thing to do, and it's _always_ the tempting thing to do.

It's stupid to argue, "You should never tear down a building" (like <http://www.joelonsoftware.com/articles/fog0000000069.html> implies) and it's also kinda stupid to write an article entitled, "Why We Tore Down Our Building (And Why You Should Too)"

Neither is universally right. The right thing to do in a given situation is a difficult and complicated question to answer, and it depends on the building in question: how big it is, how well it was designed, how well it's been maintained, etc.

<comment><USER3> How often do you build a prototype building? Or a building as a side project?

Your analogy fails, sir.

It's easier and more common to write dirty code that functions as it should than build a building with poor foundation but that looks and functions as it should.

<comment><USER4> > _How often do you build a prototype building? Or a building as a side > project?_

This is one of the most amazing things about rapidly growing cities in most of the world. Neighborhoods that start out as informal shanty-towns full of lean- tos with leaky roofs become, over the course of years, first neighborhoods with modest but permanent cement block buildings and tin roofs, and sprout all the typical urban amenities like power lines and sewers (often at first pirated ad-hoc from other nearby neighborhoods), have their roads paved, etc., and a few decades later look like normal neighborhoods, sometimes even surprisingly gentrified ones.

<comment><USER3> Absolutely, as someone who grew up in a city like Mumbai, I know much about shanty towns and from my knowledge of them, they are far from ideal. ie. They are not know for a strong foundation, cleanliness, longevity etc. They are constantly _hacked_ and _patched_ by its residents to ensure basics like protection from rain, electricity and basics like a toilet.

<comment><USER2> And that's how New York and Rome and Shanghai grew into world cities. They didn't pave them over and start from scratch. They grew out of shantytowns.

<comment><USER3> But wait, we were talking about buildings, not cities. A city is made up of many buildings. And buildings are torn down across cities on a daily basis.

<comment><USER5> Right, and chunks of code are thrown away on a daily basis.

The question is: which is the more appropriate metaphor for a project? A building or a city?

<comment><USER3> I agree with the position that _it depends, code may be a building, or a city or any number of things_.

I disagree with the OP that deciding to recode can simply be compared to tearing down and making a new building for no reason. That's oversimplification.

First, there are times when buildings _must_ be demolished and built from scratch. The OP makes this idea seem ridiculous but it happens everyday when buildings are in fact demolished and rightly so. Second, fewer buildings are demolished and built from scratch relative to programming projects demolished and built from scratch due to the inherent differences between a coding project and a building project. For one, the former is more regulated and carries more physical risk than the latter(a coding project).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> They threw out 3 months of work... That's not a rewrite, that's a prototype. People do this all the time.

<comment><USER7> +100 - the biggest questions (to me) were HOW MUCH code did they throw out, and how old was it? Throwing out a few months of code you just finished writing (and which you're still intimately familliar with) is vastly different to throwing out a code-base that would be entering middle-school if it was a person.

<comment><USER8> I don't know what the old codebase is like, but the current one is just 2145 LOC, not counting tests. 62K total.

I know that startups do way more that just write code, so I'm not criticizing them at all. And it seems they're not afflicted with the typical engineer modesty when it comes to their own codebase, which is a good thing. On the other hand it's not exactly a superhuman hacking achievement to rewrite this from scratch.

<comment><USER9> So if we're charitable and say the new codebase is, oh, three times as compact, that means they threw out about 10% of their code.

</comment></comment></comment></comment><comment><USER10> Netscape 6 is (or was) the oft quoted example of why not to do this. All that old code may seem old and boring, but it has a huge amount of knowledge, wisdoms, learnings, fixed mistakes, performance improvements, great ideas, deleted bad ideas and security fixes built into it.

When you throw out your code you're throwing out all that knowledge on the assumption that you can build it all back with improvements.

Evolving an application from a known good state to a known better state is usually the best approach unless your codebase is small or your app has no traction.

Rewriting your app from the ground up is like getting divorced and dating a new girlfriend. The first few months are a lot of fun until you figure out how much you lost.

<comment><USER11> Without Netscape 6, we wouldn't have had Phoenix/Firebird/Firefox, and probably wouldn't have IE7, IE8, IE9 and KHTML/Webkit would have come about very differently and all these would have had much less competition.

Netscape 6, or at least the mere fact that it existed and worked well enough and the fact that it was the first browser ever that did standards well and focused on not much else other than standards, made it the most important browser ever created.

Netscape 6 was the most revolutionary browser project ever created and had the development effort behind Netscape 6 not been done, we would possibly have had a much worse very IE-only web today.

Never mind that beyond all that, Netscape 4 was terrible and deserved to be thrown out.

<comment><USER12> > Netscape 6 was the most revolutionary browser project ever created

I dont disagree with the general sentiment of your comment. But as someone who attempted to use Netscape 6 at various stages of its development, I fear that statement might be stretching facts a little bit.

</comment></comment></comment><comment><USER13> A few people have pointed out that it's easy to throw out your code when you (a) have tests for it, and (b) only have three months invested in it. I agree with both of those points, but want to tip my hat to a team that rewrites their code after three months.

The reason some code bases can't be rewritten after a few years is because when the code was only three months old, the team passed on the chance to rewrite it while it was still a tractable exercise.

<comment><USER14> Very much agree. An extra layer on the danger cake (for web apps) is if your user base grows slowly while keeping the business profitable. Suddenly (sic) you hit real capacity limits after n years, and have _no idea_ how the "organically grown" code in question works.

</comment></comment><comment><USER15> I've never used NowJS nor looked at the source for it, so I can't comment about their justification for a rewrite.

But most programmers I know don't need _any_ encouragement to rewrite stuff, myself included!

<comment><USER16> That's the attitude I am trying to avoid these days. When I look at something that I want to rewrite I now ask the following questions,

1\. Do I have sufficient tests and testing to do this without breaking things?

2\. Do I want to want to rewrite because I cant be bothered understanding it?

3\. Is there going to be any gain now or in the near future by rewriting it?

4\. Will I be able to rewrite it sometime in the future as part of another piece of work which actually delivers value?

Unless I come up with Yes, No, Yes, No I tend to leave it alone. There are other things of value I can do with my time.

EDIT - Formatting...

<comment><USER17> Thank you, these criteria just saved me from tearing down a building.

</comment></comment></comment><comment><USER18> _3\. Sunk costs and egos get in the way of good software_

Egos are what drive people to throw away their entire codebase and start over.

<comment><USER19> Egos and _lack of skill_.

It's so much easier to write from scratch than it is to refactor. So many programmers have no idea how to tackle an existing codebase, even if it's one they've wrote themselves.

<comment><USER18> Very important clarification, you are quite correct.

</comment></comment></comment><comment><USER20> Justified or not, I think a project owes it to its users to _change major version numbers_ when a major rewrite (much less a complete one) has occurred.

As perfect as your code might be, customers deserve a hint when major changes were done under the hood. Moving from 0.6 to 0.7 screams "just a few changes, some new features", not "we threw everything out and started over". This should have been made into "1.0beta", I would think.

<comment><USER21> There are other factors involved when deciding a version number than the code under the hood: API changes, new features, is it production ready, 'this is the now stable API that we'll be maintaining for a long time', etc.

Edit: for perspective, a thoughtful proposition on how to approach software versioning: <http://semver.org>

<comment><USER20> I agree that there are many factors. I'm just saying that some changes are important enough to trump anything else; the presence of a rewrite should decide the version all by itself.

</comment></comment></comment><comment><USER22> sigh; a headline like this is little more than HN linkbait. As others have mentioned, throwing out all your code is generally a bad idea, especially if your project is of significant size. How many lines is NowJS anyway? I doubt it was much of a loss.

<comment><USER23> I'm still trying to figure out what NowJS does other than expose an RPC call using socket.io. All of the features on the website are actually socket.io features.

</comment></comment><comment><USER24> Throwing it away is easy when there's not that much of it.

My codebase is 10s of thousands of lines, it evolves as I get better but I'm not going to scrap it.

</comment><comment><USER25> Please bear in mind the counter article everyone is citing (<http://www.joelonsoftware.com/articles/fog0000000069.html>) was written 11 years ago. I'm not saying that it's wrong because it's from 11 years ago, but you really want to consider its central example.

Netscape 6.0 was a complete rewrite. The article claims that this was a mistake.

Now, if you would recall, one of the reasons Netscape 6.0 was completely rewritten was to use Raptor/NGLayout. Raptor/NGLayout was later renamed to Gecko. Gecko is the currently developed Firefox rendering engine, and Netscape 6.0 marked the start of the Mozilla foundation.

I would harshly argue that Gecko would not have taken off nearly as well without Netscape's rewrite. But this is definitely not a story about Gecko's popularity. It's about the reason why Gecko was the decision they took at the time, and the current impact of Gecko.

Besides the fact that Gecko was one of the early open-source success stories, the reason why Netscape decided to scrap everything and start from scratch was simple: Netscape 4.0 was horrid. Remember back to the days of IE vs Netscape. Netscape was significantly slower, and had no dynamic HTML among many other features. It was buggy and would crash frequently. And the development on the "continuation" of 4.0 code was simply too slow to compete, because of outdated, not modulated code, and stuff stuck in that simply "worked," and never changed to allow for future changes.

Now, people attribute Netscape 6 to Netscape's death because of this radical decision. But take a look at Netscape's usage statistics: [http://upload.wikimedia.org/wikipedia/en/1/16/Netscape_Navig...](http://upload.wikimedia.org/wikipedia/en/1/16/Netscape_Navigator_usage_share.png) . Hey, guess when Netscape 4.0 came out and IE started to dominate? 1996-1997. By 2000, when Netscape 6 was released, Netscape's usage already dwindled down to nothing.

Now, you're thinking, why didn't Gecko save Netscape? It takes too long to reverse these tides. Netscape was already dead. AOL acquired Netscape in 1998, to combat IE. Then, in 2003, AOL won an antitrust suit against Microsoft, and allowed AOL to use IE royalty-free. Netscape was pretty much scrapped at that moment because the damage had been done.

But wait.

Mozilla released Phoenix in 2004, based on Gecko. You should now the story from there. (Clue: Phoenix -> Firefox)

Disclaimer: I'm not saying that Firefox > IE or Chrome or whatever. I'm saying that the codebase Netscape 4.0 was based on was doomed to fail. Gecko still lives on today, and was started as a rewrite of Netscape.

Anyway, my point is, there are times to rewrite things, and there are times to keep them the same. If you have a good, legitimate reason to rewrite, as Netscape or NowJS did, you should. If you are just the stubborn programmer that always implements his own Queue or QuickSort when libraries exist, don't.

<comment><USER26> Throwing away Netscape 4 and rewriting it from scratch wasn't a bad decision because nothing good ever came of it; it was a bad decision because it _killed the company_. The shattered remnant of Netscape that hobbled across the finish line to release "Netscape 6" wasn't even Netscape anymore, it was a rapidly fading division of AOL, IIRC, that just stamped its name on a Mozilla product it had little to do with producing at that point, to widespread derision.

As bad as Netscape 4/5 may have been, while I can't guarantee trying to refactor instead of rewrite would have gone better, I _can_ guarantee it couldn't have had any _worse_ a result than the Total Death that was the actual result.

And the phoenix-return of Mozilla is the exception, not the rule.

<comment><USER27> In support of your comment, I think some are forgetting how horrible Netscape 6 actually was to use. (Or am I just getting old? It wasn't that long ago!)

Compared to earlier versions it was incredibly slow—even by the standards of the time—and crashed a bit more frequently. It took much longer to load or perform some common tasks. Sure, the rendering engine was better for many pages, but browser sniffers were still common, and (like now) weren't updated often enough, so bad versions of sites got served occasionally too.

There were a host of reasons why Netscape 6 was bad from a user's perspective. Spolsky has it right when he says Netscape 6 was a piece of junk. Let's not allow time passing to permit us to remember it more fondly.

Sure, future versions got better, but that was due to he creation of a new "corporate" memory. It took a while to get over having discarded so much learning.

</comment></comment></comment><comment><USER28> Well, just because some prominent luminary says it shouldn't be done never means it's always a bad idea. A lot of the basis against rewrites are for relatively mature projects still on a high growth trajectory or large installation base. However, there are exceptions to that as well. Foursquare went from LAMP to Scala/Lift, PostgreSQL, and MongoDB with minimal complications and it's paid off handsomely to support their amazing growth.

Also, the money quote: "It's managed to survive our vicious benchmarking tools and our ridiculously comprehensive test cases. " My assumption is they are using the same languages and tool sets (not porting from language X to Y).

I'm curious as to how long the rewrite took though.

</comment><comment><USER29> Rewrites are always fun and I applaud any man brave enough to undertake such an effort.

I've often been faced with a situation warranting a rewrite, but I never mustered the courage to actually go with a full rewrite I don't think. Gradual rewrites are much more my thing.

<comment><USER30> I've been really really tempted to do one, but sadly the pressures of the job take precedence and so it usually ends up being the case that you stick with the code you've got and try and hack extra things in, knowing full well you really don't want to and aren't at all happy with it.

So my 'rewrites' sometimes come in the form of superficial organisation. Looks moderately nicer, doesn't work any better.

I guess it is courage though. You don't really know that your rewrite will be an actual improvement, or if you'll even pull it off. Brave move indeed.

</comment></comment><comment><USER31> _It's managed to survive our vicious benchmarking tools and our ridiculously comprehensive test cases._

I guess they did not rewrite those from scratch. If so, I would guess they only rewrote, at the most, 25% of their code.

</comment><comment><USER32> Once you start making revenues from your code, a complete rewriting is probably the worst thing you can do for your company. Sometimes it might be warranted, but customers care about solving problems, not about technology.

Chances are if you wrote properly modularized code, you can rewrite modules one by one, which is perfectly legit. But just dropping everything and trying to rewrite a product from scratch is a mistake that a company usually only makes once (before they die).

</comment><comment><USER33> Especially when getting into a codebase that is not yours you are tempted to think "why dont i just rewrite this in a better an cleaner way". Then you go on todo that and fall into most of the pitfalls the original author fell in before, have to rethink every idea behind and it usually is alot more work than you think. That said it depends heavily on the size of the project and a bunch of other things, for a 3 month old project it might make sense.

</comment><comment><USER34> You should read the book, "In Search of Stupidity - Over 20 Years of High-Tech Marketing Disasters"

Refactoring is almost always preferable to throwing out all your code, imho.

</comment><comment><USER35> I'm glad they're happy with the rewrite, but honestly, this makes me feel a bit nervous about updating my Node app utilizing NowJS to the 0.7 release.

Maybe it is better. Maybe it is more stable, smaller, and faster, and well- tested. But it hasn't had as much "real world" use thrown at it as the previous codebase had.

I'm not saying I won't upgrade, but I'll likely wait a bit until I do and stay with what I know works right now, at least in production.

</comment><comment><USER36> Frequently, throwing out "all your code" is a sign you did pretty much everything wrong to begin with. Personally, the sign of a decent design is when you can wind up doing the old "Grandpa's Mattock" trick:

"This is grandpa's mattock; my father replaced the handle and I replaced the blade".

</comment><comment><USER37> I'd be dubious that they actually rewrote everything - having working stuff lying around that already worked, some of which was probably just fine, I'd hope it got copy-pasted into the new code...

</comment><comment><USER38> Relevant: Things you should never do - <http://www.joelonsoftware.com/articles/fog0000000069.html>

</comment><comment><USER39> Whether their decision was right or wrong, they made a decision that big companies tend not to make. Startups should probably have a bias towards decisions like that.

</comment><comment><USER40> An attention grabbing headline but all the same I have been using now.js and its been a great tool (although a cut down on the print statements would be nice).

</comment><comment><USER41> If you're dealing with human DNA, a complete code rewrite will likely fail.

But if its just an amoeba and you have a lot of time, go for it.

</comment><comment><USER42> It's probably easier to do this sort of rewrite if you've already got "ridiculously comprehensive test cases".

Anyway, congrats on 0.7 Sri!

</comment><comment><USER43> Be ready to throw away your first version. I wish I had the right quote on hands. The K in K&R said that.

</comment><comment><USER44> Its not always the right thing as there are years of issues/corner cases that have been resolved.</comment>


EBay hit with new fine over counterfeit Louis Vuitton products - <AUTHOR> http://business2press.com/2009/11/30/ebay-hit-with-new-fine-over-counterfeit-louis-vuitton-products/ eBay has been hit with a massive €1.7 million (USD $2.55 million) fine after the company failed to adhere to an injunction that ruled the company wasn't doing enough to block the sale of counterfeited Louis Vuitton products. <comment><USER2> Hmm, does that mean I should probably return my bag?

</comment><comment><USER3> ebay should keep improving its software to stop really stop them... in those geographic areas at least</comment>


MoviePass exposed thousands of unencrypted customer card numbers - <AUTHOR> https://techcrunch.com/2019/08/20/moviepass-thousands-data-exposed-leak/ <comment><USER2> This breach could have been avoided by simply having security audits of the service and customer data and using a secure hash algorithm (Bcrypt) for the user data. There isn't an excuse for this to happen, especially in 2019. If you have an account with MoviePass, the following details about this breach should concern you:

> None of the records in the database were encrypted.

What could possibly go wrong here? /s

>..We found records with enough information to make fraudulent card purchases.

So a MoviePass account also has unencrypted account data (Name, email, address, card no., etc) to make it possible to perform fraudulent card purchases?

Magnificent. /s

> The security researcher said he found the exposed database using his > company-built web mapping tools, which peeks into non-password protected > databases that are connected to the internet

So there was no password protecting these accounts in the first place anyway? Who's idea was that?

> "MoviePass takes this incident seriously and is dedicated to protecting our > customers' information.

Here we go again.

</comment><comment><USER3> I dont understand how this still happens today. There is process and procedures for handling customers data. This is one company that wont see any of my money.</comment>


Friendsweekly – A weekly newsletter to stay in touch with people you care about - <AUTHOR> https://friendsweekly.com/ <comment><USER2> I agree with the need for 'safe' social places like to be built.

But since the entire system is based upon lists and lists of email addresses, there REALLY needs to be a Ts & Cs and Privacy Policy in place here.

I'm assuming this is a one-man-band (Jayme?) behind this which I also commend, but if you don't add those things and also some background info about who's behind it (and how safe are all those email addresses) it's going to have a hard time winning trust.

(And yes, though I can kind of see where he's coming from, 'RSS' in the title title is misleading. Rather like Spotify calling a 'talkie' audio file a 'podcast'. It simply (and really) isn't.))

<comment><USER3> Can you elaborate on the podcast thing

<comment><USER2> A 'podcast' is (or was!) a media file located at the 'url' of an RSS feed item 'enclosure'.

When a podcasting downloading application (aka:'podcatcher') 'subscribes' to the RSS feed, it gets notified (actually via a 'pull' or 'ping') that a new latest item is available. The application then automatically downloads the media file and places it in a playlist in your media player for offline use.

At least that's how it always used to be when we started building these things years ago. ;)

Hope this helps.

<comment><USER2> The term has been somewhat evolved to mean an 'episodic' series of media files (audio or video). Which is why so many places call them a podcast now.

Rather like when people online post a big blurb of text _anywhere_ and just call it a 'blog'. it diminishes the true meaning of the term.

</comment></comment></comment></comment><comment><USER4> I can't find a link to their privacy policy. I like the idea but would be hesitant to give it a go without giving that a glance-over.

</comment><comment><USER5> This looks great but I don't see anything about pricing / business model, which worries me. Are they going to start charging for subscriptions once they're established? or inserting ads everywhere to make money? or do the intend to pursue freemium features with a solid "free forever" feature set?

I only really want to invest the time and energy into getting my friends using this service if it's the latter.

<comment><USER6> What kind of premium service on top of this would you suggest?

<comment><USER7> File or photo storage

International pen-pals

Long term journal archive

</comment></comment></comment><comment><USER8> Hey, this seems really neat to me. I'd really like it if it takes off.

That said, many people I know are 'addicted' to social media (mostly Instagram, some Facebook). It's less about sharing what's going on in your life with loved ones, and more about 'showing off' – a carefully curated feed of text and images. Often with the purpose of seeking approval or validation.

I have left all (traditional) social media for the most part, but I don't know if many people will be willing to do that, and/or replace/supplement it with this.

<comment><USER9> _> I don't know if many people ..._

Every service doesn't need to appeal to every person, or to destroy FB.

Would it be successful with 1,000 users? 10,000? 100,000?

Certainly there's some small fraction of the world that would find this useful.

<comment><USER10> Is that small fraction in the same friend group? If not they'd be just a bunch of random strangers on the internet. The problem is that FB, Insta, etc... is where most people's friends are. I don't have any use for a social network my friends don't or won't use.

I really do like this idea. I have a few friends I send a long email to every 2 or 3 months, just to keep them up to date on my life, touch base, see how they are doing since the last time we spoke. I quite like the format. I don't need to tell people about my life daily, or in most cases even weekly or monthly.

<comment><USER9> _> Is that small fraction in the same friend group?_

Certainly if you just select people at random, it's unlikely they'd all want this service.

But if you already send a long email to friends periodically, and if they appreciate reading your long emails, and if they occasionally send you lengthy updates, then chances are the folks in your friend group would like the product.

To quote patio11 talking about financial services:

 _If there is a 100x100 matrix of broadly consumed financial products and potential customer segments for them, we can compete on product for one cell of that matrix, win by utter domination, and then start expanding from there._

[https://twitter.com/patio11/status/1208909582896181248](https://twitter.com/patio11/status/1208909582896181248)

This approach might not work well for financial services, but shouldn't it might be feasible for like-minded groups of people.

</comment></comment></comment></comment><comment><USER11> This is extremely sweet, quaint, and I absolutely love the concept... but... what RSS? Where's the privacy policy? Support via twitter? Who's project is this and what else are they doing with my data?

</comment><comment><USER12> Can I at least see what the email will look like or how you'll pull all this data without signing up?

</comment><comment><USER13> While I like the intent here, I personally would be really annoyed if a friend gave my email address to a site like this. It is NOT OK to give your friend's private email addresses to third parties.

<comment><USER14> Indeed. Especially when all this can be implemented with regular email directly.

</comment></comment><comment><USER7> I created an account and tested the subscription function.

1) The subscription URL starts with http: instead of https: though your site has SSL set up.

2) The subscription URL can only be used by someone who is logged in. To improve onboarding, I think it should go to the create account screen as opposed to the login screen.

For me personally, I won't use (divulge my friend's email addresses to) this software unless it's open source and I can host it on my own server.

I'd be happy to donate $20 if I end up using it.

</comment><comment><USER15> so it says it keeps your fam stuff out of the public social feeds... but uses email.. which makes a lot of stuff public, like sending postcards around the world right?

I think people are already confused enough about how email works and how non- private it is.. so I would be careful with that wording.. unless the emails are encrypted of course - then good on you for working on something cool.

RSS in the title is kind of mean - I was hoping to see a new mobile friendly version of netvibes / pageflakes that allowed friends and family to check off boxes to get notified about updates in some of the categories (rss feeds)- and make opml shareable / clone-able so people could start their own..

I tinkered with the idea of doing just that with buddypress and rss widgets for profiles. Have not researched a good way to close a profile or set of feeds, but the other pieces are there.

</comment><comment><USER16> As others have said. The idea is good but without a privacy policy that is a lot of PII to be forking over.

</comment><comment><USER17> RSS in the title is misleading. This looks like an email newsletter thing and has nothing to do with the syndication format you can subscribe to in a feed reader.

<comment><USER18> Bit of a tangent, but you can pipe email newsletters into an RSS feed.</comment></comment>


How Facebook Ruins Friendships - <AUTHOR> http://online.wsj.com/article_email/SB10001424052970204660604574370450465849142.html

<comment><USER2> It seems like this author has several unrelated points:

* some people post boring updates;

* it's easy to miscommunicate emotional content;

* some people overshare;

* SNSes collapse our multiple public masks (heavy metal and kittens) into one;

* dumping people is more painful.

They also include a single sentence about the advantages of SNS web sites.

So what's the article _about_? Why did they feel the need to write a 1300-word editorial about every negative aspect of social networking sites? It seems weird to devote 1300 words to the negatives and one sentence to the positives.

The author's experience is fairly different from mine. My Facebook signal-to- noise ratio is somewhere around -5 to -10 dB. Here are the most recent interesting bits from my Facebook stream (just the front page):

* A friend's youngest daughter is about to go off to college. Major life transition for him.

* Another friend, who's mostly famous for his anti-spam efforts, is DJing at a community radio station I hadn't heard of before. Add to my mental list of friends involved in community radio.

* A new online video site called Magma has launched and been recommended by someone trustworthy.

* Some details on my ex-stepson's microbrewing experiments. Sounds like he's getting pretty serious about microbrewing, and would be a good person to ask if I have questions.

* Another friend, who I thought was going to be at Foo Camp this week, is still in Montreal. Maybe Foo Camp hasn't started yet? I can't find information on the web about it.

* Another friend has decided to get a Singer 6510 sewing machine because the less expensive machines weren't worthwhile. Useful data point for the next time I buy a sewing machine.

* My sister's cousin just visited San Francisco to visit family — but apparently my sister wasn't included in the outing. Maybe she was busy?

* Another friend is having a hard time recovering from surgery a few weeks ago, and can't type. He's not finding Dragon Naturally Speaking useful for coding.

* Another friend is starting her first day of work as a full-fledged lawyer. In Puerto Rico.

* Another friend has just joined a chorus. I didn't know she sang.

 _None_ of these are so urgent as to justify a phone call to tell me about them. But they are all very interesting to me, and it's highly beneficial (I think) for me to know things like that about what's going on in my friends' lives.

And then there's the opportunity to respond to people — just to remind them that I'm thinking about them sometimes, but also sometimes to offer my advice or thoughts, or to let them know I appreciated what they had to say.

<comment><USER3> _"I'm tired of loved ones—you know who you are—who claim they are too busy to pick up the phone, or even write a decent email, yet spend hours on social- media sites"_

Yes, because getting on the phone with you for hours on end telling you all about my vacation is the same thing as spending 3 minutes uploading my photos to Facebook. Has it occurred to the author that maybe said friends aren't close enough to be spending time on the phone like this?

I call shenanigans on this entire article. It seems to suggest that Facebook as _weakened_ friendships. No, I still talk to my closest friends just as often - on the phone, online, in person, wherever. The difference is now you can keep track of your "outer circle" much more easily than before. This is not a bad thing.

<comment><USER2> Also, you can arrange to meet them more easily.

</comment></comment></comment><comment><USER4> This is why microblogging needs layers. The inanity of a post should be machine-readable so users can filter those they follow based on how much they want to know. At the bottommost level would be stream-of-bioinformatics auto- logged by attached devices. At the top level would be something like "[username] was born [timestamp]. [username] died [timestamp]." Anything in- between should be categorized somehow (by the user themself? by a trust network? by NLP?) I like to use the ZUI and LOD metaphor here.

<comment><USER5> Nah, at the bottom should be "GUESS WHICH TARANTINO MOVIE CHARACTER YOU ARE!?"

<comment><USER4> I suspect there would be millions of data points on the bioinformatics corresponding with the taking of that quiz.

</comment></comment></comment><comment><USER6> Here's a novel idea. Stop checking people's facebook status updates if you don't care!! Wow, that was really hard.

</comment><comment><USER7> Disclaimer: WSJ's parent company owns Facebook's biggest competitor, Myspace.

</comment><comment><USER8> I'm actually considering only using Facebook for business relationships. Probably 75% of my _friends_ are customers or industry peers. In that regard, I find it a useful tool for connecting and getting instant feedback on things.

For personal connections I find it annoying for many of the reasons he states.

</comment><comment><USER6> On another note, it is this kind of mindset that is both unadaptive and uncreative. Rather than tout the benefits of the new social world, it focuses on the negatives. And then, rather than focusing on how the negatives can be fixed, it focuses on just complaining about them.

</comment><comment><USER9> I wonder how many here prefer txt based communication over talking on a phone, except while driving.

With Facebook you can state something and a conversation may or may not happen. With txt, email or IM you can communicate one to one what's going on now, where & what time to meet up and other conversational subjects.

Due to bootstrapping I got rid of my cellphone and really have not missed it; only once when I had a flat-tire I wish I had one. Now & since then I just carry my iTouch as there is WiFi all around. I'm probably anomaly?

<comment><USER10> I prefer face to face to texting, texting to phone, and phone to email/im. At least, for keeping up with local friends. For friends who live several states away, I prefer facebook > im > skype. I hardly get any personal e-mail.

</comment></comment><comment><USER11> The eye roll button is truly a good idea.</comment>