How to build (and how not to build) a secure "remember me" feature - <AUTHOR> http://www.troyhunt.com/2013/07/how-to-build-and-how-not-to-build.html <comment><USER3> Good article, but one thing is explained in a weird way:

Don't bother with cookie expiration. That's the wrong approach, _because the cookie is controlled by the user_. Always do a server-side check whether or not the auth token in the cookie is allowed to continue the session.

So you could simply set the expiration date for a cookie until 2030 but make sure that the auth token from that cookie cannot be used after $EXPIRATION_TIMESTAMP on the server.

You could also follow a layered approach:

If the user logs in every few days, re-authenticate him using the auth token from the cookie. But if the user was seen more than $MAX_INACTIVE_DAYS ago, do not re-authenticate and terminate all sessions, even if the "remember me" function is set to half a year or so.

<comment><USER4> Good point, but your explanation is also a bit confusing. If I understand correctly, your point is not so much "don't bother with cookie expiration" as "don't trust cookies to expire when you tell them to". In other words, the server should double-check cookie expiration dates because you don't want somebody fudging your 7-day cookie and using it to log in next year. Am I right?

<comment><USER5> Implement cookie expiration server-side.

<comment><USER6> Would anyone be tempted to do this "client-side"? What would that even mean, besides what the browser does automatically? Or are we just saying, "don't trust that the client won't send expired cookies"?

</comment></comment></comment></comment><comment><USER4> > _A more pragmatic mitigation is to still separate the auth cookie from a > dedicated "remember me" cookie and use the latter to re-authenticate the > user but impose some restrictions._

What are the benefits of using a separate cookie for the "remember me" feature, provided that you impose the same restrictions (e.g. requiring the password again before accessing sensitive areas of the website) and same security measures like "httponly" & "secure"?

I've been using a single cookie with a randomly generated and periodically replaced session identifier, which expires at the end of the session by default but lasts longer if the user selects "remember me". I'd like to know whether there is a compelling reason to switch to two cookies.

<comment><USER7> One significant benefit is being able to enforce a one-time use policy the remember-me cookie. If you only utilize it when the user is not logged in, then you use it to authenticate, set a regular session cookie, and generate a new remember-me cookie. If an old remember-me cookie is ever used that means someone probably sniffed the cookie, and you can invalidate all sessions at that point and even force a password reset if you are particularly paranoid. You can't do this with the regular session cookie because a user might have multiple tabs open. For remember-me the same effect is only a race condition if the user opens two tabs simultaneously.

<comment><USER4> > _You can 't do this with the regular session cookie because a user might > have multiple tabs open._

Why not? It's considered standard practice to refresh regular session identifiers every X minutes, and this rarely causes race conditions unless your app is AJAX-heavy.

My apps regenerate the session identifier every time it detects that it has been more than 5 minutes since the last regeneration. So if a user who has been away for a few hours returns to the site, his session identifier will be immediately regenerated and the old one will become useless. If race conditions become a serious issue, I can allow the old session identifier to continue to work for the next 30 seconds or so. It also shouldn't be too difficult to add a feature that throws tantrums if someone continues to use the old one much later than that.

<comment><USER8> If an attacker uses a compromised session id before it is regenerated, the attacker will receive the regenerated session too. They'll have a long-lived session to the victims account.

<comment><USER4> If the attacker uses a compromised remember-me cookie, it will also be regenerated for him. Same problem.

<comment><USER8> If you use the scheme described linked from the article, when the legitimate user logs in again, the attacker will lose access to the session permanently.

<comment><USER4> Oh, I see. A separate cookie makes it easier for you to check for compromised sessions. I suppose you could also do that with regular session cookies if you keep good track of identifier history, but it'd be a lot more hassle.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Remember me cookies are a specific case of some data sent to the client that the server would like to verify at a later point in time. The most direct way that comes to mind for solving this type of problem is to send the client just a random identifier and have the server look it up in a persistent store upon use.

The other way of solving it is to have the server sign whatever data is sent to the client via an HMAC. That combined with some basic serialization gets you a generic approach that you can use for all kinds of things. This also has the scalable benefit that it doesn't require a centralize persistent store.

Here's a high level summary of how we handle these use cases:

# Server -> Client (Assume server wants to round trip object X)

      1. Server serializes X to a URL friendly string (JSON + Base64 works well enough for this)
      2. Server calls generateToken(type, message, expiration) which signs the message/expiration with secretKey+type. It then returns a JSON/Base64 serialized map containing message/expiration/hmac.

# Client -> Server

      1. Client sends back the final JSON/Base64 string
      2. Server decodes and extracts the message, expiration, and hmac
      3. Server verifies the HMAC by regenerating it and comparing it against the client supplied one
      4. Server verifies the expiration date hasn't passed
      5. Server returns back the deserialized object

Couple of notes:

* The HMAC prevents the client from tampering with the message

* The 'type' field is so that tokens generated for one request type cannot be accepted somewhere else in the application. It's kind of like namespacing.

* The 'type' field does not need to be included in the message itself. It's inferred by the server based on the client request type.

* The object/message itself can be blank. In that case this becomes a secure expiring token.

Couple of possible extensions/improvements:

* If the data being sent back/forth is particularly sensitive you could also have the server encrypt either it or the entire message itself. If it's not though then it would be overkill.

* Including the requesting clients IP in the HMAC generation to further limit the set of user's it would validate against is an option as well though generally that's a bad idea. People's IP addresses change fairly often and that kills the basic use case of taking your work home with you.

<comment><USER10> This is where most cookie schemes wind up -- sending and retrieving HMACs.

I wrote my honours dissertation on an opt-in scheme that used cookies, HTTPS and javascript to track users visiting multiple websites.

What you have here is what I called "Protocol 1": the first elaboration of the naive protocol. An additional elaboration (Protocols 2 and 3) is to remove user identification from cookies entirely. Each cookie is regenerated on each HTTP request with a new ID and HMAC. This means that if a cookie is successfully harvested, its useful lifetime is limited.

There are more attacks after this. I got as far as Protocol 10; it transpires that Protocol 10 is broken anyhow. Depending on the sophistication of your attacker, there's no safe way to do what I was trying to do.

<comment><USER6> This sounds interesting. Can you provide a link to this dissertation?

<comment><USER10> Email me (in profile).

</comment></comment></comment></comment><comment><USER11> Regarding how long to keep the "remember me" cookie for, this is one of the overlooked reasons why native apps are eating the web's breakfast. When was the last time you have to re-authenticate on a native mobile app?

Maybe it happens on some finance/banking apps, but I don't recall seeing it on apps like Facebook or Kindle for example.

Web developers could, for example, add longer times if the user agent is mobile.

And Troy is spot on about the middle ground of "logged-in-ness". Developers are finally realising what Amazon knew all along, that it's not binary. You can keep the user partially logged in, while requiring authentication to perform sensitive tasks.

<comment><USER12> > When was the last time you have to re-authenticate on a native mobile app?

All the time. The Facebook android app is horrible.

<comment><USER13> Not for me. Did you by any chance move the app to your SD card? Apps that use the android Sync provider don't work if they're moved.

</comment></comment></comment><comment> brown9-2 How does the "reference implementation" of ASP.NET actually work? Is the cookie's value mapped to some in-memory entry in the application server, is it stored in a database, etc? It seems that the article doesn't say.

<comment><USER14> > Is the cookie's value mapped to some in-memory entry in the application > server, is it stored in a database, etc?

Neither. At login the server signs the new session cookie with a secret application key. Later, when a client requests a page and sends over the session cookie, the server verifies the signature. If it matches, the data in the session cookie -- which usually includes the username, whether they're logged in, and for how long -- can be trusted.

This is nice because it makes scaling a stateful site easier. Server-side session stores often become the bottleneck. Also, from a REST standpoint, updating a session database during a GET request (eg to freshen the session) is problematic.

ASP.net was the first time I remember seeing the signed session cookie trick, but most web frameworks have it now:

