Hacker News Reader

Comment by tyingq | Hacker News Reader

They have 4 hand picked examples on their homepage: https://copilot.github.com/

One has the issue with form encoding: https://news.ycombinator.com/item?id=27697884

The python example is using floats for currency, in an expense tracking context.

The golang one uses a word ("value") for a field name that's been a reserved word since SQL-1999. It will work in popular open source SQL databases, but I believe it would bomb in some servers if not delimited...which it is not.

The ruby one isn't outright terrible, but shows a very Americanized way to do street addresses that would probably become a problem later.

And these are the hand picked examples. This product seems like it needs some more thought. Maybe a way to comment, flag, or otherwise call out bad output?

View on HN

> The ruby one isn't outright terrible, but shows a very Americanized way to do street addresses that would probably become a problem later.

As someone who has been coding up address storage and validation for the past week in my current job, that one really made me laugh. Mostly because it tries to simplify all the stuff I have been analyzing and mulling over for a week into a single auto-complete.

Spoiler: The Github Copilot's solution simply won't work. It would barely work for Americanized addresses, but even then not be ideal. Of course trying to internationalize it, this thing isn't even close.

I get what Copilot is trying to do. But at the same time I don't get it. Because from my experience, typing code is the fastest part of my job. I don't really have a problem typing. I spend most of my time thinking about the problem, how to solve it, and considering ramifications of my decisions before ever putting code in the IDE. So Copilot comes around and it autocompletes code for me. But I still have to read what it suggested, making edits to it, and consider if this is solving the problem appropriately. I'm still doing everything I used to do, except it saved me from typing out a block of code initially. I still have to most likely rebuild, edit, or change the function somewhat. So it just saves me from typing that first pass. Well that's the easy part of the job.

I have never had a manager come to me and ask why a project is taking so long where I could answer "it just takes so long to type out the code, i wish I had a copilot that could type it for me". That's why we call it software engineering and not coding. Coding is easy. Software engineering is hard. Github Copilot helps with coding, but doesn't help with Software Engineering.

> I spend most of my time thinking about the problem, how to solve it...

A few years ago, I got a small but painful cut on my fingertip. I thought I would have a hard time on the job as a dev. To my surprise, I realized I spend 90-95% of my time thinking, and only 5-10% of the time typing. It turned out to be almost a non-issue.

As the owner of a fairly normal American address that is either corrupted by the UPS address validation service, this is a good time to remind everyone: accept the address that your customer enters. If you offer a service to try to improve your customer’s address, keep in mind that it’s a value added service, it may be wrong, and you MUST test the flow in which your customer tells your service to accept the address as entered. And maybe even collect examples in which the address change is accepted to make sure it does something useful.

Vendors have lost sales to me because they were too incompetent to allow me to ship things to my actual address. Oops.

P.S. for the US, you need to offer at least two lines for the address part. And you need to accept really weird things that don’t seem to parse at all. I know people with addresses that have a PO Box number and a PMB number in the same address. Lose one and your mail gets lost.

P.P.S. If you offer discounted shipping using something like SurePost, make sure you let your customers pay a bit extra to use a real carrier. There are addresses that are USPS-only and there are addresses that work for all carriers except USPS (and SurePost, etc). Let your customer tell you how to ship to them. Do not second-guess your customer.

> I don't really have a problem typing.

Im absolutely with you and want to upvote that part of the comment x100. Unfortunately it's often considered a fairly spicy opinions.

Entire frameworks (Rails) are built around the idea of typing as little as possible. Others can't even be mentioned without the topic of boilerplate/keystroke count causing a flame war (Redux).

A lot of engineers equate their value with the amount of lines they can pump out, so there's definitely a demand for tools like these.

There's also some legitimate stuff. There's a lot of very silly thing I have to google every time I do because I have a bad memory. It saves the step of googling. In a way, it was the same debate around autocomplete at the very beginning, but pushed to the next level. Autocomplete turned out to be a very good thing (even though new languages and tools keep coming out without it).

I never commit something that I can easily google (with a high quality solution) to memory

>Because from my experience, typing code is the fastest part of my job. I don't really have a problem typing. I spend most of my time thinking about the problem, how to solve it, and considering ramifications of my decisions before ever putting code in the ID

So very true.

[1] Understanding the problem > [2] thinking about all possible solutions > [3] working out which solution fits best > [4] working out which implementations are possible > [5] working out the most suitable implementation

... and finally, [6] implementing via code.

A lot of my job is thinking hard about how to do [X], incidentally needing to remember how to do [trivial thing Y] and looking it up.

Like, I did it before, remember that it was trivial, I just forget the snippet and I have to break focus to look it up - often by scrolling through my own commit history to try and find the time I did [trivial thing Y] four months ago.

I do kind of wish I could automate that. Skipping the actual typing of the snippet is sort of gravy on top of that.

