[HN Gopher] Why and How We Retired Elm at Culture Amp
___________________________________________________________________
Why and How We Retired Elm at Culture Amp
Author : elorm
Score : 197 points
Date : 2023-04-08 17:59 UTC (5 hours ago)
(HTM) web link (kevinyank.com)
(TXT) w3m dump (kevinyank.com)
| sickcodebruh wrote:
| I remember looking closely at Elm in 2016. I was a year or two
| into being the first and only web-focused software engineer at a
| hardware startup. Working solo, moving fast, refactoring
| aggressively as we iterated and sought our product's UI, I was
| craving more help from my language than JavaScript and React
| alone could offer.
|
| Elm was appealing for all of the reasons described in this post.
| Functional programming, static typing, batteries included so
| there would be fewer dependencies to juggle. Improve
| predictability of my code, cut down on bugs, make it harder to
| screw up, easier to refactor. People using it seemed to love it!
|
| But TypeScript's promise was too good. The JS I already knew but
| stronger! Keep my existing React code base but refactor it to be
| safer! No need to learn entirely new syntax; instead, adapt my
| ways of working to let the compiler be a better collaborator!
| Easy to break out of it when I absolutely had to!
|
| Elm offered many of the same things but require more faith. You
| invest in different syntax and the Elm way of doing things and
| you get more safety, better syntax. But the risk of being stuck
| on a path that's hard to get off, the cost of ramping up, the
| challenge of onboarding anyone in the future -- that was not in
| my budget. Even if it was, even if it offered much of
| TypeScript's value but did those things better... Was it going to
| be so much better than it justified the risk? I didn't see how it
| could be.
|
| I went TypeScript immediately after the 2.0 release so I could
| use @types packages from definitely-typed. I spent a week
| refactoring the entire project and never looked back. It was one
| of the best investments in technology that I ever made.
|
| I remember a ton of advocacy for Elm on forums and blogs until
| then. I'm far from an Elm insider so this is pure speculation but
| if I had to guess, I'd bet wasn't the only person who doing
| napkin math about the right frontend language/tooling investment
| right around that time. I wonder to what degree the rise of
| TypeScript clipped Elm's wings and whether a different timeline,
| maybe Elm getting started just a year or two earlier, would have
| allowed the project to hit some critical mass to change the
| future.
| [deleted]
| vmchale wrote:
| > I tell myself that it would be rude and ungrateful to the Elm
| community for me to publicly declare Culture Amp's departure from
| the fold
|
| > What We Owe to Elm
|
| Everyone who talks about Elm sounds like they have Stockholm
| syndrome. Don't think I've seen a single good experience lately.
| epolanski wrote:
| Because the language is frozen in 2019, it's last meaningful
| release.
|
| It was doomed to end this way due to the close leadership and
| being developed behind closed doors by a single developer.
|
| This kind of projects, as amazing as they are, and Elm is
| absolutely an amazing language and project that has changed and
| influenced web development meaningfully, are just untrustable.
|
| If you can't have a discussion with library authors where they
| confront their ideas in the open, you need to move on or pay
| the consequences.
| jrochkind1 wrote:
| > If you can't have a discussion with a library authors where
| they confront their ideas in the open
|
| Interestingly, for the most part you can't do this with Rails
| authors. It does not make me super confident in the future of
| Rails. From the authors point of view, I suppose it saves
| them time arguing in public in useless ways.
| epolanski wrote:
| I don't follow much Rails, but from your comment, at least
| in case of Rails, the number of authors is plural.
| jlundberg wrote:
| What is lacking in the 2019 release and in what ways does the
| frozen feeling make things bad in reality?
|
| I am curious since we have one major project written in Elm
| since 2017 and it has been a great success.
| surprisetalk wrote:
| I'm curious about this too.
|
| There are no obvious landmines in the Elm compiler.
|
| I adore using technology that feels "finished".
|
| I personally view its infrequent updates as its best
| feature.
| [deleted]
| RichieAHB wrote:
| To be clear I don't use Elm in production so my thoughts
| are purely speculative. However, when you remove FFI to JS
| - in a language which is focussed around the web platform,
| which evolves pretty quickly - and you only have a handful
| of developers, it strikes me that just keeping up with the
| Web API bindings alone, is a lot to undertake. For example,
| if you want the new Web Transitions API, I guess you'll
| have to hope you can call it through JS ports.
|
| As others have noted, the Elm architecture has influenced
| many more pragmatic frameworks that have taken the key
| principles while still allowing work to get done.
|
| I've used Elm a few times for hobby projects and while it's
| super nice to model state and render most HTML and CSS (and
| is even enjoyable to write), you always feel that one day
| you'll become too locked in and that Evan may decide to go
| live on a farm.
| pyrale wrote:
| > What is lacking in the 2019 release and in what ways does
| the frozen feeling make things bad in reality?
|
| Things I've personally missed include websockets, missing
| features in the browser interface like preventDefault in
| the Keyboard API, etc. It's not a big deal, but if you need
| lots of less covered APIs and have to develop ports for
| many little things, it becomes an annoyance.
|
| In professional contexts, I haven't had trouble with Elm,
| but others have reported missing the kind of features
| people usually require, like server-side rendering, the
| ability to deploy a private package repository that doesn't
| feel like a hack, etc.
|
| 0.19 was a great version, but it is very barebones, and
| some new developments that have happened in other
| ecosystems just didn't happen because of the way
| contribution works in Elm.
|
| If you only need what's already there, Elm is glorious. If
| you don't, you know it. Evan can't really be blamed for it,
| as he's always been very clear about that, but at the same
| time, it's kind of a pity to see such a great work that
| can't really be extended.
| the_gipsy wrote:
| Websockets is like two ports? Maybe three with the
| connection event.
| surprisetalk wrote:
| I think this was a very charitable summary of both sides.
| Thank you.
| SantalBlush wrote:
| I don't know, these two quotes don't immediately take me to
| "Stockholm syndrome."
| vmchale wrote:
| If you read more about the Elm community you'll see similar
| things. Been happening for years!
| https://dev.to/kspeakman/elm-019-broke-us--khn
| SantalBlush wrote:
| Could you explain how the two quotes above are similar to
| the story in this link? Because they don't look similar to
| me.
| [deleted]
| savanaly wrote:
| I'm not surprised Elm is not viable anymore at a medium or large
| company, despite continuing to use it every day myself for side
| projects. The creator has deliberately shunned publicity or
| popularity for it in the last few years so adoption and therefore
| hiring has slowed to a crawl. We still have a vibrant and
| passionate small community, but the emphasis is on "small". No
| matter how superior it is to e.g. React it will lose out at a
| company level if you have pay the price of retraining all your
| frontend devs to "think in elm" to continue using it.
|
| I'm mainly sad that we'll be losing the chance of any future
| Kevin Yank videos about Elm. I really love the videos of his I've
| seen on youtube, including non-Elm ones such as the one about how
| to use VoiceOver for devs [0].
|
| [0] https://www.youtube.com/watch?v=38qQzmkXGS4
| [deleted]
| ricardobeat wrote:
| > it will lose out at a company level if you have pay the price
| of retraining all your frontend devs to "think in elm" to
| continue using it
|
| This is something every framework is up against, since React
| won. It has become more and more of its own JS dialect, so devs
| that grow up with it also "think in React".
| rcme wrote:
| On the other hand, React is super slow, a problem which is
| further exacerbated by the fact that rendering and
| invalidation happens somewhat indirectly, meaning it's really
| easy to accidentally make something super slow.
|
| For your run of the mill website, this probably doesn't
| matter. But for interactive web content, it can absolutely be
| a competitive advantage to use something faster and more
| responsive.
| MajimasEyepatch wrote:
| I don't think I've ever seen a web app where the
| performance of React was such a bottleneck that it would in
| any way justify migrating to another tech stack. You'd have
| to get so far into a project for that to become an issue
| that the cost of switching would be huge.
| rcme wrote:
| Have you tried the new Reddit website?
| [deleted]
| yladiz wrote:
| Do you think it's solely because of React?
| rcme wrote:
| If you read my original post, one of my points was that
| React's rendering and data model makes it too easy to
| render unnecessarily, which causes perf issues.
| yladiz wrote:
| I would say "can cause" performance issues, but I
| wouldn't say React is one of the primary reasons for poor
| performance. You can get very far with little
| optimization in React, so I am skeptical that the way
| React works fundamentally causes issues.
| Yoric wrote:
| I haven't used React in a long time, but when I did, one of
| the main reasons for using it was that it was much faster
| than most handwritten non-trivial DOM code because it
| managed to avoid the `write CSS -> read layout` anti-
| pattern.
|
| What makes React so slow these days?
| justrealist wrote:
| Just people who don't understand how to write performant
| React, honestly.
|
| There are ways of writing React that result in vast
| numbers of re-renders... it's not a best practice, but
| it's relatively easy to make happen, especially if you
| ignore the official recommendations and pull
| Stackoverflow answers from 2015.
| internetter wrote:
| Sure, to some degree, but you have to wonder why it's so
| easy for developers to footgun themselves. It's the fault
| of the language, imo, not bad developers.
| Yoric wrote:
| What would prevent that?
| internetter wrote:
| I believe the term is "fine grained reactivity".
| Basically, components do not rerender when data updates,
| only the specific part of the DOM dependent on that data.
|
| This alleviates all the footguns that come with rerenders
| (including the infamous infinite loop) _and_ often
| results in cleaner code.
|
| I'm partial to solid[0] (there are lots of comparison
| articles, but I think [1] and [2] show it the best). I
| believe svelte is similar and vue is experimenting with
| this as well
|
| [0]: https://www.solidjs.com/
|
| [1]: https://news.ycombinator.com/item?id=30508524
|
| [2]: https://news.ycombinator.com/item?id=35061672
| justrealist wrote:
| I've never seen a language or framework that is both easy
| to be quickly productive in, and free of footguns.
|
| React is easy to be quickly productive in... thus, it has
| footguns.
| Marazan wrote:
| React is easy to use without understanding the component
| lifecycle. The penalty is poor performamce rather than a
| non-functional app.
|
| You saw the same thing in the before times with Adobe
| Flex. So much code from people who had no understanding
| of the lifecycle - apps that worked but were appallingly
| slow and buggy.
| internetter wrote:
| It's a combination of many things, but imo one of the
| worst is all the footguns regarding state and the
| rerenders they cause
|
| https://emnudge.dev/blog/react-hostage
|
| It's so easy, that we monkey patch react to debug it
| https://github.com/welldone-software/why-did-you-render
|
| Plus the vdom... Isn't great, the bundle size puts react
| at an inherit disadvantage, and the community has a knack
| for over reliance on bloated packages
| internetter wrote:
| Everyone seems to be saying that the performance doesn't
| matter, but as a general consumer and an employee with
| ADHD, I absolutely notice every millisecond, and have been
| known to abandon products over it (or make my own frontend,
| depending on the viability of alternatives).
|
| Like, I can feel the delay typing in a web browser compared
| to native, and it drives me crazy. If the output doesn't
| seem like a direct response to my input, I lose focus.
| Simple as that, and react seems to be a big part of that
| problem.
|
| We have ways to go in our apps, but solid has done wonders
| already. Currently I'm researching state caching and
| optimistic updates, both of which should also improve it.
|
| Fast enough is a myth. Instant apps are magic.
| slimsag wrote:
| What are your thoughts on the direct descendant, Roc? [0] I
| know it's pre v0.1 so maybe you don't have any, but as a fellow
| Elm lover it seems pretty compelling on the surface albeit less
| directly frontend-dev focused.
|
| [0] https://github.com/roc-lang/roc
| pyrale wrote:
| That's the language's claim, but it really feels weird to
| call oneself a direct descendent when the original language
| creator has not left the boat.
| kelipso wrote:
| It's just what a fork is, no?
| pyrale wrote:
| afaik, it's not a fork of Elm, they started from a clean
| slate.
| kelipso wrote:
| Right I see. At any rate, C has hundreds of languages as
| its direct descendants, it's a common term used for
| programming languages.
| zem wrote:
| why? my parents are alive and I'm still their direct
| descendant (: it's just acknowledging the language's roots.
| JohnCurran wrote:
| There is also gren, a fork of Elm being actively developed
| https://gren-lang.org/
| G4BB3R wrote:
| Elm is used in many medium/large companies. The biggest ones
| are NoRedInk and Vendr, the later reached 1B valuation recently
| with 600k+ loc Elm codebase.
| crispinb wrote:
| I wish I had, just once, had as thoughtful and thorough manager
| as Mr Yank (terrible name for an Aussie) seems to be (at least as
| far as you can ever tell from the self-presentation of an
| article).
| cwzwarich wrote:
| TL;DR: they bridged Elm with React, and when they started using
| Web Components there was an impedance mismatch between the
| bridges between Elm/React and WebComponents and the bridge
| between Elm and React, so they had to pick one of Elm and React.
| savanaly wrote:
| I would say the Web Components portion of this article is a
| detour, mainly he was explaining his discovery you can't
| utilize web components to marry React and Elm together as one
| would hope. The real TLDR is it's too hard to hire Elm devs.
| zackbloom wrote:
| I wonder how you got that TLDR. He literally said they hired
| a bunch of people only because they did Elm.
| jdlshore wrote:
| No, they didn't end up using WebComponents. The real issue was
| that it was too much trouble to have Elm & React in the same
| codebase. They were migrating the code to Elm, but then merged
| with another company. Now 75% of their company was only
| familiar with React. Only 6 people were strong Elm advocates.
|
| Because React and TypeScript had progressed since they first
| decided to use Elm, because the cost of maintaining two
| frameworks was high, and because the cost to switch to Elm was
| out of reach, they decided to "contain" Elm by no longer
| permitting it for new components.
| macintux wrote:
| That's a bit too short, I think. TypeScript plays a role as
| well, as does an acquisition.
|
| I liked the description of the internal discussions. Working at
| a larger company where decisions are made in a completely
| different part of the organization and you're stuck dealing
| with the ramifications leaves me a little nostalgic for a
| smaller firm where it's practical to engage all stakeholders.
| jrumbut wrote:
| On the other hand, at this larger organization it was
| possible to have devs devote months to experiments that were
| ultimately shelved.
|
| It was kind of cool that they really explored all the avenues
| for making it work.
| Herval_freire wrote:
| They had an acquisition where the code became 75% react over
| night due to the acquisition. This was the major turning point.
| Purely business, purely popularity. It wasn't technical
| superiority.
| benatkin wrote:
| It also didn't impress them. I don't like the idea of using Web
| Components with Stencil either. I like Web Components though.
| javchz wrote:
| I really felt this story as someone how had to abandon
| coffeescript like 8 years ago in a similar fashion.
|
| The syntax was easy, simple, and enoyiable. But at the end of the
| day, when you implement something like react or angular in real
| projects can get messy really fast.
|
| At least a lot of the good things of coffeescript still kinda
| live in TS and new versions of vainilla JS.
| tantaman wrote:
| don't hire people if they're too excited about the tech stack,
| proceeds to rewrite their app every time a new shiny comes out.
| karmakaze wrote:
| The problems were not with Elm per se but rather maintaining both
| Elm and React components.
|
| > It seemed we were faced with a choice: Elm or React. Continuing
| to support both was fast becoming unsustainable for us.
|
| > The thing that ultimately tipped the balance in React's favour
| for us was that we acquired another company whose entire codebase
| was written in React, and whose team knew nothing about Elm.
| Overnight, we went from a company that was writing about equal
| amounts of Elm and React (and which might well have decided to
| double down on Elm) to one that was writing about 75% React.
| anonymouskimmer wrote:
| I can't be the only person who wondered why a company was still
| using the Elm email client.
|
| Edit to add: There are enough names and acronyms available. To
| avoid even temporary confusion, and to make literature searches
| easier, try to avoid popular ones from yesteryear that were used
| in your general discipline.
| [deleted]
| polar wrote:
| > I can't be the only person who wondered why a company was
| still using the Elm email client.
|
| You are not.
| [deleted]
| smitty1e wrote:
| Gopher less cryptic humor.
| andrewstuart wrote:
| Kevin did the right thing.
|
| IMO these days you have to have very strong justification to use
| anything other than the top 2 or maybe 3 "mainstream"
| technologies in any field.
|
| Unless you're doing something extraordinary (and you're probably
| not), most software can be built with VueJS/React TypeScript C#
| Python Postgres MySQL/MS SQL.
|
| That's your entire stack covered there.
|
| These technologies get the job done, people know them, there's
| massive community support and critically important when you're
| hiring, you're fishing in the big pool.
|
| Also, ChatGPT knows these technologies well and that's
| increasingly important.
|
| Any other technology choices really need very strong
| justification.
|
| And, if your company is still using some branch of the technology
| tree which several years ago looked like it might have something
| to offer but has since become obscure or withered in its
| popularity, it might be time to do as Kevin Yank did and prune
| that branch off your tech tree.
| tinco wrote:
| MS SQL? I've been a ("full stack") web developer for 18 years
| now, and I've never seen anyone use MS SQL for a web
| application. That's immediately a tell that I'm in a bubble,
| and obviously you are as well if you think MySQL/MS SQL are
| even in the top 3 (behind Postgres, MongoDB, Oracle?).
|
| Since you mentioned it, I just asked ChatGPT and in a list of
| 30 unicorn companies based around web applications, half of
| them were built in Ruby which isn't even in your list.
|
| If becoming a successful company is part of the justification
| for technology choices, you'd need a _very_ strong argument to
| not pick Ruby.
|
| I'm not really sure that's true, but if you want to make strong
| recommendations I feel they need to be backed by data, and not
| some hunch on what technology is popular right now. And Ruby
| has been less popular for over a decade now, and it's still
| used by half the most successful companies out there. So the
| data isn't on your side here.
| __jem wrote:
| SQL Server actually rocks. I was extremely skeptical about it
| going into a new job having mostly used Postgres, but it's
| actually so much better than Postgres in some dimensions it's
| kind of crazy. I always assumed proprietary DBs were just a
| scam, but there's definitely reasons to choose one,
| especially in the enterprise space.
| andrewstuart wrote:
| >> I've never seen anyone use MS SQL for a web application
|
| Are you working in the corporate world? The data you request
| is that on my local job board there are > 833 jobs for MS-SQL
| - that's mainstream.
|
| MySQL/MS SQL - I would not use them personally but they are
| very popular. Industry acceptance and popularity matter when
| pragmatically choosing a tech stack for a company.
|
| Ruby is definitely not in my list - it may be fine if you are
| a unicorn company with a vast flow of developers who want to
| get on board the success train, but for the other companies
| hiring is a nightmare.
|
| "Whatever happened to Ruby?"
| https://www.infoworld.com/article/3687219/whatever-
| happened-...
|
| Again, my local job board has 148 Ruby jobs versus 1554
| Python jobs versus 855 C# jobs.
|
| The fact that a technology is used by big companies does not
| mean it is not in decline. Facebook still uses PHP - a
| technology clearly in decline. Like it or not, Ruby's best
| days are behind it - the fact that so any successful
| companies are built with Ruby is historical information.
|
| And besides, its up to you what you think the list is of
| modern mainstream technologies - doesn't matter what I think
| is in that list.
|
| The point is that choosing something less than mainstream
| such as Elm or Haskell or whatever is likely to cause
| problems.
|
| And for the record - that same job board returned one job
| when searched for "Elm", and it was actually an ad for a Ruby
| job.
| notreallyauser wrote:
| Is anyone else disappointed this wasn't about old school email
| clients, and a belated migration to, perhaps, pine?
| tomca32 wrote:
| > Culture Amp was well on its way to doing this in 2018, when
| things started to get hard for the recently-formed Design System
| team.
|
| This is the problem right there. Design system teams never work
| well. A design system that's complicated enough to need a
| dedicated team always creates more friction than it's worth.
| Turns out that it's really hard to standardize UI components in a
| way that makes them flexible enough to be used across different
| teams.
|
| The only design systems I've seen work well are the minimal ones
| that just define the color values of the visual theme and look of
| some basic components like buttons but leave the implementation
| up to the individual devs.
| epolanski wrote:
| Hmm, that's not true?
|
| GitHub, Atlassian, Microsoft, plenty of greatly and widely used
| design systems out there.
|
| The problem is different: they are huge investments that most
| non-large companies cannot afford for economic and logistic
| reasons.
| the_gipsy wrote:
| But those companies are several leagues higher than whatever
| Culture Amp is.
| marcelr wrote:
| I've seen this at 2 companies so far and tend to agree. At this
| point if your design system requires more than css its probably
| too complicated.
|
| Maybe design systems work when you are the size of google, etc,
| but otherwise they are way more work than people seem to
| believe.
| ShadowBanThis01 wrote:
| I was going to be impressed that anyone was still using Elm. But
| this turns out NOT to be the E-mail client.
| dangjc wrote:
| Some nuggets of wisdom from the article when managing an
| engineering org:
|
| - "if the only reason an engineer wants to work for you is
| because of your tech stack, that may be a warning sign. Culture
| Amp therefore avoids hiring engineers who are purely technology-
| focused. As a product company, we seek to hire people who are
| mostly excited about our product and its mission, and who are
| happy to learn new things when necessary to progress that. When
| someone tells us in an interview they're excited about working
| here because they like functional programming (say), we count
| that as an indication they might not be a good fit."
|
| - "Perhaps the greatest challenge for engineers as they reach
| more senior levels in their career is to make decisions that
| balance the moment-to-moment joy (or frustration) that a given
| tool affords them, and the costs (or benefits) that same tool
| might create for their team, company or client over time and at
| scale"
| hgsgm wrote:
| >> we seek to hire people who are mostly excited about our
| product and its mission,
|
| Consider the source: https://www.cultureamp.com/
|
| A completely generic me-too startupy startup. I can't even
| figure out what their product is.
| [deleted]
| kevbin wrote:
| "Culture Amp customers experience 2x the rate of innovation"
|
| LOL
| mrmincent wrote:
| Maybe it's just because I'm also based in Melbourne, but I've
| worked for two or three places that use cultureamp, it's a
| pretty solid service to help manage personal development
| goals and employee surveys etc. I even used to work for a
| competitor of theirs, and I'd rate their stuff much better, I
| wouldn't write them off just because you're not familiar with
| them.
| jrsj wrote:
| Why are the people who talk the most about company culture
| typically the ones with the cultures I find most off putting?
| shp0ngle wrote:
| It's pretty clear to me from the front page?
|
| They provide saas tools for companies to do... HR-y/"company
| culture" stuff? It's pretty clear.
|
| I am not the one to be overly excited for that, I don't
| really care for HR, but some people might?
| elm_master wrote:
| This isn't surprising. Elm precludes TypeScript and React+Redux.
| I don't even bother with elm now.
| capableweb wrote:
| What a good point. Everything that came before TypeScript and
| React+Redux is clearly inferior now, because it came before
| those things.
| wiseowise wrote:
| Parent comment implies that TypeScript + React + Redux combo
| is superior technology and the only reason Elm got traction
| in the first place is that mentioned combo hadn't been
| invented yet.
| wpietri wrote:
| Are you perhaps misunderstanding what "precludes" means? Or
| perhaps the person you are replying to does?
| satvikpendem wrote:
| Elm "prevent[s] from happening; make[s] impossible" TypeScript
| and React+Redux? I think you don't mean "preclude" in that
| sentence.
| [deleted]
| pickledish wrote:
| > When someone tells us in an interview they're excited about
| working here because they like functional programming (say), we
| count that as an indication they might not be a good fit.
|
| Hmm. I'm not one of these tech-stack-driven types of developers
| they're talking about in this paragraph, but even I had to raise
| an eyebrow here -- this seems like the kind of rule that'd have a
| super high false negative rate. I understand the kind of person
| they're trying to avoid hiring by accident, but... being excited
| about a cool language being a "point against" to try to serve
| that goal? Seems a little over the top
| jrsj wrote:
| Especially since it's Elm. How many people would have any idea
| how to even use it & not mention that they're excited by it an
| interview? Counting that against someone is probably an even
| worse interview practice than being overly reliant on leetcode.
| And I _hate_ leetcode driven interviews.
| zem wrote:
| something I always remember from my brief time lurking on
| comp.lang.lisp is a post saying a really good language is one
| that would get you to take a job just because you would get to
| work in it. it's the pleasure of using a tool that fits well in
| your hand and works with you to get the job done.
| charlieflowers wrote:
| I thought that same thing.
|
| Besides, it wasn't liking a particular _language_ they took as
| a bad sign, it was _functional programming_.
|
| If you like functional programming, and you encounter a
| candidate who also likes it, and you consider that a red flag
| ... that seems highly irrational and inconsistent.
|
| (Not trying to sound combative. I appreciate the original post!
| Just being candid about something that sounds odd to me).
|
| Edit: I would bet there's more context that was out of scope
| for the original post. I would not be surprised if it were much
| more than just "liking functional programming." If someone is
| overly zealous to the point where you might wonder if they'd
| start an uprising or storm off in a rage if asked to do
| anything other than functional programming (or anything else
| for that matter), that would be a red flag.
| snovv_crash wrote:
| I think it's the over-zealous part. If someone can't name a
| few cons of some technology relative to its competitors, they
| probably don't have a balanced perspective of when it should
| be used and when not.
| autarch wrote:
| He doesn't go into much detail here but what I _imagined_ he
| meant was that if someone came to an interview excited about
| Elm but knew nothing about the company, that would be a strike
| against them. If someone came excited about Elm _and_ was
| interested in the company's product that was fine.
|
| But this is just me filling in the blanks as I think they
| should be filled in. It'd be great to see him spell this out a
| bit more.
| whateveracct wrote:
| I had a leader once who told us outright any mention that
| Haskell was a motivation for the job is a red flag. It was a
| Haskel codebase. Turns out we failed to hire basically anyone
| (most were all yes but a single no from the leader) and then
| the leader pushed us to move off Haskell citing difficulty
| hiring and that he had hired people in another office who
| didn't know or want to learn Haskell. Dirty tactics.
| duxup wrote:
| > but knew nothing about the company
|
| How much does anyone really know about a company they don't
| work at?
|
| And if that's the issue (I don't think it is from what o
| read) then they just have to say that and not the bit about
| functional programming.
| whateveracct wrote:
| It's just ego imo.
| bawolff wrote:
| > If someone came excited about Elm _and_ was interested in
| the company's product that was fine.
|
| We're talking about a company that makes workplace engagement
| surveys. I have trouble imagining anyone is actually truly
| excited about that product. No 5 year olds ever said that
| they want to grow up to write engagement surveys. They aren't
| saving the world.
|
| And that's ok. Most products aren't very exciting when you
| get right down to it. One of the most toxic beliefs in tech
| companies is that everyone should be obsessed with the
| product.
| mynameisvlad wrote:
| Yeah, that seems like a weird rule to have. If anything, I'd
| _want_ engineers to be excited about languages, tools and
| paradigms, even if they weren't exact fits with the current
| stacks we're using.
|
| The whole article's point is that these change, anyway. So
| those people they're rejecting on this silly rule might
| eventually become the people they crave if functional
| programming becomes cool again at Culture Amp in 5 years.
| kelipso wrote:
| > if functional programming becomes cool again at Culture Amp
| in 5 years
|
| I think that's kind of the thing they're actively trying to
| avoid. They don't want one type of programming to become
| popular and have the team decide to spend $X and y months and
| switch to it because it results in increase in some nebulous
| programming productivity or whatever because they hired a
| bunch of z programming paradigm fans, and then later spend
| more money and time to switch to another thing etc etc when
| the importance of programming language or frameworks on the
| making money aspect of the business is not clear at all.
| mynameisvlad wrote:
| But functional programming _might_ be the best choice for
| some project in the future. And this whole decision just
| seems like an overreaction.
|
| To discount candidates entirely based on their excitement
| about one paradigm (saying nothing of their excitement of
| others) seems like it's just pushing the needle to the
| other extreme.
| topaz0 wrote:
| I think the idea is you want to avoid hiring the person who
| will quit if you eventually stop using their pet technology.
| mynameisvlad wrote:
| That would be reasonable if the post put it that way, and
| said they ask lots of additional questions and back and
| forth to determine this specific thing.
|
| But as it is stated, it just seems like an overly broad
| rule that will hurt more than it helps in the vast majority
| of cases.
| topaz0 wrote:
| The previous couple sentences before what your parent
| quoted make this clearer IMO. e.g. they don't want hires
| to be "purely technology focused".
| zac23or wrote:
| Hiring rules in general are bizarre.
|
| I worked at a place that doesn't hire developers who use Visual
| Studio!
|
| Another only hired ugly and disabled women for specific jobs to
| combat male sexual misconduct. Of course, an "ugly, crippled
| woman" got pregnant by a co-worker in no time.
| marci wrote:
| Conflating getting pregnant and sexual misconduct is a weird
| take.
|
| To whom it may concern: being respectful when attracted by
| someone is a thing.
| wpietri wrote:
| Most hiring rules have notable false negative rates and that's
| fine because you have multiple applicants per position and
| because getting it wrong can be very expensive.
|
| Personally, I think being excited about a cool language is a
| mixed signal. An interest in technology is great, but on the
| clock that has to be thoroughly suppressed in favor of actual
| business needs and constraints. At home, I like fucking around
| with all sorts of stuff. At work, I'm a confirmed member of the
| Boring Technology Club. [1]
|
| [1] https://boringtechnology.club/
| marcosdumay wrote:
| The plenty of fish on the sea argument don't hold if you
| enforce a systematic bias.
| CoastalCoder wrote:
| > Most hiring rules have notable false negative rates and
| that's fine because you have multiple applicants per position
| and because getting it wrong can be very expensive.
|
| I think it depends on how you define "fine". Perhaps "fine"
| for the hiring company, but it externalizes the cost of
| wasted job leads for candidates.
| ajmurmann wrote:
| This is the right attitude. I make a conscious effort to find
| reasons not to use a technology in excited about at work
| because my excitement otherwise will bias the decision in the
| other direction.
| throwawaymaths wrote:
| I mean it depends, right? There are several technologies out
| there that are fantastic because they are less annoying, have
| fewer footguns, easy to debug, easy to read, good tooling
| (docs, tests, package management), and respect the
| programmer's sanity. Is it _wrong_ to only want to work with
| such systems? If some company rejects me because I 'm a tech
| stack fanboy without asking and understanding _why_ I care
| about the stacks that I do, that means they don 't respect my
| sanity. Hate to say it, but most "boring" technologies with a
| legacy from, say, pre-2000-ish, cared zero about those
| things.
|
| So, great. Buh-bye.
|
| Nb: many technologies post-2k _also_ don 't care about those
| things. So yeah, don't be shiny new on those either.
| bcrosby95 wrote:
| It's funny because that slide shows why we use Elixir. With
| the clustering BEAM offers out of the box we've been able to
| eliminate things like memcached, redis, and rabbitmq from our
| production environment.
|
| But most people wouldn't call Elixir "boring tech".
| duxup wrote:
| If all you want is something to thin a stack of resumes why
| not be honest and just randomly throw out the required
| number?
| wpietri wrote:
| Because you're looking to thin it differentially, such that
| the odds of a good hire go up, or at least the odds of a
| bad hire go down. One kind of bad hire is the technology-
| lover who values their own preferences over the needs of
| the business.
|
| E.g., a friend of mine took over a team with a couple of
| strong FP advocates on it. They had written a core tool in
| very FP-ish JS. They enjoyed the novelty of the greenfield
| work, but once it was down to just making the changes users
| needed, they got bored and moved on. The remaining part of
| the team tried picking it up, but it was too alien, either
| because of the FPness or just because the code was opaque.
| Either way, they eventually had to rewrite it.
|
| Or personally, I have made a lot of good money coming in
| after some would be brain genius, ripping out their
| supposedly cutting edge work, and replacing it with
| something boring. I remember one place where a core part of
| a system was build on the 0.7 version of then-fashionable
| technology. Except it wasn't even 0.7 as released, but
| something with custom patches applied. None of the people
| there could maintain it. Looking at git blame and doing a
| little web searching, it turned out the developer
| responsible had then done a self-promoting conference talk
| about their amazing work, and then quit shortly thereafter.
| After I removed it and replace it with something much
| simpler, not only could the people there maintain it, but
| it worked better than before.
| pmarreck wrote:
| > Because you're looking to thin it differentially, such
| that the odds of a good hire go up, or at least the odds
| of a bad hire go down.
|
| I'm certain you could increase the odds of a good hire in
| all sorts of other ways by seeking correlational
| stereotypes, but some of those (age, gender, race) would
| be seen as... very bad, possibly illegal, and some others
| (traditional-ness of first name, for example) would
| possibly also work but would be highly questionable.
| Heck, I bet you could find a correlation with whether or
| not the person used an AOL email address or not. What
| makes filtering by this stereotype correlation superior,
| ethically, to those other stereotype correlations? If
| "interest in new tech" is an immutable attribute of the
| person's personality (which it almost entirely likely
| is), then in both cases you're filtering based on
| immutable attributes, so they should be considered
| ethically equivalent on paper, where you have a lot of
| false negatives, but your "good hire" rate goes up.
|
| > One kind of bad hire is the technology-lover who values
| their own preferences over the needs of the business.
|
| So basically you want to hire non-technology-lovers who
| simply "GSD" and don't care about things like long term
| maintainability or test coverage (or test runtime, or
| code quality, or...) because at the end of the day that's
| just added fees you can charge to the client when you
| have to revisit the codebase in the future. I see.
| snovv_crash wrote:
| > So basically you want to hire non-technology-lovers who
| simply "GSD" and don't care about things like long term
| maintainability or test coverage (or test runtime, or
| code quality, or...) because at the end of the day that's
| just added fees you can charge to the client when you
| have to revisit the codebase in the future. I see.
|
| No, you have it exactly wrong. What you describe are good
| development practices that provide actual long term
| business value. What you want to avoid is someone saying
| "yeah I'm excited to use the nested lambdas and variants
| and callbacks and asynchronous systems" because this
| shows they just want to play with toys, not solve
| problems the business has like too many bugs, or slow
| runtime, or missing features. Engineering is about
| solving problems, and technologies are tools to solve
| them.
| mynameisvlad wrote:
| > What you want to avoid is someone saying "yeah I'm
| excited to use the nested lambdas and variants and
| callbacks and asynchronous systems" because this shows
| they just want to play with toys, not solve problems the
| business has like too many bugs, or slow runtime, or
| missing features.
|
| How does that sentence _show_ that, exactly? All it shows
| is that they 're interested in new technologies. That
| says nothing about whether or not they are interested in
| "[solving] problems the business has like too many bugs,
| or slow runtime, or missing features". Those two are not
| mutually exclusive; one can certainly care about both.
|
| Taking it a step further, who gets _excited_ about
| "[solving] problems the business has like too many bugs,
| or slow runtime, or missing features". That certainly
| sounds like what someone would say to please their
| interviewer more than anything.
| pmarreck wrote:
| But interestingly, some of those examples you cited are
| literally solutions to some of the problems you cited,
| so... For example, a language like Elixir that has
| "trivial concurrency and immutability" enables a test
| suite that can run across all of your cores at once and
| is deterministically guaranteed (assuming you watch how
| you touch shared mutable state outside that code, such as
| a database) to not step on itself while doing so. Compare
| this to any one of a number of mutable languages (such as
| Ruby) that claim concurrency but in actuality often
| contain deep software bugs that result in flagging,
| nondeterministic tests UNLESS they are run single-core.
| That is absolutely a solved engineering problem that then
| may prevent other mitigations like having to run the test
| suite across 25+ cloud machines (in single-core mode) and
| waiting 25 minutes for a test result before being able to
| continue, which then directly increases developer
| productivity.
|
| Also, being interested in those 2 things is not mutually-
| exclusive. I LIKE that this is a tangible business result
| of a fundamental language design decision.
| mrkurt wrote:
| If you're after feedback, nothing in this post sounds
| like a tangible business result to me. It sounds like fun
| technical wizardry.
| catiopatio wrote:
| > The remaining part of the team tried picking it up, but
| it was too alien, either because of the FPness or just
| because the code was opaque.
|
| Sounds like they hired people unqualified to take over
| product maintenance.
|
| If your engineers can't wrap their head around "FP-ish"
| JavaScript, they're not exactly batting .300.
| seattle_spring wrote:
| There's plenty of code that can be so complicated that it
| becomes easier to rewrite versus understand. I worked
| with a coworkers who made the most absolutely spaghetti-
| like JS modules, insisting on event emitters and queues
| and stuff like that for even the most basic tasks. The
| result was an incomprehensible mishmash of events
| shooting from file to file to file. Touching how these
| events were handled in some way might destroy how they
| were interpreted for completely different tasks, it was
| wild. It's very possible that the code in question wasn't
| just opaque because it was "FP-ish", giving the parent
| the benefit of the doubt.
| snovv_crash wrote:
| Exactly. Code that is too asynchronous with lots of
| pubsub basically turns into GOTOs with data - there's no
| way to trace the execution step by step.
| duxup wrote:
| I feel like we just went back from "it doesn't matter
| need to filter somehow" back to "it matters".
| mrighele wrote:
| If you think that a technology/language/etc is cool and
| better than the rest but it is not as common as <mainstream
| thing>, of course you'd be excited to learn that a company is
| using it.
|
| If you're a company that chose a very niche language because
| <a number of reasons> and discard an applicant because he
| likes the same very reasons, LOL, you're a bunch of idiots
| satvikpendem wrote:
| Well, they're moving away from said language, so why would
| they want to hire someone who joined because they liked Elm
| but then doesn't get to use Elm at work? They're more
| likely to leave the company than someone who doesn't really
| care so particularly about Elm (or whatever language or
| tool it may be). So in OP's case, it's a sound business
| decision.
| _the_inflator wrote:
| I totally agree. I engraved Angular 2016 in our Tech Stack.
| Fast forward 7 years now, and we are on Angular 14.
|
| Accomplishments so far? Large and stable platform as well as
| a Low Code Editor on top of it. We systematically
| componenized every useful piece of Frontend there was and
| evolved from a library into a platform, while other
| departments jumped ship every now and then (jQuery, React,
| Vue, etc.). After years of resistance all finally joined out
| platform, because it is fast, stable, convenient.
|
| Moral of the story: consistency is everything. A tool is a
| tool.
| valenterry wrote:
| Sounds more like it was about consistency rather than about
| boring vs. exciting technology.
|
| Because 1.) Angular was still "the hot shit" at the time,
| 2.) React was already there, so you could have chosen that
| as well and it is still here.
| wpietri wrote:
| For sure. I used to be a real tech snob. And I still like
| experimenting. But I've had to admit that the particular
| technology used just doesn't make the difference I would
| like it to. E.g., PHP is a "fractal of bad design" [1], but
| Facebook seems to be an ok business. Or Javascript was
| clearly a frightful hack job to start, barely adequate for
| mouse rollovers and a little form validation, but now you
| see plenty of companies doing fine using it front end and
| back. These days I would much rather have a good team and a
| good culture than my favorite technology.
|
| [1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-
| design/
| valenterry wrote:
| Facebook hired dedicated people to invent their own hack-
| language over PHP to deal with PHPs problems.
|
| Sure, a business can succeed with a crappy language. But
| that doesn't mean the language has no impact, otherwise
| Facebook would have just sticked to it.
| paddw wrote:
| It's always seemed to me like one of the main perks of having
| your company use a weirder functional language was the ability
| to attract talent that preferred it to more standard choices.
| An experienced developer might be willing to actually take a
| pay cut if it means using a favorite language rather than
| grinding out another Python/Typescript CRUD app or what have
| you.
|
| I understand where the author is coming from, but I think
| having a preference and being excited about a tool your going
| to be working with all day is a reasonable thing, and it's ok
| if developers are excited about a technology for its own sake
| as long as they can make that compatible with continuing to
| make the business work.
| duxup wrote:
| "Culture fit" always seems like a cover for decisions that are
| arbitrary or just personal biases.... or in some cases bigotry.
| [deleted]
| rapind wrote:
| I'd wager some big bucks that this never actually happened.
| Sounds super made up. No way they were like "Well Shelly really
| knows what she's talking about, but too bad she's excited about
| functional programming... that's just so 2015."
| dkarl wrote:
| After ten years of using Scala, I think if I was running a
| Scala team, the safest thing would be to hire people who are
| not excited about Scala. Like it, yes, but not be super pumped.
| Developers who are primarily motivated by the excitement of
| learning new technology tend to write code that commits
| everyone around them to learning just as much, just as fast,
| which obstructs and pisses off developers who are primarily
| motivated by getting shit done. A team needs to strike a
| healthy balance between powering up with new ideas and getting
| shit done, and having people in the team who skew to one side
| too much to either side of that balance is a recipe for
| conflict. Eventually people will leave, often highly productive
| get-shit-done people, unless you fire the disruptors first.
| ironmagma wrote:
| What are you doing running a company that uses Scala without
| having people who largely know the stuff already, though?
| Regardless of how quickly some newbie learns, the senior
| folks should already know all that stuff, or at least most of
| it. If they don't, that's the actual problem.
| adamwk wrote:
| As an ex-Scala developer I feel like Scala is also the worst
| language in this regard, even compared to more academic
| languages. At least Haskell is somewhat prescriptive; in
| Scala people continually invent new ways to do the same
| thing. How many iterations of dependency injection or IO are
| we at now?
| nitwit005 wrote:
| I see this as true generally. Managers want people who seem
| super excited, but people who treat the job as mundane often
| seem to get the best results.
| didericis wrote:
| I've had the good fortune to work at a small place where the
| understanding between R&D disruptor types and get-shit-done
| GSD types was pretty good. When R&D types contain
| themselves/keep the playground from spilling over until
| whatever they're playing with is ready/explored, and the GSD
| types don't bulldoze the playground and let it feed them new
| tools/approaches/ideas when ready, it's like an organization
| level flow state. Wish I had a formula for how to replicate
| that, is magical.
| shrubble wrote:
| My take on this is that he wants to avoid "science projects"
| being produced rather than client work being finished.
| jrumbut wrote:
| It does feel like a landmine they've set up, perhaps another
| benefit for them of moving to React is that they can stop
| worrying about it?
|
| I've seen a lot of companies that superficially resemble
| Culture Amp. I've seen one that uses Elm. I'm probably going to
| come in talking about Elm.
|
| I have some sports-related decoration in my living room. It
| would be a weird experience for someone if they came in, saw
| it, started discussing sports, and I was put off by that.
| ironmagma wrote:
| Agreed. It's almost as baffling as a company rejecting an
| applicant for mentioning they like to make money.
| BFLpL0QNek wrote:
| It's not uncommon.
|
| I've twenty plus years experience building software on the JVM.
| From EJB's of early 2000s to original Spring, then the more
| recent Spring Boot, a plethora of other JVM tooling. Then I've
| used various languages on top of the JVM, Groovy, Clojure, ETA,
| Scala. I haven't used Kotlin only because not had a role that
| needed it. Then I have a list of non JVM languages, frontend
| stacks and sysadmin/cloud or as they like to call it DevOps
|
| Scala has been my JVM language of choice for the past ten
| years.
|
| When I was last applying for jobs my experience with Scala
| seemed like it was a huge negative for the companies I
| interviewed at. It was "you're one of them" and things got
| frosty after mentioning I'm reasonably experienced in Scala and
| its functional programming libraries and enjoy it as find I
| have less bugs.
|
| If I removed Scala from my cv and never mentioned it I got a
| much more positive experience.
|
| Some of the roles I didn't mind it going frosty. My red flag
| radar went up aswell and I got the sense of big balls of mud
| and I'd probably hate it but needed a job. Some it was a huge
| disappointment, exciting company, exciting projects, perfect
| fit skills wise but I was seen as a Scala developer not a great
| fit for Kotlin as excited as I was to use it because of the
| companies projects.
|
| Not sure what I'm trying to say but this "not good fit"
| attitude doesn't seem uncommon if you have used specific
| languages/tools/things people interviewing you don't like or
| didn't grok. Tech talks a lot about diversity which is mostly
| virtue signaling and forget diversity of minds is also good.
| theK wrote:
| I think the original point wasn't about it being uncommon but
| about it being a significantly problematic rule.
| [deleted]
| vector_spaces wrote:
| I interviewed somewhere once and mentioned that I did some
| projects in Erlang and learned a bit about functional
| programming. The founder told me that functional programming is
| a joke and that I'm clearly a computer scientist and not an
| engineer, and told me he'd never hire me as an engineer.
|
| This was one of my first tech interviews after spending nights
| and weekends self-teaching. I only mentioned this at all
| because the dudes LinkedIn said he was involved with some
| Erlang orgs.
|
| Anyway, I did take a non-eng role there, and it was easily the
| worst and most abusive (like verbally abusive, psychological
| abusive, generally fucked up) places I've ever worked.
| Eventually i got my first engineering gig at a more humane
| company and have been doing great since
|
| I learned recently that the other company went to zero. Good
| riddance (though I am bummed for folks who lost their jobs)
| Yoric wrote:
| I've recently had an interviewer tell me that "Erlang is an
| academic language" and promptly stop the conversation after
| that. That's in a company that was attempting to make
| distributed applications easier to write.
|
| This was both:
|
| - factually wrong;
|
| - a bright red flag that the company doesn't know their own
| domain as well as they think/claim;
|
| - a bright red flag that their scope is much more limited
| than what they claim in the job description.
|
| :shrug:
| john-tells-all wrote:
| You totally dodged a bullet.
|
| Even if the company despises Erlang for whatever reasons,
| it's still _very valuable_ for them to examine and be
| educated about it. Erlang makes tradeoffs for X optimizing
| for Y, we 'll choose a different tradeoff since we're
| optimizing for Z.
|
| Once I interviewed at a company with many competitors. I
| continually asked "how will this company succeed while the
| competitors have a _ten year_ head start? What choices do
| we make that the others didn 't?". I got blank stares.
| Literally nobody was interested in examining the
| competitive landscape.
| jszymborski wrote:
| "You wouldn't perchance know what the 'Er' in 'Erlang' is
| short for, would you?"
| arthurcolle wrote:
| Oooooh!! I know this one! Ericsson!
|
| Do I get a prize?
| pmarreck wrote:
| 1) "The founder told me that functional programming is a joke
| and that I'm clearly a computer scientist and not an
| engineer, and told me he'd never hire me as an engineer."
|
| This sort of person intends to sleep in the bed that they
| make, so best to leave them to it.
|
| On the other hand...
|
| 2) I'm an Elixir guy looking for work for a few months now.
| I've been applying to Ruby on Rails jobs where it makes sense
| (it was a thing I used to do). Should I be concerned that
| this is the perception out there? IS this the perception out
| there? I've heard this attitude from businesspeople in the
| past (such as from Brad Birnbaum, a former boss who is now at
| Kustomer; this was while I was at Desk.com) at times, "I
| don't want academics, I want builders". He said this to me
| repeatedly; in hindsight he was probably trying to signal to
| me that I was starting to look too academic.
|
| Notably, all of the apps that the businesspeople I've heard
| say that, are now shut down after being bought out (and Brad
| is now a bajillionaire after a Meta acquisition). Hmmmmmm.
| But I guess that was the plan all along: To build only good
| enough to last to a buyout.
| mrkurt wrote:
| I think people who are earnest about the sentiment aren't
| screening specific languages. They're trying to find people
| who think hard about business problems and follow with
| implementation.
|
| We do this. Our hiring process is impossible to pass for
| people who fixate on implementation. We have people do a
| simulated building exercise, and the developers that do
| well let the user needs drive the implementation.
|
| We think we've noticed a correlation between some dev
| communities and people who lead with implementation. We've
| seen a little of this with Elixir, but I'm not really
| worried about it. We've found a number of people who really
| enjoy Elixir that are also user-first.
| jemmyw wrote:
| I moved away from Rails and then back to it because I
| really wanted to join a particular company. The answer to 2
| is somewhat yes, but Elixir no longer counts. People
| "build" with Elixir, it's the builders FP. This isn't my
| opinion (I try not to have one on this subject, fed of
| language snipes) just the general attitude I've noticed.
| pmarreck wrote:
| > Elixir, it's the builders FP
|
| I'm really glad to hear that, because to me it does seem
| like Elixir is the FPL that is closest to satisfying a
| GSD mentality and not getting caught up in too many
| interesting rabbit holes.
| Yoric wrote:
| I'd say that it's all in the eye of the beholder.
|
| Not so long ago, everything FP or reactive programming was
| considered academic. Heck, even virtual machines, garbage-
| collectors, threads or distributed programming were
| considered academic. These days, who doesn't use most of
| these bricks?
|
| Which means... sadly, it means that I have no clue what the
| future holds for Elixir, or Erlang, or any technology that
| is perhaps a bit too much in advance on its time.
| Herval_freire wrote:
| What company. Worth avoiding.
| victor9000 wrote:
| I would just stress to folks that red flags go both ways. If
| the work environment seems toxic from your experience as a
| candidate, chances are it will only get worse once you join.
| scrame wrote:
| That's not both ways. That's exactly what a red flag in
| interviewing means.
| victor9000 wrote:
| Employers look for red flags in candidates, candidates
| should do the same. My apologies for confusing you.
| rwmj wrote:
| I run an OCaml project, but I would reject interview candidates
| who say they are primarily interested in the project because of
| OCaml. It's definitely a negative factor in the evaluation. I
| don't need someone adding baroque functional programming purity
| into a working project with real customers and regular
| developers. Plus there's a vast amount of C code which is not
| going anywhere, so I assume they would hate dealing with that.
| neodypsis wrote:
| One can enjoy OCaml while also being proficient in C and C++.
| I don't follow your logic.
| doodpants wrote:
| There's a well-known phenomenon where a person who has just
| learned a programming language will tend to write code that
| resembles the idioms of a different language that they have
| more exprience with, until they learn to write properly
| idiomatic code in the new language. For example, someone
| coming to Python from Java might write so-called "Java-
| flavored-Python" until they become more familiar with how
| things are generally done by experienced Python coders.
|
| Your comment comes across to me as "I run a project written
| in C-flavored-OCaml, and the last thing I want is for someone
| to come along and pollute it with properly idiomatic OCaml".
| Because otherwise, if you had good reasons to choose that
| language, and your code takes advantage of the language's
| strengths, wouldn't the code already be "baroque" to some
| degree? Why would you assume a new person would make it
| worse?
| satvikpendem wrote:
| That's not what it sounds like to me at all. To me it
| sounds like they have some FFI into C and that OCaml may
| just be a part of the larger project. There is nothing that
| indicates that they write "C-flavored-OCaml."
| zem wrote:
| I'd likely fail that filter, but not for love of baroque fp
| purity. my career has largely tended to be at the bottom of
| the stack, building the bricks that other team members use to
| build features, and I would be excited about ocaml because I
| think it gives you good tools to build solid and composable
| components. I would also do good work in the C part of the
| codebase if needed, I just wouldn't be excited about getting
| to work in C.
| bsnyder788 wrote:
| My thoughts exactly when reading that.
| xwdv wrote:
| It's best not to hire an employee who is excited about
| anything. These people are running high on emotions and will
| almost certainly be a troublemaker later. Better to hire a
| professional who is ready to work and is cautious about rocking
| the boat.
| bawolff wrote:
| It also seems like the type of bullshit people would spout when
| asked "why do you want to work here". (Real answer is because i
| like money, but you can't say that in an interview, and talking
| about language is generally pretty safe)
| _the_inflator wrote:
| To be honest, I don't ask this question, because of this. Why
| ask people to lie? Better talk about their interest and how
| we can both benefit from aligning them in the context of our
| tech stack.
| hgsgm wrote:
| There are thousands of companies that pay money. Why do you
| want to work here? Are you literally applying to every
| company you see a listing for? No.
| bawolff wrote:
| It is a job, not a religion. I want to work at X due to
| some combination of having skills that match their needs,
| room for growth, reasonable work culture and reasonable
| compensation. Just like everyone else who applies. I am not
| going to have some deep seated emotional attachment to the
| company, and i am definitely not going to have it at the
| interview stage. For that matter i might not have even
| heard of the company before seeing their job advert. My
| knowledge of what the company is really like at this stage
| of the game is very limited.
| azangru wrote:
| Thousands of companies that have openings for positions
| that match your skills, that advertise at a time when you
| are looking for a job, and that are roughly within your
| reach (geographically or sponsoring a visa)? I don't
| believe you.
| surprisetalk wrote:
| Evan will be giving a talk about "Elm on the Backend" later this
| month.
|
| [1] https://gotoaarhus.com/2023/sessions/2529/elm-on-the-backend
|
| The video will not be published online.
|
| _> NOTE: My goal is to get some early feedback from the in-
| person audience, so the video will be held back for now. I am not
| announcing a release, and the roadmap and this status update are
| still the primary documents for long-time Elm users to set
| expectations about this work._
|
| [2] https://github.com/elm/compiler/blob/master/roadmap.md
|
| [3] https://discourse.elm-lang.org/t/status-
| update-3-nov-2021/78...
|
| EDIT:
|
| In the second link, Evan says the following:
|
| _> As I allude to in the roadmap 410, nearly ten years of
| working in constant interaction with "silicon valley mindset" had
| taken a toll on me in many ways. Within the dominant value
| system, there are specific rewards and punishments for specific
| behaviors, and despite my personal views on this value system, I
| had internalized certain patters of thought and behavior by
| interacting with it online._
|
| I think sometimes HN gets excited about technology and forgets
| that tech is made by humans.
|
| Just a reminder to be kind :)
| epolanski wrote:
| Evan has always hid away from confrontation about his work.
| boxed wrote:
| I want to be kind, but sometimes you also have to be HONEST.
|
| Evan doesn't just hide from confrontation. He and his team
| bans everyone who are confrontational. Like me. They wouldn't
| even acknowledge that they banned me, which is just cowardly.
| No one I worked with who used Elm would go close to talking
| with their own account on the Elm reddit because they were
| sure they'd get banned.
|
| I argue hard because I was raised that way and I believe it's
| the best way to quickly find the truth. Like Steve Jobs said:
| strong opinions, loosely held. You argue hard, then when you
| are convinced by the other side, you flip with absolutely no
| time in between trying to "save face".
| surprisetalk wrote:
| I believe kindness and honesty are orthogonal.
|
| _> He and his team bans everyone who are confrontational._
|
| I have a very distinct vibe. And sometimes people don't
| want me at their parties because I don't fit their vibe.
| Sometimes I'm invited to parties and then asked to leave
| because I don't fit the vibe. I don't think anybody at
| fault in these situations :) It's hard to curate
| communities, and it's hard to fit in
| poszlem wrote:
| In my opinion, Daniel Dennett's quote, "There is no
| polite way to suggest to someone that they have devoted
| their life to a folly," is highly relevant to this
| situation, and I respectfully disagree with your
| viewpoint.
| surprisetalk wrote:
| Thank you for being respectful :) no offense taken
| [deleted]
| the_gipsy wrote:
| You know, I think I kinda get why they would ban you.
| theK wrote:
| The title is misleading, they haven't retired anything and won't
| for a long time.
|
| > Codebases written in contained tech stacks can continue to
| exist and have features added to them
|
| Phasing out might be a better term.
| mrcwinn wrote:
| I still take the overall point that Elm was simpler, but it's
| funny how people react to curly brackets.
|
| When I look at the provided screenshots comparing Elm to
| JavaScript, I see no meaningful difference in terms of visual
| noise. Maybe I've just spent too much time with too many
| languages.
| comp1927 wrote:
| elm does stay far from "now" stack (react,redux,css module,es6).
| But it shines in more learning and tinkering as side effect! (to
| some extent)
|
| community,design,rules,tools are mutiple goals when dev picking
| up new tooling. https://www.youtube.com/watch?v=oYk8CKH7OhE
|
| I think the real failure is not wholly technical. e.g.
| job,mainstream pressure <imagine ceo ask why not react?>
|
| What's important but underlooked. 1. founder of language don't hv
| time to add power tools into existing core language. one way or
| the other, you say we hv X that does same job. but actually not
| the same.
|
| 2. hype disappear after a while (fp hype)
|
| 3. code comparison
|
| e.g. rewrite in diff ways of prod code
|
| elm ver: https://github.com/cultureamp/kaizen-design-
| system/blob/3ac2...
|
| react ver: https://github.com/cultureamp/kaizen-design-
| system/blob/3ac2...
|
| ---result LOC point of view, react has 100 less code for button.
| Elm has good functional style, however distance(html, elm
| template) > distance(html,react). So, elm has "too much" high
| level built-in abstraction, which makes code reading harder.
|
| ---my take react is ok in most of cases
|
| react native is great (but you will end up writing large screen
| adaption, native feature for hardware X, shipping web code to
| native app user is ok, reverse not true).
|
| react hook is horrible (checkout some ecommerce oss, 100 warning
| after compile, 10+ hooks in same component, communication that
| not to trigger rerendering)
|
| vue has more consistency but 0 in native app direction unless you
| happy with doing everything in web
|
| angular was great until ppl left it to maintanance mode. tooling
| is very complete. (stencil,ionic)
|
| kotlin could be better glue between js and native. it makes code
| cleaner, easier.
|
| typescript is a noise :[ yey
| efitz wrote:
| I must admit, I read this headline and wondered why I should care
| which email editor they used. I read half the article and still
| don't know what Elm is but I'm guessing it's a language?
___________________________________________________________________
(page generated 2023-04-08 23:00 UTC)