Elm 0.19 Broke Us - <AUTHOR> https://dev.to/kspeakman/elm-019-broke-us--khn <comment><USER2> I think there's a very weird mismatch between the way the core language people are pushing for the adoption of the language, and then at the same time they will turn around and say "we'll, it's not even 1.0, yet, so what'd you expect".

The way Elm is developed is fit for a language that has little to no users, and can take going so long between updates, that remove escape hatches needed to fill out the immaturity of the language.

It really saddens me to see it go like this, because I once had high hopes for Elm. Nowadays I see it purely as a stepping-stone into more advanced languages like PureScript and Haskell. Elm is there to hold your hand, but it seems it has no intention of ever taking you further than the basics.

<comment><USER3> What you term the "immaturity of the language" is imo a well thought put focus on simplicity. It was never Elm's intention to reach the complexity of Haskell or indeed PureScript. I think that was a sound decision.

<comment><USER4> I think you are right, but the way decisions are communicated in Elm are frustrating. There are lots of decisions like this, which in the end are just decisions, but can be frustrating if you are expecting a more complex language.

Even without talking about type classes, the lack of applicative is weird. I know: nobody understands what applicative is for, but if you have map and you are currying parameters, you're _going_ to run into the issue ;-) Instead, you've got map, map2, map3, map4, map5 (which also, frustratingly, don't implement applicative). There are lots of validation scenarios that are just way more complex to do in Elm than they need to be.

But to be honest, it's fine because the language is not supposed to give you everything that you might want. It's geared for people who want a subset that's easy to learn. If I'm going to write code for myself in this space (functional language that compiles down to JS), I'm going to pick Purescript because it has everything that you're ever going to want. But if I'm choosing a language for my team that doesn't know functional programming and (to be blunt) doesn't really care to learn: Elm is a much better fit. They can learn just enough to get their work done.

But I just wish it was stated in those terms clearly. The premise of the article has been played out time and time again in the Elm community: "I thought this was a fully featured functional language, but when I tried to do this completely reasonable thing I got my hand slapped".

At every turn the response to, "Why can't I do X" is "Because you don't need to do X. It's much simpler to do without X" \-- which usually isn't true. It's much simpler to _learn_ something without X, but X is there to make your life much easier as long as you can deal with the complexity of learning it. It's the old "ease of use" vs "ease of learning" issue.

<comment><USER5> On the other hand, people need to learn to take no for an answer and move on.

Instead, egos get involved and a new essay of the week appears on how Elm is doomed because it doesn't have <pet feature>. That nobody can take Elm seriously if it doesn't have type-classes, synchronous FFI, derivable JSON codecs, component state, or whatever the pyre was built on that day.

If you didn't know better, you'd think they were disgruntled paying customers.

Elm's simplicity, lack of abstraction, and resulting boilerplate have more to offer than helping beginners learn. Nothing demonstrates this better than coming back to an old Elm application and immediately making meaningful changes to the code despite a long hiatus from using Elm at all.

There are a lot of languages that continually add features in this space like PureScript, ReasonML, and even TypeScript.

Why not see where Elm ends up with its aggressive devotion to a minimal API instead of trying to turn it into a language we already have?

Some of the best aspects of Elm come from its restrictive nature. Like how every Elm application uses the same "TEA" abstraction which is a breath of fresh air for anyone who never felt particularly empowered by the paralyzing abundance of options in the JS ecosystem nor the task of webpack-plumbing them together.

<comment><USER6> Nobody can take Elm seriously because _having lines of code in Elm_ is a liability at this point.

If Evan hadn't wanted this to happen, he shouldn't have positioned it as the "beginner-friendly" language and then pulled the petty dictator routine out as soon as people were locked into his ecosystem.

> Nothing demonstrates this better than coming back to an old Elm application > and immediately making meaningful changes to the code despite a long hiatus > from using Elm at all.

Or... not having it compile because the BDFL (or, realistically, DFL) has decided to remove half the features it needed to compile.

</comment></comment></comment></comment></comment><comment><USER7> I've heard of a few people discontent with Elm for the reasons mentioned in the article make a very successful jump to ClojureScript and being much happier about it.

It offers an MVU framework: re-frame. There are others too. Its community is very friendly and helpful, it loves to discuss the language itself. No one seems to think of themselves as more knowing. It has never ever broken backward compatibility. It's a core tenet of the language to never break anyone ever. Finally, it has very good interop with JavaScript. And its getting better and better every release.

It's also ran by a BDFL, actually more like two. Rich Hickey as the BDFL of the standard language design, and David Nolen as current implementer and main maintainer of ClojureScript. But they're loved and admired. And if you disagree with their direction, you're free to add your own features as a macro, that's why they made the language a Lisp.

The language design prioritizes pragmatism. All discussion starts with: What exact problem are you facing for which there are no simple way to solve. And working backwards from real problems, solutions are added and new constructs are built.

The only thing is, it comes from a different school of thought opposite to strong static types. But it shares a lot in common, emphasis on pure functional code, immutability of variable and values. No OOP, everything is a function with support for higher order functions, closures and partial application. And the same focus on interactive live development.

If you don't mind losing the strong static types, I highly recommend giving it a try. You'll only miss the nice Elm error messages.

<comment><USER8> Good suggestion!

Just to clarify one point, though, Clojure/Script does support OOP, with protocols/records/types, it's just not the first thing we suggest people reach for in the language. As a community, we're much more likely to use boring maps/vectors/functions first, and switch to OOP when we really need type-based polymorphism, or extreme performance.

One consequence of not forcing everything to be OOP (like, e.g., Java) is an honest evaluation of where it makes sense, and where it adds nothing but complexity.

<comment><USER7> Well, I don't want to get into a semantics debate, but I can't help myself :p. And I'm pretty sure Rich Hickey himself would disagree with you about Clojure/Script having OOP.

Protocols, records and types are not instances of OOP in my book. Polymorphism and abstract data types are concepts orthogonal to OOP and FP. The fact Clojure/Script has support for polymorphism and ADT does not mean it supports OOP.

If you want to claim it supports OOP, I'd say it does in the form of interop. Genclass, proxy, or defining classes in Java or objects in JavaScript and using them from Clojure/Script.

But, what is OOP exactly? We can debate this. I like to use Wikipedia's definition that it is languages where there is a construct, called an object, which groups together data fields and methods which can access and modify the data fields within.

Clojure/Script has no such construct. But one can define them in Java or JavaScript, and use them from Clojure/Script through interop.

<comment><USER9> Records and protocols meet your definition of OOP exactly.

<comment><USER7> Well, like I said, we're in the realm of a semantic debate, and I'm definitly being pedantic.

But, as I see it, records and types define only data. The former as an immutable map with pre-defined keys, the latter as a fixed set of data fields. Thus neither are an object.

Protocols define only function signatures, without data. More like interfaces. Thus it too is not an object.

Why am I being pedantic? Because data and functions are never coupled in this case. But in traditional OOP, an object groups data and methods, and are thus coupled together tightly.

<comment><USER9> But a record defines implementations of the protocol methods. Would you say Traits in rust aren't an OO construct?

The data and methods are coupled in the record definition. The methods depend on having the records fields in scope.

<comment><USER7> > Would you say Traits in rust aren't an OO construct?

I'd say traits in Rust, typeclasses in Haskell and Scala imlicit views are the equivalent to Clojure/Script protocols. And similarly, those constructs by themself aren't OOP. I think a simple proof is that if they were, then all OOP languages would have them. But because there are OOP languages (the most popular ones at that) which don't have them, then it follows this construct is not fundamental to OOP.

> But a record defines implementations of the protocol methods.

It's better to think of it as a protocol is extended to a type. It is not the record which defines the implementation. The methods don't belong to the record, they are independently defined, they can come from a dependency, they can even be shared with other types and other protocols. This is contrary to objects which define their own methods.

> The data and methods are coupled in the record definition.

Functions are associated with a protocol and a type independently of the record or protocol definition. This association is many to many. The same function can be associated over many protocols and many types. There is no coupling. You can even dissociate them. To add new associations or dissociate existing ones, you don't need to touch the record definition at all.

> The methods depend on having the records fields in scope.

They don't. Record fields aren't scoped to their associated methods. They are always public. There is no self or this scope. They are just normal functions like any other. You don't even need a protocol. Just write a function which takes a record and does something with it. Now if you want to make this function type polymorphic, you can use a protocol.

I'm not sure I'm explaining myself very well. Think of an object. The object defines some data fields. And it defines some methods together. You can't use those methods with other objects. The ownership is tied to the object that defined them. The only way to share the methods is through inheritance. Similarly, you can only manipulate the data fields of an object through the object, because the object owns the access to them. Only if it chooses to make them public or expose a getter/setter are other objects allowed access. This is OOP. If you model your programs with objects like that, you are doing object oriented programming. Data is encapsulated behind objects, and can only be manipulated through sending a message (a method call) to the object. The object defines the set of possible methods for that data. You can't do that in Clojure/Script, because no object like construct exists that would allow you to do it.

Now in Clojure/Script, you have datatypes. That is, data with an associated type. You can create custom ones, such as records. A record is a set of key/value pairs with an associated type. A Person record defines a type Person, with keys Age and Weight and their values. That's all a record does. It can't restrict access to its data, it can't expose methods, and it can't receive messages (method calls). You can now write functions that take input of this new type. Those functions can be defined anywhere. They have no special access to the data inside Person, there's no `this` or `self`. The functions don't live inside the datatype. Now, if you want a common set of functions to work over many different types, you can specify a protocol. That's all a protocol does. This is just functional programming.

Sorry for the length. The distinctions are subtle, couldn't find a way to explain them with less words.

<comment><USER10> The essence of OOP is abstraction via message sends to and from an otherwise opaque interface. (Really really close to actors, but message sends are synchronous by default and objects don't have their own thread of control.) That's what gives you polymorphism; inheritance and encapsulation are down to discipline. Often implemented as a table of function pointers for performance reasons, the message sends becoming ordinals into the pointer table, and losing a certain degree of encapsulation and first-classness in their own right, like delegation or queuing or other interesting things.

OOP isn't specifically attached to tying behaviour and data together. But if you only get to interact with state via message sends, and you try and follow that all the way through so your only non-primitive values are objects (and perhaps even your primitive values are objects too), then at least some of those opaque references are going to be mutable. And then you get state into the mix, and trouble starts brewing.

IMO Rust traits, Go interfaces, Java interfaces are the essence of OO.

<comment><USER7> I mean, yes and no. That's why this is a semantic debate. There are no right or wrong. Paradigms of programming are not formal concepts.

Some people say the essence of OOP is polymorphism. Others say it is inheritance. Others say it is the tying together of data and behavior.

I personally find issue with saying OOP is just ADTs + polymorphism. Which is what rust traits, go interfaces and java interfaces are.

        Type A
        Type B
        function F(value) {
            switch(typeof value) {
                case A: "I am A."
                case B: "I am B."
            }
        }

There, I have achieved object oriented programming. I have values with an identity, A or B, and I have polymorphic functions over them.

I don't know, it feels too broad to be useful.

That's why I prefer to say that OOP is more related to the tying together of data and behavior behind an object. This is how the Gang of Four book defines OO.

I find it frames things in a way that is more differentiating.

So now I can have OO, inheritance and polymorphism in any combination I want. This means Clojure/Script can now be defined as supporting inheritance and polymorphism, which it does, yet not supporting OO. And I can have another language supporting OO and polymorphism, but not inheritance, such as Rust. Or without OO and inheritance, but with polymorphism like Go, etc.

<comment><USER11> > This is how the Gang of Four book defines OO.

That book defines OO from the point of view of Smalltalk and C++.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I think Elm can learn a lot from Rust before 1.0 here. Rust made some "insane" decisions that should have pissed off the community but did not mostly because of the way the communication was handled. There were obviously some disagreements along the way which caused some valuable community members to jump ship, but overall it was really well handled and the language became better as a result.

<comment><USER13> Elm could learn even more from Perl 6. One of our mottos is "torture the implemeters on behalf of the users." Another is "hug trolls" and try to turn them into productive members of the community. Or the even more basic approach of not removing features without deprecating them for a release cycle. And for crying out loud listen to your users, as they see edges of the software that a language designer can miss.

<comment><USER14> And how well has any of that worked out for Perl 6?

<comment><USER15> Working out better and better, thank you.

</comment></comment></comment></comment><comment><USER16> The reddit discussion for this post is a telling confirmation of the articles complaints about the community forums/interaction: [https://www.reddit.com/r/elm/comments/9a0hc6/elm_019_broke_u...](https://www.reddit.com/r/elm/comments/9a0hc6/elm_019_broke_us/)

<comment><USER17> It is interesting that the message locking the post seems to portray engaging with people with opposing views about design decisions as _taking time away from working on Elm_ , instead of being itself a form of working on Elm!

Maybe Elm needs some sort of "Please do not use this language in production" sign, and no "Community" link at the top of the home page. There's nothing wrong with a group of folks making a language for themselves / their employers, perhaps putting it on GitHub because why not, but not having a home page at all and making it clear that this isn't a stable language for others to use and they will put much more emphasis on the feedback from their own experiences than from others'. There's definitely nothing wrong with them doing that until they get to a 1.0 they're happy with, and then releasing it to the community.

<comment><USER18> Elm is much more stable than every option in the market. Lots of companies with 100k+ loc web apps, and 2 companies with 250k+, with no runtime exceptions in production, due to it's type system. Removing native modules was needed to keep the language guarantee to not crash in runtime for every program that compiles.

<comment><USER17> "Stable" as in "doesn't crash in production" and "stable" as in "doesn't change backwards-incompatibly" are two almost entirely unrelated uses of the word. Most folks looking for a language prioritize the latter. There's no point in not having runtime ezceptions if your code stops compiling.

I understand that removal of native modules was required for maintaining (some interpretation of) the promise of being crash-proof, and that it needs to be done before 1.0. My point is exactly that the language _isn 't_ at 1.0 yet.

But more than that, my point is about the approach the developers take to the language, not about any specific decision. I'd still have the same comment about an Elm which lacked native modules from day 1, or an Elm where they figured out how to keep native modulea. Not running into breaking changes by luck is different from intentionally prioritizing stability and other people's use cases. It doesn't matter how many people are deploying Elm in production today—it's still a pre-1.0 language and maybe they shouldn't be deploying Elm in production.

<comment><USER18> I agree with you, but breaking code is not really a problem since elm compiler is fast and has nice error messages. Porting big code bases takes time, but it's very worthy imo.

<comment><USER6> > breaking code is not really a problem since elm compiler is fast and has > nice error messages.

Not true on either front. Elm's compiler does not have good error messages, and breaking code is absolutely a problem.

</comment></comment></comment></comment></comment></comment><comment><USER3> I'm torn about this. I'm rooting for Elm and I think it currently might be the best frontend solution. I really like Evan's focus on developer UX and simplicity. This means removing things, making the language smaller and simpler. And to do that you need to maintain a certain amount of control.

However this seems to have backfired. Too many in the community want this or that and/or don't feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. JS interoperability and just enough Algol syntax to staisfy the masses.

Evan is between a rock and a hard place here and it's due to the current sentiment in frontend dev.

<comment><USER19> I author the Cycle.js framework and for a good while I considered it to be a sister project to Elm, because both had a focus on simple functional reactive programming for frontend. I've advocated Elm and been a bit in the community as well.

Evan is great person, I still remember fondly the time we had good long conversations at a conference. I started the first attempt at integrating Elm with React Native, and that was only possible through hacking the native modules in various ways. I figured I couldn't progress with this plan due to how restricted Elm is regarding native modules, but also other things like naming of community modules. Elm is strict not just as a language but also as a community culture.

What shocks me about the latest state of Elm and its community is how easily conversations get locked. Locking should be the last resort. What leaders block or ban indicates what they do not want to risk. There should always be the possibility of blocking to say that "we cannot afford having X in our community." and defend some basic principles.

In many communities, X is just personal attacks or harassment, that kind of thing. The consistent pattern I see in the Elm community management is that X is dissent. "We cannot risk having divergent discussions (polite or impolite) in our community" is message that restricts thought freedom and reinforces cult-like behavior. It's not a good thing to have in a community, specially in an open one on the internet where membership is fluid (unlike dissent in a company for example). Curbing dissent ultimately leads to lack of innovation (which comes from freedom to create without fear of rejection), which reinforces the status of the leader as the primary source of innovation, because whatever the leader does is assumed to be never rejected. I think these community dynamics are bad in the long run, it creates more feeling of rejection, decreases innovation, and centralizes even more responsibility and power to the BDFL.

<comment><AUTHOR> Andre's talk "The Past, Present, and Future of Cycle.js" [1] describes how Cycle was grown by the community through discussion and experimentation.

[1] [https://vimeo.com/216787869](https://vimeo.com/216787869)

</comment></comment></comment><comment><USER20> I agree that community management and handling of issues could be better in Elm, but I'm willing to overlook that due to the terrific quality and innovation of the end result. Elm has benefited greatly from vision and the willingness to take risks, which is much easier to do with less communication overhead and fewer contributors.

Maybe someday Elm will adopt a more community-oriented approach, but I don't think that is necessary right now.

<comment><USER21> If I could upvote this more than once, I would. Spot on.

</comment></comment><comment><USER22> I looked at Elm a couple years back and decided on Purescript instead: [http://www.purescript.org/](http://www.purescript.org/)

Has a much better FFI story with JavaScript than Elm, and has a more powerful type system (higher kinder types, etc). Row polymorphism makes writing pure code a joy, the effects system is unobtrusive. I actually enjoy programming purescript more than Haskell.

<comment><USER23> [https://github.com/slamdata/purescript- halogen](https://github.com/slamdata/purescript-halogen) is a very nice frontend library with local state per component, such that not the entire vdom needs to be diffed.

However, if you want an easy migration path, there is [https://github.com/pselm/core](https://github.com/pselm/core) Which is a drop-in replacement of the Elm 0.18 API in purescript. You can almost directly copy your elm code to it and it will work with minor changes

<comment><USER24> I like halogen, but elm folks may want something more familiar (and with less type variables).

<comment><USER23> Definitely. One of the 'elm-like' libraries (like the one I also linked) are a great stepping stone to get started.

<comment><USER24> I don't think you even need to call them stepping stones. They are perfectly fine libraries in their own regard.

Slamdata had some specific requirements with halogen that everyone may not need. And although the free monad approach is nice, it certainly is not fundamental or necessarily the best depending on the task to UI construction.

</comment></comment></comment></comment></comment><comment><USER25> I recently took on a contract to fix a busted elm project. There were no runtime exceptions but it was such a Frankenstein monster I couldn't believe it.

If you're doing any real work on the web, you're going to have to use external libraries and code and such. You're not going to have time to recreate an entire mapping framework in Elm or whatever and the minute you need to commingle in such a way you loose a major benefit of such system.

Also "no runtime exceptions" does not mean the application isn't broken, does not absolve your developers from real testing and QA their changes.

Also it says a lot when someone wants to call their framework a kernel and patterns their behavior off you know who.

<comment><USER26> In general, type checkers almost never catch any errors that wouldn't have been found extremely quickly in a strongly typed dynamic language.

<comment><USER27> Having worked in a large codebase to fix type errors in an evolving language, this is not true. There are plenty of errors.

What is true is that the errors you catch are most often benign and not obvious, user-visible bugs, for one reason or another. (If they were obvious, they would have been fixed sooner.) The code might be abandoned or rarely executed, or it's never called with that argument. Something like that.

Occasionally you do find a serious error, though.

</comment></comment></comment><comment><USER21> I would have liked to have seen custom operators stay around in 19, but I understand the motivations. I think it was in 18 they removed back-ticks for the same reason. Just makes it way easier for newcomers to learn the language.

As far as I understand it, the native modules lockdown had to take place. Period. The one thing that most attracts myself (and many others, I'm sure) to Elm is the guarantees that the compiler gives you towards ensuring no run-time errors. Give folks the ability to author and publish Elm native modules and the entire platform loses that guarantee.

<comment><USER28> I don't. If you ban custom operators, how can you find out future use cases where custom operators make a lot of sense? I am extremely distrustful of a language where certain people are more equal than others. Those elevated people could be blessed library authors, or within the core implementation or whatever, but I hate not being trusted to use my tools properly.

<comment><USER6> Agreed. Not allowing footguns is great, but custom operators aren't a footgun and in any case the fact that Elm has operators at all kind of indicates that they you're just being treated as a second-class citizen.

</comment></comment></comment><comment><USER29> I love Elm. Discovered it last year and loved the language so much that I went on a conference later in the year on my own budget.

I love how low the cognitive load of adding features is. Having a small baby, it helps a lot.

That being said, some things really confuse me, and especially the way the governance model is accepted and cherished. We have a `almighty god` deciding what will and not be done, the accepted reason being that it's not 1.0 yet.

I mean, with 0.19 coming out, all IDE support went out the window and the answer from the author of the language is basically : 'changes are known since last May, things should have been done already. I don't even know what the status is'. Communication is at the minimum lacking tact. Others could say straight offensive for not-core users.

I understand PR is hard and not fun. But then find someone to do it for you, or act as to minimize it.

At the moment, the advantages of elm far outweight the issues for my personal use. But I really wonder about the long run, but I'm really afraid someone gets really pissed and forks the language in the long run, fragmenting and ending up destroying this great community. That would really be a waste.

<comment><USER30> Are you paying to use Elm? What's stopping you from sticking to 0.18? What's stopping you from building your own 0.19 IDE support?

<comment><USER29> This is 100% what i mean. This exact way of thinking is what imho might well prevent Elm to strive as much as it could.

And btw, I am (modestly) involved in the IDE support. So do check before being cynical <3.

<comment><USER30> My exact way of thinking is that you are not entitled to anything, and neither am I.

I run businesses on Elm. I use it because it's the alternative that makes the most business sense (most confidence that I can release things without them breaking, and least chance of failure at runtime). I make money with this tool, and I don't pay to use this tool.

If a better tool came along, I'd use the better tool. So far, Elm is the best alternative in my opinion. Everyone has this freedom to pick and choose their tools.

And what does it mean to strive? Scala was a striving language. And? It's garbage. It tried to be all things to all people, and ended up being an awful tool.

I find it absolutely amazing that so many petulant children in this thread believe they are facing some kind of authoritarian oppression because the language designer said "You know what? Synchronous FFI has almost only been a bad thing. All FFI should be synchronous from now on."

<comment><USER29> First, I'm not sure what makes you think you can just insult me. I'd recommend you tone it down.

Second, most of what I see here is very similar to my experience:

* I love Elm * I take its pros and cons * The day i don't find what I want there I ll just move out of it. * I do my best to participate in the community as well * Bonus: I also got into Scala and stepped out

The only thing I was trying to convey is : * The creator of the language is very opiniated (that is fine) * The way of communicating is not ideal (that is shame, it doesn't have to BE this way). * I hope someone will not really get annoyed by it to a point where the community will get separated / torn. Because it would most likely lead to a lot of negativity.

Not sure what brings you to call me a pedulant child. I don't remember saying I was oppressed. . .

<comment><USER30> I'm sorry that my general frustration with most of the comments in this thread materialised as being directed toward you specifically. That wasn't my intention.

People (not necessarily you or I) _are_ going to be annoyed though. And this is fine. A tool doesn't need to be the most popular alternative to "thrive" or to "win" (quoting some other commenter now).

The thought process for most people in this thread seems to be:

1\. Get mad when their "freedoms" (dangerous synchronous FFI) are taken away.

2\. Complain, because the programmer knows best (ego/hubris).

3\. Complain further about "the community" when their egos aren't pandered to.

If the maintainers relinquished their ideals, we'd have a language as dangerous as most of the alternatives. Frankly, I'm not interested in a "community" where everyone gets along but the software is always broken. I need my stuff to work.

To you, specifically, I appreciate that you tried to keep the discussion amicable. Thank you for that, and again I'm sorry.

<comment><USER29> No big worries. Insults fly a lot on HN, this won't be the last time. Agreed. It's not about pleasing people.

Being opiniated is what brought Elm where it is. And it is not about winning. Definitely agree there too.

I just wish design considerations were communicated in a more positive, rather than autoritative manner. Because it makes people lose motivation and brings negativity.

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> I only briefly dabbled in Elm and I'm not terribly qualified to comment on specifics, but I had a similar, negative impression of the way the project is managed. Especially in comparison to many other open source projects.

</comment><comment><USER32> I would be totally on board with these changes if an alternative way of doing things had been offered.

From the philosophical point of view they are exactly what is needed to allow Elm give as much guarantees as possible.

The sad reality is that very little pragmatism went into this release and now stuff like web-sockets won't work [1]. This is very surprising because web- sockets are an use case where the Elm-architecture really shines.

Things like this reinforces my idea that while Elm is a very nice language I wouldn't want to have it in production, or even in a side project, at least till it reaches 1.0 and becomes more stable.

[1] [https://github.com/elm-lang/websocket/issues/27](https://github.com/elm- lang/websocket/issues/27)

<comment><USER30> Why can't this be done with ports?

<comment><USER32> I'm not sure. I haven't looked into the issue much.

In any case, I would expect web-sockets to work out out the box in a language that is specifically designed to run in the browser.

If that's not working I'm sure that less common parts of the web platform aren't supported either. Normally I wouldn't care and implement stuff myself and contribute back, but it doesn't seem to be a realistic option in Elm.

I appreciate that what's there is generally of very high quality, but I cannot pretend that there aren't many missing pieces and, more importantly, no clear roadmap

</comment></comment></comment><comment><USER33> I was experimenting with Elm around .14 or .15 if I remember correctly. At the moment the language allowed you to use prime(') to name variables, and that was the suggested way if I had to guess by the tutorials and examples.

During next release they decided that primes as part of a name were not their cup of tea and removed it. Just like that. When I asked why was prime no longer allowed, since I couldn't see any good reason behind it, I got the usual: "it's pre-1 release you should expect things to change, etc."

What left a bitter taste in my mouth was that this change had nothing to do with the language itself. It seemed as if they decided that using prime is not good style, so they forbid it.

I haven't touched Elm since.

<comment><USER34> I think rust went through a huge amount of simmilar changes pre-1.0. I think everyone was better for it. I appreciate they're taking their time to get it right pre-1.0. 1.0 is a fairly solemn promise and I respect them for not taking it lightly.

<comment><USER33> That's exactly the kind of answers I got instead of giving me one good engineering reason on why primes were made forbidden just like this. Thanks for the demonstration.

<comment> star-techate The actual reason is probably "when people use primes, they post code that gets syntax-highlighted by tools that don't know about primes, and this results in Elm code looking broken and stupid."

<comment><USER33> Which is not a good reason to ban them completely from one release to the next. It only shows that they don't really care about their users that much.

</comment></comment></comment></comment></comment><comment><USER35> For those of us who desperately want to put javascript (the entire language) behind us, many of the "problems" this article mentions are features.

Refusing, on principle, to be inter-operable with unchecked javascript code is a _defining virtue_ of Elm.

edit: grammar

<comment><USER6> > For those of us who desperately want to put javascript (the entire language) > behind us, many of the "problems" this article mentions are features.

Yes, not having FFI is a feature. Brilliant.

</comment></comment><comment><USER36> Whilst I get the point about the community leadership being more autocratic than others, the Elm language itself has always been opinionated - thus it's difficult to empathise with the rest of the sentiment of this post. An 0.x release, two years in the making, drops two features such that it can further fulfil its design goals and everything is ruined?

</comment><comment><USER37> I really enjoy the fable-elmish philosophy, I think that the community is great compared to what the author of this post experienced, but..BUT, the platform on the whole is just too immature. I remember trying to compile jquery using the otherwise great ts2fable.. and it was, and probably still is, pretty much impossible. Or trying to use fable-elmish and getting "undefined behaviour" in a "hello world" test page. Luckily I discovered pretty soon these limitations, but I think that when a platform is not battle tested by millions of people you'll always get this kind of grief. So just test if elm or fable-elmish or whatever framework work well for you before committing head first into it..

</comment><comment> robert-wallis One of Elm's main focuses is code that is not possible to crash. Once I groked that, native modules going away in favor of ports made much more sense.

<comment><USER38> Maybe it's my recent living in the Erlang/Elixir community, but writing code that is not possible to crash doesn't make sense to me. Servers die, machines get unplugged, network partitions happen, etc. I don't discount that the type system allows you to specify segments of your program that can be provably impossible to crash, but doing that for entire nontrivial programs seems like an impossible ask to me.

<comment><USER39> > Servers die, machines get unplugged, network partitions happen, etc

These things happen in backend / distributed systems. They don't really happen in the browser, which is basically a self-contained sandbox that can make network requests. The browser code needs to handle those network requests maybe failing, but that's about it in terms of dealing with unpredictability. So, it's totally reasonable to think that a web-app should never be able to crash.

<comment><USER38> So if I make two API requests and get some nonsensical data that comes back, (say v1 from the first request, and v2 comes back from the second because of some bug in the backend). The program can certainly prepare itself for validating that data, and reject the v2 if it's not prepared for it, but then what do you do? To me "crashing" that entire page is a reasonable way to get around that for some programs. You as a browser can also lose Internet, in which case you also need to be prepared for things that happen on the other end depending on the circumstances of disconnection (did my request go out before it died? should I retry?). The problem is certainly more constrained, to your point, by being in a browser, but it's trivial to get your program in a nonsensical state that such that you cannot render as soon as you introduce external APIs. Perhaps Elm gets around this somehow, but I'm failing to see how.

Edit: redirection --> disconnection

<comment><USER40> > The program can certainly prepare itself for validating that data, and > reject the v2 if it's not prepared for it, but then what do you do? To me > "crashing" that entire page is a reasonable way to get around that for some > programs.

Such stuff is mostly handled via types like `Maybe APIResponse` or `Either ErrorMsg APIResponse`, so the type systems can guarantee that you handle both cases. And handling the error case (even if it's just a simple message to the user like "Error: Unable to fetch new weather data for location X/Y") is better then just crashing.

I mean it depends on your definition of crashing, but I consider it similar to undefined behaviour. So I greatly prefer

        $ ./fetch_weather $location
        panic: unable to fetch new weather data for location X/Y

to

        $ ./fetch_weather $location
        Segmentation fault

and I guess most people do (where segfault is similar to 500 Internal Server Error which is equally bad).

</comment></comment></comment></comment></comment><comment><USER40> In the end I think it's a good thing to be strict in language design and openly reject many ideas and suggestions. I guess it's a case of "too many cooks spoil the broth".

Most languages have too many features anyway so removing them can be a positive thing.

<comment><USER6> > Most languages have too many features anyway so removing them can be a > positive thing.

This is completely unsubstantiated.

</comment></comment><comment><USER41> And this is why I love TypeScript: It's just JavaScript, with a type system. If it's not in the standard then it's not in TypeScript (by default). There's no risk to adoption.

<comment><USER2> Typescript certainly is nicer than plain JavaScript, but it doesn't come anywhere near Elm (or PureScript or GHCJS). It really is a world of difference (edit: in type safety, that is).

The reason for that is simply that TypeScript has to fit in with JavaScript, while the others do not.

<comment><USER41> I mean, Dart offers this. The difference between Dart and the other strongly typed options is that a massive pile of funding (and production apps) drive Dart and its direction. So it's quite stable, if a little too risk averse.

That said, I've never found Strong Typing to be that essential for front end dev. TypeScript is incredibly pragmatic, which is why it's been so successful imo.

Nothing stops people from writing all their dependencies in TypeScript. But it's not necessary to use it successfully.

<comment><USER2> What is the "this" that Dart also offers? With the languages I specifically called out, a LARGE part of them is purity, and not providing the type system escape hatches that TypeScript/Flow does, to maintain easier gradually switching a codebase. A nice thing at first, but nothing gained for new projects.

<comment><USER41> this = a sound/strong type system:

[https://www.dartlang.org/guides/language/sound- dart](https://www.dartlang.org/guides/language/sound-dart)

</comment></comment></comment></comment></comment><comment><USER42> Custom operators make code _more_ readable when used appropriately; and any aspiring general purpose language that refuses to support them is cutting off the nose to spite the face.

<comment><USER43> Any language with a large userbase has a large group of people who don't use them appropriately. The result is a majority of code that is unreadable. Any language that depends on people to just "don't do that" is a language that will be full of people who do exactly that.

<comment><USER42> This is a social problem, it can be solved without such a blunt instrument. Single letter variable names also make code more readable, but only when used appropriately. Your argument would suggest banning those!

IMHO it is better to concentrate on getting the semantics right and not waste any goodwill on restricting syntax.

<comment><USER43> Yes it is a social problem. But I disagree that you can solve the social problem without very opinionated and restrictive syntax and semantics.

<comment><USER42> I respect your position, which was shared by the designers of Java and Go, but any language I choose to use is one that seeks to empower me. For example, the purity restriction in Haskell exists to ultimately empower me, not because the language designers have contempt for my abilities.

<comment><USER43> I also respect yours. This is why there are multiple options in the PL arena for people to choose.

</comment></comment></comment></comment></comment></comment><comment><USER44> I just wanted to let you know that a possible alternative functional MVU is Mithril/Meiosis

[http://mithril.js.org](http://mithril.js.org) \- vdom lib - for the V [http://meiosis.js.org](http://meiosis.js.org) \- state pattern in conjunction with streams to give you the M/U

Check out the gitter chatrooms, the communities for both are very FP oriented, and working on making it easier to do FP all the time.

this guy came from elm: [https://github.com/pakx/the-mithril- diaries/wiki/Coming-From...](https://github.com/pakx/the-mithril- diaries/wiki/Coming-From-Elm)

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

</comment><comment><USER46> Can somebody take pity on me and explain why the ports system that's supposed to be used for JS integration can't replace the native modules?

<comment><USER2> As far as I know, ports are strictly asynchronous, compared to native code, which can be synchronous. This means that if you are using native code for something that is 100% synchronous, you now have to go through a huge hassle of every calling site becoming async.

</comment></comment><comment><USER11> Another proof that sticking with platform languages is a better option for productivity, even if the languages might miss a few shinny features.

<comment><USER30> Yeah, productivity.

Because spending 10 minutes writing asynchronous FFI code is definitely worse than spending a couple of hours debugging a runtime failure.

<comment><USER11> It is always funny when people compare external languages to platform ones, but keep forgetting to include tooling, libraries and eco-system when comparing them, reducing it to grammar and semantics.

</comment></comment></comment><comment><USER47> Sounds like reasonable removes to me, custom operators are a pain.

<comment><USER6> > Sounds like reasonable removes to me, custom operators are a pain.

Not the point. The point is that it breaks backwards compatibility for the arbitrary prejudices of the Supreme Leader.

</comment></comment><comment><USER48> had to realize for a sec that they weren't talking about the mail client

</comment><comment><USER5> Article aside, the HN and Reddit comments really reflect our toxic entitlement culture. How many comments here seem to exist for no other reason but to get in a negative jab of their own?

I'm reminded of Rich Hickey's great response ([https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_au...](https://www.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/)) to a similar situation.

</comment><comment><USER49> And that, in short, is why I prefer _really_ freakin' old languages for doing real work.

</comment><comment><USER50> These kind of stories make me value Go's approach a lot more. You just have to worry about making your product better.

<comment><USER51> Go's approach? Go has the same extreme BDFL approach to ignoring community feedback in favor of the leader's vision. I don't see what is different about Go.

<comment><USER7> I think the difference with Go is the Google backing. Go ignores community feedback, but not the feedback it gets from within Google. So at least it can justify itself by saying, this works for Google, and that's proof enough its pretty damn good.

Elm's BDFL cannot make such claim, since he doesn't use it to build products closely similar in nature to most users of Elm. I think this is both good and bad. Its good in that Elm is more ideological in nature, since the creator is not motivated to break his ideologies by real world constraints. Its bad, because people who have those constraints must find ways to shoehorn the beautiful ideology, into the dirty real world. That's where a lot of the user pain comes from.

<comment><USER52> Evan works at NoRedInk which has 250 000 lines of Elm in production.

<comment><USER7> Interesting, I thought he had moved on to doing a masters or PhD.

Well then, I take back some of my hypothesis.

</comment></comment></comment></comment></comment><comment><USER53> This was confusing to read if you only knew about the email client Elm. In general I wish people spent more time naming things better, and reducing naming clashes.</comment>


More evidence that you're a mindless robot with no free will - <AUTHOR> http://www.kurzweilai.net/more-evidence-that-youre-a-mindless-robot-with-no-free-will <comment><USER2> It makes sense, and it seems related to some anecdotal experiences. I've had variations of this dream's plot several times:

I am at my living room talking to someone. I tell this person that someone else is going to call on the phone. Then I walk towards the phone knowing that it will ring once I reach and grab it. Sure enough, as soon as I do it the phone rings, but it rings in 'reality', in other words I am already awake and I actually hear it ringing.

At first I tried to explain it by assuming that while still sleeping I hear the first ring which triggers the dream's plot and I actually wake up to the second ring. But it was hard to explain why the plot's timing was so precise as to match me grabbing the phone to the instant I wake up and hear it ring.

Then I had 'single events' that matched the dream's pattern: event E will happen in the future and I would dream plot P that would end at the exact T time of E happening in 'reality'. For example: I was dreaming I was in a gathering and someone came from behind, gabbed my shoulder and it was my mom waking me up. Or once I was dreaming that I was moving a heavy box which I dropped and the instant it hit the floor I woke up to a door slamming in my house due to the wind.

As in this experiment, I think that my brain built the dream's plot in milliseconds after unconsciously experimenting the actual event, wake up, boot up and play back the plot.</comment>


Managers: This isn't remote work. It's leading through a crisis - <AUTHOR> https://soapboxhq.com/blog/employee-motivation/managing-in-a-crisis <comment><USER2> Thanks for sharing Brennan :)</comment>


Canadian banned from U.S. for marijuana investments seeks waiver to cross border - <AUTHOR> https://www.theglobeandmail.com/cannabis/article-canadian-banned-from-us-for-marijuana-investments-seeks-waiver-to/ <comment><USER2> Isn't this obviously a possible outcome since federal law still doesn't change regarding marijuana?</comment>


Show HN: Make copy suggestions on any website - <AUTHOR> https://usepastel.com/copy-changes <comment><USER2> This is very cool. I'm going through the pain of gathering feedback from users and making copy edits on my new launch What level of effort is required to integrate if my product is already built?

</comment><comment><USER3> Looks awesome! Curious do you have any integrations?

</comment><comment><USER4> I also recommend using this :^)

[https://news.ycombinator.com/item?id=21234753](https://news.ycombinator.com/item?id=21234753)

</comment><comment><USER5> This looks super useful!

</comment><comment><USER6> This looks pretty dope</comment>


Racket 6.0: New package system, new doc CSS, JIT support for ARM - <AUTHOR> http://blog.racket-lang.org/2014/02/racket-v60.html <comment><USER2> I'm using Racket for a major project right now. It's been hit and miss. On the one hand, Racket is by far the best alternative/non-mainstream language—the docs are good, there are surprisingly broad libraries, and of course it's great to support the good people at Northeastern.

On the other hand, there is evidence here and there that this language isn't commonly used in production. For example, the pattern-matcher is very well- implemented and feature-full, but there's no way to use it programmatically nor is there a way to get the set of bindings. There is also the sad fact that Racket is a Scheme in the traditional Scheme fashion, and so is still trapped in an 80s design aesthetic. Generics are poor, ADTs aren't easily implemented, static types exist but are not so widely used and have strangenesses.

<comment><USER3> "no way to use it programmatically nor is there a way to get the set of bindings"

These don't really make sense in the context of Racket. Pattern matching is a macro and thus doesn't exist at run time, though of course with eval the distinction between run time and expansion time is not so well defined. Accessing the lexical environment is not something you do in Racket -- it breaks optimisations and is generally considered a bad idea.

</comment></comment><comment><USER4> Racket is my first functional language and its been fun, but is it more of an educational language or is it used in production?

<comment><USER5> We're using it in production at my job. (In a decent-sized polyglot system also made up of Haskell and Clojure).

There aren't as many libraries available compared to more popular languages, but I haven't yet had too much trouble getting things accomplished. For the above-mentioned languages we're using, I'd put the useful library situation at: Racket-> Haskell-> Clojure in order of least to greatest.

Depending on what you need it to interoperate with, it's totally usable in production environments as it stands.

<comment><USER6> How come you are using all three of those languages in production rather than just one of them?

<comment><USER5> I'm using different languages for different parts of the system.

While I could probably do everything in one language, I'm not sold on the idea that that's actually a good idea (aside from developer convenience, which considering I'm the only developer I don't rate very highly). I also don't feel qualified enough as a language person to really hold defensible opinions about their relative strengths and weaknesses yet.

For example, part of the system is a network service that runs deployed on servers in our environment. All that code is Haskell. I didn't want to have to deploy and manage an interpreter or JVM on those systems, and I don't trust myself to write C that I feel confident deploying in production. Haskell seemed like a good win there (other folks might use Go, or whatever). It turned out to be really easy to write a network server in Haskell that receives the messages that the service needs to receive. Also, it was the first time I used a language that had good (or really, any) pattern matching, and I'm sold on it.

The "business" logic of the system is all currently in Racket. It could certainly have been written in Haskell, but I'm still getting up to speed in it, whereas I was able to get pretty minimal functionality up and running with Racket very easily.

Right now only the web interface is Clojure. I briefly considered using Yesod for the web piece, but it seemed really complicated. And although Racket has a nice web server, it requires buying into the "continuations" style that they advocate (or rolling your own web libraries, which seemed like a bad idea for this project).

I think the continuation-based approach for web servers is certainly valid, and maybe even technically better, but they're swimming against the tide with that approach, and as web programming is so far my least favorite part of building this system, I wasn't willing to buy into that enterprise.

Thankfully, I was able to get a Clojure web app up and running very quickly (basically just Ring and Compojure).

The system is designed where there's pretty hard boundaries between all the parts, so by the time all is said and done, it might all be written in the same language; but that's not necessarily a design-goal. I figure different languages seem to have different strengths, and there's not really a good reason for me to try and shoehorn everything into one.

<comment><USER7> If you want to try out Haskell for web development again one day ping me (email in profile) and I'll send you a copy of Snap for Beginners[1]. I'm releasing it at the end of the week and it should make getting started in web dev with Haskell easier.

[1] [http://snapforbeginners.com/](http://snapforbeginners.com/)

<comment><USER5> Yeah, I pre-ordered your book, I look forward to reading it.

When I originally looked at using Yesod, it seemed fairly complicated for what I needed (which is basically just the crud-iest of crud apps). I'd only been using Haskell for a couple of months, and I'd never done any web programming; so I figured I should try to use something that wouldn't require quite so much "stuff".

I finally decided to try out Clojure because I'm planning on using Datomic for the main datastore (because it looks like I can have it backed by Cassandra, which lets me store all of our data in an HDFS cluster.) and the "Web Programming with Clojure" book just came out. I figured I could probably figure out a very basic database-driven view web app just by going through the book. That turned out to be true, actually, and it wasn't that hard to get my app up and running.

What dawned on me going through the book was that what seemed complicated to me really wasn't a function of the language, but the way almost all mvc web libraries seem to be laid out; and that actually once I understood how they worked, I could probably implement the same thing very similarly in almost any language that has a similar library.

So I might eventually look into making a REST api using Snap to handle the requests, and sort of encapsulating all input and output in the system with Haskell.

</comment></comment></comment></comment></comment></comment><comment><USER8> Just want to make note that DrRacket has the best integrated REPL of all the lisps around, its highly underestimated.

<comment><USER9> Have you tried SLIME? I'm wondering why you put DrRacket above SLIME.

<comment><USER10> Is SLIME any better than Geiser? I've been using it with Racket and it's pretty good.

[http://www.nongnu.org/geiser/](http://www.nongnu.org/geiser/)

<comment><USER11> Geiser is great, but SLIME is much better mostly because Common Lisp was designed with interactive programming in mind(the condition system, the object system, dynamic variables ect. are all features that help with interactive programming). You get an almost smalltaskesque feeling with slime.

</comment></comment></comment></comment><comment><USER12> Is Racket good for learning Lisp/Scheme or is it better to start with something else?

<comment><USER13> If you are interested in learning a LISP, then Racket makes a lot of sense. It is actively being developed and extended and because of its roots in academia extensions tend to be address interesting problems- many arise out of computer science research by professors and grad students.

On the other hand, if you want to learn Scheme by working through SICP, then I would recommend MIT Scheme to avoid impedance. There's not much benefit from using the Racket ecosystem for that. Likewise, if the goal is to work through _On LISP_ then a common Lisp implementation makes sense.

Of course there's no reason not to have all those languages installed..or at least that's what I tell myself.

My last advice is that Racket is an ecosystem. It provides many languages including Algol and Datalog and Scribble and Typed Racket. This makes for a lot of documentation and it is uneven. The guide will be too shallow and the reference will be more boilerplate rather than providing deeper explanation and further examples.

<comment><USER14> It has admittedly been several years, but I distinctly remember MIT Scheme being an utter pain in the ass to get built. I'd recommend Racket for people just getting off the ground for that reason alone.

<comment><USER15> GNU does provide binaries for some systems: [http://www.gnu.org/software/mit- scheme/](http://www.gnu.org/software/mit-scheme/)

However, there hasn't been a release since 2011. The primary maintainer (Chris Hanson) is now at Google, and seems to be busy with other things. Previously, he was at MIT and used to write most of his own research projects in Scheme, so it got a lot more maintenance attention.

</comment></comment></comment></comment><comment><USER16> This language just keeps getting better and better. I am so glad I bought the Realm of Racket book. Cannot wait to get my Scheme on!

And with ARM this will soon become the only language I need!

<comment><USER17> Yes, I really love racket. Congratulations to the team!

</comment></comment><comment><USER18> Congrarulations, the Racket team! It's really a joy to use Racket. Racket is elegant, powerful and fast. Everybody should try it. It's extremely easy to install and setup. And whenever you have any question, a fantastic community is there waiting for you.

</comment><comment><USER19> Anyone used Racket AND clojure in production? Any first hand experiences? We're looking to add another language/environment to our, currently RoR+Postgres stack, and have a soft corner for lisps.

</comment><comment><USER20> How is whalesong coming along? Anyone using it for production apps.

<comment><USER21> What is whalesong? Do you have a link?

<comment><USER22> Racket to JS compiler by Danny Yoo. [http://hashcollision.org/whalesong/](http://hashcollision.org/whalesong/)

</comment></comment></comment><comment><USER23> Having used clojure for a few things recently, I am interested in picking up a non-jvm lisp. It seems like Racket and Chicken Scheme are both well recommended. Anyone reading this have experience with both / insights as to why I might want to select one vs the other?

</comment><comment><USER24> The package ecosystem has expanded. I like that.

[http://docs.racket-lang.org/pkg/getting- started.html#%28part...](http://docs.racket-lang.org/pkg/getting- started.html#%28part._github-deploy%29)

</comment><comment><USER25> I like that the docs look less like they jumped out of the geocities era. Still could go a long way though. Signalling is important, and if you signal "old and unupdated" to your users, that's not a great start. (e.g.: [http://docs.racket-lang.org/pkg/Package_Concepts.html](http://docs.racket- lang.org/pkg/Package_Concepts.html))

"prev", "next" (when the table of content is right there next to it) and "top" (usually the header / logo link these days) and collapsible TOC trees screams "we copied this out of MSDN '97 and windows .chm files".

The "...search files..." looks like it was written by a programmer. The white on gray line with the black on white line next to it looks odd. Natural spacing sometimes is a great substitute for lines.

The main docs page ([http://docs.racket-lang.org/](http://docs.racket- lang.org/)) contains way too many fonts and way too many colors. Pick a scheme and go with it.

My favourite examples of docs that look like people cared:

[http://flask.pocoo.org/docs/quickstart/](http://flask.pocoo.org/docs/quickstart/) (well designed, tasteful font, color and spacing selection)

[http://docs.vagrantup.com/v2/getting- started/index.html](http://docs.vagrantup.com/v2/getting-started/index.html) (lack of search bugs me)

[https://developer.mozilla.org/en-US/docs/Web/CSS/:nth- child](https://developer.mozilla.org/en-US/docs/Web/CSS/:nth-child) ("hide sidebar" here serves a real purpose: hides the whole thing so the doc display is wider, kinda nice that TOC follows you)

Conclusion: Glad it's improving, but please keep at it! Great docs make your product a joy to use!

\</comment><comment></comment><comment></comment><comment></comment><comment>-

edit: let me add some WORSE examples to put things into perspective:

[https://www.tcl.tk/man/tcl8.6/TdbcCmd/tdbc.htm](https://www.tcl.tk/man/tcl8.6/TdbcCmd/tdbc.htm)

[http://junit.sourceforge.net/javadoc/](http://junit.sourceforge.net/javadoc/) (ughhhh)

[http://www.gnu.org/software/smalltalk/manual/](http://www.gnu.org/software/smalltalk/manual/) (whenever I see the gendocs selection page I get nostalgic. Really? 120 vs 420kb? I didn't care even when I was using dialup. Also the "one webpage per node" version almost always sucks because you can't search for anything. And the "all in one page" version sucks because it's too huge sometimes. Who uses the ascii text version or the info docs version?)

<comment><USER26> I think you have a valid point (other than in the case of the Vagrant docs, which I absolutely detest [0]).

The simplest way to make good-looking docs might just be to 'just use Sphinx' (as does Flask, mentioned and [http://docs.python.org/](http://docs.python.org/) and [many others][1].

Another example of amazing docs (they've always been pretty decent, but amazing in their most recent style) are the PHP docs: [http://www.php.net/manual/en/function.pg-affected- rows.php](http://www.php.net/manual/en/function.pg-affected-rows.php)

The docs are a necessity to make up for the shoddy, inconsistent patchwork that is their language design, but they are damned well designed and easy-to- use for the wading through flat scope that is required by those who use the language.

Similarly, styles based on YARD/codo ([http://coffeedoc.info/github/coffeedoc/codo/master/](http://coffeedoc.info/github/coffeedoc/codo/master/)) are pretty nice for API references.

[0]: Disappearing sidebar when you resize to narrow, _huge_ amounts of spacing everywhere and sidebar names that can't be expanded without navigating to their root. :/

[1]: [http://sphinx-doc.org/examples.html](http://sphinx- doc.org/examples.html)

<comment><USER25> Ooooh the PHP ones are even better than they used to be, I hadn't checked in a while. I have always loved the user comments in docs idea. I've noticed so many bugs, gotchas and idiomatic patterns simply by looking at those comments. I bet it gives the devs a good idea on what to work on next, too. It didn't used to have votes which was bad because it perpetuated bad advice sometimes, but now it seems they have that too!</comment></comment></comment>


World's Lightest Material Is a Metal 100 Times Lighter Than Styrofoam - <AUTHOR> http://www.sciencedaily.com/releases/2011/11/111117154643.htm

<comment><USER2> I find it interesting that they haven't named the "new metal" material yet. Is this new class of materials supposed to be lumped together under "micro- lattice", similar to how most people refer to plastic(s) as a general material class?

I guess they'll come up with a catchy name. If not the scientists, then the collective media-savvy cultural sub-conscious will.</comment>


Police Body Camera Bursts into Flames; New York Pulls 2,990 from Use - <AUTHOR> https://www.nytimes.com/2018/10/21/nyregion/police-body-camera-explode.html <comment><USER2> LOL, Just what the police unions wanted, probably a cleverly faked 'spontaneous fire'</comment>


Testing an AI algorithm from concept to production - <AUTHOR> https://www.optimail.io/blog/validating-optimail-testing-ai-algorithm <comment><AUTHOR> Author, here. In this post, I review the various ways that we put our email marketing optimization algorithm to the test, starting from simple sim environments in R, to scrappy real-world tests, more complex simulations, and ultimately a private beta with a production app. I hope it helps those thinking of bringing their own algorithms to market, and would love any feedback!</comment>


Silicon Valley Is Listening to Your Most Intimate Moments - <AUTHOR> https://www.bloomberg.com/news/features/2019-12-11/silicon-valley-got-millions-to-let-siri-and-alexa-listen-in <comment><USER2> If they want to listen to me fap, then I hope they get thoroughly traumatized.</comment>


The great university con: how the British degree lost its value - <AUTHOR> https://www.newstatesman.com/politics/education/2019/08/great-university-con-how-british-degree-lost-its-value <comment><USER2> Notably, in the chart, the US seems to do even worse.

If you doubt this, consider hiring a new BS grad sight unseen. Do you feel lucky?</comment>


Kerr black holes images and videos (2012) - <AUTHOR> http://www.madore.org/~david/math/kerr.html <comment><USER2> "In fact, from the distant observer's point of view, nothing beyond the horizon really exists, and a physical black hole's mass could be said to consist of the mass of the collapsing star, ever frozen in the last stages of its collapse."

Mind blown.

I remember reading that we cannot see a black hole with the naked eye, but never go an explanation as to why...

This is a really good article.

<comment><USER3> Since, as the article explains, an outside observer would never see things falling towards the black hole actually reach the 'black' part - they'd just get slower and redder as they get close. So - wouldn't a black hole appear entirely surrounded by all the things that ever 'fell into it', still there outside it? I've never seen an 'artist's impression' of one that looks like that..a big ball of dust, rocks, ice etc.

(Imagine if garbage bins looked like that..)

<comment><USER4> So... the black hole may look like a collapsing star but also like a planet? The only thing distinguishing it then would be its escorting (but not yet fallen) world around it?

</comment></comment></comment><comment><USER5> Off topic. Whenever I waste a lot of time on youtube looking into some subject(today it was black holes) it ends up on Hacker News also. Surely, somebody has a name for this effect.

<comment><USER6> Baader Meinhof, possibly?

<comment><USER3> Thank you. [https://en.wikipedia.org/wiki/Baader–Meinhof_effect](https://en.wikipedia.org/wiki/Baader–Meinhof_effect)

</comment></comment></comment><comment><USER7> Related: visualizing travelling through a Schwarzschild black hole:

[http://jila.colorado.edu/~ajsh/insidebh/schw.html](http://jila.colorado.edu/~ajsh/insidebh/schw.html)

As OP page indicates, the Schwarzschild description is simpler as it doesn't take into effect the rotation, but their visualization, especially with the distorted space background, are impressive nevertheless.

</comment><comment><USER8> Great page, the software builds really easily. Try it!</comment>


Apple Releases Fix to MBPs in Response to Consumer Reports' Battery Test Results - happy-go-lucky http://www.consumerreports.org/apple/apple-releases-fix-to-macbook-pros-in-response-to-consumer-reports-battery-test-results/ <comment><AUTHOR> Oh good. In my normal usage, which is of course repeatedly loading 10 webpages (not from cache, only in Safari), I will have excellent battery life. I'm glad I don't know anybody who will use the machine differently.

Honestly though, how much did this article and the inevitable 'Recommended' rating cost Apple? My internal BS detector is beeping.</comment>


Google gave our business listing to a competitor - <AUTHOR> https://www.parkcityluxuryrealestate.com/blog/google-gave-our-our-business-listing-to-a-competitor-and-our-fight-to-get-it-back.html <comment><USER2> This Reddit Comment describes what's happening here well: [https://www.reddit.com/r/google/comments/gtexcj/google_gave_...](https://www.reddit.com/r/google/comments/gtexcj/google_gave_away_our_business_listing_to_a/fscjgyp/)

>The core reason it happened... this place doesn't qualify to be on the map in the first place and it thus confuses the system.

>The secondary reason... the name of a feature is supposed to be the name and nothing more.

>A real estate agency qualifies to be on the map. Google also lets certain professionals to be on the map, with realtors being one such professional.

>This is neither of those, this is a "team". It's not allowed on the map anymore than the team or shift I'm on at my job.

>Here's the exterior. As you can see the name of the agency is "Summit Sotheby's International Realty", that's on the map at [https://goo.gl/maps/cVEtvvRqCnJq5aEJ8](https://goo.gl/maps/cVEtvvRqCnJq5aEJ8).

>Other than the agency, all that then qualifies to be at this location are listings for individual realtors. So a listing that says "Cindy Wallace" and nothing more in the title is allowed. Instead we have her trying to keyword stuff her listing with Park City Utah Real Estate - Cindy Wallace Team. She also uses the category of Real Estate Agency when she isn't one, she needs to use the Real Estate Agents category. Probably doesn't work the trend of trying to represent your "team" as it's own agency.

>It's pretty common for people to not follow the rules and then complain that the algorithms don't do what they want. Follow the rules and the algorithms will then work.

<comment><USER3> If what this reddit comment is saying is correct, it seems to me to mean that Google's business reviews are unreliable information.

The complaint is not that "The Fisher Group" should be on the map instead of "Summit Sotheby's". The complaint is that reviews which used to be attached to one agent (Stan/Ben Fisher) are now attached to a different agent (Cindy Wallace). Apparently this happened because two different Google Business accounts (one that Stan/Ben Fisher had had for years, and one that Cindy Wallace just created) got merged into one. That seems to me to be a problem for two reasons:

(1) How can Google not comprehend the idea of multiple business accounts at the same address?

(2) How can Google merge a newly created Google Business account with one that has existed for years _without checking with the owner of the one that has existed for years_? Saying "well, the person who set up the new account made a mistake" is not a good answer.

Of course, AFAIK these people aren't paying Google, so to Google they're not customers, they're just users whose data Google wants to sell. But maybe if enough people get the idea that Google is simply incapable of providing accurate data on businesses and reviews, and stop depending on Google for that information, and word of that gets around, Google might start thinking that maybe they need to do something. (Not that I'll be holding my breath.)

<comment><USER4> > it seems to me to mean that Google's business reviews are unreliable > information

Of course they are - any information at this scale is best-effort and should be treated as just a general indication and possibly erroneous.

<comment><USER5> Even the Yellow Pages were able to manage information at this scale more accurately. Google's culture favors minimum effort, not best effort.

<comment><USER6> The local yellow pages made the business pay about €1000 to be listed (could be quite a bit more depending on the category). Google may have numerous issues but it doesn't require you to pay one month of income.

<comment><USER5> Is it even possible for a business to pay Google for better service? It seems like they just can't be bothered to fix the info, not even for €1000.

<comment><USER7> Yes, but it's called getting a google employee drunk.

Not even joking, this is by far the fastest way to get a response.

<comment><USER8> Plying people with alcohol seems very unethical.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Once again, HN is the last-resort customer support line for Google. Oh well, upvoted. Embarrassing the company is the only way to get any slightly complex issue resolved.

<comment><USER10> I was (briefly) on a Maps-adjacent team at Google circa 2015.

From the outside, you just can't imagine how few Google engineers are responsible for how many products and data integrations.

One example: back then it was a dozen people (literally) responsible for every single business's hours, category, and more for all of planet Earth. They automate the crap out of it and the automation mostly works (scrape structured data off websites, Google My Business, various aggregators, etc.) but it means there's no conceivable way you could provide customer support that will keep up with the volume of support requests because the support requests often ultimately have to get routed to an engineer... and there are only a dozen engineers on the team that owns stuffing all this data into Maps. And those engineers are supposed to be doing mostly feature work. Over time accuracy got better, but 95% accuracy, to say nothing of 99.9% accuracy, is unachievable to the point of being a non-goal.

One of this team's bigger time sucks was just _other Google engineers_ complaining about inaccurate data. Someone would go to their favorite restaurant, notice the hours were off, or the business category was wrong, and file a ticket. Then the team would sometimes manually edit the listing to fix it. Sometimes they'd say "no, you have to deal with the same shitty data as all our customers". But that was just the requests coming in from a few thousand users who had access to the internal ticket system and new which component to file stuff under. (Incidentally: this is the origin of the Maps feature where you can now just directly edit a listing and if other users, agree, it gets published.)

So, yeah, there isn't really a scalable way to manage support requests. But HN works for some subset of cases, and I too upvote the cases that get complained about here.

EDIT: accuracy in the raw data was pretty bad but on a view-weighted basis it was pretty respectable IIRC (>90%). Turns out most people on Maps are looking at the same small subset of establishments, so you have to get those right even if that means making choices that reduce accuracy on other listings.

<comment><USER11> If I may ask you, because that's something I've wondered many times with Google: why are the docs and self-help support option so basic on most of these things?

I understand the idea of "automate it, it must scale", but especially then I'd expect the systems to add/correct/delete info to be super streamlined, the documentation to be very thorough and covering all business cases etc. Yet it feels like the opposite is true: the GUIs are generally sub-par and feel like "okay, we have a great API. Can you throw some GUI on it?", the documentation is short and often either outdated or did not cover certain cases in the first place, and "what to do if this doesn't solve your problem" is rare.

Is that "we want to be a platform, not a service provider" and meant to discourage end-users from using the system directly and pay a professional agency instead that handles the support issues? Because that's really the only explanation I've heard so far that makes some sense. It feels like Google is putting more manpower in developer relations than in customer relations and I've never understood why.

<comment><USER12> On documentation:

I've seen dozens of articles on this site about hiring practices from large technical companies, and Google in particular.

I don't remember seeing anything suggesting they even verify that the people they're hiring are capable of writing basic documentation, let alone that they appreciate the importance of it being complete, correct, and up to date.

Every indication is that Google vastly undervalues documentation, both for internal and external purposes.

<comment><USER13> > Every indication is that Google vastly undervalues documentation, both for > internal and external purposes.

This just seems to be companies as a whole. Documentation is a low-status activity (no promotions or raises available for doing it) that still requires decent cognitive function, so it is not something you want to do when you are energized and ready to go nor something you can do when tired and not in the mood to work.

There are no automated tests to tell you that the documentation no longer works, so the engineers would need to periodically check. We have automated tests in code because engineers won't comprehensively check everything.

In my org we frantically document when an engineer gives notice. Otherwise, we can't even keep the URLs updated or maintain a running list of configuration variables.

<comment><USER12> There's a virtuous circle with documentation: if you start with something that's complete and correct, then when you make a change which is visible to the code's clients you can go and change the documentation in the same patch series, and check that this happens as part of the main code review.

Digging yourself out of the hole where your documentation is already wrong or incomplete is much harder: when you go to describe a change you might find that the thing you're changing isn't mentioned, or is described wrongly, or there is no terminology for the thing you need to talk about.

So you need everyone to take care that standards don't slip, which is why it's important to make the importance of documentation part of the company culture, and make sure every programmer is capable of doing their bit.

</comment></comment></comment></comment></comment></comment><comment><USER14> "Google Offers No Help"

Even though I love Google, this is increasingly getting scary. More than hackers getting into my account, I am actually more afraid of getting locked out by Google one day.

An year or so back I created a Google account for my five year old daughter to be used on a Nexus 7 2012 (yes, it still works). Recently, I reset the device and tried logging in with my daughter's account but had forgotten the password. In spite of giving the recovery address correctly and entering the OTP that was sent, Google kept telling me it couldn't confirm if I was the owner of the account.

Since this is a new account I don't have a problem but what if this happened to my main account?

</comment><comment><USER15> The current internet giants got huge monopolistic like power that many dictators of many countries would envy. The set their rules, execute them, and judge them.

Even having a decent map listing is sometimes make it or break it in competitive industries such as hotels or restaurants.

I believe once you become a platform there should be an independent nano- courthouse where you can appeal. Today being rejected or having listing hijacked on Apple, Amazon, or Google platform is equivalent to the economical death penalty for many individuals.

It should be possible to pay $100 by individuals and appeal to an independent nano-courthouse if the original platform rejects or blocks you. If you win, the appeal fee is refunded and the platform has to cover the cost. If you lose, your $100 is gone.

<comment><USER16> I believe that article 17 introduced something like this in UE for YouTube?

</comment></comment><comment><USER17> One of the main problems with these giant mega corporation is that they don't have the bandwidth to interact with people and there is no recourse for people when things to wrong. Corporations are negligent by design and the worst part is that the government allows them to keep sweeping problems under the carpet at no cost to them.

Because of their scale, corporations are harming millions of people in thousands of different ways through their neglect but because the level of neglect is subtle when mentioned in a court room setting, these corporations are not being punished for the real damage that they cause.

<comment><USER18> This is not a "giant mega corporation" issue, it's a Google issue, because they simply do not prioritize customer support at all.

Now I'm neither an Apple fan nor Microsoft fan (don't like their business decisions at all), but I have been required to deal with their customer support at times. It's actually possible to get your hands on a real human to get support, so you can solve stuff.

The same cannot be said for Google.

<comment><USER19> > Now I'm neither an Apple fan nor Microsoft fan (don't like their business > decisions at all), but I have been required to deal with their customer > support at times. It's actually possible to get your hands on a real human > to get support, so you can solve stuff.

Did you actually get customer support for Apple Maps? Because they've been completely ignoring my updates to their mistakes in my area and have been pretty much the same as Google in that respect. Except that at least Google Maps are correct.

</comment></comment></comment><comment><USER20> At this point Google has a monopoly on the search business.

When their algorithms hurt a business when you try to search for it, and they are not willing to change it or help, why is this not libel?

They should be responsible for supporting this monopoly, and they should have competent support people that can either explain what's going on or can fix it. They have neither and businesses really do suffer.

I think a class action lawsuit should be started against Google until they start investing in support services and that can adequately fix mistakes. If not a class action lawsuit, then I fully support legislation and regulation that forces them to spend on support.

This has happened so many times across so many of their platforms, it's obvious what they are doing. They have created a monopoly and then their entire ecosystem depends on them, but they spend almost nothing to support their ecosystem. That's how they remain so profitable.

<comment><USER21> >why is this not libel?

Is this not just a straight up section 230 instance? They're just displaying user generated content.

</comment></comment><comment><USER22> This is the reason I hate google. No customer support at all. They will just provide link to forum. I will go with Microsoft anytime for business software than Google. I feel like it is company built by nerds with zero business sense. If your KPI depends on building new products, there ain't a reason to improve existing ones. Classic case of Goodhart's law.

<comment> tech-historian It's not like Microsoft is pure as the driven snow, either. It's a massive corporation with all sorts of warts. Just to name a few from the past few months:

WinGet fiasco: [https://www.theverge.com/2020/5/28/21272964/microsoft- winget...](https://www.theverge.com/2020/5/28/21272964/microsoft-winget- windows-package-manager-appget-copied)

O365 Installer forces Bing as search default: [https://www.theverge.com/2020/1/22/21077280/microsoft- chrome...](https://www.theverge.com/2020/1/22/21077280/microsoft-chrome-bing- extension-office-365-proplus-installer-default-search-engine)

Azure jacks up prices in sneaky ways: [https://www.lastweekinaws.com/blog/microsoft-screws- customer...](https://www.lastweekinaws.com/blog/microsoft-screws-customers- and-its-own-advocates-alike/)

MS ends partner benefits: [https://www.theregister.co.uk/2019/07/11/microsofts_reasons_...](https://www.theregister.co.uk/2019/07/11/microsofts_reasons_for_ending_free_licenses_for_partners/)

Closes eBooks store, customers lose all purchased books: [https://www.bbc.com/news/technology-47810367](https://www.bbc.com/news/technology-47810367)

Microsoft partners with ICE for facial recognition and other technology: [https://gizmodo.com/microsoft-employees-up-in-arms-over- clou...](https://gizmodo.com/microsoft-employees-up-in-arms-over-cloud- contract-with-1826927803)

etc etc etc.

</comment></comment><comment><USER23> The discussion here is largely about how it's impossible to be really correct at Google scale, and this is something that terrifies me about where the industry is going. When there's a task that can be done by people, we can always correct issues. Going down to 99% correct could also mean cutting costs by like 90% through automation, so the business is going to be happy, except that now there's no one for the consumer to turn to but the bots when things go wrong.

In the future, if your name is Scunthorpe [0], you're out of luck, because it's impossible to not have these issues at scale, and apparently scale is inevitable.

[0] [https://en.wikipedia.org/wiki/Scunthorpe_problem](https://en.wikipedia.org/wiki/Scunthorpe_problem)

<comment><USER24> The "x is impossible at google scale" (where x usually means customer support but in this case information correctness) argument falls flat to me. If x is impossible at their scale, then their scale needs to be cut back. Companies shouldn't be allowed to be so large and all-encompassing and monopolistic that they negatively impact society because x is impossible at that scale.

<comment><USER25> You're right. Yet currently there is one major normativity in action and that is the normativity of the market. Market rewwards economies of scale and monopolies more than anything else. Unfortunately there is no working institution left to bring in the normativity of societal good for balance. One might hope for state to make a move, but big tech pays _the_ most lobbying money currently, so I wouldn't hold my breath.

<comment><USER24> > so I wouldn't hold my breath

Of course. I agree that market pressure is pushing companies that way and there's little that can stop it now. But that still doesn't make the excuse a good one, certainly not for us, the people.

</comment></comment></comment></comment><comment><USER26> Searched for lawyer both in the post and this comment section and got nothing.

You'd be surprised what a lawyer can accomplish, even with no real law backing you up. You want an actual response from Google? Get a lawyer involved...

<comment><USER27> That's actually another problem in itself. You shouldn't need a lawyer just to be given the time of day when there's a problem.

</comment></comment><comment><USER28> Some may be sympathetic to Google not providing enough customer support for tricky issues.

But here's a much simpler problem I've had.

I have a Google My Business account which was long ago properly authorized and verified for a business at a particular location. Verified by landline phone, photos, etc.

One day some random member of the public put in some incorrect information.

I didn't notice the change for about 6 months.

Now, even though I created, control, have verified etc, the Google My Business account for that data, and theoretically I'm the only person with that level of control over the business listing... I'm "not authorised" to correct the information via Google My Business itself.

Wtf?! Isn't that what it is _for_?

I can still login to Google My Business. I can edit some fields - I'm still regarded as the authority for sensitive things like phone number. So they haven't removed my special status (nobody else can edit the phone number).

Rather, some things in Google My Business which are editable fields and the UI invites me to edit, give "not authorised" when I submit. That was surprising, I thought I was the authority.

After trying every option, I tried Google's online support from Google My Business. It said I'd get a response in a few days; in reality it took longer than a month to get a terse and useless reply. I sent a few messages in that time, basically asking "is there anyone there"?

Eventually I did speak with someone at Google about this. They told me that I needed to go through the whole "prove your business is what you say it is and not what a random member of the public said it is" verification rigmarole all over again, with photos, etc. In the circumstances I was not able to do so (I wasn't on site enough any more, and our office wasn't as visually distinctive any more).

I'm asking myself, what is the point of a verified Google My Business account if randoms can override the business owner and lock them out anyway??!

That was last time.

Before that, it took _2 years_ to remove an incorrect address and location for the business.

I don't think that can be put down to "limited staff for customer support".

I put it down to poor & misleading system design. What is the point in telling people to get, verify and maintain Google My Business account, only to _subtly not mention_ that it still isn't authoritative data for your listing, and the owner may get overridden by randoms. Probably without noticing for a long time.

</comment><comment><USER29> I know that this makes it to the front page because it is symptomatic of frustrating and frightening things that affect society as a whole. I won't comment on those things because I don't know the answers.

But insofar as you want to solve your particular problem, there is a simple answer that seems not to have been suggested here. Get a lawyer and sue them!

</comment><comment><USER30> I do not know for sure if this is related, but it definitly tastes the same:

Back in 2010 [1] I logged into google using chrome on my mother's device. Removed the account from the device afterwards. Today, many devices later, we still were not able to stop my mother from receiving autofill entries, contacts and such originating from my account.

Long story short: I am tried to vouch for the existance of non-layer-8 trouble leading to "shared accounts". Neverending fun.

[1]: maybe 2012

</comment><comment><USER31> This matters because there's a monopoly in the market.

</comment><comment><USER32> This is gross!

</comment><comment><USER33> I think, We haven't seen single week in 2020, where Google didn't fail to make it front page for worst customer support and for their evil practices.

<comment><USER34> Except when the headline says 'competitor' the truth seems to be 'coworker'.

<comment><USER35> Except in their industry they are still competitors even if they've chosen to be co-workers to save on costs like office space and marketing.

<comment><USER34> In a sense, everyone is. Want that promotion? Better be going 'above and beyond.' Even just choosing who to lay off is competitive.

</comment></comment></comment></comment><comment><USER36> Disclaimer: I work at Google but not on Maps and am speaking for myself, not my employer.

I am normally very sympathetic to HN complaints about Google customer service. They're normally about Cloud or GSuite, this one is a bit different.

Does anyone here think it would actually be possible to have a free (or even cheap) comprehensive maps service that also has customer support? How many dedicated support people would you need to make fair human decisions about every place, road, and business in the entire world?

Maps are just really really hard, especially as we expect them to be so much more than the simple maps they replaced. It's a database of everything there is to do in the world. And we don't pay a dime.

<comment><USER37> I hope it's not controversial to say that if your ambitions are to be the whole world's middle man on something, you have some responsibilities regarding how to do it.

Google doesn't have a "hey, these are scraped and only have like 80% accuracy" disclaimer or anything like that when they direct customers to businesses. I don't know where the line is but Google has some level of basic ethical requirement to not try to be the middleman when their failures (or in google terms >80% accuracy) cost others rather than themselves.

It's presented as correct, not as a best guess. I get that it's impossible to be 100% correct at this scale, but then just don't present it as authoritative. Or let people correct mistakes that are harming them. Or _something_ besides just driving traffic to their own product and saying there's nothing they could do.

<comment><USER19> Is there ANY company that will do that? Can you sue the yellow pages if they're wrong? Or a wrong map?

Or even your own projects - are you willing to put your money and perhaps even criminal record on the line if your company sells data that's not accurate for a percentage of customers?

<comment><USER38> >Can you sue the yellow pages if they're wrong? Or a wrong map?

Yup. You can also win.

[https://www.pmmag.com/articles/84301-oops-the-yellow- pages-b...](https://www.pmmag.com/articles/84301-oops-the-yellow-pages-blew- my-ad)

>>A Pennsylvania caterer had an outdated phone number placed in his ad. The phone number, used briefly in the past, had been assigned to someone else. The result: The caterer lost a ton of money and eventually filed for bankruptcy. He sued the phone company for negligently listing the wrong number. The jury awarded him $200,000.</comment></comment></comment></comment>