Live data from Hacker News

Ten Years of Erlang

ferd.ca

101–110 of 155 posts

Re: Ten Years of Erlang

#101
post #87

Functional programming has too long of a learning curve to the average programmer. A language should be judged by how long it takes average programmers to become proficient in it, not the "Sheldon Cooper" types. In typical medium and large organizations, it's difficult keep being selective about programmer hiring. (There are org structural/political reasons that would take several paragraphs to explain.) This problem…

Hi there, I sometimes try to help normals relate to me by asking, "You know Sheldon Cooper from Big Bang Theory? I'm like a stupid, slighty-less-social-idiot Sheldon Cooper." I identify with Dr. Cooper. (BTW it sucks being like that. Don't ever think we do it because we like it. There are a few perks but it mostly sucks. Also, it's like living in "Idiocracy". I can't watch that movie because it's too painful. That's…

Re: "Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive."

This is the theory that the elite are so productive that they can replace say 10 non-elites. The main problem with this is that most problems to be automated (or upgraded) are not well-defined. It takes iterative interaction with analysts, users, testers etc., and this is where probably 2/3 of the effort takes place. Communication and teamwork is more of a bottleneck than raw coding, and the Sheldon Cooper types rarely do well on that.

If the requirements were clearly defined, the 10x-Elite Theory would possibly work in practice. But it's a rare day in May one gets a clearly-defined specification that doesn't shift around a lot.

If you could find a domain having clearly-defined specs, then you could implement that 10x Elite Theory and crush the competition by cranking out software for a fraction of the traditional competitions' price. For example, make an office suite fully compatible with MS-Office, and charge 1/2 of what Microsoft does. You'd be a billionaire. (Past attempts were not sufficiently compatible, which may be a tall order because one has to mirror bugs in MS's software to be so.)

Re: Ten Years of Erlang

#102

Earlier quoted context omitted.

Not being facetious, but could the joy resemble the fun I associate with developing with Ruby?

if you want that kind of joy with erlang, try elixir. it's basically ruby on the erlang vm.

I don't get why people think Elixir is like Ruby. Other than some syntactic similarities, I can't think of any substantial similarities.

Re: Ten Years of Erlang

#103
post #87

Functional programming has too long of a learning curve to the average programmer. A language should be judged by how long it takes average programmers to become proficient in it, not the "Sheldon Cooper" types. In typical medium and large organizations, it's difficult keep being selective about programmer hiring. (There are org structural/political reasons that would take several paragraphs to explain.) This problem…

The blog post is not actually about making FP accessible to the masses nor a how to guide about it, and if you read through the post, it’s even stated in there that it’s not important for the language to gain widespread use. That’s why I downvoted you. It’s not because of your opinion, it’s because it’s probably not in the right thread.

Actually, I'm not fully sure what the author's main point is. If I had to write a short summary based on my best guess, it would be: "I'm disappointed Erlang didn't catch on more, but the general programming & architectural lessons I learned from using it were still worth the effort". Is that clearly a wrong interpretation?

My post relates to measuring "worth" here, and to the reasons why it probably didn't catch on.

Re: Ten Years of Erlang

#104

Earlier quoted context omitted.

Using an atom doesn’t require any extra characters in Erlang. Update: just realized you mean the single quotes when you need an arbitrary atom name. Understood. I definitely wish Erlang had the same macro capability. I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.

> I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir. Please, don't use such an excuse for not trying out a language. :( The unpleasantness you speak about is akin to motion/sea sickness - the signals your brain receives disagree with the brain's predictions of what they should be. The discrepancy manifests as a feeling of unease at the very least, or you may throw up non-stop for 3 d…

As someone who already knows and loves Erlang, I’m already quite familiar with the advantages Elixir offers, other than macros.

I like Erlang’s syntax. I like the concision. I like the clear differentiation between variables and atoms that capitalization offers. Erlang’s syntax and underlying model are firmly entwined in my head.

Re: Ten Years of Erlang

#106

Earlier quoted context omitted.

if you want that kind of joy with erlang, try elixir. it's basically ruby on the erlang vm.

I don't get why people think Elixir is like Ruby. Other than some syntactic similarities, I can't think of any substantial similarities.

A lot of the tooling is Ruby-like. Phoenix and Rails are very similar as well.

They do have some major fundamental differences though and I think the similarity is often overstated.

Re: Ten Years of Erlang

#107

Earlier quoted context omitted.

LiveView is great for writing form validations or simple admin stuff. Even though the examples show that you can do 60fps animations, it is not the intended use case, you're not going to write anything that needs small latency or that needs a ton of processing using LiveView, front end developers are fine.

Even in very simple CRUD projects I have to write a few hundred lines of Javascript to enhance the UI. Stuff like: if you check this box 4 more options appear. Or here is an autocomplete field/dropdown that autofills in 4 other form fields. A lot of basic stuff that cannot be done with raw HTML alone. I can see how something like LiveView would replace the need for mucking around with jQuery when your project doesn't…

I've recently adopted two libraries for my server-side backend app:

1. unpoly to handle common JS behaviours (such as show this div when this checkbox is selected)

2. Web components to handle more complex pieces of UI while maintaining compatibility with LiveView: rendering a functional jQuery carousel via LiveView/Websockets is much harder than just pushing a element through the socket. Admittedly I haven't tested if the DOM diffing library LiveView uses plays nice with web components.

Re: Ten Years of Erlang

#108
post #88

"But the vast majority of them will be a continuous flow of serial early adopters who surf from tech to tech, sniffing the best opportunity to gain a competitive advantage by being first to use a type of framework, language, or toolkit." - Oh god, that hit me so hard.

What's the common slang for that? "Buzzword Surfer"?

middle manager?

Re: Ten Years of Erlang

#109

Earlier quoted context omitted.

> Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks. LiveView still needs more work to be really ergonomic, wouldn't work for all use cases, but I'm personally holding my breath here in excitement to adopt it in my Elixir projects. Still, I find it…

Elixir isn't really Ruby inspired though. The only thing about it that really derives from Ruby is the focus on developer productivity.

It’s hard to say it’s not inspired by Ruby when Jose and many of the core contributors came from the Ruby world.

It’s not at all the same thing as Ruby on Beam though - it’s a very different language, but it does borrow a lot of good ideas from the Ruby ecosystem while improving on them in many ways.

Re: Ten Years of Erlang

#110
post #103

Earlier quoted context omitted.

The blog post is not actually about making FP accessible to the masses nor a how to guide about it, and if you read through the post, it’s even stated in there that it’s not important for the language to gain widespread use. That’s why I downvoted you. It’s not because of your opinion, it’s because it’s probably not in the right thread.

Actually, I'm not fully sure what the author's main point is. If I had to write a short summary based on my best guess, it would be: "I'm disappointed Erlang didn't catch on more, but the general programming & architectural lessons I learned from using it were still worth the effort". Is that clearly a wrong interpretation? My post relates to measuring "worth" here, and to the reasons why it probably didn't catch on.

[deleted]
Post reply on HN