but on the other hand, it’s got to be grating to deal with the same entitled, uninformed or complaining comments all the time.

Over the years, I have come to believe this is a vital part of building a community. Using draconian tactics to stomp out annoying comments is using power unwisely and worse yet – cripples your community in multiple ways.

The first thing to remember is that when a comment (entitled, uninformed or otherwise) comes up repeatedly – that is a failure of the community to provide a resource to answer/counter/assist with that comment. That resource can be a meme, a link, an image, a FAQ, a full on detailed spec document, whatever. This type of thing is part of how a community gets a personality. I think a lot of the reason there are a bunch of dead discourse servers for projects is too stringent policing. You should have a place for people to goof off and you have to let the community self police and become a real community. Not entirely, obviously, but on relevant topics.

This constant repetition of questions/comments is healthy, normal, it is the entrance of new people to the community. More importantly, if gives people who are just slightly deeper in the community someone to help, someone to police, someone to create resources for, even to a degree someone to mock (reminding them they aren’t THAT green anymore) – a way to be useful! This is a way to encourage growth, each “generation” of people helps the one that comes after them – and it is VITAL for building up a healthy community. In a healthy community the elders will only wade in occasionally and sporadically to set the tone and will focus on the more high minded, reusable solutions that move the project forward. Leave the minor stuff be done by the minor players, let them shine!

Beyond being vital to build the community – it is a signal of where newcomers are hurting. Now if documentation fixes the problem, or a meme… terrific! But if it doesn’t, and if it persists … that is a pain point to look at – that is a metric – that is worth knowing.

I would prefer that the discussions weren’t removed or locked, but on the other hand, it’s got to be grating to deal with the same entitled, uninformed or complaining comments all the time. I’ve read most of these discussions, and other than people venting, nothing is ever achieved in them. My reflexive reaction is to be uncomfortable (like a lot of other people) but then, there is also a certain clarity when people just say that they will not engage in a discussion.

I’ll go one further and say I’m quite glad those discussions get locked. Once the core team has made a decision, there’s no point in having angry developers fill the communication channels the community uses with unproductive venting. I like the decisions the core team is making, and if those threads didn’t get locked, I’d feel semi-obligated to respond and say that I’m in favor of the decision, or I’d feel guilty not supporting the core devs because I have other obligations. I’m glad I don’t have to wade through that stuff. FWIW, it seems like the community is really good at saying “We’re not going to re-hash this decision a million times, but if you create a thread about a specific problem you’re trying to solve, we’ll help you find an approach that works” and they follow through on that.

I don’t have a lot of sympathy for folks who are unhappy with the removal of the ability to compile packages that include direct JS bindings to the Elm runtime. For as long as I’ve been using Elm the messaging around that has consistently been that it’s not supported, it’s just an accidental side effect of how things are built, and you shouldn’t do it or you’re going to have a bad time. Now it’s broken and they’re having a bad time. This should not be a surprise. I also think it’s good decision to actively prohibit it. If people started using that approach widely, it would cause a lot of headaches for both the community and hamstring the core team’s ability to evolve the language.

I’ll add the perspective of someone who loved Elm and will never touch it again. We’re rewriting in PureScript right now :) I’m happy I learned Elm, it was a nice way of doing things while it lasted.

In Elm you may eventually hit a case where you can’t easily wrap your functionality in ports, the alternative to native modules. We did, many times. The response on the forum and other places is often to shut down your message, to give you a partial version of that functionality that isn’t quite what you need, to tell you to wait until that functionality is ready in Elm (a schedule that might be years!), or until recently to point you at native modules. This isn’t very nice. It’s actually very curious how nice the Elm community is unless you’re talking about this feature, in which case it feels pretty hostile. But that’s how open source rolls.

Look at the response to message linked in the story: “We recently used a custom element to replace a native modules dealing with inputs in production at NoRedInk. I can’t link to it because it’s in a proprietary code base but I’ll be writing an speaking about it over the next couple months.”

This is great! But I can’t wait months in the hope that someone will talk about a solution to a problem I have today. Never mind releasing one.