django -- [https://docs.djangoproject.com/en/dev/topics/http/sessions/#...](https://docs.djangoproject.com/en/dev/topics/http/sessions/#using- cookie-based-sessions)

rails -- [http://guides.rubyonrails.org/security.html#session- storage](http://guides.rubyonrails.org/security.html#session-storage)

flask -- [http://flask.pocoo.org/docs/api/#sessions](http://flask.pocoo.org/docs/api/#sessions)

node -- [https://github.com/mozilla/node-client- sessions](https://github.com/mozilla/node-client-sessions)

mojolicious -- [http://toroid.org/ams/etc/mojolicious-session- cookies](http://toroid.org/ams/etc/mojolicious-session-cookies)

</comment></comment><comment><USER15> Help!

Most of this discussion I understand. One point is, it all involves lots of work with browser cookies stored on the user's computer.

My approach so far is to send the user the character string version of a GUID (globally unique identifier, supposely unique in all space and time, on all computers or some such) in an HTML text box marked as "hidden" so that it doesn't show on the screen. Then I use that GUID value as a key in a key-value store where the value keeps the short term info I want on the user and their 'session'. I wrote my own little key-value store with TCP/IP, some class instance de/serialization, and two instances of a .NET collection class.

However, my understanding is that some browsers are willing to help implement the function "Remmeber me on this computer" without help of cookies. How? My guess: For the text boxes on the login in Web page, in the HTML use names for the boxes that the browser interprets as 'user name' and 'password', and then the browser stores the contents in its dedicated disk space by Web page. Right?

So, there's a 'security hole' here if the user is on a computer shared with other people!

Also, my understanding is that so far on mobile devices, the browsers do not permit cookies. True? And if so, do mobile browsers permit the function of remember me I described above?

Thanks.

<comment><USER16> You are a bit confused, but I'm not sure why you're being downvoted...

> GUID

GUIDs are really not the best idea, they can be (sort of) predicted - <USER2> attacker can guess which GUIDs are in use as session identifiers. Better to use a random string (generated by a cryptographic random number generator)

> without cookies

Browsers can store user's password when they request it. It is a security hole, consciously made by the user for added convenience. Also, only the user who made this decision can fall into this hole - it's his credentials that get stolen.

> mobile devices ... do not permit cookies

they do (although some might not store the cookies for as long as the expiration would require). However, they don't allow the user to store the password (as in the previous paragraph, the remember me function as you call it)

To round it up, it's a good thing you're experimenting with your own key/value store and session implementation, but it's usually better to use tested components in production (especially for the session stuff - it's very easy to get wrong). Anyway, keep experimenting, that's the best way to learn - I just hope somebody reviews your stuff before you shoot yourself in the foot :)

<comment><USER15> Thanks, I needed that!

I've done a lot of programming, some quite advanced, and likely for longer than 99% of the HN audience. But this is my first effort with a Web site, HTML, CSS, etc. So, I believe I can write good code and think through design issues well enough, but I am missing some information about mobile devices and browsers.

My little session state store code is working great. It was fast, fun, and easy to write, and it's been working flawlessly as I use it while developing more code.

My main alternative was to use what Microsoft's ASP.NET offered. First they offered storing session state in the same _application_ (whatever that is, maybe just an address space). That alternative would give problems once my site is busy enough to need more than one Web server unless I had some front end box, maybe from Cisco, implement something like _session affinity_. The second alternative was using SQL Server. I'm trying to keep down the use of SQL Server, especially for something as _light_ as a session state store where relational database, with ACID, etc. is gross overkill.

Thanks for the information on cookies: I don't want to assume or ask that a user's Web browser accept cookies.

When my site goes live, there will be no reason for users to have a user ID or password or log in -- later there will be. So, when I have some users log in, there is some question just how to handle that in a way both secure enough and also really easy for the users. If the user lets their Web browser store the user ID and password (not in a cookie) and a user wants to use that facility, so far fine with me -- that browser functionality is an industry standard and, thus, not to be too embarrassed about. Maybe I can get some actual documentation of that browser feature in pages for programmers at Web sites of the Web browsers -- Firefox, IE, Chrome, etc.

For using a GUID as a random key, I don't see what's wrong. I just ask for a new GUID whenever I need one. I use GUIDs for so many things inside my server code that no user can see a sequence of GUIDs from one of my servers. So, all a user could see would be just a few GUID values and should have one heck of a time guessing GUID values for other users. But, a well regarded generator of random strings would be easy to use also. I'm familiar with high quality random number generation, mostly would want assembler code for the arithmetic, don't want to try to write Intel x86 assembler to be called from Microsoft's Visual Basic .NET, would not want to use such a random number generator for session ID, and am not thrilled about writing my own random string generator. That's why for now I used GUIDs for session IDs. But I could ask ASP.NET to encrypt the GUIDs. Then a user could grab the encrypted string and maybe reuse it but would have to decrypt to see a GUID to guess the GUID sequence and extrapolate to a GUID of another connected user and then encrypt! Seems a bit much! Besides, they'd also have to guess the IP address of the other connected user and fake the IP/TCP/HTTP or whatever headers that report IP address. Maybe the NSA, some guys in a big basement in China, or some brilliant, bored wacko in Belarus wouldn't have anything better to do!

For what is stored in session state, I add to that right along as I write the rest of my Web pages. So I have a class, marked as

      <Serializable()>

and add properties to it as I want something _persistent_ during the user's logical _session_.

I read somewhere that Web browsers on smart phones don't support cookies. Good to learn that this is not correct.

Since cookies are now a privacy concern, I'm still reluctant to ask my users to have cookies enabled for my site. For persistence a session ID, I don't need a cookie and can use just a GUID (or a random string) in a hidden field. For persistence for user ID and password, my site doesn't use those yet!

Thanks for the answers!

<comment><USER16> You're welcome. I had a look at your comment history and I sincerely apologize for calling you confused, I'm probably more confused than you in a lot of things. Also I appreciate your "long form" style of commenting :)

As for using either in process or SQL Server way of storing the session tokens - there is also a third way and that is writing your own session storage provider, it should be relatively easy and have all the advantages of rolling your own solution and ASP.NET session ID strength [http://msdn.microsoft.com/en- us/library/ms178587(v=vs.100).a...](http://msdn.microsoft.com/en- us/library/ms178587\(v=vs.100\).aspx)

I don't believe you need to do anything special for the password storing (in browser) to work - just keep the same name or id on the HTML elements which accept the username and password and the URL of the login page.

An attacker can just fire as many requests as your simplest page can handle with incrementing GUIDs (not necessarily incrementing by one, GUIDs are made of some machine identification and current time so there is probably even smarter way). If any of the requests doesn't result in "Session expired" page, the attacker has just defeat your session ID because of using GUID. If you go with the custom session storage you can avoid this problem.

When you store stuff in the HttpSessionState, it gets stored (by default) in the memory of the process, it will use the custom session storage provider, if you write one.

I believe that 100% of users accept cookies. But it's true that for storing session id you don't really need it. Also in the EU we now have this stupid law requiring websites to inform users that they use cookies... [http://econsultancy.com/nl/blog/9202-eu-cookie-law-three- app...](http://econsultancy.com/nl/blog/9202-eu-cookie-law-three-approaches- to-compliance)

Good luck with the website - you sound like you're just the right amount of crazy for changing the world :)

<comment><USER15> "Confused" is not the worst I've been called, and at times it's, i.e., "confused", been correct!

Thanks for the feedback.

For the link to MSDN, checking my collection of such Web pages, I downloaded that page on 3/15/2012 as file number 739 from MSDN in my collection of documentation for ASP.NET, TCP/IP, etc. of the 4000+ Web pages of documentation I have so far!

Reading some of that Web page again, it looks complicated, more work to make use of their _provider framework_ than just write my own code.

For using my code for session state store, in a Web page just write early in the execution of the Web page code

        result_code = SSS_retrieve( )

make whatever use want of

         Public users_session_state As New SPP_session

for an instance of my class

         SPP_session

and near the end of the execution of the Web page write

        result_code = SSS_store( )

Simple.

My code for making session state persistent enough, still available anywhere in my server farm with no issues about concurrency or locking, and nicely fast is really simple: So, the session state store is just a little program in Visual Basic .NET (apparently as good as anything else at making use of the common language runtime, CLR, and .NET Framework).

The program runs as just a console application started just from a command line, actually from a short scripting program (in ObjectRexx, my favorite scripting language until I convert over to Power Shell).

The program implements just a _key-value_ store. To this program, each key is just an array of type byte; similarly for each value. The implementation is just via an instance of a .NET collection class, hopefully AVL trees or red- black trees. There is a second instance of that collection class used for handling session time outs, as I recall, hard coded at 40 minutes. We're taking simple, dirt simple, here!

The program just listens on a dedicated (hard coded!) IP port number for a connection request. Since the program is single threaded, there are no problems with concurrency or locking. That is, the program serves just one customer at a time!

From timings, on a single core, 3.0 GHz processor, the program should be able to do the work needed for a site to send 1000+ Web pages a second. If my Web site needs more capacity, then just do _sharding_ , that is, in the code for a Web page, given a session ID, do a look up and find the IP address and port number of the executing instance of the session state store program that handles that session ID.

Keep 512 such instances busy, and could have a really busy Web site! With 16 threads and instances per processor, that would be 32 processors which would fit easily in just two standard racks. A big Web site and session state handled with just two racks! Nice!

Microsoft has a collection class in storage with scope the 'application', i.e., all Web pages in one instance of IIS, and I tried to use that storage for my session state store. The first bad news was that during development something got confused raising an exception "invalid cast". So each time I changed the code for a Web page I had to issue Microsoft command

         iisreset /restart

to get everything working again.

It is true that my way of handling session state makes my Web page code look different.

So far I'm happy with how I'm handling session state.

Thanks for the detail on how the next GUID is generated -- just add 1, which is less obscure than I had hoped.

So, maybe for a GUID start with the MAC address of a network adapter, use some time and/or date, and then increment or some such.

If a malicious user wants to break into my site, then they will have to guess both the GUID of the session ID of a current user and also that user's IP address. If that is not secure enough, then I can just ask ASP.NET to encrypt the data in the hidden field. Then a malicious user would have to decrypt to find a legal GUID, generate some trial GUIDs, encrypt, guess an IP address, and post the data back to my server. And at that point, all they have managed to do is to have my server send some confused response to the IP address of the real user with that session ID. No biggie. Besides, my Web site is not for a bank or trading Bitcoins, etc.!

For "crazy", it can look that way to others. To me I just saw an unsolved problem, turned it into a math problem, got a math solution, and wrote some code. I believe that the problem is important and my solution good. We will see, at least see if users like my solution.

</comment></comment></comment></comment></comment><comment><USER17> I tend to like doing: sha256(sha256($password) . $ip)

This encrypts the password and makes the cookie only usable by the IP it was set for. Then to verify the cookie, since I already store sha256 of the password, it's trivial to do, without having to store an additional token for persistence. Of course you can replace sha256 with your fav hashing function.

<comment><USER18> What if the user gets their session hijacked when they're on a static or long- term dynamic IP? If the user were to relogin, their session ID would be the same. I think it would be beneficial to at least store a salt associated with their session and regenerate the salt when authenticating.

sha256($password . $ip . $random_salt)

You could also regenerate the salt periodically.

<comment><USER19> No. None of these. Please stop. The system is _entirely broken_. No amount of tweaking is going to fix it.

</comment></comment></comment><comment><USER20> Remembering the username _can_ be pretty useful, especially if you find yourself in a place where you common usernames are taken on other sites and you have to use different usernames in different places.

<comment><USER21> Being reminded of a username could also be helpful if you have more than one username at a given site - for instance, personal and business accounts for a bank or credit card site, per-project accounts for a contractor, etc.

</comment></comment><comment><USER22> Or you can do this:

Client generates random value, puts it into cookie and passes it to server along with valid credentials. Server remebers it for this user and whenever at later time it sees this value in the cookie it logs in this user. Server forgets this value when this user logs out and after some time.

If client does't have javascript or you don't trust randomness it can generate you can create this value on server and make the server set this cookie when it responds to login.

<comment> brown9-2 What is the point of generating this value on the client? The second scenario you describe seems to work the same, minus the need to generate values on the client, with the same outcome.

<comment><USER22> I guess no point. Pick the one that you feel better with.

<comment><USER22> Also the server should keep it hmac-ed in case db silently leaked.

</comment></comment></comment></comment><comment><USER19> There's a lot of misinformation in this thread, so I'm going to describe best practice for this sort of thing.

      1. The client authenticates, and asks to be remembered.
      2. The server generates a cryptographically random token of at least 128 bits in length. This token is *never* directly stored server-side.
      3. The hash (or, possibly, a slow-hash) of the token is saved in the database along with a time of expiry
      4. The non-hashed token is sent to the client as a cookie completely independent of the session cookie

When the client visits the website:

      1. The server checks for the presence of the remember-me cookie
      2. If the cookie is set, it is hashed and this hash is searched for in the database (and filtered to tokens with expiry times after now)
      3. If the user is successfully logged in, the old token is deleted from the database. A new token is generated and sent to the client by the previously-described process

Now for a little bit of explanation.

This process completely isolates the authentication token from the session. If a token is somehow intercepted or discovered by an attacker, it is _only_ usable for a single session. Such tokens should never be allowed to serve as permanent entry points into a user's account.

The token is never directly stored server-side. This confers two benefits. First, these tokens should be considered password-equivalent — if someone manages to steal your table of remember-me tokens, they would be completely unable to use them to log into a user's account. Second, this prevents timing attacks; if you simply looked for matching tokens in your database, an attacker can (shockingly simply) use timing information to guess a user's remember-me token in O(n) time.

<comment><USER6> I don't see why you have to store the hash of the token. You know the key you used for HMACing, why can't you just check that the cookie contains a valid hash of the rest of its data (which is as extensive as you need: session id, expiry, IP, whatever)? To prevent the use of old sessions just make the session id a counter. A single session counter per user is probably less hassle (and more useful) to store than the whole hash.

<comment><USER19> To avoid the problem of storing the token's hash, you have introduced:

      * parsing a structured cookie, vs a meaningless 128-bit string
      * securely storing and managing a secret HMAC key (which may be used to forge or modify credentials)
      * securely verifying an HMAC using a constant-time string comparision

So what, exactly, is the benefit of your proposal over mine? You've removed the (useful) distinction between an authentication token and the user's session. You've introduced significant additional complication and moving components. And you've increased the attack surface for security vulnerabilities. For what?

Doing all that to store a 32-bit integer is somehow _less_ hassle than hashing and storing a 128-bit string?

<comment><USER6> _you have introduced: parsing a structured cookie, vs a meaningless 128-bit string_

You're going to need some logic for dealing with session, user, etc. metadata. Stipulating that parsing metadata out of a cookie is in some sense harder than reading it from a DB, keeping it in the database requires more storage (in _addition_ to the 128-bit hash), more syncing among the various masters and slaves, and higher security. (An attacker who gets a DB dump can't see account metadata that isn't stored in the DB. Sure I'm storing a counter but what can he do with that?)

 _securely storing and managing a secret HMAC key_

How do you run an online service without doing key management? Whatever techniques you use for your other keys, use them for this key too. It isn't as if we need a separate key for each user.

 _You 've removed the (useful) distinction between an authentication token and the user's session._

I don't understand this claim. If I want to generate a new token for the current session, what's stopping me?

 _And you 've increased the attack surface for security vulnerabilities._

Because HMAC collisions are easy now? I've moved some things around, but I'd say there is a tradeoff between the CAP costs of the "store everything" technique you propose and the slightly more involved validation process I describe. It's cool if you prefer your method for your situation, but can't we admit that "I'm going to describe best practice" was a bit overstated?

<comment><USER19> > Because HMAC collisions are easy now?

When you get the details wrong? Relatively so. And even experienced people get this shit wrong more often than they get it right. Rails had this vulnerability. Google's KeyCzar had this vulnerability. The average, non- crypto-enthusiast has effectively zero chance of getting this right out of the box.

Comparing server-computed hashes is inherently safer and less error-prone than comparing client-controlled HMACs.

      * https://github.com/rails/rails/commit/5e6dab8b34152bc48c89032d20e5bda1511e28fb
      * http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/

> but can't we admit that "I'm going to describe best practice" was a bit > overstated?

Not when it _is_ accepted as best practice.

      * http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/
      * http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication

The only difference between my description is I do not store the username with the cookie; it is unnecessary and confers no discernable security benefit. I also avoid associating multiple remember-me tokens with a user, so an attacker who intercepts one must use it before the user next logs in.

Is your approach _wrong_? No. But it is more difficult for the average programmer to do securely and correctly, and confers few (if any) real benefits.

<comment><USER6> Thanks for the thoughtful responses!

</comment></comment></comment></comment></comment></comment><comment><USER23> Can someone explain how the example of the JSON encoded cookie could be used for XSS?

<comment><USER24> > What this means is that client script can access those cookies which means > that if you can get a piece of XSS onto the site – just as you can on the > Aussie Farmers site – you can steal cookies containing passwords if you can > get a customer to load the XSS payload

The author is saying that, putting the password in a cookie means that, if there is an XSS vulnerability somewhere, it can be trivially used to steal usernames and passwords, since the XSS can be used to inject code on the site that can grab the values from document.cookie and append them to a hidden iframe.</comment></comment>


Ask HN: How should you tag your phone number to reduce the number of robocalls? - <AUTHOR> When a business ask you what type of phone number did you just provide them, do you say home phone, cellphone or business phone? <comment><USER2> I really don't think you can avoid spam. At the end of the day, there are only so many phone numbers, and it's trivial to enumerate them to find those that are live. Spammers can simply cycle through lists.

Now if you're worried about more "targeted" spam, I would probably say do not pick the "business phone" option.

</comment><comment><USER3> The best and only way to avoid spam is to not pick up a number that you don't know. If it is someone important, they will leave a message. Rest are probably spam anyway.

</comment><comment><USER4> Not sure this helps but since using Google fi I have no spam as all those calls are labeled spam</comment>


The fall and rise of technology juggernauts - <AUTHOR> http://www.ft.com/intl/cms/s/0/6b859714-99ba-11e5-9228-87e603d47bdc.html <comment><USER2> [https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=we...](https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjK36q27cPJAhWJKJQKHTgwB9cQqQIIGzAA&url=http%3A%2F%2Fwww.ft.com%2Fcms%2Fs%2F0%2F6b859714-99ba-11e5-9228-87e603d47bdc.html&usg=AFQjCNEoWH8mpNSXgRV9XcrCMYBSg0UBGA&sig2=wfdZYlmuaW3WmIxoY1lGTQ&cad=rja)

</comment><comment><USER3> "Almost all of today's technology juggernauts formed before about 2008 required smallish amounts of capital. Google, for example, consumed only $8m before turning profitable. Maybe this means that sooner or later a new class of company will come into vogue — a rare species known as the profitable unicorn."

Unlikely as long as an investor led arms race is on.</comment>


StackMob Launches Hosted HTML5 Service - <AUTHOR> http://techcrunch.com/2012/02/15/bring-on-the-web-apps-stackmob-launches-hosted-html5-service/

<comment><USER2> What does this even mean?

Hosting "HTML5" is exactly the same as hosting "HTML".

</comment><comment><USER3> Very cool!</comment>


Pop Culture Architecture - <AUTHOR> http://deliberate-software.com/pop-culture-architecture/ <comment><USER2> As the article ultimately is a critique of Microservices as the current architecture du jour, the title should probably contain the word "Microservice" \- I would have gone for how the article's headlines are set up:

"Pop Culture Architecture - Example: Microservices"</comment>


Response from Senator Menendez (NJ) in regards to the PROTECT IP act - <AUTHOR>

Thank you for contacting me to express your views on S. 968, the Preventing Real Online Threats to Economic Creativity and Theft of Intellectual Property (PROTECT IP) Act.  Your opinion is very important to me, and I appreciate the opportunity to respond to you on this important issue.
The PROTECT IP Act will prohibit foreign websites, formerly operating outside the realm of U.S. law, from exploiting U.S. Internet service providers, payment processors, search engines, and ad placement services.
From enrolling in classes to communicating with our loved ones, the Internet can be a critical medium in the daily lives of Americans.  The Internet was created to be a venue for sharing information, and we must continue to make certain that consumers can access that content without discrimination.
However, the expansion of the Internet has also created more opportunities for copyright infringement.  Illegal downloads have been cited as one of the main causes for the decline in the music industry.  As new mediums of communication develop, it is imperative to discuss how to best protect privacy rights and intellectual property.  Rest assured that I will work with my colleagues in the Senate to best address this explosion of Internet content and issues that come with it, and ensure that intellectual property rights are protected while being mindful of those who access that content. <comment><USER2> Sen. Ron Wyden (D-OR) blocked the PROTECT IP act at the end of May.

"Wyden Places Hold on Protect IP Act

Overreaching Legislation Still Poses a Significant Threat to Internet Commerce, Innovation and Free Speech

Thursday, May 26, 2011

Washington, D.C. – Continuing his opposition to legislation that aims to protect intellectual property at the expense of free speech, technological innovation and the very foundations of the Internet, U.S. Senator Ron Wyden has issued the following statement announcing a hold on the motion to proceed to the Preventing Real Online Threats to Economic Creativity and Theft of Intellectual Property Act (PROTECT IP)...

more at [http://wyden.senate.gov/newsroom/press/release/?id=33a39533-...](http://wyden.senate.gov/newsroom/press/release/?id=33a39533-1b25-437b-ad1d-9039b44cde92)</comment>


An Intuitive Explanation of Fourier Theory - <AUTHOR> http://sharp.bu.edu/~slehar/fourier/fourier.html

<comment><USER2> Let's dumb it down a little further.

<http://www.complextoreal.com/chapters/fft1.pdf>

Check page two.

<comment><USER3> This is a good document. Signals and systems was one of the more interesting courses I took back in the day.

<comment><USER2> I graduated this past spring and after reading the stuff on this ladies site, I finally get what all those classes were about.

</comment></comment></comment><comment><USER4> I'm glad to see things like this on Hacker News. Sure it has relatively little to do with the regular topics, but it's the kind of interesting thing that I'd like to find from people who populate here.

Digital Signal Processing/Intro to Signal Processing has been one of the most interesting classes I've taken so far.

</comment><comment><USER5> Huh, I did signal processing and communication systems in college, and I don't recall anyone ever mentioning the lens thing. It says the distance from the image to the lens has to be "f" Is this the Nyquist frequency?

<comment><USER6> f is the focal length.

<comment><USER5> now I'm smacking myself. Yeah, should be obvious.

</comment></comment></comment><comment><USER6> If this stuff excites you, read the first chapter of Joe Goodman's book, _Introduction to Fourier Optics_. That's the book I read to really understand fourier transforms.

</comment><comment><USER7> I'm a bit confused. Is the DC term always in the center of 2D frequency image? If so, how does that provide any information about varying levels of background luminance?

<comment><USER6> The DC term is always at the lowest spatial frequency (DC.) So, if you plot your FT so that the DC term is in the middle, then the DC term is in the middle :)

It provides NO information about the varying levels, it tells you something like the sum of all the pixels / number of pixels. If you have a 10x10 uniform image, all pixels=1, the DC term will by 1/100.

Again, the DC Term is the absoloute lowest spatial frequency, hence it's DC.

<comment><USER8> The DC term also known as ao, Co, and Do (in the trigonometric, compact, and exponential forms) is the average value of the signal over its period (if it is periodic). It is the integral of the signal over one period divided by the period.</comment></comment></comment>


Expaflyr is now open for beta. All request are welcome - <AUTHOR> http://expaflyr.com/

<comment><AUTHOR> I'll be accepting all beta invitation request as soon as possible during the first days. I hope you guys can give me some advice since I'm new to this. Thanks !</comment>


Is China Taking the Lead in AI? - <AUTHOR> https://sloanreview.mit.edu/article/is-china-taking-the-lead-in-ai/ <comment><USER2> scary</comment>


Malformed cookie handling with document.cookie – who's responsible? - <AUTHOR> https://medium.com/@listenonrepeat/malformed-cookie-handling-with-document-cookie-whos-responsible-5968254d7d63 <comment><AUTHOR> Malformed cookie appears to be able to be set in all major browsers - [https://jsfiddle.net/xkqk954m/](https://jsfiddle.net/xkqk954m/)</comment>


The Money Laundry: Tracking Criminality of the Banking Industry - <AUTHOR> https://www.thelaundry.money/ <comment><USER2> Doesn't appear to include state-level settlements. For example, Deutsche Bank's latest settlement with NYS DFS.

</comment><comment><USER3> That quote on the header is fake from what I understand</comment>


Gears of war: When mechanical analog computers ruled the waves - <AUTHOR> http://arstechnica.com/information-technology/2014/03/gears-of-war-when-mechanical-analog-computers-ruled-the-waves/

<comment><USER2> An interesting article, but it annoys me when the author talks of analog computers having "an infinite level of resolution... because they use physical rather than digital inputs and outputs".

Physical machines have varying levels of tolerance, and this impacts the accuracy of calculations in just the same way as a truncated number in a digital system reduces accuracy.

It was a lot more interesting to read about the pros and cons of digital vs analog computers with respect to maintenance, reprogrammability, energy use, and reliability. It's a pity there wasn't a similarly in-depth account of the precision of each system.

<comment><USER3> Yep, it's embarrassing that this got published. Did the author just forget about mechanical tolerance? The random motion of molecules? Ambient sound waves? Electromagnetic noise?

I suppose it's forgivable that the author didn't think of these things but they should have run their technical article past a subject expert before publishing it. This isn't a nitpick, they screwed up the core concept of their article!

> there wasn't a similarly in-depth account of the precision of each system

That's because digital circuits won the "precision wars" so spectacularly that there was no need for comparison. On a digital computer, you can just keep adding bits to your datatype, doubling your precision with each bit, until you are happy. Bits cost almost nothing today (and very little 30 years ago) so you use as many as you need. If you underestimate how many you need, that's a planning problem, not a limitation of the digital technique. Meanwhile, the price of increasing the precision of an analog computer (mechanical, electrical, or fluidic) shoots up dramatically after a few decimal places and goes to infinity after a few more. That _is_ a limitation of the analog technique.

Here's a fun demo of how the digital nature of a circuit grants it complete noise immunity (within tolerances), unlike any analog circuit that could ever be built:

[https://www.youtube.com/watch?v=4TCnYYpZxEc#t=2806](https://www.youtube.com/watch?v=4TCnYYpZxEc#t=2806)

<comment><USER4> Make a circuit "digital" does not automagically make it more accurate, and you cannot "add bits" to a datatype to make your measurement more accurate.

Before a digital circuit can process a signal, it must first be quantized, an inherently analog process. Your digital data is only as good as your analog signal, plus inherent quantization noise[1]. In addition, any mixed-signal IC represents a design compromise between digital and analog constraints.

Any signal processing system is inherently limited by the SNR of its source signal. There is no point in building a more accurate converter than the noisiest component of your input data. In fact, when metrologists are trying achieve the maximum accuracy in their measurements, it is not uncommon to leave a test circuit on for days at a time, in order to reach a thermal equilibrium to minimize the seebeck effect[2].

And when engineers to need to make the most accurate of measurements, what do they turn to? Analog circuits. The world's most accurate voltage reference, the Kelvin-Varley Divider, dates back to the late 19th century[3]. For a modern example of a precision reference, see Jim William's excellent white paper, "Quantifying Silence"[4].

[1] [http://en.wikipedia.org/wiki/Quantization_(signal_processing...](http://en.wikipedia.org/wiki/Quantization_\(signal_processing\))

[2] [http://www.keithley.com/knowledgecenter/knowledgecenter_pdf/...](http://www.keithley.com/knowledgecenter/knowledgecenter_pdf/LowLevMsHandbk.pdf)

[3] [http://en.wikipedia.org/wiki/Kelvin%E2%80%93Varley_divider](http://en.wikipedia.org/wiki/Kelvin%E2%80%93Varley_divider)

[4] [http://cds.linear.com/docs/en/application- note/an124f.pdf](http://cds.linear.com/docs/en/application-note/an124f.pdf)

<comment><USER5> Very inexpensive digital circuits can perform calculations on their inputs with much higher precision than any analog calculator ever built. Weight, volume, power, or dollars, pick your cost.

Yes, you are limited by your measurement, but you are so limited when operating entirely within the analog domain as well. Therefore it makes sense to make your measurements as accurate as possible, quantize once, and be done with it. Keeping it in the analog domain merely allows more points for noise to enter the picture.

</comment></comment></comment></comment><comment><USER6> Obligatory link to youtube video of a 1950s training video on the mechanical fire control computers (which I stole from HN last time this sort of topic came up):

[https://www.youtube.com/watch?v=s1i-dnAH9Y4](https://www.youtube.com/watch?v=s1i-dnAH9Y4)

edit: This video is the same footage featured throughout the article, in fact.

<comment><USER7> Ah... You beat me to it!

</comment></comment><comment><USER8> Some of these analogue computers are pretty amazing things.

I can kinda get my head around slow moving ships being tracked by a mechanical computer, but the Russian ZSU-23-4 Shilka self propelled anti-aircraft artillery vehicle used an electro mechanical gun aiming computer in the 60s and 70s.

A mechanical computer that can track a supersonic rapidly manoeuvring jet aircraft by radar, and adjust the aim of its guns quickly enough and accurately enough to score hits. It's amazing what can be achieved.

</comment><comment><USER7> Interestingly, several months ago I came across the following 1953 training video dealing with this same subject.

[http://youtu.be/s1i-dnAH9Y4](http://youtu.be/s1i-dnAH9Y4)

</comment><comment><USER9> off topic, but did anyone pay attention the Juniper deception force adds they sport?

This line of one commercial just blew my mind: 'the less they know, the safer they are' ...can a security oriented company actually get away with saying that?!

</comment><comment><USER10> No not about the video game.</comment>


The US schools with their own police - <AUTHOR> http://www.guardian.co.uk/world/2012/jan/09/texas-police-schools

<comment><USER2> Coming from Germany, I could only shake my head about this (imhl) totally stupid state-behaviour. Sorry, but having studied teaching for 2 years, before switching the subject and having teached a lot in non-school environments, I can't possibly imagine any argument supporting this legelative behavior.

Sorry, to say that, but I am so glad, that I grew up in another country, in another time.

If I were a parent, I would strongly think of relocation abroad. out of such a system.

Sorry, if sounding rude. But I had to try real hard, not to use any swear words.</comment>


Be always on holidays with The Holiday Start-Up business model - <AUTHOR> http://linuxforme.com/the-holiday-startup.html

<comment><AUTHOR> Any opinions?</comment>


Bradley Manning and the "Hacker Madness" Scare Tactic - <AUTHOR> http://www.slate.com/blogs/future_tense/2013/07/31/bradley_manning_and_the_hacker_madness_scare_tactic.html

<comment><AUTHOR> 'In the Manning case, the prosecution used Manning's use of a standard, more than 15-year-old Unix program called Wget to collect information, as if it were a dark and nefarious technique. Of course, anyone who has ever called up this utility on a Unix machine, which at this point is likely millions of ordinary Americans, knows that this program is no more scary or spectacular (and far less powerful) than a simple Google search. Yet the court apparently didn't know this and seemed swayed by it.'

Our legal system needs for IT competence …</comment>


Visualized user base using Three.js and WebGL - <AUTHOR> https://leansync.com/status

<comment><USER2> Anyone interested in building something based on this should think twice. I just started building my own version of the globe and it has crashed my computer twice already. (brand new macbook pro retina using chrome). Something related to chrome and this webgl isn't playing nice together. Force quit doesn't even save it. Needs a hard reboot.

<comment><AUTHOR> Macbook Pro 2012 here. I only experienced one issue which is somehow similar and caused by resuming from sleep when the webgl tab is still the active one. Then Chrome and everything else from MacOS will hang for 1 minute until Chrome figures out that WebGL crashed. But I do not have to hard reset for recovery. Just wait a minute....

I always close the tab before closing the lid.

<comment><USER2> For me it happened when I have it in a background tab. If I switch away for a while and then click back on the tab it will freeze.

<comment><AUTHOR> Just happened to me as well a few seconds ago (I actually had even 3 instances open in the background and no sleep/hibernation involved). But again just waiting for about 1 min finally led to a responsive system again.

</comment></comment></comment></comment><comment><USER3> Is there a possibility of interaction with the provided data on the globe?

Also I would really like to see the "address network", e.g. lines between the dots.

<comment><USER4> It all happens inside the DOM, whit all interaction the browser provides.

</comment></comment><comment><USER5> So how much of this is open source and available? I can see lots of uses for something that looks this good and to which you can overlay your own information.

<comment><AUTHOR> To be fair: I took one of the Google Chrome Experiments (can't find the exact demo right now but here's where they are hosted: <http://www.chromeexperiments.com/webgl/>), stripped it down, customized it (using particles instead of animated lines) and pump the geo data into the globe.

So I'd say with Three.js, Google's code for the Globe it's in the end just a couple of Javascript lines for the page and the customization of the globe. I'd say 98% is open source from a technical perspective.

<comment><USER6> This one I imagine: <http://workshop.chromeexperiments.com/cloudglobe/>

<comment><AUTHOR> It's a similar one but not exactly the one I started off. I used the one which shows the world population for 3 predefined years.

<comment><USER6> <http://www.chromeexperiments.com/globe>

<comment><AUTHOR> Yes, that's it.

</comment></comment></comment></comment></comment></comment><comment><USER7> Adding touch events would be nice. Using Chrome beta for android and I can see the globe, but can't interact easily.

<comment><AUTHOR> Absolutely. I had the same thought when checking with my Nexus S. Not sure how easy/difficult it is to implement though as touch events are always a bit different than mouse controls.

</comment></comment><comment><AUTHOR> Position data is based on user-provided addresses (city and country only).

</comment><comment><USER8> Hm, lot of users are in the ocean (after I rotated the globe?)

<comment><AUTHOR> Seriously ? Let's hope they can swim :)

It happened to me one or two times that I thought the same because the dark color of the sea looks somehow more solid than the continents.

If it's really a rendering bug could you share a screenshot ?

</comment></comment><comment><USER9> It is beautiful. I really like this :-)

<comment><AUTHOR> Thank you. Appreciated ;)

<comment><USER10> _cough_ _cough_

<comment><AUTHOR> Anything I did wrong ? I think I gave your library all the credits it deserves by naming it in the title and providing details where the used parts came from in the comments below.

Or is it that I used the most trivial particle rendering ? :)

<comment><USER10> I did the original WebGL Globe (texture, atmosphere shader, interaction, ...). Just sounded like you were taking credit for the overall aesthetics. As far as I can see, aesthetic-wise the difference is that you didn't pass the height for the cubes.

I don't really mind though, the whole point was to get people to use the platform. Just found it funny :)

<comment><AUTHOR> I see. Well quite some work went into upgrading the globe.js to Three.js rev 56 (API changes and debugging related errors) and the integration stuff (creating the geo data) under the hood. Plus using particles instead of the cubes (which was rather easy). So although it still has definitely a lot from your version (globe and three.js) it's definitely not just a cheap and quick copy for ripping off credits ;) That's why I appreciated the comment. Consider a big part of the credit as yours :)

Just a side-node: the API docs were the biggest obstacle in the whole process. W.r.t to platform usage I think this would be one of the top prio things to get even more people using Three.js.

<comment><USER10> Yup. Working on that... also need to update WebGL Globe so you don't have to :)</comment></comment></comment></comment></comment></comment></comment>


Everyone on HN, thanks a million - <AUTHOR>

Not really sure how to thank everyone at the same time, so here goes. Thanks a million for existing!
We adopted the position to release stuff as soon as we're no longer embarrassed about it, and we did that yesterday with the wysiwyg editor for bootstrap. After an announcement on HN, a ton of fantastically useful suggestions, comments (and github pull requests) followed and the whole thing is much much better now. I stayed up until 5AM merging all the requests, implementing suggestions and fixing the problems that you guys reported.
There's only 3 of us working really on this project and we don't have the time or the resources to properly test in all possible OS/browser combinations. With roughly 10K people according to our statistics looking at this, complaining, proposing suggestions, commenting on code etc, the community on this site provided a fantastically useful ... dare I say 'service'?
As the project is opensource and bootstrapped, paying someone else to do this kind of testing is way over our budget, not to mention that no testing consultancy out there would provide git pull requests on everything from code styling to browser tweaks.
Thanks again. We'll be back with more half-baked opensource ideas soon! <comment><USER2> <http://mindmup.github.io/bootstrap-wysiwyg/>

</comment><comment><USER3> It's also okay to release things when you're embarrassed. Actually, if you're not embarrassed you likely* waited too long.

</comment><comment><USER4> Didn't see the original post. Nice work, don't let it get bloated.</comment>


Sell Ice Cream, Not Cream and Ice - <AUTHOR> http://www.currentlyobsessed.com/2010/03/13/sell-ice-cream-not-cream-and-ice/

<comment><USER2> The internet is made for lead-gen...

One of my favorite businesses on the planet buys adwords ads for specific car searches ("blue honda accord 1997") and offers the searcher three competitive quotes-- just fill out a form. They then sell these leads to three car deals who have the vehicle in question for $20/per lead. Last I heard they were bidding on 750,000 adwords and making millions per month.

<comment><USER3> do you have any link to that landing pages?

<comment><USER4> Just google a late model used car. Click on the ads on the right side of the SERP.

</comment></comment></comment><comment><USER5> It depends on what your goal is. If you just want to make money, there are a lot of boring (IMO) ways to do that.

On the other hand, I (and I'm sure many other HNers as well) like to _make cool stuff._ It would be nice if it turned into cash, but I would prefer to enjoy the stuff I code instead of hacking some small corner of the Internet for cash... that certainly takes innovative thinking, which I really respect, but it's just not interesting to me.

<comment><USER6> I think for me, before visiting LeadsCon, it was never so crystal clear that you could have a business _without_ much product or technology. I've seen a lot of people pursue tech or product with business being an afterthought and it is interesting to see the other extreme.

In the end I'd have to agree that (for me anyway) happiness isn't going to come without a health combination of all three elements.</comment></comment>


Is Cobol holding you hostage with Math? - <AUTHOR> https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b <comment><USER2> There is a little more to it than "languages don't provide decimal or fixed point". Both Java and Python provide decimal implementations as part of their standard libraries, and languages don't provide fixed-point as it's largely trivial: "just do integer operations and scale them appropriately".

The problem is that fixed point is ambiguous: there are multiple ways to do rounding (unlike floating point which has been largely standardised since the early 90s). In fact, the COBOL rounding rules are rather complicated: [https://stackoverflow.com/a/30215718/392585](https://stackoverflow.com/a/30215718/392585)

This has some interesting consequences:

I know of an insurance company where there were difficulties trying to replicate the exact premium calculation (which was done on a mainframe in COBOL), part of which involved taking 1.01 to the power of a positive integer (which depended on various risk factors of the policy).

COBOL was not really intended for numerical work, and so doesn't have a "pow" function (or at least this version didn't): instead, it turns out that the programmer had used a simple loop which would iteratively multiply a variable by 1.01, incurring round-off at each iteration. So the only way to emulate it exactly was to use the same arithmetic _and_ the same ugly hacks used in the original software.

<comment><USER3> Why replicate the same calculation with the same errors? Shouldn't it be specified as a pure math formula somewhere, probably in the contacts? So they did it slightly wrong for a long time, but why would that be the reference instead of the contract.

<comment><USER4> It hurts even when there is no explicit contract. After integrating a couple of factories we found out that not precision is king, but stability is. Too many processes depend on each other, from small to big, and if you're lucky to mess it up without immediate notice from workers (which happens rarely, since they give a good friction on this slippery surface), costs to fix it may outprice the precision gains for years. Essentially, no matter what the hw/sw platform is, business "ABI" is locked into algorithms used, and rounding/floating/fixed is only one of these. I've seen [edit:algorithm-wise] wrong cost-price distributions, penalty calculations and so on, that were a foundation for chains of table-based and gut-based decision making. Things simply don't add up for everyone, not to mention how hard is turning a switch for the entire org that runs e.g. 24/7 and/or has unfinished production shifts.

That was a knowledge I wish I already had back then, since these sorts of projects provided a lot of frustration, insecurities and expenses that you never could imagine working as software half-pm/half-coder. At some point you start to doubt whether you're skilled for this job or just a loser with a keyboard.

Minor/simple processes lack that cohesion and can be fixed or left as-is without much trouble though.

<comment><USER5> The requirements doc or contract generated to create the software almost always has a lot less thought and a lot less debugging and adjusting in it than the actual software and processes subsequently built around it that have been running that way for the last decade oe three.

Can you imagine if, suddenly, an insurer had a 1% shift in premiums overnight because someone fixed the rounding algorithm to comply with the 1983 spec that had been mis-implemented in COBOL?

</comment></comment></comment></comment><comment><USER6> I had many adventures interfacing other stuff with mostly MicroFocus COBOL. Some personal observations:

* The COBOL knowledge shortage is a myth. I got pretty good at reading their code and giving the COBOL guys small bugfixes while most of the time not even having the compiler at my disposal. Learning COBOL the language is pretty easy, even if actually doing something with it is slow, verbose and bureaucratic. Training new devs will never be the problem if a company and a person were found willing.

* But training is the problem, politically. Why would a dev learn a language that is a bad mark on the resume while being paid less? Why would management want to risk their career by pushing forward an evolutionary dead end?

* And the language is a dead end. NLS in Cobol is really weak, which means it's a no-go for anything global. Fixed width everywhere causes massive technical dept as there is a tendency to 'cheap out on bytes', after which you're completely locked in by the required data migration everywhere. Cobol culture is rife with obsolete practices. One program equals one file (and some libs managed by other cobol devs) most of the time, so methods of a few thousand lines are the norm.

* The real value of the COBOL devs I know is that they are business people first, technical second. They know their business, deep. They've seen everything and smell if an idea is good or bad. Because of this, they run rings around younger devs and analists when you look at business value, especially if said devs/analists are outside consultants that knknow basically nothing and just code what's been fed to them. While training for Cobol is easy, training for the actual business is close to impossible.

* Another Cobol upside is being a technical dinosaur: The Enterprise Architecture Astronauts or bungee-boss CEO won't touch it with a 10 feet pole, so there is no new great architectural vision every other year. Lava flow architecture is not that huge a problem. Besides, your code base lived more than 40 years and is already ugly as hell. The technological investment and training cost have been made long ago. Cobol devs can just convert problem to program without weird technological surprises, integration hell, or architectural distractions.

Don't get me wrong. I'm very glad I don't do COBOL. But its not burn-it-down- and-start-over-now bad either.

<comment><USER7> Keen observations.

I worked on the periphery of a mainframe, COBOL modernization project. Basically an attempted rewrite. Utter failure.

My hunch at the time was the better technical strategy would have been to run all that stuff within an emulator (to get off the nearly dead mainframe) and to focus on process improvements (eg source control, repeatable builds, schema management). But otherwise leave the legacy code in place.

</comment></comment><comment><USER8> Daily reminder: floats are emulated reals.

Money values are rationals, not reals.

Languages need to support the full number stack, including the rationals!

"Floating point decimal" is wrong and the worst of both worlds. Unless you live in the USA, you need to do currency conversions anyways, and those aren't decimal.

<comment><USER9> Floating point numbers are all rational. Given that rational numbers are a countable subset of real numbers, I think it's inaccurate to say that floats are somehow "emulated reals" as opposed to rationals. The radix of a floating point number relates to the quotient of a rational number. For example in decimal floating point significand-base-exponent form, 1.23 is 123 * 10^-2 or 123/100.

<comment><USER10> All floating point numbers are rational, but not all rational numbers are floating-point, including very simple ones like 1/3, and ones common in finance like 1/100, which is the point.

<comment><USER9> 1/3 and 1/100 are perfectly representable using floating point. Sure, I've never seen fp in base 3 in the wild, but base 10 isn't unusual for the exact reason you're pointing out.

So what I see is a conclusion that floating point is "emulated reals" as opposed to rationals, despite all floating point numbers being rational numbers and that decimal floating point is wrong and "the worst of both worlds", but I don't see a valid argument for it.

</comment></comment></comment></comment><comment><USER11> Java has BigDecimal in the standard library. That gives you arbitrary precision. Also, using a double instead of a float gives you a bit better precision. The performance hit of using double instead of float on modern hardware is not something that should be a showstopper.

I don't get the argument about libraries and performance. We're talking about companies using emulators of ancient hardware to run decades old software. Pulling in some library is a complete non issue from a performance point of view.

Speaking of hardware, that is magnitudes faster than anything imaginable when most cobol was first written. Performance is not the key concern here.

<comment><USER12> Ergonomics of using a feature plays a big role. The was a famous example when a programmer did something like

bigDecimal.doubleValue() + bigDecimal2.doubleValue()

just because Java does not have operator overloading and using methods instead of familiar operators was ugly.

<comment><USER13> Are you saying that personal sense of esthetics trumps correctness?

Anyway, BigDecimal has an add() method (overloaded for rounding behaviour)

bdResult = bd1.add( bd2 )

<comment><USER14> >BigDecimal has an add() method

Using it for formulas makes for wonderful code.

Try

        y = (5x^3 - 3x^2 + 7x + 1)/(3x^2 - 7x)

See how readable that is using methods like .add()

Side note: the notation we have is not that old; but as soon as people actually started working with polynomials, they invented notation that makes it sane.

That's to say, Java's .add() is _so_ 1400's.

<comment><USER13> There is no argument from me that a + b is more readable than a.add(b). Java founding fathers (Gosling?) decided against operator overloading sighting the mess it allowed to created in other languages. The mathematical notations for spelling out polynomials has been optimized over some time - Java being a general purpose programming language has other fish to fry.

There are languages that allow for a cleaner way to express mathematical statements, this is valid Julia:

        julia> p(x) = (5x^3 - 3x^2 + 7x + 1)/(3x^2 - 7x)
        p (generic function with 1 method)

        julia> p(1 + 2im)
        2.4 + 0.2im

</comment></comment></comment></comment></comment><comment><USER15> While much of this was interesting and perhaps true, I don't really think it's why COBOL is still being used. It's still being used because it works for cases where the "BO" part of "COBOL" is relevant, in domains where the potential downside of migrating are very, very large (if it goes badly), and the potential upside is actually pretty limited. Best case, your migration doesn't get noticed as causing any problems, and now your programmers keep leaving for other industries because their skills are more general. That's a whole lot of scary scenarios on one side of the scale, against a pretty meager upside on the other side of the scale.

<comment><USER16> > upside is actually pretty limited.

You're selling the upside short. Having a pool of software devs to draw from who are familiar with the language and typical deployments is a big deal.

The next y2k crisis for this industry will be in a decade or three when there's few left who have experience here.

<comment><USER17> _Having a pool of software devs to draw from_

Well, in a world where everyone is self-taught from what's trending at the moment. In the old days if companies needed someone with particular skills they would train them and make an effort to retain them. Now the cost and the risk has all been pushed onto the employee.

It should be a simple equation: cost of training vs cost of rewriting every 2-3 years...

</comment></comment></comment><comment><USER18> I'd like to point out that COBOL generates rather efficient fixed-point math code on IBM mainframes because those mainframes have a dedicated set of machine-level instructions that deal with fixed-point math.

The data type used is "Packed Decimal" where each nybble in a string of bytes represents a digit, except the last nybble. The last nybble describes the sign of the overall number. It's similar to BCD with a sign-nybble at the end.

Here's a list of the Packed Decimal instructions with a description of each.

[http://faculty.cs.niu.edu/~byrnes/csci360/notes/360pack.htm](http://faculty.cs.niu.edu/~byrnes/csci360/notes/360pack.htm)

<comment><USER19> Interesting, but I assume those machines are dead?

<comment><USER18> No, these instructions are still present in IBM's z/Architecture.

</comment></comment></comment><comment><USER20> The main reason COBOL is still around is not math.

The main reason is that business and domain logic exists only as COBOL logic. COBOL devs are ~60 on average, and many people who wrote system requirements are probably already dead. Existing code runs millions or billions of dollars worth of transactions often based on arcane financial rules and internal regulations. Good luck untangling that without stopping the business and without losing that functionality.

Relevant links:

\- [https://uk.reuters.com/article/uk-usa-banks-cobol- idUKKBN17C...](https://uk.reuters.com/article/uk-usa-banks-cobol- idUKKBN17C0DZ)

\- Reverse engineering a factory: <if someone can find a link to this fascinating story, please help me :)>

</comment><comment><USER21>
        PIC 9(3)V9(15).

is really shorthand for

        PICTURE 999V999999999999999.

Fixed point numbers are declared like that.

COBOL is a decent language for business logic. Especially when money amounts are involved. Certainly better than PHP.

<comment><USER22> The "picture" syntax for records was an _excellent_ idea that should be tried again in more modern languages.

</comment></comment><comment><USER23> C#/.NET has the built-in decimal type which is technically floating point, but it has a 96-bit mantissa and a base-10 exponent which makes it behave similarly to fixed point numbers.

<comment><USER24> The same type existed in classic Visual Basic as well. It's part of the set of basic COM types in Windows.

</comment></comment><comment><USER25> The statement about Decimal being an import is a garbage, misleading statement. Decimal IS PART OF THE STANDARD LIBRARY!!!! It might not be in the global context, but that is a far cry from having to install an external library which this article makes it seem like.

Also, performance wise COBOL might be faster on a single machine, but good like trying to scale it out. Plus, a distributed architecture can make it easier to deploy software and hardware upgrades since you can generally take out a few nodes without bringing down the whole system.

I'm not saying all this code should be rewritten. If you have some code out in the wild that works, you should always weigh carefully the risks in terms of cost and potential new bugs before doing a rewrite. However, lack of fixed point is a lousy excuse to not upgrade.

<comment><USER17> _good like trying to scale it out_

COBOL demonstrably scales sufficiently to run the entire global economy, so no luck required.

<comment><USER26> To be fair, the parent did specify scaling "out" and went on to claim other benefits of a distributed architecture, which are not even unique to that architecture [1].

Of course, that comment's definition of "single machine" ignores the intrinsically distributed nature of mainframe architectures, on which on might reasonably suppose COBOL would run.

[1] e.g. a "single machine" only needs a single replica for those benefits. Sure, even that's a _form_ of distributed architecture, potentially subject to at least some of the Fallacies Of Distributed Computing, but I'm confident that's not what was meant.

<comment><USER17> Indeed. I am no fan of IBM the company due to the poor way they treat workers they are laying off, and the way they keep winning big government contracts despite their many many high profile failures is deeply suspicious. And their cloud offerings are a joke.

But I won't deny that Sysplex has been proven to work in the field.

</comment></comment></comment></comment><comment><USER27> Couldn't you at least port your COBOL to C? It's also statically typed, compiled, there are high-performance libraries that support arbitrary levels of numeric precision (GNU GMP), and every engineer trained in the last 20 years at least has some C experience.

<comment><USER17> _every engineer trained in the last 20 years at least has some C experience._

I think that's a massive exaggeration. Most people these days think JavaScript without a framework is "bare metal".

<comment><USER28> One should be hesitant to call those people engineers.

<comment><USER29> One should be hesitant to label computer programmers as "engineers".

Gatekeeping is fun.

<comment><USER30> Firstly, it's not unjustified to say that someone who thinks vanilla JavaScript is "bare metal" obviously doesn't know what they're talking about. Secondly, as a software-engineer-in-training, I agree - software "engineering" doesn't have much in common with other engineering, but I think that's a good thing for software.

<comment><USER31> Could you imagine if software engineers DID do rigorous engineering practices?

It would be mayhem! Projects would just NEVER FINISH.

<comment><USER28> But when they do finish, it will stand the test of time!

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> I'm curious to see how languages with support for rational types would handle this problem. (E.g. Scheme, Clojure, Haskell) Seems to me that they would eliminate the round-off problem entirely for a great number of commonly-faced applications in the finance world. (So easy to use `x/100`.)

<comment><USER33> In Common Lisp:

      (defun r1 (y z)
        (- 108 (/ (- 815 (/ 1500 z)) y)))

      (defun r (n &aux (l '(4 425/100)))
        (loop for i from 2 upto (1+ n)
              do (setf l (append l
                                 (list (r1 (elt l (- i 1))
                                           (elt l (- i 2)))))))
        l)

      CL-USER 68 > (loop for e in (r 20) and  i below 20
                         do (format t
                                    "~%~3a~20,15f"
                                    i
                                    (float e 1.0d0)))

      0     4.000000000000000
      1     4.250000000000000
      2     4.470588235294118
      3     4.644736842105263
      4     4.770538243626063
      5     4.855700712589074
      6     4.910847499082793
      7     4.945537404123916
      8     4.966962581762701
      9     4.980045701355631
      10    4.987979448478392
      11    4.992770288062068
      12    4.995655891506634
      13    4.997391268381344
      14    4.998433943944817
      15    4.999060071970894
      16    4.999435937146839
      17    4.999661524103767
      18    4.999796900713418
      19    4.999878135477931

</comment></comment><comment><USER34> I'm doing an internship at a logistics company, and we're building projects in .NET. They're keeping us away from the Cobol, but part of me really wants to learn it. There are a lot of Senior Devs who only work in Cobol, and they're getting close to retiring. I feel like it might be a good trade to be an expert in Cobol and .NET, since most enterprises are going to have some of both.

Any Cobol free-lancers hanging out here? Whats you're job perspectives like? Are you filthy rich?

<comment><USER35> I investigated this recently after I read another article about COBOL [1]. My conclusion is that it's a much better idea to learn modern languages and frameworks, and work with web/mobile applications, or machine learning. COBOL does not paid very well for the average developer. I saw COBOL jobs advertised with salaries around $50k to $80k. Another article [2] talked about how "experienced COBOL programmers can earn more than $100 an hour" to fix up old bank software. That's a reasonable hourly rate but nothing amazing. An experienced web/mobile developer will earn more than that, and the work will be much more enjoyable: modern language and tooling, modern software development practices (e.g. test-driven development), plenty of libraries, lots of answers on StackOverflow, etc.

[1] [https://qz.com/email/quartz- obsession/1316505/](https://qz.com/email/quartz-obsession/1316505/)

[2] [https://www.reuters.com/article/us-usa-banks-cobol- idUSKBN17...](https://www.reuters.com/article/us-usa-banks-cobol- idUSKBN17C0D8)

<comment><USER36> This is the dirty secret, and I think it's largely because COBOL devs don't create that much value. What I mean is, those systems are in place, have largely worked for years, and only need a bug fix here and there. For those, you can get some retired guy back as a contractor and it's still way cheaper than a dedicated COBOL dev. I don't think I know of anywhere that is writing big new projects in COBOL (I'd love to hear of counter-examples). Instead it seems like they've found ways of bolting on extensions as part of some middleware.

So what's interesting instead is where are the rumours of a COBOL dev shortage coming from?

</comment></comment></comment><comment> le-mark Good article, very informative. You used to hear the "can't do the math" excuse a lot around y2k with respect to migrating these systems to something (anything?) else. You don't hear as much nowadays. I think a lot of that boiled down to properly handling rounding, which is non trivial as other posters have mentioned.

A lot of commenters here are missing the point about decimal library support. The point is not that language x does or doesn't have some sort of support for decimal math, the point is it's not _native support_. Even if language x supports a decimal type, back by a byte[] (for example) there is still function/method call overhead for basic operations (+-/*). For high volume stuff she's talking about, it adds up, fast.

I think there are a few languges with similar native decimal support; ada and pl/1 iirc.

Cobol is an albatross that's going to be with us for a loooong time to come.

<comment><USER37> >there is still function/method call overhead for basic operations (+-/*). For high volume stuff she's talking about, it adds up, fast.

With the right style of C++ programming (trait/templated focused instead of inheritance) or Rust's static-dispatch-by-default it should be no more of a performance impact than 'native' Cobol calls after the compiler optimizes it.

</comment></comment><comment><USER38> Confusion about many of the comments.

COBOL can be used for online system and performance wise a 16 MB (M not G) even for a small mainframe (PC on P5!) can support 1000 uses easily. Whilst it is totally dated, no one support and IBM charge a lot - None is related to cobol, or cics or ims ...

For the floating point part ... not using those. Most of the attention is to handle and agree upon how to do exact calc inclding reminder. No rounding per sec in the system. Nothing lose. Not even one cent. Hence, floating point ...

And change it to c, ada etc. It is English programming language. The hard part is to translate and test. And explain to use decmical as exact number.

... lots of project has successfully migrated. But unless you get that right - cobol is not slow and it is an exact number computation with in depth business know-how, good luck.

</comment><comment><USER39> # Short version

The Muller's Recurrence is a mathematical problem that will converge to 5 only with precise arithmetics. This has nothing to do with COBOL and nothing to do with floating and fixed point arithmetics as such. The more precision your arithmetics has, the closer you get to 5 before departing and eventually converging to 100. Python's fixed point package has 23 decimal points of precision by default, whereas normal 64bit floating point has about 16 decimal points. If you increase your precision, you can linger longer near 5, but eventually you will diverge and then converge to 100.

# Long version

What's going on here is that someone has tried to solve the roots of the polynomial

        x^3 - 108 x^2 + 815 x - 1500,

which is equal to

        (x - 3)(x - 5)(x - 100).

So the roots are 3, 5 and 100. We can derive a two-point iteration method by

        x^3 = 108 x^2 - 815 x + 1500
        x^2 = 108 x - 815 + 1500/z
        x   = 108 - (815 - 1500/z)/y

where y = x_{n-1} and z = x_{n-2}. But at this point, we don't know yet whether this method will converge, and if yes, to which roots.

This iteration method can be seen as a map F from R^2 to R^2:

        F(y,z) = (108 - (815 - 1500/z)/y, y).

The roots of the polynomial are 3,5 and 100, so we know that this map F has fixed points (3,3), (5,5) and (100,100). Looking at the derivative of F (meaning the Jacobian matrix) we can see that the eigenvalues of the Jacobian at the fixed points are 100/3 and 5/3, 20 and 3/5, 1/20 and 3/100.

So (3,3) is a repulsive fixed point (both eigenvalues > 1), any small deviation from this fixed point will be amplified when the map F is applied iteratively. (100,100) is an attracting fixed point (both eigenvalues < 1). And (5,5) has one eigenvalue much larger than 1, and one slightly less than 1. So this fixed point is attracting only when approached from a specific direction.

Kahan [1, page 3] outlines a method to find sequences that converge to 5. We can choose beta and gamma freely in his method (Kahan has different values for the coefficients of the polynomial, though) and with lots of algebra (took me 2 pages with pen and paper) we can eliminate the beta and gamma and get to the bottom of it. What it comes down to, is that for any 3 < z < 5, choose y = 8 - 15/z, and this pair z,y will start a sequence that converges to 5. But only if you have precise arithmetics with no rounding errors.

For the big picture, we have this map F, you can try to plot a 2D vector field of F or rather F(x,y) - (x,y) to see the steps. Almost any point in the space will start a trajectory that will converge to (100,100), except (3,3) and (5,5) are stable points themselves, and then there is this peculiar small segment of a curve from (3,3) to (5,5), if we start exactly on that curve and use exact arithmetics, we converge to (5,5).

Now that we understand the mathematics, we can conclude:

Any iteration with only finite precision will, at every step, accrue rounding errors and step by step end up further and further away from the mathematical curve, inevitably leading to finally converging to (100,100). Using higher precision arithmetics, we can initially get the semblance of closing in to (5,5), but eventually we will reach the limit of our precision, and further steps will take us away from (5,5) and then converge to (100,100).

The blog post is maybe a little misleading. This has nothing to do with COBOL and nothing to do with fixed point arithmetics. It just happens that by default Python's Decimal package has more precision (28 decimal places) than 64bit floating point (53 binary places, so around 16 decimals). Any iteration, any finite precision no matter how much, run it long enough and it will eventually diverge away from 5 and then converge to 100.

Specifically, if you were to choose floating point arithmetic that uses higher precision than the fixed point arithmetic, then the floating point would "outperform" the fixed point, in the sense of closing in nearer to 5 before going astray.

[1] [https://people.eecs.berkeley.edu/~wkahan/Math128/M128Bsoln09...](https://people.eecs.berkeley.edu/~wkahan/Math128/M128Bsoln09Feb04.pdf)

<comment><USER39> In the light of the mathematics above, it is really quite artificial to declare that 5 would be the correct answer. This is not an optimization problem, but with some misuse of language I am tempted to say that 100 is the global optimum, and only by balancing on a knife's edge is it even possible to approach the local optimum of 5. And 3 is the tip of a needle.

So we could just say that arithmetics with less precision is better, here, because it reaches the global optimum quicker? Whereas higher precision arithmetic is "lingers" in the "orbit" of 5 a little longer.

</comment></comment><comment><USER40> Delphi has Currency type, and I heard that it is largely responsible for Delphi's hold on financial software.

</comment><comment><USER41> Wow. I didn't even finish reading the whole post, but just the beginnings of the post gave me a much better functioning intuition about how floating point works! Thank you Marienne!

</comment><comment><USER42> If it's decimal currency, why not process amounts as integer cents?

<comment><USER17> _why not process amounts as integer cents?_

Trading is actually done in "basis points" or "pips" which are 1/100 of a cent

<comment><USER42> Fine, integer centicents or microcents or whatever is required for the application at hand.

<comment><USER17> Right, my point being that some of this stuff is non-obvious and there is often a reason "why not"

</comment></comment></comment></comment><comment><USER43> I recently went through our Perl, Python, PHP, and JavaScript code making sure sales tax and VAT calculations were right, particular when the sale amount and tax rate were both in floating point (damn legacy code...). During the course of this, I found some good test cases. They are given below.

Let R = the tax rate x 10000, in a jurisdiction where the tax rate is an integral multiple of 0.0001. Note that R is an integer.

Let A = the sale amount x 100, in a jurisdiction where prices are an integral multiple of 0.01. I.e., in the US, A is the sale amount in cents. Note that A is an integer.

Let T = the tax * 100, or in US terms, the tax in cents. Note that T is an integer.

If you can arrange to keep your amounts in cents and your rates in the x 10000 form (or whatever is appropriate for the jurisdiction), then you only need integers and things are simple:

      def tax(A, R):
        T = (A * R + 5000)//10000
        return T

You probably have to go from cents to dollars somewhere, such as when informing the user of prices, taxes, and totals. I believe that integer/100, rounded to 2 places in all cases and printed in all of the above languages will be correct, but I kind of cheated and for display results I treated it as a string manipulation problem, not a number problem (which also takes care of making sure amounts less than $1 have a leading 0, and that multiples of 0.1 have a trailing zero) [1].

If you don't have the amount and rate in the nice integer forms above, but rather have them in floating point such as you get from parsing a string like 12.34 (for a price of $12.34) or 0.086 (for a tax of 8.6%), here are three functions to return the tax in cents that might seem reasonable, and you might think are properly handling rounding:

      def tax_f1(amt, rate):
        tax = round(amt * rate,2)
        return round(tax * 100)

      def tax_f2(amt, rate):
        return round(amt*rate*100)

      def tax_f3(amt, rate):
        return round(amt*rate*100+.5)

Alas, they are all flawed.

        input        f1  f2  f3
      </comment><comment></comment><comment>- --- --- ---
       1% of $21.50  21  22  22 ( 22 is right)
       3% of $21.50  65  64  65 ( 65 is right)
       6% of $21.50 129 129 130 (129 is right)
      10% of $21.15 211 211 212 (212 is right)

It does work to convert from floating point to the x 100 and x 10000 integer form, and then use the integer function given earlier:

      def tax_f4(amt, rate):
        amt = round(amt * 100)
        rate = round(rate * 10000)
        tax = (amt * rate + 5000)//10000
        return tax

      def tax_f5(amt, rate):
        amt = int(amt * 100 + .5)
        rate = int(rate * 10000 + .5)
        tax = (amt * rate + 5000)//10000
        return tax

Both of those are right in the test cases above, and I believe in all other cases (well, all other cases where everything is positive...). For Python I've done brute force testing of all combinations of amount = 0.01 to 25.00 in steps of 0.01 and rate = 0.0001 to 1.0000 in steps of 0.0001 to verify that.

I've also done a brute force C test that involved sscanf(..., "%lf",...) of strings of the form "0.ddd...ddd" where the 'd' are decimal digits, and there are up to 9 of them. In all cases multiplying the resulting double by 10^k, where k is the number of digits after the decimal point and called round() on that gave the correct integer. Assuming that Python, PHP, etc., are using IEEE 754 when they do floating point, the results should be the same in all of those, which is why I believe that tax_f4 and tax_f5 should work for all cases, not just the ones I actually tested in the Python brute force test.

I did another C test, over the same range as the sscanf test, to verify that given an integer I, in the range [0, 10^k] for positive k up to 9, if you computer (double)I/10^k, then multiply that by 10^k and round(), you get back I.

My conclusions (assuming IEEE 754 or something that behaves similarly):

1\. It is OK to store money values and tax rates in floating point, at least as long as you have 9 or fewer digits after the decimal point. Just avoid doing calculations in this form.

2\. Converting from a floating point representation to an integer x 10^k representation by doing a floating point multiply by 10^k and a round to nearest integer works, at least as long as k <= 9.

3\. sscanf '%lf', and I expect most reasonable string to float parsers, if applied to a floating point number of the form 0.ddd... with up to 9 digits after the decimal point, will work as expected, in the sense that they will give you a floating point number that when converted to integer x 10^k representation as described in #2 will give you the integer you expect and want.

4\. I did not do any tests of floating point amounts that had large integer parts. With a large enough integer part, the places where I mention k <= 9 above might need to have that 9 lowered.

[1] e.g., in PHP:

      function cents_to_dollars($cents)
      {
        $cents = strval($cents);
        while (strlen($cents) < 3)
          $cents = '0' . $cents;
        return substr($cents,0,strlen($cents)-2) . '.' . substr($cents,-2);
      }

</comment><comment><USER44> Ada also has decimal fixed point built in, without the overheads the author is worried about. But I agree with the author of that built-in easy and _efficient_ support of decimal arithmetic is not so common.

</comment><comment><USER45> Many languaged have rational numbers (fractions) and big integers in their stack. This has the advantage that one has full control over where and when to trade off performance against accuracy.

</comment><comment><USER31> You really should right a new opening line Marianne; fractions are legit, and tons of people like them. Like most people who can do simple division without a calculator... Starting off with "no one likes fractions" is not a way to make friends or impress people.

</comment><comment><USER46> It's not exactly difficult to just write your own fixed point library in Java. I'm sure it'd be tricker to get exactly the same behavior as the old code, but it still doesn't seem like it should be a huge time sink on a large project.

</comment><comment><USER47> Have found similar to be true in my experience with COBOL, and older banking systems that rely on COBOL.

</comment><comment><USER48> Does Rust have solid support for fixed-point decimals, BTW? Would be quite a selling point, I suppose.

<comment><USER49> Not really, although I imagine this might become possible once 'const generics' stabilizes. Then you'd be able to define a generic type with a certain precision (of course you can do this today but you have to define a different type for different numbers of decimals). Overloading the arithmetic operators can be done. The only problem I see would be not having syntactic sugar for defining such a number, unlike integers and doubles.

<comment><USER48> Actually, I have absolutely no idea, how it is represented internally. Shamefully, I'm so used to thinking that there are 8/16/32/64-bit signed/unsigned ints, IEEE-754 floats and bunch of other "basic" stuff, and pretty much anything more sophisticated is being done with those plus some union/record/ADT/pointer magic on top of it, that I'm entirely unable to imagine how introducing another fundamental data-type would work. Would Rust's compiler backend ever able to make it as "native" and efficient as floats? Would your typical Intel/AMD/Qualcomm processor even know how to deal with this stuff, or it would turn out as "efficient" as manual string-based arbitrary-precision calculations? And, regardless, is there any difference between how Rust compiler technology could represent it and how gcc could represent it?

</comment></comment></comment><comment><USER50> Time for COBOL to get it's Elixir.

</comment><comment><USER51> Marianne, I'd like to chat with you about this article not in public. Whats the easiest way to do that?

</comment><comment><USER52> Isn't this more that floating points are not the solution for everything and most 'computer scientists' have little clue. Posits for the win (within a larger range of win at least)!</comment>


Why many restaurants don't actually want you to order dessert - <AUTHOR> http://www.washingtonpost.com/blogs/wonkblog/wp/2015/02/10/why-restaurants-dont-always-want-you-to-order-dessert/

<comment><USER2> $30 entrees? $20 desserts? And those are mid-level restaurants?

I thought the US was cheap, and Netherland was expensive, but I eat in excellent restaurants and often pay less than €20 for a main course, and never more than €10 for dessert. A 3 course meal for less than €40. Unless I'm somewhere really fancy that aims for (or has) Michelin stars, of course.

Also, in most restaurants, you fill the table for the whole evening. You need to start really early to be finished in time for late eaters to be able to fill the same table.

And much of the time in restaurants is actually spent waiting for the next course. If the restaurants are really in such a hurry, they could just bring the food sooner. In fact, I think desserts would be more suitable for that, since they can often be prepared in advance.

</comment><comment><USER3> I find it hard to believe that mid-level restaurant desserts don't have a healthy profit margin. Most desserts in these restaurants are food service cheesecake, topped with whipped cream and chocolate drizzle, and marked up to $7 or $8.

<comment><USER4> in practice, a slice will get ordered by up to five people and then extend the meal up to twenty minutes.

If you were selling time on that table it would be more like $10 for twenty minutes. Hence the problem. No one is arguing that the markup is huge, its that it comes at a cost.

on the other hand, an appetizer does not extend the meal and has a similar margin.</comment></comment>


Russian dairy farmers gave cows VR goggles with hope they would make better milk - <AUTHOR> https://www.cnn.com/2019/11/27/us/virtual-reality-russian-dairy-farm-cows-trnd/index.html <comment><USER2> Or perhaps you could put them in a field.

<comment><USER3> In winter, in Russia.</comment></comment>