Earlier quoted context omitted.
But are language enthusiasts really better hires in general? I've known many of them who loved the theory and toying with a language but were not any better at producing actual value than the average joe.
I have noticed a lot of language / framework collectors where every new project is in a new framework or language on their CV. While it will expose you to a lot of different ideas I doubt you will code very well in any of them if you are swapping every year. I have seen plenty of Python written like its Java and its just less elegant code. And Django code that doesn't follow best practices seems to be the norm. If yo…
Elm changed my mind about unpopular languages
191–200 of 321 posts
Re: Elm changed my mind about unpopular languages
#192Earlier quoted context omitted.
The communities for languages like Elm are definitely smaller, but they're also "passion languages", if that makes sense. Nobody is learning elm because they've been or feel forced to (like you might with React, eg) or because they needed to maintain a legacy codebase at an old job or something. They're learning it because they're interested/like it, etc. So when it comes time to hire you have a small(er) pool of can…
F# is a bit surprising, since it’s already on top of a mainstream platform. If all else fails you can glue in C# if you ever find that you really can’t do something with F#.
[1]Languages like PureScript provide a much more convenient FFI for this glue, but the glue and escape hatch is still there with Elm.
Re: Elm changed my mind about unpopular languages
#193Earlier quoted context omitted.
> But are language enthusiasts really better hires in general? I've known many of them who loved the theory and toying with a language but were not any better at producing actual value than the average joe. I think they may be safer hires, anyway. They will be able to program themselves out of a wet cardboard box, which is more than you can say about the average Joe who may just be good at bluffing the interview.
Provided you dangle enough money and have a good interview process you can easily cull those people who can't code themselves out of a wet paper bag. The thing that would worry me about niche languages is the amount of wheel reinvention you'd have to do. Not sure the cost/benefit calculation starts to look so great any more when you realize that your enthused elm developers will have to build a whole lot of stuff tha…
Interviewing costs money—good tech interviewing particularly so. The less of the people you have applying to start with, the more money you save on culling then by way of tech interviews.
Re: Elm changed my mind about unpopular languages
#194Re: Elm changed my mind about unpopular languages
#195Haskell has enormous momentum now[1], and it's speed of development is accelerating. I came to it not because it was cool, but because my experience maintaining and refactoring a big Python program had become really painful. Haskell lets me keep the codebase smaller, it's easier to be pretty sure things are working, it's easier to refactor, and I'm sure the language will only keep getting better. Those are all unders…
That's been the story of Haskell for over 10 years. The world and other language ecosystems are changing faster than Haskell is growing. Clojure and Scala give you an alternative to Python that have the power of the Java ecosystem to take your programming out of academic and toy projects. And Python finally has static typing, 10 years after it was announced.
In this way, both your statement and the parent's statement can be simultaneously true.
Re: Elm changed my mind about unpopular languages
#196Earlier quoted context omitted.
> say you used it at work Please don't do this. If you're not found out in the interview, you'll be found out on the job eventually due to your obvious lack of experience. Some of my most personally loathed coworkers have been people who have bullshitted their way into positions by claiming skills they don't have or aren't qualified in, making them a nightmare to work with.
Is there some way in which side project experience is different than professional experience no one has ever informed me of?
I never know if someone has seen my repositories but it's been invaluable to have projects I can confidently link to. Until I got to that point, I remember an anxiety of "gee, I sure hope they take my word for my skills." Talk about imposter syndrome.
But yeah, I agree with what you were trying to say. Whether you are honestly representing your skill level doesn't have much to do with whether your experience was paid or done in free-time.
Re: Elm changed my mind about unpopular languages
#197My question is, how will he feel about this three years from now? When he is trying to hire someone? Or when the folks behind Elm don't update it as often as they should? The problem with unpopular languages is twofold: * lack of talent that can step right in and be effective * lack of resources to push the language forward The first can be remediated by planning to bring new hires up to speed, and just making that i…
Worth noting that in our experience, hiring has gotten way easier for us since we became an Elm shop. We really struggled to hire React engineers (who have a zillion positions to choose among - why would they pick ours?), whereas there seem to be a lot more great programmers who want to use Elm than there are companies hiring for Elm positions. Here's a verbatim quote from a cover letter (one I happened to be reading…
Re: Elm changed my mind about unpopular languages
#198Earlier quoted context omitted.
"Coconut: Simple, elegant, Pythonic functional programming." http://coconut-lang.org/
Wow, this looks very cool! Why is this not more popular? Coconut seems like something many people, including me, would want to use for every Python project of sufficient complexity. What's the catch?
The catches:
1. You have to be OK with a compilation step that isn't part of the Python world.
2. To the best of my knowledge the language has been and still is being developed by a single person, so there's the "Evan gets hit by a bus" risk built in.
3. Tooling is virtually nonexistent. There's a Vim plugin that understands the language syntax but there's zero IDE support. Of course you can debug the generated Python with Pycharm/VS Code/etc and having done it I can say it's not terribly painful but isn't terribly fun either.
I think that over time the lack of tooling will be the biggest hindrance to the language's further adoption. OTOH I'd be curious to know if this has been a major factor in other unpopular languages remaining unpopular. I seem to remember a lot of complaints about tooling in the early days of Scala but the language still managed to become fairly successful once that situation improved.
Edit: formatting, final thoughts
Re: Elm changed my mind about unpopular languages
#199My question is, how will he feel about this three years from now? When he is trying to hire someone? Or when the folks behind Elm don't update it as often as they should? The problem with unpopular languages is twofold: * lack of talent that can step right in and be effective * lack of resources to push the language forward The first can be remediated by planning to bring new hires up to speed, and just making that i…
When I need to do something new, I look for small companies from weird places with promising products. I get favorable terms, and usually rapid turnaround in features as we figure out what things we though we needed vs reality.
Re: Elm changed my mind about unpopular languages
#200My question is, how will he feel about this three years from now? When he is trying to hire someone? Or when the folks behind Elm don't update it as often as they should? The problem with unpopular languages is twofold: * lack of talent that can step right in and be effective * lack of resources to push the language forward The first can be remediated by planning to bring new hires up to speed, and just making that i…
In the worst case, you just adopt the runtime yourself. I don't understand why people draw boundaries around certain frameworks, runtimes, and languages and say "I'm hiring that kind of engineer". A good developer can go up and down the stack as needed and fix any part of it --- including the language runtime.
That said, as someone who is no stranger to contributing to upstream, the prospect of becoming the maintainer strikes me as something that is certainly not to be done lightly.