It would be nice if there were a way to automate the "remembering what that one function is called and what order the parameters are in" portion of my job.

IME the best thing for this is looking at the method listing in the docs for the classes I'm using. E.g. for Ruby, it's usually looking at the methods in Enumerable, Enumerator, Array, or Hash. Or I'll drop a binding.pry into the function, run it, and then type ls to see what's in scope.

Even in the 90s that was a solved problem in Visual Basic with autocomplete. That a lot of dev environments "lost" the ability to do it is mind boggling. With that said, doesn't Rubymine let you do that with autocomplete with the prompt giving you all the info you need? (I haven't done Ruby in a long time).

Still, having to look up the doc or run the code to figure out how to type it is orders of magnitude slower than proper auto complete (be it old school Visual Studio style, or something like Copilot).

orders of magnitude slower than proper auto complete

Having worked extensively with verbose but autocomplete-able languages like Java, compact dynamic languages like Ruby, and a variety of others including C, Scala, and Kotlin, I've come to the conclusion that, for me, autocomplete is a crutch and I develop deeper understanding and greater capabilities when I go to the docs. IDE+Java encourages sprawl, which just further cements the need for an IDE. Vim+Ruby+FZF+ripgrep+REPL encourages me to design code that can be navigated without an IDE, which ultimately results in cleaner designs.

If there's any lag whatsoever in the autocomplete, it breaks my flow state as well. I can maintain flow better when typing out code than when it just pops into being after some hundreds of milliseconds delay. Plus, there's always the chance for serendipity when reading docs. The docs were written by the language creators for a reason. Every dev should be visiting them often.

That's totally cool but the grandparent was talking about remembering shit they already knew. Not everyone has a fantastic memory, and remember the arguments are A then B or B then A doesn't deepen your understanding of a language. Most of the time the autocomplete and the official doc use the exact same source anyway, formatted the same way, with the same info.

But if it works for you, more power to you!

remember the arguments are A then B or B then A doesn't deepen your understanding

What I meant is that you will coincidentally learn new things by going to the docs for old/simple things. In addition to remembering that method ordering, you might learn about a new method that simplifies your task.

this sounds super interesting, is there a video or upload somewhere that i can watch this being performed in real time?

I very briefly show some of the interactivity of Ruby+Pry here: https://youtu.be/Gy7l_u5G928?t=805 (the overall code segment starts at https://www.youtube.com/watch?v=Gy7l_u5G928&t=626s)

I'd be happy to hear about better demonstrations, and there's also Pry's website (https://pry.github.io/) where they link to some screencasts.

I spend most of my time thinking about the problem, how to solve it, and considering ramifications of my decisions before ever putting code in the IDE. So Copilot comes around and it autocompletes code for me. But I still have to read what it suggested, making edits to it, and consider if this is solving the problem appropriately.

So, rather than helping people program better, all its done is replace a bunch of the offshore cut-and-paste shops with "AI."

Isn't address storage and validation a solved problem? Why is it so complicated?

Ex:

412 1/2 E E NE

412 1/2 A E

1E MAIN

1 E MAIN

FOO & BAR

123 ADAM WEST RD

123 ADAM WEST

123 EAST WEST

> This product seems like it needs some more thought. Maybe a way to comment, flag, or otherwise call out bad output?

Wait for your colleagues to use it, fix the bad code in the pull request, and wait for copilot to learn from the new training data you just provided!

This is actually a good idea that is missing from nearly every machine learning product. How do you back propagate lessons from user interaction into future training of the model? It can be done, I can't think of a place I've seen it done though.

It would be viewed as IP theft by most companies to upload private code to this for use by others

It would have to be in the same range of what is suggested, small patches and opt in.

If snippets are a legal problem, then Copilot is problematic by default, since it suggests code that may or may not be sourced from free software.

Even free software snippets have clauses like GPL or attribution.

Putting GPL code in proprietary codebase would cause a company massive headaches...

So I agree copilot is problematic by default, liability to lawsuits for employers and forced open sourcing, liability to IP lawsuits as well which will end up on employees shoulders.

It's tricky, because once you start accepting user feedback, you need to moderate it, or else someone will poison your model for fun and profit.

But what about all the bad training data provided too?

Copilot appears to be “give more efficiency leverage to the worst kind of coder.”

It takes what should be your method of last resort - copypaste - and makes it the first thing you try.

All the steps in between - looking at the docstring for the function you're calling, googling for more general information, looking at and deciding not to use not-applicable or poorly-written SO answers - get pushed aside. So instead of you having to convince yourself "yes, it's safe to copy-paste these lines from SO, they actually fit my problem" you're presented with magic and I think the burden for rejecting it is going to be higher once it's in your editor than when you're just reading it on a SO post or Github snippet.