Many people did not see native modules as a shortcut or a secret internal API. They were an escape valve. You would hit something that was impossible without large efforts that would make you give up on Elm as not being viable. Then you would overcome the issues using native modules which many people in the community made clear was the only alternative. Now, after you invest effort you’re told that there’s actually no way to work around any of these issues without “doing them the right way” which turns out to be so complicated that companies keep them proprietary. :(

I feel like many people are negative about this change because it was part of how Elm was sold to people. “We’re not there yet, but here, if we’re falling short in any way you can rely on this thing. So keep using Elm.”

That being said, it feels like people are treating this like an apocalypse, probably because they got emotionally invested in something they like and they feel like it’s being changed in a way that excludes them.

You’re right though. Maybe in the long term this will help the language. Maybe it will not. Some people will enjoy the change because it does lead to a cleaner ecosystem and it will push people to develop libraries to round out missing functionality. In the short term, I have to get things done. The two perspectives often aren’t compatible.

I’m personally more worried about what will happen with the next major change where Elm decides to jettison part of its community. I don’t want to be around for that.

I think what bothers me the most about the core team’s approach to features is not that they keep removing them, but that for some they do not provide a valid alternative.

They’ll take away the current implementation of native modules, but coming up with a replacement is too hard, so even though the core libraries can use native code, us peasants will have to do without.

They won’t add a mechanism for higher rank polymorphism because coming up with a good way to do it is hard, so even though the base library has a few magic typeclasses for its convenience, us peasants will have to make do with mountains of almost duplicated code and maybe some code generation tool.

So where does that leave Elm right now? Should it be considered a production-ready tool just by virtue of not having very frequent releases? Or should it be regarded as an incomplete toy language, because of all the breaking changes between releases, all the things that haven’t been figured out yet, and how the response to requests for ways to do things that are necessary in real code is either “you don’t need that”, which I can live with most of the time, or “deal with it for the moment”, which is unacceptable.

I think Elm should make it more clear that it’s ostensibly an unfinished project.

I was hoping to read other points of view on that matter, thanks for taking the time writing down yours!

More like should it be legal to show customers of the bank that it has a hole in the wall covered up with some wallpaper.

Basically, should it be legal to do a physical security pen test without a contract.

Yup, Scala example could be translated directly as:

(defn long-comp-1 [] 5)
(defn long-comp-2 [] 6)

(defn aggregate [i j]
  (println "i is" i "j is" j))

(def result-1 (future (long-comp-1)))
(def result-2 (future (long-comp-2)))

(defn aggregated-future []
  (aggregate @result-1 @result-2))

I got the inspiration for the error message catalog from Elm and it’s mostly a stop gap measure to help with most common gotchas. I don’t have the impression that it got a lot of adoption over the past couple of years which might indicate that most people aren’t struggling too much with the error message (or perhaps it just wasn’t discoverable enough). It also looks like Clojure 1.10 will have significantly improved error messages out of the box, and spec allows for tools like expound that produce human readable errors. I’m hopeful that the errors catalog won’t be necessary going forward.

The link provides a good rationale for how the company operates and what their goals are. Their product is open source, and can be self-hosted, which is quite a bit more than just being another email provider in my opinion.

Looks like the site structure changed, here’s the new link.

Similarly just having the same precedence and associativity for everything would give you an easy-to-predict and easy-to-read syntax. This way you gain terseness, but you have to get used to the associativity of whatever mechanism you’re using, whereas s-expressions (or *shudder* XML, etc) are more portable, but require you to explicitly state the tree with more characters.

For example, right associative:

50.04 + 34.57 + 43.22 / 3

And for the sum of everything over three, it would be:

(50.04 + 34.57 + 43.22) / 3

This is the style that APL/J/K and various languages inspired by them tend to use (they also add different precedence for certain operations that take another operation as one of their inputs, such as fold). Many people use such languages as an enhanced calculator (there are plotting utilities made for them, etc). For example, in K, where division is % and assignment is ::

force: (6.67e-11*mymass*collidingmass)%radius*radius
yearlybill: 12*rent+electric+internet

Or with functions, where / is fold:

force:{[m1;m2;radius](6.67e-11*m1*m2)%radius*radius}
yearlybill:{[monthlyutilities]12*+/monthlyutilities}

I think your assessment that Scala faces pressure from both Java/Kotlin as well as functional languages is spot on.

https://www.benfrederickson.com/ranking-programming-languages-by-github-users/ indicates that Scala lost 20% of its active users within a year, while Kotlin tripled its amount of active users, surpassing Scala by a large margin already.

The goal of simplifying the language with Dotty seems like a good idea […]

That’s not going to happen. The promises on conference slides do not reflect the reality.

There are already 6 or 7 new keywords, not speaking of other additions, and the cleanups do not depend on Scala 3 at all – in fact many of them have been implemented (and shipped behind a flag) for years already.

The privacy issues with centralized services revolve around them actively working to mine your data. These companies are in the business of making money, and you are their product.

This is a common error. Centralized doesn’t immediately equal evil or selling you out. It depends on how they’re set up. There’s companies that just sell you a service without trying to send your data to others. FastMail was a popular Gmail alternative whose users say it’s super-fast and stuff, too. MyKolab was a Swiss one I found for $5 a month with privacy policy. ProtonMail is a recent entry with crypto. HushMail is possibly the oldest of those. ZixCorp has similar services. The PGP company should probably be in this list.

That’s just email. There’s long been solutions doing similar things for chat, backups, mobiles, and so on. There’s just hardly anyone buying them. A few have been around a long time making money. Mostly selling to businesses, though. There is a market but won’t get you rich easily. One can build centralized, non-profit companies with charters protecting privacy. I’ve pushed this a long time. Also, put it in the EULA’s with EU-style penalties for privacy failures if users push for them. Maybe also in the hiring agreement for employees where they can refuse to work on surveillance or privacy-defeating features without termination. On top of that, one might build several of the same company in different countries as a public-benefit multi-national where they sort of check on each other but otherwise operate independently in their own market with tailored solutions.

There’s a lot of potential. There’s also companies taking care of their customers every day using tiny subsets of what I described. Often just owners or company culture that believes in it. People talking like all businesses are evil or have to sell out their customers do those businesses a disservice. Instead, we should try to see what protections we can build on top of those proven models in centralized form before telling people they have no choice but use decentralized stuff. I mean, we can have people developing both in parallel. I even encourage to mitigate impact of failures.

Well there is the Librem at least.

https://puri.sm/shop/librem-5/

Also Fairphone:

We offer the ability to choose between the Google experience and the freedom of open source. Both versions are officially supported by Fairphone and we will provide continuous software updates.

In addition, and because the code is openly available, everybody is free to work on making other operating systems work on the Fairphone 2. The community already offers alternative operating systems like Sailfish OS, Ubuntu Touch and LineageOS.

You can unlock the bootloader on most Android phones and you can run LineageOS or other AOSP forks, sometimes Ubuntu Touch and Sailfish ports, or postmarketOS.

You typically have to run the vendor android kernel fork if you want to have useful functionality, but some devices (Nexus 5, Nexus 7, Xperia Z2, Xperia Z2 Tablet) can run mainline Linux.

https://wiki.postmarketos.org/wiki/Devices

One large scale study of GitHub projects fails to show a significant impact overall, and shows no impact for functional languages.

That is not the language used by the authors of the paper:

The data indicates functional languages are better than procedural languages; it suggests that strong typing is better than weak typing; that static typing is better than dynamic; and that managed memory usage is better than un-managed.

Annecdote but Typescript exists purely to make an existing language use static types. It has near universal appeal among those who have tried it, and in my experience an entire class of errors disappeared overnight while being having almost no cost at all apart from the one-time transition cost

Meanwhile “taking all projects will average things out” is unlikely to work well. Language differences are rarely just about types, and different languages have different open source communities with different skill levels and expectations

As much as I like empiricism and the “there’s not actually that much difference” hypothesis, that article has flaws. In particular, it has sloppy categorization, fex classifying bitcoin as “typescript”. Also, some of its conclusions set off my “wait what” meter, such as Ruby being much safer than python and typescript being the safest language of all.

That link doesn’t seem to be working. Is this the same study?: http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

I think you make very good points (even though I currently have a preference for static types). I’d love to see more empirical evidence.

As you note, runtime contracts are very much underused and most people aren’t familiar with the concept. Since Rich decided to call them specs everybody working with Clojure calls them that now. It’s really unfortunate Racket contract system isn’t well known, as it’s quite comprehensive and was clearly an inspiration for Spec.

Cubes combine the distracting background noise of an open plan office with having to sit by yourself :/

Cubicles are far better than open offices in my opinion.

The fact that the option to work remotely is not a standard thing in 2018 is just shocking in my opinion. Vast majority of people working in tech end up commuting just to sit in front of a computer in a different place. The whole model of having people clock in and out is based around factory work. It makes absolutely no sense for creative activities like programming. You don’t have a steady output as a coder, and you’re not going to be productive for 8 contiguous hours a day.

I also think that remote work is one of the most practical ways to combat traffic congestion in big cities. If everybody who works with a computer would get off the road then we’d have drastically less traffic in cities.

It doesn’t even have to be all or nothing, as you point out a mix of coming to the office a few times a week and working from home when you don’t need to be there would be a huge improvement. There’s also benefit for the companies as they would need a lot less office space.

Having an open office is basically telling your employees that you see them as nothing more than cattle.

terrible battery life

Really? It’s that bad? The Dell is better?

There’s a spectrum here. I’m guessing that when you use static typing, you’re probably not using SPARK, Dafny, or Liquid Haskell. Compare to them, most statlangs are pretty weak in what they can actually tell you. In those languages, you can also statically verify behavior, like “this procedure always terminates” or “this function is always called with a nonempty list and returns the same list, but sorted.”

The problem is that they’re a lot harder to use. It’s the standard expressiveness vs legibility tradeoff here: the more valid expressions you can write in a language, the fewer properties they all share in common. Statically-typed languages have more expressiveness and less legibility than formally verifiable languages, and dynlangs have more expressiveness and less legibility than statlangs. In return for losing static typechecking, you get the ability to leverage the complete runtime language for defining types. For example, in Python you can define the type of all classes with an odd number of letters in their name, and in J you can define the obverse (quasi-inverse) of a function.

I think most popular dynamics end up too expressive with not enough legibility. My justification is how rapidly gradual type-checkers are spreading. It implies that the parts of the dynlangs being used aren’t the bits that require the crazy expressivity dynamic typing gives you, so it’s worth adding legibility. But there’s still a lot space left to explore.

Opposite experience here. I’ve worked with many kinds of statically typed languages, including Java, Haskell, and Scala for nearly a decade. I ultimately found that static typing introduces a lot of mental overhead in practice, and limits the way you’re able to express yourself. Many dynamic patterns such as Ring middleware become difficult in static languages. I’ve been working with Clojure about 8 years now, and I don’t miss types in the slightest. If I did, I would’ve gone back to a typed language a long time ago.

Dynamic typing tends to be problematic in imperative/OO languages. One problem is that the data is mutable, and you pass things around by reference. Even if you knew the shape of the data originally, there’s no way to tell whether it’s been changed elsewhere via side effects. The other problem is that OO encourages proliferation of types in your code. Keeping track of that quickly gets out of hand.

What I find to be of highest importance is the ability to reason about parts of the application in isolation, and types don’t provide much help in that regard. When you have shared mutable state, it becomes impossible to track it in your head as application size grows. Knowing the types of the data does not reduce the complexity of understanding how different parts of the application affect its overall state.

My experience is that immutability plays a far bigger role than types in addressing this problem. Immutability as the default makes it natural to structure applications using independent components. This indirectly helps with the problem of tracking types in large applications as well. You don’t need to track types across your entire application, and you’re able to do local reasoning within the scope of each component. Meanwhile, you make bigger components by composing smaller ones together, and you only need to know the types at the level of composition which is the public API for the components.

REPL driven development also plays a big role in the workflow. Any code I write, I evaluate in the REPL straight from the editor. The REPL has the full application state, so I have access to things like database connections, queues, etc. I can even connect to the REPL in production. So, say I’m writing a function to get some data from the database, I’ll write the code, and run it to see exactly the shape of the data that I have. Then I might write a function to transform it, and so on. At each step I know exactly what my data is and what my code is doing.

Where I typically care about having a formalism is at component boundaries. Spec provides a much better way to do that than types. The main reason being that it focuses on ensuring semantic correctness. For example, consider a sort function. The types can tell me that I passed in a collection of a particular type and I got a collection of the same type back. However, what I really want to know is that the collection contains the same elements, and that they’re in order. This is difficult to express using most type systems out there, while trivial to do using Spec.