The Problem with F# Evangelism - <AUTHOR> https://thomasbandt.com/the-problem-with-fsharp-evangelism <comment><USER3> This article retreads common complaints about the F# experience for outsiders that I've seen numerous time. I'm going to go a different direction.

The problem with the F# community is that they keep asking how to convince C# developers to use F#. I'm convinced that is not the right way to grow the F# ecosystem.

Most C# developers tend to come from enterprise and have a set of values and practices that is generally at odds with open-source, functional languages. They are used to producing codebases that can never be open-sourced, using tooling provided by a single vendor. They don't tend to be the ones contributing interesting or new libraries. In fact, this is a large issue with .NET in general. Most strong libraries are spiritual or literal copies of something from the JVM world.

This urge hurts in other ways. For instance, Don Syme has indicated he doesn't want to put things like Type Classes or Dependent types into the language because it adds a cognitive load to the language that's hard to balance vs the gains in productivity. But their absence means that many of the dev's you actually want contributing to the ecosystem, just use other languages. They adopt Haskell/Idris/Scala/whatever and start contributing blog posts, tweets, libraries, conference talks, etc.

I actually think a large part of this decision is that many of these things would make F# pretty incompatible with C#, which is trumpeted as a feature, but again, it waters down the language to the point that C# dev's look at it and say, "Why bother? It's compatible like VB is, so C# can already accomplish the same things." And in the meantime, it prevents new features that would attract others.

What sounds more enticing to developers, "More Functional C#" or "Haskell With Better Tooling"? What's more, there are even examples of how some of these features could be implemented (both Type Classes and Dependent Typing exist in some capacity through feature requests and F*, an experimental Microsoft language).

Basically, F# should be more about being different than the rest of .net, than trying to be ".net through an OCaml set of glasses".

<comment><USER4> I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers.

Immutable data is also becoming a common pattern even in C# but it's tedious as hell to write.

Functional programming is also seeping in but again tons of boiler plate.

Biggest problem with F# is that it has it's own warts + it's a big upfront switching cost and a steep learning curve but it offers many marginal improvements - when you sum those improvements it ends up being worth it IMO but that's a very hard sell.

<comment><USER5> C# developers in my shop loathe the SQL type provider because it requires them to have a compatible SQL Server database schema at build-time. The extra level of organization required is more than they can accept.

<comment><USER6> that kind of thing is a collosal mistake in my opinion - just on the face of it I/o at compile time seems very wrong.

<comment><USER7> An understandable position.

Here's the context that makes it not a big deal:

1) If there is some fundamental issue with having a dev DB then you would just use another ORM, just like in C#. Really, this specific type provider is not an ORM, it's for SQL server data munging. Most every project I've seen in a decade has multiple dev DBs, many used in testing, many used for staging... being able to talk to a valid schema source should be relatively straightforward... but if it isnt then get a different type provider or use an ORM with explicit code generation.

2) Compile time guarantees about data sources is a huge source of comfort when dealing with DBs owned by external actors or teams. For data scientist, integrator, sys admins, and such the norm is connecting to operational DBs that you have very little control over. This specific Type Provider ensures that your scripts will not compile if there has been a breaking schema change. That means you're seeing these issues during deployment, not as costly runtime errors that may or may not corrupt your application state. Less debugging, more safety, better guarantees, immediate feedback on issues; all in realtime.

To summarize: if compile time validation of JSON structures, XML structures, SQL Schema, or custom file formats creates some kind of pain, then don't use a provider of types that relies on analyzing data structures to create code :)

For the other 99.9999% of the time type providers are a DREAM for working with external data sources, provide most of what we want ORMs for, and are very lightweight in comparison. It's rapid data exploration with built in prototyping. Very nice.

</comment></comment></comment></comment></comment><comment><USER8> I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing:

Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associate _programming_ with specific constructs and idioms of C-style languages. It's incredibly difficult to break that barrier.

I think that functional programming is on the rise, and that more and more developers are starting to realize that the types of bugs that hold them back can be reduced by using a more powerful language. But it's got a very long way to go, because there is a lot of unlearning to do. The article alludes to this a bit. For example, immutability is one of the key concepts in nearly every FP language. Functional programmers take it for granted, but it's transformational and completely changes the way you have to solve a problem. This hump is often too big for many people to get over, at least in their first trial with a functional programming language. It's hard to solve a task you know how to solve when you now need to re-think your approach because the language doesn't let you change _x_ in-place.

Additionally, I believe that many programmers aren't necessarily aware of all of the problems they're having. The next time you hear someone say, "and make sure to check for null here", watch them to see if they're seeing that as a general problem hurting their ability to get bits out the door or not. In my experience, it's not usually viewed that way. Yes, null is a necessary evil in many environments, but it's one that can be tamed, and different languages have already figured out how to do that. But unless it's seen as a _problem_ by people at large, they won't see that as a carrot when you wave things like Optional types in front of them.

Overall, I'm still excited. Jet.com is a billion-dollar company that built their stuff with F#. There are similar stories of companies successful with F# (and other functional programming languages), and it feels as though this is happening more often. And as the mainstream (read: C-style languages) adopt more functional programming techniques, I think this will only get better. I think that people will see the value, then see a language which does it better, and give it a try.

<comment><USER9> "...realize that the types of bugs that hold them back can be reduced by using a more powerful language."

I hear this a lot with FP but would love to see some real world examples of this if anyone has any links.

<comment><USER10> How many times have you had the runtime exception

        AttributeError: 'NoneType' object has no attribute 'foo'

(or its equivalent in your favourite language)?

<comment><USER11> That's something addressed by static typing though. I'm pretty sure any dynamic language has that issue, functional or not.

<comment><USER10> It's fair to say that the boundaries of "functional programming" are pretty amorphous and I certainly didn't mean _untyped_ functional programming. In any case, if you want to prevent null/None errors in a way that gives the programmer his/her own access to create similar new abstractions then you need

* sum types

* parametric polymorphism

* pattern matching

at which point you may as well also add

* first class functions

and then if you don't describe your language as "typed functional" then how do you describe it?

</comment></comment></comment></comment></comment><comment><USER12> I think F#'s larger problem is that it doesn't dip into many of the wells that even OCaml (its original inspiration) has dipped into. C# developers are wrong that C#'s functional facilities are just as good, but it's a big struggle to point to a place in F# and say, "THERE! THAT IS THE BEST BIT!" The closest I can get is type providers (which are cool and I wish for them elsewhere) but they're kinda specialist.

Ocaml folks have these. Haskell folks have these. Heck, even psuedo-functional languages like Clojure and Scala have these.

The other problem is one of tooling (disclaimer, last time I tried this was just over a year ago). F# not only has pretty obscure tooling, but in conventional tooling it introduces a total linear order to your entire source tree, and it's one YOU must maintain with a GUI list. What's more, the F# community is very keen to disseminate the language.

I think F# would be more popular if it did more to differentiate itself from imperative programming. There is a longstanding argument that this is "unfriendly to data scientist", but I'm really not convinced by this, as I meet very few mathematicians outside of the stats world who don't on some way, shape or form espouse functional programming.