Even for a newcomer looking to learn, working on simple stuff that it has great completions for, it seems like it will sabotage your long-term growth, since it takes all the why and the reasoning out of it. Autocomplete for a function name isn't that relevant to gaining a deeper understanding. Knowing why a certain block of code is passed in in a certain style, or needs to be written at all? Probably that is.

Thinking about it more: there's a very small subset of problems that I think this is actually great for. And I do run into this somewhat often: relatively new libraries or frameworks that don't really care about thorough documentation so they only show you a few happy path snippets and nothing about how to do something more interesting, so you have to bridge the gap between "this one line in the doc obviously doesn't work with me, but I'd like to figure it out without reading all their source code from scratch..." - getting more example snippets barfed up onto my screen from other people who've figured it out before could be a sort of replacement for the library writers having provided documentation in the first place. But ... this is a somewhat insane way to work around a problem of shitty code documentation, and is still insufficient in a couple ways:

* some poor bastard is going to have to be the first person to figure out how to do something, so that copilot itself can know

* any non-code nuances around "oh, if you do that, your memory usage is going to explode" or "oh, by the way, if you do that, make sure you don't do your own threading" will still fail to be communicated.

I'm not really sure that type of tool could really be anything else.

How would a model become aware of all of the various edge cases that depend on which SQL database you use or differences in language versions over time?

> I'm not really sure that type of tool could really be anything else.

It can't be, because they've chosen to use a deep learning approach. That makes it a dead end right from the start.

> How would a model become aware of all of the various edge cases that depend on which SQL database you use or differences in language versions over time?

A lot of things that we call "edge cases" are only a problem for humans. They're not "edge cases" from the point of view of the grammar / semantics of programming languages and libraries. The way a hypothetical, better Copilot could work, is by having directly encoded grammars and semantics metadata corresponding to popular languages and tools. It could generate code in principled and introspectable way, by having a model of the computation it wants to express and encoding it in a target language.

Of course, such hypothetical Copilot is a harder task - someone would have to come up with a structure for explicitly representing understanding of the abstract computation the user wants to happen, and then translate user input into that structure. That's a lot of drudgery, and from my vague understanding of the "classical" AI space, there might be a bunch of unsolved problems on the way.

Real Copilot uses DNNs, because they let you ignore all that - you just keep shoving code at it, until the black-box model starts to give you mostly correct answers. The hard work is done automagically. It makes sense for some tasks, less for others - and I think code generation is one of those things where black-box DNNs are a bad idea.

> The way a hypothetical, better Copilot could work, is by having directly encoded grammars and semantics metadata corresponding to popular languages and tools. It could generate code in principled and introspectable way, by having a model of the computation it wants to express and encoding it in a target language.

But that sounds like too much work, let's just throw a lot of data into an NN and see what comes out! /s

> and introspectable

Which most importantly means "debuggable", I assume. From what I get there doesn't seem to be any way to ad-hoc fix an NN's output.

Can it submit pull requests to itself with if/else boolean logic/hacks?

a large data set covering exactly what you just mentioned?

This is my thought as well. I get the "make productive engineers even more productive" angle, but productive engineers' bottleneck isn't coding. Sure, coding up a boilerplate Go web server is tedious, but I have done it so many times that it takes me two seconds now.

On the flip side, coding can be the bottleneck for the worst kind of coder. When I first started coding, coding was hard simply because I had very little reps and was just learning to understand how to code common solutions, data structures, libraries, etc. Fast forward a few years and, if I were still struggling to understand these concepts, Copilot is a lifeline.

I’m gonna have to disagree - coding can and does take significant amounts of time even when I know exactly what problem I am solving.

I admit that at many organizations there are so many other factors and bottlenecks, but it’s not uncommon that I find myself 8+ hours deep into a coding task that I had expected would be much shorter.

On the other hand, usually that’s due to refactoring or otherwise not being satisfied with the quality of my initial solution, so copilot probably wouldn’t help…

Hmm... I mean, these all seem like mistakes I could make and I don't think I'm the "worst kind of coder".

The currency one I learned a while back, but it's not like I intuited using integers by default.

Value being a reserved keyword, I'm not sure I'd know that and I do Postgres work as part of my myriad duties at the startup I work at. Maybe I'd make that mistake in a migration, maybe I have already.

In a way, is it much different then what we do now as engineers? I'm hard pressed to call it much of an engineering discipline considering most teams I work on barely do design reviews before they launch in to writing code, documentation and meeting minutes are generally an afterthought, and the code review process while decent isn't perfect either and often times relies on arcane knowledge derived over months and years of wrangling with particular <framework, project, technology>.

It's pretty neat, presumably it'll learn as people correct it, and it'll get better over time. I mean it's not even version one.

I get the concerns, but I think they're a bit overblown, and this'll be really useful for people who want to learn how to code. Sure they'll run into some bugs, but, I mean, they were going to do that anyways.

