A certain CEO says that we won't need programming languages because you will be able to program AI systems with natural language. Well, the problem with natural language is not that we do not have the tech, it is that natural language is too imprecise. People will, again, end up being dissatisfied by the output of AI systems and blame it on the tech, while the problem just remains that as humans we kinda suck at being explicit about what we want.
To use the example from the article: spreadsheets could use strongly-typed columns, but guess the column type automatically based on the values entered. When things go right, it'd be just as easy as today, but if things go wrong, you always have an escape hatch: with a little more work, you can manually specify the column type. Problem solved. That gives you the increased productivity you want for the happy case, without the frustration of trying to find a workaround for the corner case. This kind of approach needs more architecture work at the beginning of a project, but it's almost always feasible.
That being said, I think your frustration is warranted, although I think it's much more pervasive than tech. At its core, I think the problem is that, in your example, the CEO and the programmer are having two different conversations without really realizing it. The CEO wants a problem solved, but the programmer wants the tools to solve the problem themselves. The CEO thinks that ML should be able to solve their problem, but the programmer sees that ML as a tool has serious limitations, and won't help solve under-specification. And then they both end up talking past each other.
It seems that a lot of (at least western society) is built around the idea that when someone asks for help, what they "really" want is, metaphorically, to be given a fish for dinner, instead of learning how to fish. That's the CEO in your example; the presumption is "I want help" means "solve my problem", not "make it easy for me to solve my problem myself". It's one of my biggest frustrations, because it inherently robs you of agency and in many cases can be downright condescending -- for example, when I was working as a mechanical engineer, there were shop floor guys ignoring the tolerances I specified on my drawings because they assumed I was over-specifying them, because they lacked the context of the rest of the design, and weren't willing to sit down to hear the bigger picture. But when I had to send the parts back for re-work, they acted like it was my fault.
Anyways, this is all a really long-winded way of saying, I think this is largely a social problem, not a technological one. But I don't think it's inherent in humans; I think this is something we've learned as a part of our culture.
I agree with the implicit part, but not with the cynicism. Most human-to-human communication has implicit details, simply because there would otherwise be too many "obvious" details that need to be communicated. Suffice to say, humans tend to misunderstand each other when different assumptions are held and things can go horribly wrong.
People like mathematicians and programmers, who are used to formal thinking, know that you have to be rigorous in your statements. We understand that details and edge cases matter. And it can be frustrating when other people don't understand that you need to look at the full picture instead of a very rough sketch.
> I've been annoyed by how people do not want to be specific, but then rant about how someone did not understand exactly what they wanted.
I'm also annoyed when this happens. But then I say: This is what you requested. I can only work with the information that you provide to me.
I think it depends on the attitude of the person giving feedback. I generally find that digging into why this isn't what the user wanted is more illuminating. Tell me a story and I'll gain context and get more of the implicit details right going forward.
This breaks down when someone starts talking outside of that shared understanding (say, on the internet) but do not realize more context is now needed.
If only there was a trade, a group of educated professionals with specific training in the use of language to describe a desired outcome. We could call them "language engineers" and regulated them via state associations meant to protect the public from charlatans.
People choose these system with loose conversions over and over again because it's an advantage up to a point. Of course it becomes a liability when expanded too much and used in now critical systems, but IMHO the tradeoff usually ends as a net positive. Which is why, over and over we build more of these systems, and they fare better in the market than the stricter ones.
There doesn't have to be a tradeoff if you make it optional.
- people love to export as CSV. And I kinda understand them, csv looks simple enough, what could go wrong ?
- other spreadsheet softs need to recognize the same field and act the same way. Google Sheets, LibreOffice, KingSoft's one etc. Not counting old office versions that aren't updated anymore, because the owner doesn't want to move into the cloud.
- the flag needs to stay when moving sheets around, copy to another set, etc.
That could still be better than nothing. But could still lead to catastrophic loses as people get used to it working most of the time, there's no perfect solution.
This would also offer the path for changing the default over time to safe by default. There will be more spreadsheets created in the future than exist now.
They already added an option in the settings last year to deal with this specific issue. Their solution isn't perfect either, they made the tradeoff to optimize for up to date excel users.
Also keep in mind that the first person doesn't necessarily use excel at all. The file might start and end as a text file or TSV.
Right Click > Format Cells > Text.
Set the data type of the column and Excel will not fiddle with it. Let it stay implicit and Excel will to guess. This change is saved in the file. The article only slightly touches on this: converting to CSV and losing all the Excel formatting and then opening it in Excel again.
Just because they have something they call CSV import or export doesn't mean the feature actually works.
An option was added last year [0] the way you propose it, but until then users already had the option to mark the columns as text. The same way we have to deal with any data where auto detection might be problematic: explicitely set a type, and potentially a format.
But of course that's bothersome, sometime people forget to do it, sometimes they don't even know how to properly do it etc. And some of these people will still probably forget to set the option, and there are still edge cases where it can fail (macros are cited)
[0] https://www.theverge.com/2023/10/21/23926585/microsoft-excel...
This only works on Excel files though, which save a type for columns/cells. With CSV files, Excel would just auto-format them. I guess you could save everything as xls/xlsx, but I shouldn't have to use a vendors file format because they're threatening to corrupt my data if I don't.
I don't want Excel to take over the file association for .json but I do sometimes wish Excel would just invent a file extension like .xljson that loads JSON so that at least you could trivially rename a JSON file to .xljson and get working double-click for your business users but a file format (with optional schema support even) that's a more modern and saner de facto standard than CSV.
I think that one dumb trick would improve everyone's productivity a great deal.
If the excel developers cared about CSV support they would have added more settings to the CSV import tool that let you specify everything. Every single data base tool that lets you import CSV files has worked better than Excel. It simply means Excel wasn't built to import CSV files. Tough luck.
.xlsx file extension is well supported by many open source libraries. If you insist on working with Excel then you should use the appropriate file format, which is .xlsx. I do that all the time and it just works.
or they dont know any better.
That's a hell of a claim to try and demonstrate when its initial advantage is far from obvious to begin with.
A) I have no clue where you got this from. It seems like a convenient assumption, but not one that's easily verified, especially when folks are introduced to the dangers of such an approach.
B) Giving people control over how the data is interpreted outside of the default interpretation seems like a no-brainer. I don't really rely on default interpretation of anything, especially in the context of spreadsheets given how eager they are to interpret data in unexpected ways, but based on this thread it seems like it's rather difficult to turn off the date conversion behavior in excel.
C) I was replying to a comment about implicit conversions, which is far larger than just the context of excel spreadsheets.
As a workflow, if every time you create a new spreadsheet you first define all the column types and constraints, you're in the world you're describing. Passing around that spreadsheet would also keep these settings as long as it's not converted and everyone's version is compatible.
That means you get the best of both worlds: people who care about strict types can be as strict as they want, other people can benefit from auto conversions.
Is this some kind of joke? Ever used Excel?
The world is full of antipatterns that people implement with little, no, or flawed analysis. They do not fare better in the market, they propagate the same way entropy does.
Excel is the polar opposite of that.
They’re good for professional and hobby code golf though.
Probably the general rule is simply, “you get more bugs when expectations don’t match reality”.
Example: 1. (null) This value can’t be null 2. (article) This value won’t be converted into a date 3. (misc) This API can be called frequently
That's too vague to be useful. You might as well say "you get bugs when you write wrong code". Whereas framing it as a lack of type safety points towards an actionable solution.