<comment><USER13> Tooling wise, tried Rider IDE from Jetbrains on Ubuntu, and out of the box it works (if you have mono + F# installed).

The ionide project is doing tremendous job of support on vscode.

It has improved compared to year, and definitely much better, in a month or two all the major IDEs including MonoDevelop will likely have .net core 2.0 support with F# baked in (speculation on my part).

<comment><USER12> I just don't see a lot of point to Mono in my domain. Even with the code inputs from .NET I've never gotten anything but sub-par performance from it for network services.

</comment></comment></comment><comment><USER14> I usually don't try to sell F# as compared to C# as noted in many other responses here. Since most of my friends work in other languages I usually just use python as my reference.

#ME: "Hey that stuff at pycon was pretty cool, huh?"

#FRIEND: "Yeah it's interesting the directions they're going with the language."

#ME: "Yeah the optional types could help clean up big code bases, and open up the door for quickcheck-like fuzzy testing."

#FRIEND: "Yeah."

#ME: "And some of the functional programming stuff is pretty neat too, I know it's easier for me to test."

#FRIEND: "It's so much easier."

#ME: "And the asyncio stuff is gonna be really nice to work with when it catches on more."

#FRIEND: "Yeah it seems a lot more ergonomic of a solution."

#ME: "And the binary distributable packaging tools look like they might actually work this time."

#FRIEND: "Probably not, but we can hope."

#ME: "I think I should introduce you to my friend F#."

Then just do some stuff in fsx with a type provider or some other neat stuff and at least you've got the message across.

People get excited about solutions to their problems. If you start giving them more problems then you're only adding to the constant subconscious cognitive load that they bear in regards to software development.

If you show it to them in terms of problems that they already have, you're reducing the cognitive load. Everybody loves having less stress.

But this is just how I approach it. F# is like Python4 for me.

<comment><USER15> Have you ever looked at Julia?

I mention it just because I've had almost a carbon-copy of that conversation but I showed them Julia and now that person actually is writing Julia for their startup. That person is doing technical chemical engineering stuff, so the fit is a bit more pronounced, but I think it's a neat language aside from that. Parametric types and multiple dispatch and lisp-macros, oh boy!

</comment></comment><comment><USER16> How can you help someone see the beauty and benefit of Typed FP without asking them to just trust you and spend a few months with it?

I used to dismiss this as academic noodling till I got tired of OO and started going back to my procedural roots with just plain functions organized into namespaces. I was pretty happy with it till the codebase grew to a point I couldn't keep track of the flow of data. Objects help you to some extent here since they group related values into one instance, but I didn't want objects anymore.

This was when I started seeing references to OCaml, especially "Why ML/OCaml are good for writing compilers" ([http://flint.cs.yale.edu/cs421/case-for- ml.html](http://flint.cs.yale.edu/cs421/case-for-ml.html)), and also saw a presentation by a programmer I respected where he built a general game playing engine in OCaml. Seeing someone use it for practical, advanced programming was the first catalyst.

Then Jordan Walke mentioned somewhere that he first prototyped React in OCaml, and shortly after they released ReasonML. The type system was amazing. All values are typed, even complex nested structures have a type. There are variants which mean I can express different shapes of the same value using types, and the compiler will tell me if I ever forget to handle a particular case of this variant.

I've been programming with Reason/OCaml for about six months now, and Typed Immutable Programming still takes me more time than just gluing together a pack of cards with imperative code. But once the code is written, it sits on an iron-clad foundation.

Most systems as they grow start to fold under its own weight, but here the accretion of code is an almost unmitigated good thing. It means my system's cognitive wealth is increasing without an exponential increase in maintenance cost.

But how can you help someone understand all this in a single conversation? A lot of people come to this because they worked on systems with pain points that Typed FP can address. But for most others who haven't had that sort of clarifying experience, what can you tell them to give it the non-trivial amount of effort it requires?

<comment><USER17> I'm not in the Typed FP world, but I found the concept of pervasive use of Sum Types making invalid states (according to the project domain) of composite structures _unrepresentable_ to be a pretty compelling nugget to chew on.

A lot of debugging is: This <object> has ended up in a weird state. Whereas the alternative could be that if the code compiles then it's impossible for that <thing> to ever be in a weird state.

</comment></comment><comment><USER18> The problem with F# evangelism is that it doesn't exist. No one is evangelizing F#; everyone is evangelizing functional programming. F# is the Python of .NET - it's multi-paradigmatic and you can do whatever you want. Sell it to people that way, and let them get into functional concepts later, or never.

F# has a huge opportunity in the enterprise. A ton of enterprise C# code is not object oriented at all, it's big, poorly thought out clumps of imperative script wrapped in methods and classes so it can be compiled or fit into the framework that's calling it. Sometimes it'll get a quick last pass run on it to make it "more object oriented", because that's what C# code is supposed to be; this usually just makes it worse. It's written in a scripting mindset: the developer needs to get things done, and adds code and bangs on stuff until it compiles and looks right when it runs in the debugger.

F# is actually well suited to this style of development, but it's hard to find anything about it, because every F# tutorial, book and blog post is actually about functional concepts, functional design, functional thinking and functional programming, including this one.

If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a _good thing_.

<comment><USER19> > If you want to sell F# to enterprise developers, show them how they can > write their C# code in it without having to pretend that it's object > oriented anymore, and how that's a good thing.

As enterprise consultant, for the types of customer projects I work with, lack of tooling support for Blend, WPF, UWP, EF, ASP.NET is a no-go to move from C# into F#.

<comment><USER7> Domain modelling in F# is lightyears beyond C#s. Parallel and concurrent development, not to mention actor systems (F#s built-in or Akka.net), are also leaps and bounds beyond the C# story. These are Enterprise issues. Identity management, default immutability, distate for null, and exhaustive pattern matching are all major Enteprise features that large, complex, and critical systems see measurable benefit from...

There is no barrier to mingling F# and C# libs to focus on specific tasks or parts of the app. Having application libraries in C# and domain code in F# is a common pattern. Particularly at the GUI level, extra-particularly with anything that uses databinding so your domain types can be used directly.

F# does not get the same amount of tooling love as C# for the "latest and greatest" from microsoft. If you look at the Enterprise track record of Microsofts "latest and greatest" since they started pushing ADO.net to present day... well, I would argue that's a huge benefit. Enterprise customers need tooling stability and platform stability, so letting ASPvReplacedInThreeMonths come and go without impacting projects is a big money saver.

<comment><USER19> > There is no barrier to mingling F# and C# libs to focus on specific tasks or > parts of the app.

Try that on .NET Native apps.

> F# does not get the same amount of tooling love as C# for the "latest and > greatest" from microsoft.

No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a productivy drop.

<comment><USER20> I'm not a C# programmer, but it seems to me that the productivity drop argument is weird. Your engineers might be in a local maximum, and it might be worth the _temporary_ productivity drop, if in the long run it would allow them to reach new (and better) heights. This, of course, is an outsider's supposition, and I understand that you're just conveying their point of view.

<comment><USER19> How it is weird having a productivity drop when everything that is done graphical by tools with a simple mouse click, must be done manually in plain code without any kind of visual assistance, beyond "compile and see how it looks like"?

<comment><USER20> No, I meant that bringing this fact as an argument is weird: I'm not arguing that there's a productivity drop, I'm saying that it's only temporary.

Furthermore, I have a few years of RAD development experience, and I know as well as you do that not everything may be coded with a couple of mouse clicks. As soon as you hit the business logic, you need to use the keyboard, you need to devise algorithms, you need to evaluate their complexities, and you need to code them down.

That being said, even just getting used to a new language gives you new insights about coding practices.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I'll go a step further. There's a problem with _language_ evangelism.

There is no "one best language" or even "one best programming style". Functional has worked for some people to address the problems they have, but not everyone has those problems.

For example: I once worked on a video switcher for TV stations. You have maybe 100 video sources, maybe 80 video destinations, and you can connect any to any. You also have about six different sources of commands to make connections. For responsiveness, each source has its own thread. So _the nature of the problem_ is one giant shared mutable state. The functional people come along, and they say "shared mutable state is evil; don't do that". Yeah, well, that's actually not bad advice, but it doesn't help me at all with this situation, since _I can 't avoid it here_.

There are other places where FP isn't the answer: Situations where you care about memory layout (high performance computing or just memory constrained), where one of the main concerns is sequencing (some industrial control operations, maybe robotics), where predictable timing is important (real time systems), maybe others.

Use the right tool for the job. FP is not the right tool for every job. Nothing is. The problem with evangelism is when it says "this is the One Right Way", instead of the humbler assertion "in some situations, this can help you with some of the problems that are slowing you down".

Don't get me wrong. FP has a good story. (Even if you don't use FP, learn its deepest lesson: _Control your state space or die_.) But FP is not always the answer. Evangelists might get further if they recognized that.

</comment><comment> d--b F# problems from a C# developer point of view:

#1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language

#2 compatibility with C# is poorly done. That F# functions cannot be consumed as C# lambda is a real mess. Boxing / unboxing doesn't feel FP ish at all. You often need to implement classes with interfaces to interact with C#'s core libraries.

<comment><USER8> > #1 tooling: visual studio integration of F# is poor. You don't get cross > language usage reference, so you lose all the benefits of static typic. > Projects and references are a mess. Being primarily a scripting language, it > feels like a toy language

Could you clarify what you mean here? Although things like Go to Definition and Find all References don't work across C#/F# boundaries (yet), but you absolutely get IntelliSense and the benefits of static typing. F# isn't a scripting language, although it does support F# scripts.

<comment> d--b You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down).

Also the benefits of static typing are that it makes it easy to refactor. Here if I change things in C#, I need to grep my F# scripts for usage, it's a real pain.

<comment><USER8> > You get intellisense alright. But using C#, I never need to #open the > namespaces myself for it to find the types I am using or the extension > methods I need. (Maybe this is because I use resharper, but still, it really > slows me down).

This is actually added in F# tooling for VS 2017! Both via a lightbulb code fix and with IntelliSense itself. If you have a reference to a .dll with symbols, the IDE can suggest an _open_ statements for you.

</comment></comment></comment></comment><comment><USER13> Not pertinent to the article but I guess to the people interested in this discussion.

The first in person F# conf in North America (to my knowledge) Open Fsharp Conf. is on Sept 28, 29 in SFO. ([http://openfsharp.org/](http://openfsharp.org/)).

My only association is I bought ticket for it.

</comment><comment><USER22> Good article. F# would find much better adoption if there were more FP style libraries out there. I have tried to move to F# but it's a real uphill battle when pretty much all sample code and most libraries are in C#. I would do it if I was alone but it's hard to convince a team of the benefits.

<comment><USER23> The problem is F# does not have a killer feature it has a list of nice features. Examples of killer features: Akka, RoR, browser monopoly.

</comment></comment><comment><USER24> The best way to get someone to tune out when you are trying to convince them to get out their _._ bubble is to casually introduce words that they don't know.

By doing this, you separate yourself from the listener, giving a clear delineation between the noob and the l337 wizard.

It also helps to feign surprise, "you dont know about monadic entropy lenses?" or use the word _just_ as in "Just run the parser combinator in reverse, its easy".

<comment><USER12> It's unfortunate tho, because for example what word do I have for the generalization that we call "profunctor" other than a profunctor. Even the words we use to describe a profunctor are "contravariant and covariant" and these words OUGHT to be more applicable to programmers but are not.

For many programmers, the axioms of what a function are (a calling point to code which is contravariant in a product and covaraint in a single return value), what objects are (a unique closure over functions values with a syntactically supported lookup of named values and a system-provided identity function) are so unvarying in their experience as to be synonymous with the word we use to describe it without needing further quantification. That gets tricky when you want to say, "Ah, but this unique way of thinking about this datatype lets us pretend it's a function and then we need to talk about what it needs and what it provides in more general terms."

Since functional programming is actually all about completely tearing down the world to everything but a series of functions, it's unsurprising it needs different words.

Finding a way to entice users to join in the functional party is really difficult because asking a programmer to do it is roughly akin to asking them to learn to program again. And don't get me wrong, I think you emerge from the other side of it better and more productive in every way, but it's difficult to prove that and more difficult still to convince people of it.

<comment><USER24> We can sell the vision without sound like a Pythagorean-cult of mathematics (functional programming). Hell, once I showed some of Python programming brethren pure functions they were hooked, HOOKED I tell you!

When I showed how to make an object system using closures, they were like, "Cool!"

Some people start with the math, some people finish with the math and others deny the math. But we can all be better programmers with functional programming. If our goal is to educate, our actions should be the opposite of alienation. Some people gravitate to FP because it is seen as hard, as bad-ass and want to show their mastery to others. Those people should probably not be teaching FP.

<comment><USER12> I think a disagreement about didactic methods and ordering is not what I was addressing. I just think at some point calling it a "Pythagorean cult" (and what, I wonder, are we murdering people over uttering?) is counter-productive.

I'm slowly recording several sessions, and I think about 2 hours in enough to introduce Purescript, explain the basics of Functors, Applicative Functors (which come nearly for free), and even explain, motivate, and use monadic functions. But I don't know how to do this without at least giving folks some words (Functor is a name as good as any, and every other name for Monad is at last as if not more intimidating

It's just at some point if we observe the shape of what we're doing, we can generalize in a useful way further (e.g., the lenses-banannas-parethesis approach).

</comment></comment></comment></comment><comment><USER19> I lost faith in F# the moment Microsoft decided it is not worthwhile to delay Visual Studio 15.3 to properly support it pushing devs to VSCode, and the lack of roadmap for .NET Native/UWP.

So first make F# a first class citzen on .NET and maybe many C# devs will look again to it.

</comment><comment><USER25> Microsoft promoted this idea that F# is for mathematicians and engineers, so its no wonder that people pick this up. And I'm not sure who is pushing this idea that F# is not fine for OO work. It has all those features. So starting with F# as a "better C#" \-- there's nothing wrong with that. Over time I think people will come to view OO as suboptimal, but in the mean time F# is just a better language to use than C#.

MS hasn't funded F# enough, and has crippled the marketing on it to continue to push C# rather than admit they've made mistakes. The tooling issues and other random incompatibilities are why I don't use it as much as I used to - it's too much friction.

<comment><USER26> No one who knew what they were talking about at Microsoft said F# was for mathematicians and engineers. It's a myth pushed by C# programmers and idiots. It's nonsense and you shouldn't repeat it.

People at Microsoft repeatedly said "Simple Code for Simple Problems". C# programmers don't like repeating that.

<comment><USER25> Doesn't matter if they didn't know what they're talking about, that was what was written on the Microsoft sites when comparing C#, VB, F#. F# was always pigeonholed into scientific and financial categories, never aimed at general code.

I'm only repeating it to point out that MS itself did poor marketing for F#, clearly favouring C#.

<comment><USER26> Microsoft didn't promote that idea. Some random people at Microsoft did, a very long time ago. Just forget about it and move on.

</comment></comment></comment></comment><comment><USER27> F# isn't generally solving problems... well, it can but rarely at the same level as it introduces problems.

People can have awfully cavalier opinions about switching languages, but it's a very heavy-weight change with strong implications for existing code, dev training (new syntax, new patterns, new pitfalls), available frameworks (often resulting in more new patterns), technology stack (which can reverberate out to testing, scalability, etc.)

Even if you assume F# is only better than C# and in no way worse, it's usually major investment to switch... typically at least an order of magnitude bigger than that bullet list of ways F# is better than C#.

</comment><comment><USER28> A great take on this topic is a talk by Evan Czaplicki, creator of Elm, another functional language: Let's be mainstream! [1] The conclusions are more or less the same than the article, but Evan goes into a lot more depth. And in my opinion, as a result, Elm does very good in this regard.

[1] [https://www.youtube.com/watch?v=oYk8CKH7OhE](https://www.youtube.com/watch?v=oYk8CKH7OhE)

</comment><comment><USER29> Good post. I really hoped for some f# code after listing all those scenarios where c# fails.

Anyway. I work in a c# shop with a large monolithic code base developed by a small team with lots of fluctuations over more than 10 years. I have no functional programming experience at all.

I love c# because we actually try to keep the code as simple and linear as possible and only introduce complexity in certain areas if performance requires it. Yes there are hacks and dirty code passages, but if you stick to basic code constructs they are easy to decipher.

If your facing more than 10 million lines of code you start to appreciate simple code. Moreover if different developers, which come and go, are working on it. Living without refactoring and inspection capabilities of resharper is nearly unthinkable to me.

Now, how would you convince someone like me to try out f#?

There are only drawbacks: Obscure things we would need to learn (type classes? monads? xyz?). Probably hard to read, 'clever' code. A mixture of c# and f#. Unknown library, build and deployment issues. And I guess, f# developers are rare around here.

Even after reading this post, there's unfortunately no convincing reason for me and management to give f# a try...

<comment><USER16> I'll tell you my experience. I never liked the arguments about reduced bugs or concise code. As a programmer the reason I would use F# (or OCaml, or Haskell, or Elm, or PureScript) is because it increases by day-to-day well-being.

I'm happier writing Typed FP because the system is very concrete in my head as I work with it. In a dynamic language, there is always a nagging uncertainty about the system - if you're using dictionaries to pass data around, you don't have certainty in what keys it'll have, and what data will be available inside it, and what could possibly be null.

When you add a new kind of a domain object (a Guest user in a user management system for example), you have no idea where all you need to handle it. You fix the obvious places, and do a text search, and find a few more. And the rest you fix over time.

The runtime robustness of untyped systems in my experience generally is a function of time. The more it sits in production, the more bugs we discover in the most commonly trafficked codepaths. We fix them - duct tape works - <USER2> then it sits and chugs along. (Robustness to change is another matter altogether).

But if you use a Typed Functional language, when you introduce a new domain object the compiler will tell you exactly where they are being used and will refuse to compile till you've made sure you're handling it in all the right places.

Value-based programming (ala Immutability) lets you write code as if you were writing mathematical definitions (high-school mathematics; no category theory or monad). While we can be disciplined about not writing mutating code, there is a real difference between 99% confidence and the second-guessing it entails, and just not having to worry about it at all. Everything is a value. There are no objects/references.

All this adds up to a state of clarity when you program. You don't have to keep second guessing yourselves; you don't have to do defensive checks that makes you feel a little bit ugly inside; you don't have to deploy worrying about the unknown unknowns that can break your system.

<comment><USER30> In Delphi, I hide this kind of complexity behind methods which check everything for nulls and types at runtime. I imagine I'd do the same thing in C#, too. So if I have json = TJSON.parse('{}'); json.Node['something'].Nodes[0].each(procedure(pNode: TJSONNode) begin; list.add(pNode.GetValue<int>()); end); { Nodes and Node properties actually create empty nodes and keep a debug string to show you where exactly your code failed so you can go back and take a look at which assumption was wrong. I then cleanup everything when the main node is freed.

So my point is; it all depends on how you code something, the language may do it at compile time to prevent runtime assertions, but that also comes with extra baggage (I assume you need to write more code to define your types, function call conditions and mappings)

</comment></comment></comment><comment><USER31> I honestly don't think there much wrong or a problem with F#

I do follow F# somehow, and compared to other languages .. it actually seem to have a very pragmatic and active community

The F# community build a lot of interesting frameworks, suave, websharper, type providers ... to name a few

I dont think, anything will look popular, when compared to Java , C# or Python .. but compare it to Haskell, Ocaml, Clojure.. Dart, D, Nim .. and the plethora of languages that compile to javascript , and you will see F# is not doing so bad

<comment><USER31> I will just make one criticism ... it is sadly somewhat awkward to install F# even on windows

and they do need a good ide

if you go to the F# .org site, installing F# without installing visual studio, is a 4 step process .. and when I tried it on windows 7 it just didnt work for me

i eventually gave up and install visual studio on linux, thing seems better, but .. still missing a solid ide

<comment><USER32> The first class IDE for F# is VS Code + Ionide. The language service backend for F# is also very well supported for emacs.

<comment><USER33> The first-class IDE for F# is the full Visual Studio, not VS Code + Ionide.

<comment><USER26> VS Code is now recommended by Microsoft for F# + .NET Core. Get with it, you're behind the times.

<comment><USER33> It's only recommended temporarily, until the issues get ironed out. It doesn't make it THE first-class F# IDE.

</comment></comment></comment></comment></comment></comment><comment><USER34> The problem is that people who are drawn to F# tend to be a certain kind of people: generally stronger in CS, but also more prone to think that changing programming language is a solution to a wide variety of problems.

Many people are not like that, and stuff like a small community, worse tools and toolkits and less programmer availability are actually a huge deal, capable of tanking a good project, whereas having a 10% better language isn't a huge gain.

It's that simple.

</comment><comment><USER35> For me, I only got into .NET because of F#, and even then I pretend C# doesn't exist. I tried learning OCaml, it has cool features, like parametric modules and GADTs. But I always ran into the issue of irreproducible builds. This didn't happened in F#.

I eventually tried F# because it was close enough to OCaml and while I was learning OCaml I always referred to this site [http://fsharpforfunandprofit.com](http://fsharpforfunandprofit.com)

I'm definitely an F# evangelist at work, but we are not a .NET shop. But I was would say that the introduction of ML features in other languages, (Swift, Rust) are good for F# evangelism, because it makes these concepts more familiar. I think the focus should be on moving F# away from .NET because F# itself, it is much more accessible that its cousins OCaml and Haskell. And if Microsoft won't give proper support, the community should move to other platforms. Some discussions are already happening here [https://github.com/fsharp/fssf-ask-the- board/issues/4](https://github.com/fsharp/fssf-ask-the-board/issues/4)

<comment><USER19> The difference being that Apple is quite vocal that Swift is the future of app development on their platforms, while Microsoft is trying to push UWP as the future of Windows apps (supported languages VB, C#, C++ and JavaScript).

<comment><USER36> UWP supports JavaScript? Cool, in that case a bunch of transpilers should work (once bindings are written) ... people can just use their preferred languages: OCaml/BuckleScript, F#/Fable, TypeScript, PureScript, et al.

I've actually written and run JScript scripts on Windows Script Host with BuckleScript, it's really nifty. You write strongly-typed code and get a JS artifact that can run on your target platform. For the curious, an example: [https://github.com/yawaramin/wsh-bs-test](https://github.com/yawaramin/wsh- bs-test)

</comment></comment></comment><comment><USER37> Businesses and developers generally won't switch languages. Evangelism makes people curious which means new businesses and new projects some times picks a new language.

I'm a C# dev since 14 years (single project) hoping my next project will be an F# one. That might mean I have to switch jobs - and I hope there are enough F# shops when I need one.

</comment><comment><USER38> We're singing from the same hymn sheet

[https://github.com/mcintyre321/OneOf](https://github.com/mcintyre321/OneOf)

[https://github.com/mcintyre321/ValueOf](https://github.com/mcintyre321/ValueOf)

</comment><comment><USER39> I'm a C# developer, love the language and how easy it is to express what's in my head as code.

I recently had a chance to play with F#. After being completely lost for a bit, I found I had to really rethink how I was reasoning about problems and the right way to solve them.

But that's the point I want to make. I don't expect to be good at FP for a while - it's going to take time to grow, along with the tooling and community. But I appreciate having a way of framing a problem differently, and like the direction F# is headed.

It doesn't mean I'm going to drop C# any time soon, I'll likely just use both - e.g. my more math heavy libraries will be F#, and my networking and Web API code in C#.

</comment><comment><USER40> I think that the problem with F# is that it feels more or less abandoned by MS itself.

It's already F# 4.x, but I can't remember any significant new features in last 3 releases at least, neither in language nor in the standard library.

<comment><USER26> That's because F# 1.0 was bascially a more powerful language than C# 10.0 (C# still doesn't have proper pattern matching for example, or discriminated unions)

For features added see [https://en.wikipedia.org/wiki/F_Sharp_(programming_language)](https://en.wikipedia.org/wiki/F_Sharp_\(programming_language\))

Named union type fields Extensions to array slicing Type inference enhancements Printf on unitized values Extension property initializers Non- null provided types Primary constructors as functions Static parameters for provided methods Printf interpolation Extended #if grammar Support for 'fixed' Tailcall attribute Multiple interface instantiations Optional type args Params dictionaries Struct tuples which inter-operate with C# tuples Struct annotations for Records Struct annotations for Single-case Discriminated Unions Underscores in numeric literals Caller info argument attributes Result type and some basic Result functions Mutually referential types and modules within the same file Implicit "Module" syntax on modules with shared name as type Byref returns, supporting consuming C# ref-returning methods Error message improvements

<comment><USER26> For library, see [https://github.com/fsharp/fslang- design/blob/master/FSharp-4...](https://github.com/fsharp/fslang- design/blob/master/FSharp-4.0/ListSeqArrayAdditions.md)

<comment><USER33> All those features mean nothing to seasoned .NET developers when you can't use the language natively on Microsofts primary application platform.

<comment><USER26> You can gripe about your fav UI stack not being supported just the way you want (you don't seem to have any other complaints), but your claim the language is not improving is wrong.

<comment><USER33> > You can gripe about your fav UI stack not being supported just the way you > want (you don't seem to have any other complaints),

.NET Native and UWP are not just UI,

> but your claim the language is not improving is wrong.

You're confusing me with the parent commenter [https://news.ycombinator.com/item?id=15029008](https://news.ycombinator.com/item?id=15029008)

</comment></comment></comment></comment></comment></comment><comment> Joe-Z I'm currently a C# developer, but have tried functional languages before. As mentioned in the article, I think a lot of people are satisfied with the functional capabilities C# already provides. I don't need to write functional code all the time, but if I can model a problem more elegantly using higher- order functions I will gladly do that.

I'd be interested to read a more in-depth description of the recent project which the OP chose to implement with F#.

<comment><USER41> Only thing is actually missing from C# now to be a "proper" functional language is a way to declare (and pass a function arguments) immutable objects.

</comment></comment><comment><USER42> I built Tsunami IDE. It is a F# IDE. I built it before VSCode or VS Community came out. I built it as a test to see if cost of Visual Studio was blocking adoption of F# and the ideas that F# codifies. The experiment was successful, I got my answer, and the answer is no. Even with free tools people have a hard time adopting F#.

First let me address those who are asking for Type Classes and Dependent Types. These would make the compiler too slow. The F# compiler works in the 100s of ms and the 100s of MBs ram. Where Scala is in the 1000s of seconds and the GBs of ram. People will give up on code completion if it takes more than 500ms and they generally don't like waiting longer than 200ms. Separately Martin Odersky (the creator of Scala) laments that the more advanced language features attracted the wrong type of people to the language and flooded the internet with overly academic tutorials.

I put a lot of the blame for the lack of F# adoption on Microsoft. Part of this is to do with the Dev Div vs Windows war that almost deprecated the whole .Net ecosystem. If Windows 8 wasn't such a disaster it's likely .Net would have been deprecated and would never had been open sourced. (at least something good came from Windows 8). Part of this war also ended with a lot of the best .Net people leaving to go to Facebook. This brain drain has really hurt Microsoft and I doubt they'll ever recover. Most of the old hands that know better are aging out and the new people at Microsoft don't know any better.

As for tooling, Microsoft has done and continues to do a bad job with F# tooling. There is is a not invented here culture at Microsoft Redmond which includes being hostile to Microsoft Research. Visual Studio is a bucket of bandaids and it takes an army of people just to keep it going. F# is given a low priority. It's worse with the latest release because they've gone overboard with compiler features with the Rosario release and have made it dog slow and painful to use. I hope they can fix it with updates but who knows. You can still get older versions. It's very possible to build a really good IDE around the F# compiler but unfortunately Microsoft refuses to do so. Thankfully, it looks like there are some good alternatives becoming available.

In comparing Scala and F# adoption, Scala has Hadoop/Spark which is a killer product that can earn a consultant a lot of money. The fact that C# is a better language that Java means there are more Java refugees going to Scala than there are C# refugees going to F#.

Thankfully Don Syme has made F# completely open source. Now with .Net being open source we no longer have to worry about Microsoft shooting itself in the foot again.

I make my money writing a product written in F# and can attest that F# is one of my big competitive advantages. I highly recommend it.

<comment><USER8> > There is is a not invented here culture at Microsoft Redmond which includes > being hostile to Microsoft Research.

I'm 100% okay with criticism about things and think it's a good when people voice it, but this is not based in reality.

MSR (and Don) work together with different groups in Azure and and the developer division. It's not perfect - we are a large, multinational corporation with the same problems in communication across organizations as any large, multinational corporation - but calling the relationship hostile is misleading, harmful to the F# community, harmful to those of us who work on F#, and harmful to F# growth. I really don't appreciate spreading this sort of stuff.

</comment></comment><comment><USER43> F# evangelism should start with small thing. Start as library or component. The main project is still c#. Just like react approach

</comment><comment><USER5> I'm the lone F# developer in a shop full of experienced and talented C# developers. I have clout, but not enough to convince any of them that F# is a better choice for many of our purposes. It's frustrating, but I try to understand that people are just naturally resistant to big changes like this.

<comment><USER22> Same for me. Do you think that in the end F# would be that much better for good C# devs? I am not so sure.

<comment><USER44> Having made the analogous switch from Java to Scala, I think it's the good devs that benefit the most. Functional languages give you more scope for factoring out commonality, avoiding repetition, reusing existing library functionality - exactly the things that make good devs better than bad devs.

</comment></comment></comment><comment><USER45> Very nice list of very practical problems functional languages like F# are meant to address. After a certain amount of experience, pretty much every OO developer will have experienced these problems, so makes for a good entry point to describe the benefits of a functional language.

</comment><comment><USER33> The real problem with F# is that the .NET Native UWP runtime isn't .NET compliant, therefore doesn't allow F# code.

See this link explaining the problem [https://news.ycombinator.com/item?id=15026396](https://news.ycombinator.com/item?id=15026396)

We wouldn't need to evangelize F#, if it just worked everywhere C# does with proper tooling support.

<comment><USER26> Barely anyone uses UWP. It's irrelevant.

<comment><USER33> Nonsense, UWP is everywhere

[https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many...](https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many_years_still_no_net_native_nor/dlp0muc/)

[https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many...](https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many_years_still_no_net_native_nor/dlpapbk/)

[https://www.reddit.com/r/programming/comments/6tdqmv/after_s...](https://www.reddit.com/r/programming/comments/6tdqmv/after_so_many_years_still_no_net_native_nor/dlk0rl6/?context=3)

</comment></comment></comment><comment><USER15> I've experienced sort of a diagonal problem to this.

F# is way too entwined with .NET to be immediately useful to programmers familiar with Ocaml or Scala or Haskell, etc.

Some of the basic List. _, Array._ stuff is simple enough, but then you start talking about interfaces and classes and members and all this stuff that doesn't really translate from C#->sanity very well.

I know people love it, but I've long considered C#/Java to be kludge languages on platforms they don't deserve. The JVM might be the most impressive software engineering marvel I can think of, and yet on top of that christmas tree stands a tall, stinky shit.

I'd love to see F# as a F#-first platform, and offer .NET interop as a secondary language feature.

I've also noticed a concerning trend in F# circles that """diversity""" should be celebrated. There is no merit in your skin color or your genitals. If you can hack well, you deserve to do so. End of story.

A counterpoint to the F# being poisoned by .NET is Clojure. Look how well Clojure did Java interop and how "not a big deal it is." Immutability everywhere, functional by default, and it feels painful to do things the Java way in Clojure. F# doesn't mind at all if you sink to .NET trickery and in some cases require it.

I could think of more, but off the top of my head, the .split instance method comes to mind. I have a Markov Chain kata that I spring on new hires to see how they do things, and .split is an instance method, which is counter- intuitive to how functional problems are solved because you don't just |> into it.

I'm waiting to see where Clojure goes with core.type before I abandon F#. I really WANT to keep riding the F# train but it causes quite a few headaches. Not more than it solves, but more than other solutions that I've considered.

To balance this out, I'll say something I really love about F#. Units of measure. Few languages have this, and the kind of numerical work we do means we really get our mileage out of UoM. I always see finance horror stories or like the excel rounding bug, it makes me wonder exactly how much money UoM has saved us from losing through some innocent type somewhere. Debugging money code is way easier when you can verify all the conversions separately from the logic. It feels like cheating, to be totally honest. I know there are big shops out there that don't have UoM in their tools, and I used to feel bad for them, but now that we have it, I can't help but NOT feel bad for them.

Anyways, yeah, F# isn't perfect. There's plenty to be said also for the amount of progress they make with language updates. It grows a crazy amount between major versions, and I haven't had too much problems yet taking old F#3.0 code and revitalizing it. Very pleasant experience in that regard as well.

<comment><USER46> 'There is no merit in your skin color or your genitals.' can't disagree with that.

<comment><USER47> But there's dismerit in monocultures - maybe those F# folks are pleased to be avoiding that.

Plus, if you're situated in a historical process (like we all are) then arbitrary things become important. Accidental weaknesses such as being perched on the CLR and tethered to the hopes, dreams and capabilities of common-garden C# enterprise developers invert strangely into advantages - in the case of F#, it makes for a very friendly, welcoming ecosystem.

</comment></comment></comment><comment><USER48> 404

<comment><USER49> maybe try again? wfm</comment></comment>


Facebook Makes You Set Facebook.com As Your Homepage In A Very Clever Way - <AUTHOR> http://digitizor.com/2010/11/27/facebook-makes-you-set-facebook-com-as-your-homepage-in-a-very-clever-way/

<comment><USER2> "Makes You" is stretching things. "Entices you" would be more accurate.</comment>


Vi Hart: How We Reopen - <AUTHOR> https://www.youtube.com/watch?v=HhRQxk9QA-o <comment><USER2> It describes a plan from a group of people about how best to get life in the USA back to normal re the virus.

First shock after 5 seconds: Nooooo! She's at - _Microsoft_ now?!? Arghhhh. Tragic. Then after a few minutes...I realized nothing was hand-drawn. :-( Also "We" means "U.S.A."... I guess I'd never felt "excluded" from her stuff before, in any way. (I'm not in the USA, like most HNers, I believe.)

<comment><AUTHOR> Last I saw, she was working alongside Jaron Lanier on cool, well-funded R&D? Seems like a great place to be for a curious mind!</comment></comment>


E-Stop and Fuel, software that keeps you awake at night - <AUTHOR> https://jacquesmattheij.com/e-stop-and-fuel <comment><USER2> Rather than the Therac-25 debacle, I would more recommend looking into the Toyota 'unintended acceleration' case. And the legal fallout from that. Because it is terrifying. Toyota was essentially as grossly negligent as it is possible to be. And the result? The court said there existed no standards they could be held legally liable for violating. So your self driving car? It will be developed by junior developers hired as cheaply as possible, driven like slaves by business-oriented managers who only care about meeting schedules, not given the tools or information needed to do an effective job, with testing time cut short and any claimed 'industry standards' for safe coding ignored. The automotive industry had 90+ coding practices they list as either 'required' or 'recommended'. Toyota followed 4 of those in their code. And the court said this was OK. Do you think Toyota spent tens or hundreds of millions of dollars rebuilding their entire development infrastructure, hiring more competent software engineers, firing the business managers who got people killed by rushing an unsafe product to market, and putting the engineers in charge of all future decisions regarding scheduling and release? No, of course not. If anything, they probably saw it as carte blanche to make things worse.

<comment><USER3> Wasn't the cause of the "unintended acceleration issue" hardware and driver error related rather than software related? That's what I've read in one book about Toyota management (the Toyota Way) and also a Wikipedia entry on the topic says:

> Toyota also claimed that no defects existed and that the electronic control > systems within the vehicles were unable to fail in a way that would result > in an acceleration surge. More investigations were made but were > unsuccessful in finding any defect until April 2008, when it was discovered > that the driver side trim on a 2004 Toyota Sienna could come loose and > prevent the accelerator pedal from returning to its fully closed > position.[4]

Based on those two sources it seems the issue was hardware related, and Toyota may have tried papering over the matt issue. The faulty matt design issue doesn't support your claim of shoddy software practices and hiring underpaid junior developers. That may still be the case but it appears not to have caused the SA issue.

<comment><USER2> There was a hardware issue, Toyota told their engineers one of the boards would have ECC RAM, but went cheap and used non-error-correcting RAM, but that wasn't the primary issue. After the court case ended, the code was subjected to static analysis by various researchers and a litany of problems were immediately found. Race conditions, uninitialized values, lack of fail-safe structure, spaghetti code, etc. I read a much better summary article awhile back that talked about automotive industry standards for embedded design and the working environment at Toyota (where developers had no static analysis tools, and didn't even have access to a bug tracker), but this article covers some of the points. The software was definitely at fault in many of the cases that killed 38 people:

[http://www.sddt.com/Commentary/article.cfm?SourceCode=201311...](http://www.sddt.com/Commentary/article.cfm?SourceCode=20131104tbc&Commentary_ID=140)

<comment><USER3> That article makes a clearer picture of the issues you were hitting upon. Especially the later software audits. Perhaps you could add it to the Wikipedia page?

</comment></comment></comment></comment><comment><USER4> For modern industrial applications, the safety circuit is often (edit- see child comment's note on safety PLCs) managed by discrete safety relay hardware such as the AB GuardMaster or Pilz PNOZ. There's a good chance these weren't even available at the time of OP's application!

A common configuration involves emergency stops, guard doors, light curtains, etc. being wired in a pair of loops with the relay. The relay continuously monitors both loops (usually with a phased pulse train), and any interruption or crossover will trip the unit. Only when the loop states return to nominal will the relay permit a reset to re-enable the outputs.

The safety relay's outputs are generally connected to dumb hardware interlocks on the various dangerous bits of the machine.

<comment><USER5> As a programmer, I like this approach to human safety for robots. By putting electrical interlocks on the doors that expose humans to the robot you can make it impossible for a software error to hurt a human.

For some applications where you need to have humans working in the same area with the robot things get a lot hard. You probably need some software involved in enforcing speed limits for robots. The compliance engineers I've talked to say getting safety certification for software is quite arduous. In this case the off-the-shelf solutions the parent child comments mention become valuable.

<comment><USER6> Just slow down machines is not enought. I'm still stunning how much the operators trust on things like E-Stop and Safety-Doors. They open the doors, don't even look and go into the machine with there hands. Most people have no idea what's behind a E-Stop and Safety-Doors these days. Also how much paper work each time .. sadly the paper part grows very fast .. and does not really help at all. Just worthless paper.

<comment><USER7> > I'm still stunning how much the operators trust on things like E-Stop and > Safety-Doors. They open the doors, don't even look and go into the machine > with there hands.

Wow. Where I am we sometimes do this, but never without real thought. And, generally, we revisit that part of the process again and again over time.

One example: initial setup of a CNC machine part. If you don't have $50K-$100K, you are setting this up by hand. You are moving the cutting head while your hand is in the same space. If you screw up, it probably won't rip your hand off, but you will likely wind up with a solid, painful gash and it might break a small bone if you get really unlucky.

People don't respect servos enough. They're remarkably powerful and probably moreso than you expect.

<comment><USER8> > initial setup of a CNC machine part. If you don't have $50K-$100K, you are > setting this up by hand.

Curious what specifically you need your hand inside for? Do you simply mean the machine is on (though entirely inactive) while putting the part in, touching off the part slipping the business card in and out, or something else entirely?

<comment><USER6> It's not just about CNC machines. All automated machines have to have E-Stops and so on. Mostly operators open door because something is mixed um inside. (To many bottles, broken bottles, broken paper, broken sensor, wathever ..

Of course as more often you can build the same machine, as better you can work out details. But sometimes there is just "one" machine. Then usually have to work out the the flaws first ..

A friend from school cleaned a CNC mill while the machine worked. The safety door was manipulated and the 2D table drove over his hand ..

</comment></comment></comment></comment></comment></comment><comment><USER9> When I was the CTO & VP of Engineering for Wayport (public, mostly hotel Internet) we designed an Ethernet switch that could use Home PNA or Ethernet PHYs. (Later adapted to also offer VDSL to an in-room modem.)

We also designed our own 802.11 access points.

All of our competitors had at least one fire. In a hotel with hundreds of people asleep. It didn't matter if they used commercial gear or not. Every one of them had a fire.

We never had one, but I was obsessed with not hurting anyone because we had missed something.

And yes, it kept me up at night.

<comment><USER10> I'm not following, what caused the fire?

<comment><USER11> I'm not him, but probably either shoddy PSUs and/or there were lithium batteries involved. It's the curse of "modern" equipment.

</comment></comment></comment><comment><USER12> > needed to be re-written because the source code could not be produced

Is that a diplomatic way of saying someone lost the source code?

<comment><USER13> They might not have paid for a source code licence. or they did, but they never made sure they had a copy, just left it with the developer. Surprsingly common for companies to get a big binder of paperwork, an installer disk, and consider it done.

</comment></comment><comment><USER14> Can relate. I 'stayed awake at night' when I had to write a program to calculate salaries.

<comment><USER15> Ha! I once wrote a program to calculate commission for the sales people at our company. I remember the director telling me he would love my numbers to be true, but thought it best I had another look. Fat fingered decimals could have resulted in some expensive commissions!

</comment></comment><comment><USER16> This was an enjoyable read. While I don't often lose sleep over my code, (it's my kids that cause that), I do often find that my mind is working on solving coding puzzles in my sleep as I will frequently wake up with a spark of insight.

</comment><comment><USER17> My own personal "staying awake at night" case is an application that connected to an ancient version of Banner (A big kludge of an ERP system for universities) to handle new applicants' enrollment process and billing. I'm rather skittish when directly handling money, doubly so when the code was all written in Perl (Which I had to learn in order to re-implement in far more readable PHP, the lesser of two evils, natch) and extremely poorly documented. In retrospective, I should not have accepted a job like that.

</comment><comment><USER18> > a fuel estimation program for a small cargo airline > ...floating point > computations

Hello, rounding errors. Oh hell no.

<comment><USER19> Please. Don't kneejerk. Any floating point errors will be multiple orders of magnitude smaller than than the accuracy of either the fuel gauges or the pumps.

<comment><USER11> Did you know in the US it's essentially against the law to use floating point math on currency? The situation is more complex than I simplified here, however the complexity is on the order than you'd need a lawyer to explain it to you to really appreciate it.

You can call it a knee-jerk reaction, but the law itself clearly has that bias, and for good reason.

All regulations were paved in blood.

<comment><USER20> Not just the US, IIRC financial institutions around the world are required to do decimal rounding. OTOH I don't see why you would even use floating point for money. Just scale your integers to the required precision (and make sure you've got enough bits for the kind of amounts you need to be able to handle) and you're good.

</comment></comment></comment></comment><comment><USER21> Just a plug for the RISKS Digest, now in it's 32nd year of operation:

[http://catless.ncl.ac.uk/Risks/](http://catless.ncl.ac.uk/Risks/)

</comment><comment><USER22> Geez, and I thought I was stressed after I wrote software that would automate computing someone's pay bonus based on efficiency metrics.

</comment><comment><USER23> So how can we approach safety in a systematic manner?

Clearly 'blame' isn't an appropriate response. It has to involve tooling.

<comment><USER24> Well before tooling is considered, it has to involve people and process. At the highest level, you must have a culture of "blame the process, not the people" or people will do what is natural when things go wrong: try to cover it up and avoid being blamed.

There are procedures in various safety-conscious industries for handling this kind of development. I like that you used the word "systemic" because it is literally a _systems_ issue, not a software, or electronics, or mechanical issue. The entire system has to be considered and analyzed for potential faults.

I spent over a decade writing code for medical devices and while the software aspect of these systems was the most advanced in terms of development process (unlike what many on HN seem to think :-), everything we did had to be considered from a system perspective because even if the individual parts were designed properly, it was possible for the interactions between them to cause problems.

<comment><USER23> I strongly agree with your emphasis on systems.

</comment></comment></comment><comment><USER25> Thank you for sharing this. I enjoyed imagining scenarios so different from the ones that rob MY sleep at night.</comment>


The Rise of Synthetic Audio Deepfakes - ajay-d https://www.nisos.com/white-papers/rise_synthetic_audio_deepfakes <comment><AUTHOR> My all-time favorite audio deepfake is Nobel prize winner Milton Friedman reading the lyrics to the 50 Cent track "PIMP". It really captures Friedman's tell-tale cadence and idiosyncratic lilt: [https://www.youtube.com/watch?v=4mUYMvuNIas](https://www.youtube.com/watch?v=4mUYMvuNIas)

</comment><comment><USER2> There is already a large problem with political ads cherry picking and slicing audio and video to cheat viewers. I really worry that deep fakes will take it to another level completely. I fully expect the current administration to eagerly adopt it if available.

<comment><USER3> I just assume if a politician is speaking they are lying, at best misleading. Add in marketing, I assume it is a lie, regardless of political party.

<comment><USER4> You still lose. There are players who don't need you to believe them, as it is sufficient for them if people cannot trust each other.

</comment></comment></comment><comment><USER5> This might be paranoid. But I've established a protocol with some people in my life. Should someone with my voice ever contact them and ask for money (because emergency bla bla), nothing is to be done until a passphrase is mentioned. It's only a matter of time, until someone gets significant voice data and related contact numbers and proceeds with using those voices to train a model. Afterwards, that model will be used to real-time fake the original voice in a scamming attempt.

<comment><USER6> That's good practice. Sadly these kinds of scams already happen without the effort of synthetic voices. Scammers call an older person and say "Hey Grandma, it's me your grandson. I need $500 for bail right away!" With the help of Facebook they can learn names and details to sound more convincing.

</comment></comment><comment><USER7> Recently a friend changed her number and told me via text. Before adding her number i asked her a question that she and only I would know like who sat next to you at the old office.

Think im going to keep doing this type of verification. It may annoy friends and family, but not sure how a hacker could ever know such small details between you and another.

<comment><USER8> Very good idea. A few years ago, I had a "friend" text me asking for emergency funds. It seemed wonky but within the realm of possibility. I asked a question about a mutual friend from the past revealed it as a scam.

</comment></comment><comment><USER9> There is an annual challenge for synthetic voice detection, ASVSpoof, that evaluates submissions on different types of attacks to speaker verification systems: text to speech, voice conversions and replayed attacks.

The conclusion from the 2019 evaluation [1]: _known_ synthetic deep fakes are fairly easy to detect using simple models with very low error rates (even high-fidelity techniques with Wavenet vocoders).

[1]: ASVspoof 2019: Future Horizons in Spoofed and Fake Audio Detection speech ([https://www.isca- speech.org/archive/Interspeech_2019/pdfs/22...](https://www.isca- speech.org/archive/Interspeech_2019/pdfs/2249.pdf))

</comment><comment><USER10> > Deepfake technology is not sophisticated enough to mimic an entire phone > call with someone.

With modern voice conversion technology it is perfectly possible actually.

<comment><USER11> Voice imitation isn't just timbre.

It's prosody, rhythm, accent, word choice, and so on.

By the time you've mastered all those, you're practically halfway to becoming a professional voiceover artist.

Remember, trained voiceover artists have been mimicking voices for a long, long time. Their timbre isn't always perfect, but faking voices doesn't need deepfakes.

<comment><USER12> If you're looking for it sure. But I'm willing to bet existing technology is sufficient to catch an awful lot of people off guard. Hearing a familiar voice is usually quite disarming.

</comment></comment></comment><comment><USER13> Audio "deepfakes" have been worked on much longer than ones for video, although video deepfakes have the added issue of deep-faking synchronized audio. Today's consumers don't seem to be bothered by video deepfakes if they play to the beliefs of the audience.

</comment><comment><USER14> Useful example is how the Joe Biden Burisma phone call that bubbled up through Russian media was fabricated. I pulled it apart with ffmpeg and there were a number of artifacts that showed editing and splicing.

If you're handy with ffmpeg and python, you can assess their veracity pretty easily. Of course, if I were on a political ratf'ing team, I'd use the same tools to add those artifacts to a copy of an offending (real but off message) stream and amplify the distribution of that fake-faked version with a debunking press release handy, so YMMV. While the Biden thing wasn't a deepfake directly, (shallow fake?) we're going to see tons of actual deepfakes around the election.

IMO, elections are no longer between candidates, they are a war on truth for domination of the narrative - office is the effect. A campaign that focuses on what happens once the war is over is daydreaming about the future and distracted from the present and this will lose them key battles. For this reason, I think deepfakes are going to be the biggest weapon in campaign arsenals for the near future. Interesting times.

<comment><USER15> I'm legitimately not sure democracy will survive modern, sophisticated propaganda techniques, plus an open, international Web, plus losing the ability to more-or-less trust audio and video recordings that we've grown used to over the last hundredish years. Between state actors and, eventually if not already, transnational corporations waging info warfare, I kinda doubt the institution can take it. Too much info, too fast, from too many sources.

<comment><USER16> I wonder what encryption and key based techniques can be used to verify the authenticity of audio and video records in the future.

<comment><USER17> > I wonder what encryption and key based techniques can be used to verify the > authenticity of audio and video records in the future.

None, since encryption isn't the answer to this problem. Take Romney's leaked "47%" comment [1] or Hillary Clinton's leaked "deplorables" comment, how would encryption have been useful to either verify the recordings' authenticity or reject them if they had been a deepfakes? It wouldn't have, as those comments were meant for private audiences, so neither of them would have officially signed them. If the encryption could trace the recording back to the individual that made it, then the leaker might decide never release the recording (since they don't want to be outed). And if all the encryption can do is trace back to a random device, why not just get a random device to sign your deepfake?

[1] [https://www.npr.org/sections/itsallpolitics/2012/09/17/16131...](https://www.npr.org/sections/itsallpolitics/2012/09/17/161313644/leaked- video-purports-to-show-romney-discuss-dependent-voters)

[2] [https://www.npr.org/2016/09/10/493427601/hillary-clintons- ba...](https://www.npr.org/2016/09/10/493427601/hillary-clintons-basket-of- deplorables-in-full-context-of-this-ugly-campaign)

</comment></comment></comment></comment><comment><USER18> The images of spectrogram analysis between the real and fake voices seemed to be distinguishable by the human eye. Can a image model be trained to detect fake voice spectrograms based on pitch and tone choppiness?

<comment><USER19> The issue is that if you can measure it, you can train an AI to beat the other AI detecting it.

As Pilate said: 'Quid est veritas?'

<comment><USER20> Generation is a much harder problem than discrimination though.

</comment></comment></comment><comment><USER21> This makes me wonder how would one go about adding an authentication key to audio? We have seen in the past encryption for text shared via email and watermarks embedded in images but I haven't come across something for audio. Happy to hear if someone has worked in this field.

<comment><USER22> > _adding an authentication key to audio_

I'm afraid that it's not going to work. Not more than adding an authentication key to handwriting.

The voice _itself_ was an authentication key, as was the hand. But now these keys are too weak and easy to forge.

I'd say we should completely stop trusting the authenticity of any recorded voice, and maybe all voice by phone. Trust the content, the style, have a set of agreed-upon keywords with your partner and/or your parents to check that the other side is indeed who it alleges to be in an extraordinary situation. Maybe not today, but tomorrow it may happen to be useful to thwart a scam directed against you, with the scammer perfectly imitating the voice of your loved one(s).

</comment></comment><comment><USER23> How long does it take to train the model?

</comment><comment><USER24> Next milestone I'm waiting for: Trump audio to Sarah Cooper video on the fly</comment>


Ask HN: Why aren't any of the new datastores written in Scala or Clojure? - <AUTHOR>

As I was looking at Cassandra, which is written in Java, I was wondering why none of the new data stores are written in either Scala or Clojure? <comment><USER2> It helps if you write your code in something that has large scale adoption if you want to tap the pool of existing talent.

It also makes it easier to get others to adopt your technology because they will have one less thing to explain to their bosses.</comment>


Ask HN: Are people misusing flags? - <AUTHOR>

For example this submission [1] is certainly provocative, but it's neither spam, trolling nor dumb and it did give rise to an interesting discussion. Yet, it apparently got lots of flags so that it's position ~105 (with 35 points in 5 hours) right now. I saw this in a couple of high to medium quality submissions lately. Is that really what flags are supposed to be used for?<p>[1] https://news.ycombinator.com/item?id=7933386 <comment><USER2> That one probably got hit by the flamewar detector, which applies when hitting a certain threshold of points, then num_comments >> num_points.

</comment><comment><USER3> That was a terrible post and I flagged it.

Author dislikes X and finds some mathematical basis to argue that X is bad and you are bad for liking it. There's a reason the best critiques of things come from people who like them despite their flaws.

Also, if you want to suggest that people are "misusing flags", you need to describe how people are using them and contrast that with the correct way. I don't think you've done either.

<comment><AUTHOR> As I said, the submission was provocative (but not of low quality) and the discussion was good. I think these kind of more controversial topics can potentially resolve false beliefs all kind of sorts or give at least some food for thought.

<comment><USER3> If someone thinks that an article is low quality, they're supposed to flag it, right? You're entitled to your opinion, but I'm not surprised a lot of people flagged it.

</comment></comment></comment><comment><USER4> _For example this submission [1] is certainly provocative, but it 's neither spam, trolling nor dumb and it did give rise to an interesting discussion._

I'm pretty certain that people are targeting HN for forum-manipulation at this point.

 _Is that really what flags are supposed to be used for?_

No. The prevalence of that many flags is certainly a sign of an attempt at willful manipulation of HN.</comment>


Ask HN: Is code review necessary when working with a 3rd party agency? - <AUTHOR> I'm trying to decide if I need to find someone to review the code for the application a 3rd party agency is building.<p>If the 3rd party is going to help with iterations of the product, do I still need someone to review the code? <comment><USER2> Depends on many things. For example: how much do you trust the company, what other products have they built, are they building a prototype or MVP, are they building software that needs to be highly reliable, secure or precise, do they do internal code reviews, do you want them to optimise for time of delivery or correctness or what exactly, etc. In any case , I'd recommend to get someone you trust to do a cursory code review after the first month just to see if they spot major red flags. Although if their code quality is bad, you'll probably spot red flags in their product as well.</comment>


Full ECommerce Template with Stripe Payments, AngularJS, Firebase and Ionic - <AUTHOR> https://www.noodl.io/market/product/P201602271203444/ionic-shop-advanced-edition-full-ecommerce-app-w-stripe-payments-and-admin <comment><USER2> not bad</comment>


The Economist Debates: Are we in a new tech bubble? - <AUTHOR> http://www.economist.com/debate/days/view/710

<comment><USER2> Bubbles happen when everyone realizes there is a gold mine somewhere, but no one knows how to find it. Some things are overvalued, some things are undervalued. Usually the gold is in a place where you least expect it.

The Netherlands had two flower bubbles, but not because people where crazy. People started to realize that this tiny patch of soggy land would one day be the biggest exporter of flowers and vegetables in the world. Flowers are clearly worth way more per kg than grain, but how much exactly? No one knows, but surely those tulips must be worth a lot.

<comment><USER3> That sounds reasonable. So why did people buy tulip bulbs instead of land in the Netherlands?

<comment><USER2> Land was being mass produced in the first half the 17th century. My guess is that people couldn't imagine running out of land because you could keep reclaiming it from the sea, but they could imagine running out of tulip bulbs. Thus they undervalued land, and overvalued tulips.

Similarly, during the .com bubble, people couldn't imagine a slightly improved search engine would be worth anything, but an online grocery store seemed like a gold mine.

<comment><USER3> Makes sense. Thanks!

</comment></comment></comment></comment><comment><USER4> We have had a cheap money policy for way too long now, decades literally. It is not just US, but also the fast growing developing countries, who all tend to keep interest rates very low.

We've also had bubble after bubble, after bubble.

Is tech 2.0 a bubble?

1\. Even if it is, it's not nearly as big or stupid as .com 1.0 was.

2\. Oil, gold, a bunch of other stuff, too much money is chasing things to buy. Is it a bubble of just an early pre-view of what inflation will do to EVERYTHING?

3\. Some prices certainly do seem extremely speculative, LinkedIn being a prime example, obviously they are worth something, but are they worth THAT much?

I think we're in a tech maturing period, that is to say, that if valuations of a bunch of tech companies suddenly collapse, other tech companies won't be affected. When tech stops being identical to all other tech, the market has reached a sort of maturity.

But yeah all markets are acting screwy right now, between a likely default of Greece and who know else, and 0 or even negative interest rates in the US, Japan, and the EU.... yeah, we live in strange times.

</comment><comment><USER5> I've not see Economist Debates before but it looks to be a very well thought out environment for debate. They roleplay the form of a debate so well that it inspires courteousness from the general audience. The timetable and structure of the debate as well as the expert commentary is all very nice.

I'd like to see such a system for political discourse. At the local, state, and national level, it would be a welcome place to share ideas. If all the major news organizations are going to keep spewing opinionated journalism, we may as well take it to the logical conclusion. With opinion should come debate.

</comment><comment><USER6> When even the guy making the "against" case opens by saying

 _I am not arguing that Netflix, Salesforce.com and LinkedIn are not overvalued; I am simply arguing that their valuations have not become completely divorced from any rational thought. If they have not, we have not taken a major step towards a bubble._

that's starting to sound kinda bubbly. "Not completely divorced from rational thought" is kinda on the faint-praise side.

<comment><USER7> Perhaps, but "kinda bubbly" is many degrees of separation from the kind of "bubbly" that was going on in 1999. So calling this "another tech bubble" is disingenuous because, frankly, it just doesn't compare in degree of irrationality.

<comment><USER8> So as he basically says, we are probably close to the start of a bubble (the mania phase).

</comment></comment></comment><comment><USER9> It's not a bubble because there's only a handful of companies which are trading at values which I would consider to be excessive for the underlying business.

Netflix, Salesforce, Tesla, LinkedIn, and potentially Facebook/GroupOn.

Almost every other technology company is trading at lower then average P/E values, including for the first time in a long time, Google and Apple.

So is a handful of potentially over-valued companies reasons to call out a bubble? I'd say no, at any given time there will be absurdly valued companies trading on any given stock exchange, that probably hasn't changed in the entire history of the NYSE.

<comment><USER10> Just curious, but what are you comparing Netflix's P/E to? How do you conclude that Netflix is overpriced?

<comment><USER11> _How do you conclude that Netflix is overpriced?_

I've said this before but anytime a stock is trading at an earnings multiple significantly higher or lower than average, the burdon of proof should fall on the person arguing for such a multiple.

Netflix is trading at a P/E of about 75. Right or wrong that should at least give an investor pause. There is a lot of success already baked into that price. At this type of multiple a company has to outperform already sky high expectations in order for an investor to make money(in a fully rational world). This is possible but it becomes increasingly difficult as that multiple expands.

<comment><USER9> For companies like Linked In with tiny earnings a sky high multiple might make sense. They only have one or two quarters of profitable business in. But for companies like Netflix and Amazon, who have sustained growth, revenue, earnings, and a pretty clear business model, you really have to think about the magnitude that 70x earnings growth implies.

<comment><USER11> I guess it depends on how you define sky high. LinkedIn is trading at 2100x earnings according to google finance. Now there are certainly times when P/E is meaningless and LinkedIn probably is one of them but for a company with no track record it should give some pause.

The question is are people investing in these companies or are they speculating about them?

</comment></comment></comment></comment></comment><comment><USER12> Do the arguments that, "there are so few companies with large IPOs" or, "there's only a small proportion of people buying in right now" seem bizarre to anyone else?

I mean, the point is to realize the bubble early. When there are 2 tech IPOs a day and your 75 year old father is buying the hottest Facebook competitor's stock...yeah, obviously a bubble.

But it's more subtle now, and we have to figure out if it's leading to where we DON'T want to be. To me, and some other people, it seems so.

</comment><comment><USER13> Eh, the boring utility sector has a 18.52 PE, versus 17.47 for technology. That's not necessarily proof of anything, and even 17.47 is a little high. But still.

<http://biz.yahoo.com/p/9conameu.html>

<http://biz.yahoo.com/p/8peed.html></comment>


Working from Home: The Desks of FreeAgent Engineering - <AUTHOR> https://engineering.freeagent.com/2020/05/18/working-from-home-the-desks-of-freeagents/ <comment><USER2> What's striking to me is the prevalence of laptops. As someone who has worked from home for a very long time, my iMac and Desktop PCs are miles and miles faster for software dev than any work-issued laptop I've ever had. Laptop CPUs have not historically been able to compete with desktop CPUs. For remote workers, give them the option of getting a desktop-class machine.

<comment><USER3> FreeAgent CTO here. We now default to quad-core i7 32GB 13" MacBook Pros which are super-flexible (travel, working in different locations etc) and definitely powerful enough for local dev.

We benchmarked these when running tests locally against 16" hex-core MBP and found comparatively little difference – CPU ultimately stops being the bottleneck at some point.

It looks like mobile dev workflow (iOS and Android) benefits from more powerful machines (and definitely 32GB RAM) but again it's a trade off over power vs portability, the latter being important for our developers.</comment></comment>


Ask HN: How can I use my skills as an engineer to help stop Trump? - <AUTHOR> I'm looking for ideas outside of traditional web-based informational campaigns, which ultimately tend to just preach to the choir. Ideas that are manifested in the physical world and complement peaceful, passive protest are preferable. <comment><USER2> Email the folks at [https://turbovote.org/](https://turbovote.org/) to see if they need tech help making it easier to register.

Find the things that depress voter turnout among progressives and treat those as pain points too.

Remember that for many poor people, a smartphone is their only computer.

</comment><comment><USER3> Why would you?

Web-based but untraditional: Make a website to offer russia to exchange him for Zhirinovsky.

</comment><comment><USER4> Vote?</comment>


AirBnB Was Not Fred Wilson's Biggest Miss - Apple Was. - <AUTHOR> http://www.avc.com/a_vc/2009/01/selling-apple-a.html

<comment><USER2> we would have made 10x or more on airbnb. apple has only gone up about 6.7x since 2009. and i only had a couple hundred thousand at work in apple. we would have invested millions in airbnb.

but we've made plenty of great investments at USV since 2009 including Kickstarter, Foursquare, Stack, SoundCloud, etc, etc

so i doubt Apple would even be in the top five in our 2008 fund when its all said and done.

<comment><AUTHOR> Fred, first things first - I cant believe you responded to this post - it was a pleasant surprise - Thanks !!

1\. AAPL has gone up 7.4x since the day you sold.

2\. "we would have invested millions in airbnb" thats the whole point, you could have invested millions in AAPL as well.

3\. Your other investments are stunning. You are so right, some of them would blast past the 7.4x AAPL benchmark - hey thats a new term for vc - the AAPL benchmark!

<comment><USER2> we don't invest in public companies at USV</comment></comment></comment>


Show HN: AnyHow – Business, team and project mgmt for agencies and freelancers - <AUTHOR> https://anyhowhq.com <comment><AUTHOR> Hi all! I'm pretty excited to share our project with the HN community.

AnyHow is a consultancy management platform aimed at agencies and freelancers. We began building this product in 2012 for our company Netlandish. Over the years it kept getting better and at some point we realized that, for our business at least, it was the best option available. We began to share it with our friends who would use it for their businesses and would then tell their friends about it.

We finally decided to do the work to make it available to all. While we're publicly launching today, AnyHow has already managed hundreds of projects worth millions of dollars for a couple dozen companies. In short, it's already battle tested.

I won't go into too many details on features, etc. here but some core things are Time tracking (multiple methods/workflows), invoicing and accepting payments, centralized discussions/file storage/wiki (w/ client access), automation for normal tedious tasks, and lots more...

If you'd like some more details see the features page[1] or an even longer list on our YesAQ page[2] (thx Basecamp!)

You can also check out this YouTube video showing brief demo's of a lot of the core features.

[https://www.youtube.com/watch?v=PIMtfcVRwXY](https://www.youtube.com/watch?v=PIMtfcVRwXY)

Tech stack (what we mostly care about here right?)

Python 3.8, Django 2.2.x, PostgreSQL 11 db, Redis, Memcached, Celery, AWS SES/S3, nginx, uwsgi. Hosted at Digital Ocean on systems running FreeBSD 12.1.

We've got a full API for the feature set ready as well. The docs are not quite complete (thus why no API links on the site yet) but that should come soon!

I'd love to answer any questions you may have!

[1] [https://anyhowhq.com/features/](https://anyhowhq.com/features/) [2] [https://anyhowhq.com/yes/](https://anyhowhq.com/yes/)</comment>


Ask HN: Anyone building a REST API only product? - <AUTHOR>

I have been thinking about building an REST API only product.  I don't have anything specific in mind but I would prefer to build something without a UI.  I end up spending hours even days sometimes on tweaking html and CSS.  Not fun...<p>Thoughts?  Is anyone else building an API only product?  How is it going? <comment><USER2> Tarsnap (<http://www.tarsnap.com/>) doesn't use a REST API (for various reasons, I built my own API), but it's essentially an API-only product. Users will (once I get the website built) be able to create accounts and check how much storage and bandwidth they're using via the website; but all the "core" work is computers talking to computers.

<comment><AUTHOR> I thought there was a client app that did most of the data management? So, if I had I desktop application and was a user of tarsnap could I bake backups into my app?

<comment><USER2> _I thought there was a client app that did most of the data management?_

Well, yes. But it's a command-line application, and all of the communication with my server is via a client-server API, not via a web browser -- maybe this isn't quite what you meant in your original question, but it certainly fits on the "without a UI" side of things.

 _if I had I desktop application and was a user of tarsnap could I bake backups into my app?_

It would be difficult to bake tarsnap backups into your application directly, but tarsnap's command-line interface is almost exactly the same as tar's -- and I suspect that tar is one of the top 10 most commonly scripted UNIX programs. So if it would be very easy for your application to run tarsnap as a subprocess.</comment></comment></comment>


The 'Erin Brockovich town' is still toxic and nearly abandoned - <AUTHOR> https://grist.org/article/the-true-story-of-the-town-behind-erin-brockovich/ <comment><USER2> I'm a scientist and every time I've looked into this, it seems unlikely that PG&E's work with chromium-6 actually caused any health problems. It's unfortunately the movie made the (likely) false narrative popular.

<comment><USER3> A lot of people ended up sick in this area and with major health issues. If not chromium 6, then?

<comment><USER2> I'm having trouble finding evidence that a statistically significant larger number of people died in Hinkley at any time, compared to the population as a whole. If that's the case, then there wasn't a problem in the first place.

<comment><USER3> Let's assume I agree with you. Are you stating that the movie EB (and the woman Erin Brockovich) was responsible for making Hexavalent Chromium 6 the fall guy and that there was nothing that happened in Hinkley to the very tiny population of 2k (or less) people?

<comment><USER2> Hard to agree to those with high confidence; the first is that I am unaware of any actual statistically significant health problems in Hinkley. I've researched this a bit, and a lot of the reported health problems are consistent with base rates, not elevated rates. U Note that news articles written by nonscientific journalists make basic errors when it comes to medicine, and often use scary sounding terms like "cancer cluster" to refer to naturally occurring, normal rates of death that are higher than surrounding areas, but not statistically significantly higher. The literature around C-VI is unfortunately hard to parse, because the area has attracted cranks.

If there is no statistically significantly higher rate of death due to diseases which could have been caused by C-VI that was drunk or eaten by residents, then I would pretty much stop there; my current belief is this is the case.

Now, if there was such a higher rate (which IIUC has never been established), and those rates were highly consistent with C-VI toxicity, and C-VI in consumed form was toxic, then I think you'd be on to something.

I think it was actually a mistake by EB herself, combined with PG&E's legal ineptitude, that led to the situation we are in. The movie just amplified the problem.

Note that I live near a few superfund sites where irresponsible local industry (thanks Intel and Fairchild!) caused leakage of TCE into the groundwater, which then plumed, and is causing a very expensive long-term cleanup. TCE groundwater contamination is much more concerning, with huge amounts of high quality scientific evidence clearly supporting the danger, and it's right next to an extremely highly populated area (San Jose). So it's not like I'm some sort of industry cancer-denier; I just think this is a situation where people came up with a compelling narrative that was wrong, and it got popular.

<comment><USER4>
      Note that I live near a few superfund sites where irresponsible local industry (thanks Intel and Fairchild!)

Have you ever been to Sharks Ice (10th and Alma)?

That paved-over lot across the street is the former Lorentz Barrel and Drum Superfund site.</comment></comment></comment></comment></comment></comment>