Is this any worse? Maybe not. Is it better? Absolutely not.

This kind of tool will only further entrench the production of mediocre, bug-ridden code that plagues the world. As implemented, this will not be a solution; it is a express lane in the race to the bottom.

it is a race to the bottom, and people are trying to win. any skilled trade is being turned into an unskilled job. it might suck, the results might suck, but it's more profitable, and that's what matters.

I've called it "The Fully Mechanized Stack Overflow Brigade" before, and everything that comes to light supports that assessment.

On the upside, think of the consultancy fees you can charge to clean up those messes.

I find it is reducing my research time by providing a decent starting solution space. Especially for boring stuff where you just need to google the signature of some standard library function.

> The golang one uses a word ("value") for a field name that's been a reserved word since SQL-1999. It will work in popular open source SQL databases, but I believe it would bomb in some servers if not delimited...which it is not.

In their defense they created the table with this column before invoking the autocomplete, so they sort of reap what the sow here.

It could at least auto-quote the column names to remove the ambiguity, but it's not a compiler, is it.

- The Go one (averaging) is non-idiomatic, and has a nasty bug in it: https://news.ycombinator.com/item?id=27698287

- The JavaScript one (memoization) is a bad implementation, it doesn't handle some argument types you'd expect it to handle: https://news.ycombinator.com/item?id=27698125

You can tell a lot about what to expect, if there are so many bugs in the very examples used to market this product.

The golang one also silently drops rows.Err() on the floor.

https://golang.org/pkg/database/sql/#Rows

I haven't seen anyone mention this issue for some reason, but in fetch_tweets.py:

  fetch_tweets_from_user(user_name):
      ...
      tweets = api.user_timeline(screen_name=user, count=200, include_rts=False)

'user' isn't defined, should be user_name, right? Side note, 'copilot' is a decent name for this (though copilots are usually very competent, moreso than this right now). You must check the suggestions carefully. Maybe it'll make folks better at code review, lol.

What are the statistics of Copilot based on a validation set? How often does it get code right?

I want to see hard statistics, not 4 hand-picked examples.

That's what I thought when I first started working in text generation too. It's highly annoying people pitch their successful models with hand picked examples. It's literally the opposite of STATISTICAL learning imo.

Yeah. And like how would you even devise a metric? Like compile it down to assembly and see if it’s similar logic?

Well, this is the question which the producers of the tool should answer.

You can't just release a ML tool onto the public if you haven't validated it first.

The Golang example would not even compile, because `sql` is not imported.

That's for the best. We don't want products that pretend to write code for us, while copying other's code without attribution and that may not even work.

Now that they have an AI that can be trained to replicate code, it looks like the next step is training it to replicate good code. That will be non-trivial, since step one is identifying good code and they may not have much big data signal to draw from for that.

We know you can't use StackOverflow upvotes. However, they should have enough signal to identify what snippets of code have been most frequently copy-pasted from one project to another.

Question is whether that serves as a good proxy for good code identification.

> The python example is using floats for currency.

Dumb question, but what is the proper way to handle currency? Custom number objects? Strings for any number of decimal places?

This is a complex topic, mainly for two reasons: 1. it works on two layers (storage and code) 2. there is a context to take care of.

[Modern] programming languages have decimal/rational data types, which (within limits) are exact. Where this is not possible, and/or it's undesirable for any reason, just use an int and scale it manually (e.g. 1.05 dollars = int 105).

However, point 2 is very problematic and important to consider. How do account 3 items that cost 1/3$ each (e.g. if in a bundle)? What if they're sold separately? This really depends on the requirements.

My 20 cents: if you start a project, start storing currency in an exact form. Once a project grows, correcting the FP error problem is a big PITA (assuming it's realistically possible).

>[Modern] programming languages have decimal/rational data types

This caveat is kind of funny, in light of COBOL having support for decimal / fixed precision data types baked directly into the language.

It's not a problem with "non-modern" languages, it's a problem with C and many of its successors. That's precisely why many "non-modern" languages have stuck around so long.

https://medium.com/the-technical-archaeologist/is-cobol-hold...

Additionally, mainframes are so strongly optimized for hardware-accelerated fixed point decimal computing that for a lot of financial calculations it can be legitimately difficult to match their performance with standard commercial hardware.

> It's not a problem with "non-modern" languages, it's a problem with C and many of its successors.

Not really. Any semi-decent modern language allows the creation of custom types which support the desired behavior and often some syntactic sugar (like operator overloading) to make their usage more natural. Take C++, for example, the archetypal "C successor": It's almost trivial to define a class which stores a fixed-precision number and overload the +, -, *, etc. operators to make it as convenient as a built-in type, and put it in library. In my book, this is vastly superior to making such a type a built-in, because you can never satisfy everyone's requirements.

It is also trivial to keep doing C mistakes with a C++ compiler, hence no matter how many ISO revisions it will still have, lack of safety due to C copy-paste compatibility will never be fixed.

> [...] no matter how many ISO revisions it will still have, lack of safety due to C copy-paste compatibility will never be fixed.

Okay, no idea how that's relevant to "built-in decimal types" vs "library-defined decimal types", but if it makes you feel better, you can do the same in Rust or Python, two languages which are "modern" compared to COBOL, don't inherit C's flaws, and which enable defining custom number types/classes/whatever together with convenient operator overloading.

Rust I agree, Python not really as the language doesn't provide any way to keep invariants.

> Python not really as the language doesn't provide any way to keep invariants

Again, how is that relevant? If there's no way to enforce an invariant in custom data types, then there's also no way to enforce invariants in code using built-in data types.

It is surely relevant.

Rust provides the mechanisms to enforce them, while in Python, like all dynamic languages, everything is up for grabs.

What I meant [1] was: In Python, invariants are enforced by conventions, not by the compiler. If that's not suitable for a given use case, then Python is entirely unsuited for that use case, regardless whether it provides built-in decimal types or user-defined decimal types. That's why I said that your objection regarding invariant enforcement is irrelevant to this discussion.

[1] (but was to lazy to write out)

It is quite simple to do the same in Julia

> How do account 3 items that cost 1/3$ each (e.g. if in a bundle)?

You never account for fractional discrete items, it makes no sense. A bundle is one product, and a split bundle is another. For products sold by weight or volume, it's usually handled with a unit price, and a fractional quantity. That way the continuous values can be rounded but money that is accounted for needs not be.

The problem is also stupid people and companies.

My last job they wanted me to invoice them hours worked, which was some number like 7.6.

This number plays badly when you run it through GST and other things - you get repeaters.

So I looked up common practice here, even tried asking finance who just said "be exact", and eventually settled on that below 1 cent fractions I would round up to the nearest cent in my favour for each line item.

First invoice I hand them, they manually tally up all the line items and hours, and complain it's over by 55 cents.

So I change it to give rounded line items but straight multiplied to the total - and they complain it doesn't match.

Finally I just print decimal exact numbers (which are occasionally huge) and they stop complaining - because excel is now happy the sums match when they keep second guessing my invoices.

All of this of course was irrelevant - I still had to put hours into their payroll system as well (which they checked against) and my contract specifically stated what my day rate was to be in lieu of notice.

So how should you do currency? Probably in whatever form that matches how finance are using excel, which does it wrong.

I wish this was untrue, but I have spent years hearing the words "why dont my reports match?" - no amount of logic, diagrams, explaining, the next quarter or instance - "why dont my reports match?"

BECAUSE EXCEL SUCKS MY DUDE.

Well, they did say to be exact, and you handed them approximations, so...

The “exact” version they wanted was full of approximations too. They just didn’t have enough numerical literacy to understand how to say how much approximation they are ok with.

I guarantee nothing in anyone’s time accounting system is measured to double-precision accuracy. Or at least, I’ve never quite figured out the knack myself for stopping work within a particular 6 picosecond window.

Sure, but at the end of the day someone had to pay me an integer amount of cents. They wanted a total which was a normal dollar figure. But when you sum up 7.6 times whatever a whole lot, you might get a nice round number or you might get an irrational repeater.

What's notable is clearly no one had actually thought this through at a policy level - the answer was "excel goes brrrr" depending on how they want to add up and subtotal things.

Generally what is done is that “int 1 != $0.01” rather it’s “int 100 = $0.01”, as in the base of the integer is 1/100th a cent. That doesn’t perfectly solve your example case perfectly though admittedly.

There's no one answer, but decimal counts of the smallest unit that needs to be measured is common. Like pennies in the US, or maybe "number of 1/10 pennies" if there's things like gasoline tax.

Say what you like about COBOL, but it got this stuff right.

You can use integers instead of decimal if you're using the smallest unit.

For Python, I prefer decimal.Decimal[1]. When you serialize, you can either convert it to a string (and then have your deserializer know the field type and automatically encode it back into a decimal) OR just agree all numeric values can only be ints or decimals. You can pass parse_float=decimal.Decimal to json.loads[2] to make this easier.

My most obnoxious and spicy programming take is that ints an decimals should be built-in and floats should require imports. I understand why though: Decimal encoding isn't anywhere near as standardized as other numeric types like integers or floating-point numbers.

[1] https://docs.python.org/3/library/decimal.html [2] https://docs.python.org/3/library/json.html

> My most obnoxious and spicy programming take is that ints an decimals should be built-in and floats should require imports

I don't care about making inexact numbers require imports, but the most natural literal formats should produce exact integers, decimals, and/or rationals.

An integer of the smallest denomination. For example, cents for the American dollar. And you probably would want to wrap it in a custom type to simplify displaying it properly, and maybe handle different currencies. If you language has a fixed point type that might also be appropriate, but that's pretty rare, and wouldn't work for currencies that aren't decimal (like the old british pound system).

Do they still use fractional cents (or whatever) in finance?

https://money.howstuffworks.com/personal-finance/financial-p...

What if I'm calculating sales tax? Can't use an integer anymore.

Yes, you can. There are algorithms for rounding up, rounding down, rounding to nearest, and banker's rounding, on the results of integer division. This is a solved problem.

To pile on, here's a copy/paste from when this was asked a few days ago:

Googler, opinions are my own. Over in payments, we use micros regularly, as documented here: https://developers.google.com/standard-payments/reference/gl...

GCP on there other hand has standardized on unit + nano. They use this for money and time. So unit would 1 second or 1 dollar, then the nano field allows more precision. You can see an example here with the unitPrice field: https://cloud.google.com/billing/v1/how-tos/catalog-api#gett...

Copy/paste the GCP doc portion that is relevant here:

> [UNITS] is the whole units of the amount. For example if currencyCode is "USD", then 1 unit is one US dollar.

> [NANOS] is the number of nano (10^-9) units of the amount. The value must be between -999,999,999 and +999,999,999 inclusive. If units is positive, nanos must be positive or zero. If units is zero, nanos can be positive, zero, or negative. If units is negative, nanos must be negative or zero. For example $-1.75 is represented as units=-1 and nanos=-750,000,000.

In its base unit. So cents in USD. Which can be an int64

Or if your language has something specific built in, use that.

> Or if your language has something specific built in, use that.

Unless your language is PostgreSQL's dialect of SQL, apparently. https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use...

It has the same issue that the other suggestion of your parent comment had: it can’t deal with fractions of cents, which is an issue you will most likely run into before you will into floating point rounding issues.

Of course for databases you should use a decimal.

> In its base unit. So cents in USD. Which can be an int64.

Note that if you use cents in the US so that everything is an integer then as long as you do not have to deal with amounts that are outside the range [-$180 trillion, $180 trillion] you can also use double. Double can exactly represent all integer numbers of cents in that range.

This may be faster than int64 on some systems, especially on systems that do not provide int64 either in hardware or in the language runtime so you'd have to do it yourself.

Not necessarily. It depends on the application.

Integer cents or an arbitrary precision decimal type.

Having worked on a POS system, the issue of using cents alone is if you've got something like "11% rebate" and you need to deal with fractional cents.

The arbitrary precision decimal type should be the default answer for currency until it is shown that the requirements no and at no time in the future will ever require fractional units of the smallest denomination.

As an aside, this may be constrained by the systems that the data is persisted into too... the Buffett Overflow is a real thing ( https://news.ycombinator.com/item?id=27044044 ).

A lot of good answers, but they mostly relate to accounting types of problems (which granted, is what you need to do with currency data 99% of the time)

I’d just add that if you are building a price prediction model, floats are probably what you need.

The example code is the start of an expense tracking tool...

Depends what you’re doing. In fact it’s not always wrong to use floats for currency. For accounting you should probably use a fixed-precision decimal type.

If someone asks how to handle money the best answer is integers or fixed precision decimals. There may be a valid case for using floats, but if someone asks they shouldn't be using floats.

Also I'm hard pressed to come up with a case where floats would work. Can you give an example?

> Can you give an example?

The answer is the same as _any_ time you should use floats: where you don't care about answers being exact, either (1) because calculation speed is more important than exactness, or (2) because your inputs or computations involve uncertainty anyway, so it doesn't matter.

This is more likely to be the case in, say, physics than it is in finance, but it's not impossible in the latter. For example, if you are a hedge fund and some model computes "the true price of this financial instrument is 214.55", you certainly want to buy if it's being sold for 200, and certainly don't if it's being sold for 250, but if it's being sold for 214.54, the correct interpretation is that _you aren't sure_.

When people say "you should never use floats for currency", their error is in thinking that the only applications for currency are in accounting, billing, and so on. In those applications, one should indeed use a decimal type, because we do care about the rounding behavior exactly matching human customs.

You can't use a generic decimal type in that case either! You need a special-purpose type that rounds exactly matching the conventions you're following. This is necessarily use-, culture-, and probably currency-specific.

Good answer. I've only ever worked on accounting style financial apps, so I've didn't think of those types of cases.

That's fair, though the example code I mentioned is the start of an expense tracker.

Fair enough -- in that case, you should definitely use either a decimal type or an integer.

Most things in front office use floats in my experience, e.g. derivative pricing, discounting, even compound interest. None of these things are going to be any better with integers or fixed-precision, but maybe harder to write and slower.

Yes, the risk management/instrument pricing part in the "Front Office" uses floats, because the calculations involve compound interest and discount rates.

And the downstream parts for trade confirmation ("Middle Office"), settlement and accounting ("Back Office") used fixed precision. Because they are fundamentally accounting, which involves adding things up and cross-checking totals.

These two parts have a very clear boundary, with strictly defined rounding rules when the floating point risk/trading values get turned into fixed point accounting values.

python has the `decimal` module in the stdlib

Create a Money class, or use one off the shelf. It should store the currency and the amount. There are a few popular ways of storing amounts (integer cents, fixed decimal) but it should not be exposed outside the Money class.

There's plenty of good advice in this subthread for how to represent currency inside your Money abstraction, but whatever you do, keep it hidden. If you pass around numbers as currency values you will be in for a world of pain as your application grows.

Either a fixed-point decimal (i.e. an integer with the ones representing 1/100, 1/1000, etc. of a dollar, or a ratio type if you need arbitrary precision.

> ratio type if you need arbitrary precision.

This is the better default, so I'd ditch the qualifier, personally. At the very least when it comes to the persistent storage of monetary amounts. People often start out thinking that they won't need arbitrary precision until that one little requirement trickles into the backlog...

Arbitrary precision rationals handles all the artithmetic you could reasonably want to do with monetary amounts and it lets you decide where to round at display time (or when generating a final invoice or whatever), so there's no information loss.

> Dumb question, but what is the proper way to handle currency?

In python, for exact applications (not many kinds of modeling, where floats are probably right), decimal.Decimal is usually the right answer, but fractions.Fraction is sometimes more appropriate, and if you are using NumPy or tools dependent on it, using integers (representing decimals multiplied by the right power of 10 to get the minimum unit in the ones position) is probably better.

Yeah, you probably want to use some sort of decimal package for a configurable amount of precision, and then use strings when serializing/storing the values

Every front office finance project I have ever worked on has used floating point, so take the dogma with a grain of salt. It depends entirely on the context.

They probably just accumulate the rounding errors into an account and write it off periodically without even realising why it happens.

No, it's just that we're in the realm of predictions and modelling, not accounting. If you're constructing a curve to forecast 50 years of interest rates from a limited set of instruments, you're already accepting a margin of error orders of magnitude greater than the inaccuracies introduced by floating point.

The models also use transcendental functions which cannot be accurately calculated with fixed point, rationals, integers etc.

Makes sense; I wasn't aware of the meaning of "front office" as a term of art in finance.

It's not like decimal or fixed point does not suffer from rounding errors either. In fact for many calculations, binary floating point gives more accurate answers.

In accounting there are specific rules that require decimal system, so one must be very careful with the floating point if it is used.

And the all suffer from rounding error problems?

I mean, fixed point and a specific type for currency (which also should include the denomination, while we are at it) are not rocket science. Spreadsheets get that right, at least.

Excel uses IEEE-754 floating point, so I don't get what you mean with the spreadsheet comment. It has formatting around this which rounds and adds currency symbols, but it's floating point you're working with.

Rounding error doesn't matter on these types of financial applications. It's the less glamorous accounting work that has to bother with that.

They're not rocket science, but they're unnecessary, and would still be off anyway. Try and calculate compound interest with your fixed point numbers.

Each country has a law or something similar that states how people should calculate over prices.

The usual is to use decimal numbers with fixed precision (the actual precision varies from one country to another), and I don't know of any modern exception. But as late as the 90's there were non-decimal monetary systems around the world, so if you are saving any historic data, you may need something more complex.

Someone already mentioned there's a `decimal` package in Python that's better suited for currency. Back when I was a Java developer we used this: https://docs.oracle.com/javase/7/docs/api/java/math/BigDecim...

The Decimal class is one way if you roll your own. py-moneyed seems to be a well maintained library though I haven’t used it.

Disclaimer: I only work with currency in hobby projects.

These are great examples. I wrote about how this will propagate all sorts of bugs.

But my argument was that it's good enough developers may get complacent and not review the auto complete closely enough. But maybe I'm wrong! Maybe it's not that good yet.

“Maybe a way to comment, flag, or otherwise call out bad output?”

A copilot for copilot? :)

post process with some language aware heuristics maybe

> And these are the hand picked examples. This product seems like it needs some more thought.

Everyone's self-preservation instincts kicking in to attack Copilot is kinda amusing to watch.

Copilot is not supposed to produce excellent code. It's not even supposed to produce final code, period. It produces suggestions to speed you up, and it's on you to weed out stupid shit, which is INEVITABLE.

As a side note, Excel also uses floats for currency, so best practice and real world have a huge gap in-between as usual.

So how do you know if the code that Copilot regurgitates is almost a 1:1 verbatim copy of some GPL'ed code or not ?

Because if you don't realize this, you might be introducing GPL'ed code into your propiertary code base, and that might end up forcing you to distribute all of the other code in that code base as GPL'ed code as well.

Like, I get that Copilot is really cool, and that software engineers like to use the latest and bestest, but even if the code produced by Copilot is "functionally" correct, it might still be a catastrophic error to use it in your code base due to licenses.

This issue looks solvable. Train 2 copilots, one using only BSD-like licensed software, and one using also GPL'ed code, and let users choose, and/or warn when the snippet has been "heavily inspired" by GPL'ed code.

Or maybe just train an adversarial neural network to detect GPL'ed code, and use it to warn on snippets, or...

You have the same issue with MIT because it requires attribution

Doesn't this go beyond license and into copyright?

The license lets you modify the program, but the copyright still enforces that you can't copy/past code from it to your own project no?

The solution might be simpler than we think,just tell the algorithm

It's very easy: don't use copilot code verbatim, and you won't have GPL code verbatim.

> It's very easy: don't use copilot

Fixed that for you.

Verbatim isn't the problem / solution. If you take a GPL'ed library and rename all symbols and variables, the output is still a GPL'ed library.

Just seeing the output of GPL'ed code spitted by copilot and writing different code "inspired" by it can result in GPL'ed code. That's why "clean room"s exist.

Copilot is going to make for a very interesting to follow law case, because probably until somebody sues, and courts decide, nobody will have a definitive answer of whether it is safe to use or not.

Stack Overflow content is licensed under CC-BY-SA. Terms [1]:

* Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

* ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

In over a decade of software engineering, I've seen many reuses of Stack Overflow content, occasionally with links to underlying answers. All Stack Overflow content use I've seen would clearly fail the legal terms set out by the license.

I suspect Copilot usage will similarly fail a stringent interpretation of underlying licenses, and will similarly face essentially no enforcement.

[1] https://creativecommons.org/licenses/by-sa/4.0/

Have you met programmers? Even those who care about quality are often under a lot of pressure to produce. Things slip through. Before, it was verbatim copies from Stack Overflow. Now it'll be using Copilot code as-is.

So, nothing new, is your point?

Then why are you complaining? Unless something is new that warrants you getting mad about people getting mad at technology.

Not the parent, but people really like to get riled up on the same topics, over and over again, which quickly monopolizes and derails all conversion. Facebook bad, UIs suck, etc. We can now add to the list, "AI will never reduce demand for software engineering".

Well, "never" is a long time.

Copilot is definitely no replacement for anything except copying from Stack Overflow for juniors.

But in the long run, AI is us basically us creating our own replacement. As a species. We don't realize it yet. It'll be really funny in retrospective. Too bad I probably won't be alive to see it.

It's true I probably wouldnt have laughed quite as loudly if there werent a chorus of smug economists telling us that tools like this are gonna put me out of a job.

Business types hate dealing with programmers, that's a fact. And these claims of "we'll replace programmers" happen with certain precise regularity.

Ruby on Rails was advertised as so simple, startup founders who can't program were making their entire products in it in a few days, with zero experience. As if.

Economists don't believe this. It's non-economists who do. Economists know that it's not possible to run out of jobs because demand is infinite.

If I want random garbage in my codebase that I have to fix anyways I might as well hire a underpaid intern/junior.

It's easier to write correct code than to fix buggy code. For the former you have to understand the problem, for the latter you have to understand the problem, and a slightly off interpretation of it.

> Everyone's self-preservation instincts kicking in to attack Copilot is kinda amusing to watch

Nobody is threatened by this, assuredly. As with IDEs giving us autocomplete, duplication detection, etc this can only be helpful. There is an infinite amount of code to write for the foreseeable future, so it would be great if copilot had more utility.

>As a side note, Excel also uses floats for currency

It's still problematic, but the defaults and handling there avoid some issues. So, for example:

Excel: =1.03-.42 produces 0.61, by default, even if you expand out the digits very far.

Python: 1.03-.42 produces 0.6100000000000001, by default.

Excel rounds doubles to 15 digits for display and comparison. The exact precision of doubles is something like 15.6 digits, those remaining 0.6 digits causing some of those examples floating (heh) around.

That depends https://randomascii.wordpress.com/2012/03/08/float-precision...

A lot of these edge cases are about theoretical concerns like "how many digits we need in decimal to represent an exact IEEE binary float".

In practice a double is 15.6 digits precise, which Excel rounds to 15 to eliminate some weirdness.

In their documentation they do cite their number type as 15 digit precision type. Ergo that's the semantic they've settled on.

"self-preservation"

My suggestion was a way to comment or flag, not to kill the product. These were particularly notable to me because someone hand-picked these 4 to be the front page examples of what a good product it was.

I agree with you. This is basically similar to autocomplete on cellphone keyboard (useful because typing is hard on cellphone), but for programming (useful because what we type tends to involve more memorization than prose).

Reply on news.ycombinator.com