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 investment in them. (It can also be a useful filter, making sure you are hiring someone who is really interested to the company and is willing to make the time investment to learn what is probaly not a very portable skill.)
The second is a bigger problem, if the main sponsor of the language moves on. If the main sponsor is committed, then you're probably fine. (I have no idea who pushes Elm forward, looks like there's a foundation from the wikipedia page.)
Here's a verbatim quote from a cover letter (one I happened to be reading this morning; we see a lot of similar stories):
> Despite my valiant evangelizing of Elm, my company has decided to embrace React over Elm, so I am looking for opportunities to develop Elm professionally.
Our Head of Talent said she'd never seen an inbound pipeline as strong as ours, and the #1 reason people cite for wanting to apply is Elm. The "Python Paradox" is real!
I'm kinda surprised more companies don't take the risk - its not like these are bad languages, either. There's still a huge chunk people (in terms of absolute number, not portion of total devs of course) out there playing around with languages like Elm or Haskell or a Lisp/Scheme, or OcaML, F#, etc. who'd be super excited to use those languages professionally.
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.
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 that you can just import in other languages.
FFIs can have warts, but in the general case library support isn't the obstacle people make it out to be.
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.
Someone who hello worlds new languages may not know the syntax or idioms to write fizzbuzz in any specific language, but they will be able to characterise the rough shape of the problem, and not just sit in silence...
"bluffer overflow vulnerability". :)
And don't get me started on the way people misuse Django.
I personally know of a story where a startup started with datomic and clojure, and it was a bad idea because datomic could not effectively delete things. Eventually they went the standard java and standard cassandra / postgres / redis type route.
Languages like PureScript provide a much more convenient FFI for this glue, but the glue and escape hatch is still there with Elm.
F# and C# compile to the same intermediate language, are interpreted on the same runtime, and are produced by the same organization for the same IDE... Their libraries are compatible and they rely on shared access to the common .net ecosystem.
Your absolute worst case scenario would involve decompiling your F# source as C#. More realistically you would use dependency management to gracefully transition out of one of the languages.
Transitioning piecemeal works exceptionally well: it's exactly how I've transitioned numerous projects away from C# onto F# ;)
I worked in Elm, and loved it. I tried to get it in several positions I worked at. Applied to a few elm positions, but was told I needed prior professional experience. So moved all my personal projects to React so I could be more marketable. My day job is still using java server faces, or django templates largely.
As noted above there are pros and cons. But if you're using a fringe language/tech and allow your team to contribute back upstream. That helps immensely. One of the other stands out I can think of is Jane Street and OCaml.
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.
I'd rather just hire for good developers in general who are interested in working in Elm than to hire only for Elm experience. As you've pointed out, there are problems in doing the latter.
I've also found this as a partial negative. Positive you took initiative, and want to learn. Negative you've now written a product that only you can maintain, and doesn't listen well.
I go down the honest path. Of I did a proof of concept, or scratch project in this language. But didn't get the buy in from the rest of the team. Which sometimes leads to why am I not good at sailing new technologies.
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.
* In a professional setting, you often have little choice of who you work with. Therefore the technical choices you make in a professional setting must take into account the possibility that the next person who works on your project may be someone who does not understand, like, or care about the way you do things, and that the way they interact with your work may have significant negative repercussions for both you and the project. This is often a tedious, difficult, and time-consuming task that requires different techniques and approaches than one would use when working on a personal project. Conversely, in a professional setting you will also inherit the work of others which may be done in ways you don't understand, like, or care about, with few or no options to change those ways, and you must develop and adopt technical strategies to deal with this as well.
* Documentation, readability, and testing take much more precedence in a professional setting since they serve as guardrails for the long-term integrity of your work as it gets passed on to others to maintain and expand.
* Working with others also requires agreement, and usually mutual compromise, on basic standards, conventions, and processes that can significantly affect your daily workflow and may greatly differ from how you would work on a personal project.
* The end goal of personal projects is usually personal enjoyment, satisfaction, and learning. The end goal of the vast majority of professional projects is to generate revenue, or otherwise serve some need that your employer deems sufficiently important to fulfill by compensating you. The intersection of techniques that are personally appealing to you and the ones that will generate value for your employer may be very small or nonexistent much of the time.
* Your employer may not care about letting technical debt pile up indefinitely as long as you can keep cranking out new features and meeting deadlines, code quality be damned. Alternatively, your employer may impose onerous processes to ensure code quality and integrity that aren't really necessary or effective, and which may even be counterproductive. In fact, there's a good chance your employer will understand very little about what you do at all and make demands that are incongruent with technical realities, which you must deal with, sometimes by performing pointless tasks solely to appease them.
* Personal projects are usually started from scratch, and often dropped or 'completed' once they reach a certain level of complexity, due to the increased level of difficulty brought on by said complexity. Rarely does one have the luxury of dropping projects on a whim for such reasons in a professional context. In general, working in a professional context often involves dealing with a lot more annoying complexity and thorny problems that simply cannot be ignored. Even successful, enjoyable professional projects may become boring after a while since their success will draw continued investment by the employer, oftentimes in areas that are uninteresting or largely irrelevant to the aspects that were originally exciting.
As to some specific points:
> Techniques to minimize failure are quite literally a matter of survival in a professional context; they are often an afterthought in a personal project. Fault prevention and tolerance are often the most difficult characteristics to achieve in any sufficiently complex software system, and their prioritization or lack thereof has an enormous impact on virtually every aspect of working on such a system.
See, I almost see this as backwards. My personal projects often depend on only myself to maintain survival, and I didn't put all that time in to see them go by the wayside so easily. This means I build in tools and resources to help put them up and keep them up, because I'm the only one who can. In a professional context, I've often seen team members not consider these issues because once it's out, it's someone else's problem- if it causes downtime, DevOps, if it's a simple bug, whoever takes the ticket.
> Your employer may not care about letting technical debt pile up indefinitely as long as you can keep cranking out new features and meeting deadlines, code quality be damned. Alternatively, your employer may impose onerous processes to ensure code quality and integrity that aren't really necessary or effective, and which may even be counterproductive. In fact, there's a good chance your employer will understand very little about what you do at all and make demands that are incongruent with technical realities, which you must deal with, sometimes by performing pointless tasks solely to appease them.
While certainly true, this is also something I would never expect someone on my team to be proud of. This is a shameful act, and done often enough leads to the departure of good talent. I expect management(including myself) to do it's job: Manage. This means not taking advantage of your employees often enough to make it a norm.
However, the thing I keep noticing about a lot of these is a certain level of assumption of what a personal project entails. That you may be producing something with significant technical debt, that you are coding in a way that isn't trying to work best with others, that you're not aiming for revenue or having to work under unrealistic constraints. Personally, I code at home the same way I code at work: With quality and hope that it will continue to have a life long into the future. Sometimes I don't return to projects for months- and I want to be able to pick them up the way I put them down. The other thing I recognize, is the kind of experience that has to do with working with others- something most personal projects certainly don't approach, but I don't look for them to solve it. Team experience still matters, I just also think personal projects mean something for technical experience.
That's great, but when push comes to shove, you can and will ignore an intractable issue in a personal project until you feel like working on it again. With a job, consistently ignoring issues can endanger your career and thereby, eventually, your ability to provide for yourself. (And to me, being a parasite who punts issues like you describe is hardly a better existence even if you're able to get away with it.)
> While certainly true, this is also something I would never expect someone on my team to be proud of. This is a shameful act, and done often enough leads to the departure of good talent. I expect management(including myself) to do it's job: Manage. This means not taking advantage of your employees often enough to make it a norm.
Sometimes accumulating technical debt is a more pragmatic option in the bigger picture - what I'm describing isn't necessarily a universally bad thing (although it often is bad); the point is that professional and personal projects have fundamentally different priorities and that they require different skills and approaches to navigate effectively.
> However, the thing I keep noticing about a lot of these is a certain level of assumption of what a personal project entails. That you may be producing something with significant technical debt, that you are coding in a way that isn't trying to work best with others, that you're not aiming for revenue or having to work under unrealistic constraints.
You are validating this assumption with statements like this:
> Sometimes I don't return to projects for months- and I want to be able to pick them up the way I put them down.
When you are in production with real customers, you rarely have the option to do this. It's great to strive to adopt good practices in your personal projects, but when shit hits the fan at 3am, you're not going to get out of bed and fix it unless you have some real skin in the game, and you're not going to be truly motivated to code as if that's a real possibility (That means having: runbooks, paging, escalations, dashboards, metrics, alarms, gradual rollouts, time windowing, calendar blackouts, rollbacks, multi-step deployments, canaries, tech-ops, feature toggling, A/B testing, backup/restore, DNS safeguards, load balancing, SLAs, pentesting, failover, status reporting through 3rd-party channel, etc. etc.). I never said personal projects don't mean anything for technical experience; they certainly do. But that doesn't mean they're representative of professional experience either.
I would rather have people who care about their craftsmanship and are
indifferent about the product than people who care about the product and are
indifferent about the craftsmanship. The former ones do a good job regardless
of what the product is about.
If down the line you find language XYZ is a much better fit, well you still have choices about migration/etc. I wouldn't expect the devs to revolt against this, if it really is a better fit.
Time and technology marches on, that doesn't mean we can't try to make the best tool choices we can while still accepting that change is a fact of life and adapting the best we can.
And, if it is a good tech that fits your business, why wouldn't you?
If that's true, it's kind of awful. "'Once the rockets are up, who cares where they come down? / That's not my department', says Wernher von Braun."
These are unbelievable fantasies. Where the time comes that another technology is a better fit is few years after when a.) team members might have changed preferences already multiple times b.) given average employee changing job once in 2 years your original team members left.
I think that hiring would is much better when companies hired less on applicant emotional state and more on calm rational decisions about work.
Elm, Haskell, Clojure, etc, seem like they fulfill the role of "2004 python" in 2018.
And ReasonML, PureScript and Kotlin the role of 1995 Python?
Where do I apply? ;-)
(To prove the point: yes, I'm one of those passion people, moving to Denmark to work in OCaml full-time, before working in Clojure full-time. Now someone give me an Idris job, heh!)
Most of our team is remote, including one from Copenhagen!
I'm excited for Elm Europe in large part so I can finally meet more of them in person!
P.S. I'd love to learn and apply Elm across. I've applied at NoRedInk but did not get any response.
Not sure how I missed that, seems like it was under reported.
Don't know if that's where op is going though :)
What are you looking for, exactly? As an "inexperienced" Scala dev, I'm genuinely interested.
Knowing C doesn't mean you can't learn React, but if you've only ever done C and low level systems programming means you have a lot to learn to get to the level of someone who has specialized in knowing React and it's environment. It's not just React. It's everything around it that also matters. Such as browsers, HTML, CSS, and all the best practices there. And while I'm sure anyone can learn that, the question is, would you do it in reverse?
Would you hire someone who knew React, CSS, HTML, and web development to write systems level C and expect them to learn it all, and, most importantly, be effective in their role?
Labelling yourself as a react engineer isn't limiting. It's just one of many things. You can have many labels, and adding a label doesn't take away from other things you can do. However, it is an effective way to communicate what skill sets you have to people that would be good to work for and with.
We've always been happy to hire good people who don't happen to be familiar with our stack already.
That’s a significant enough reason to pick one shop over another and also a reason to opportunistically apply.
“You get to work with Evan/Guido/dhh/Gosling” is a different sell than “we use Elm/etc”.
I don't think we're especially close to that happening yet, though. Obviously the opportunity to work with Evan is a big differentiator for us among Elm shops, but the cover letter I quoted exemplifies a person whose reason for leaving their current position was that they wanted to work with Elm, not React.
There are plenty of opportunities for companies to attract people like that. :)
With that said, I sort of agree with the sibling comment here. Most other people involved with a language that I've seen are still able to make objective criticisms about it.
While I understand that, I find it quite paradoxical given that Elm purportedly targets normal programmers. (Elmer here.)
Also, your comment was needlessly harsh. If you wanted to know what I consider Elm's flaws, you could have tried just asking.
The subject of Elm often gets me riled up because there's so much good about it mixed with what to me is a greater portion of frustration. I strongly disagree with how the language is managed, with the closed nature of its development, but mostly with what looks like the constant dismissal of any concerns about any of these issues any time they're brought up. By far, the most common response feels something like "everything is fine and your opinions are baseless."
There are people I know who, like me, have tried to convince employers to even consider Elm and have been shot down because, in management's words, "there doesn't seem to be any idea where the language is going", or its "too unsafe, its all dependent on one guy" or "looks like its dead now anyway, no releases in over a year and apparently it sucks at basic things like dealing with json". And yeah, some of those things, like the json nonsense, shouldn't be showstoppers. But not having an idea of what the roadmap or timeline looks like is a big deal. No releases in a year is a big deal. So then you bring that up on the elm forums or the slack, and you end up getting blasted there too because now you're seen as criticizing this thing that everyone loves.
Obviously I'm just a jackass on the internet with more mouth than brains and I wouldn't hold your breath waiting for me to ever make anything as interesting or yes, successful, as Elm is right now. I appreciate the work you've put into making Elm as good as it is.
> what looks like the constant dismissal of any concerns about any of these issues any time they're brought up.
I remember earnest (and exhausting) discussions of these topics from back in like 2014, when it was unclear what the best way to scale Elm's development would be. We tried different approaches, but the outcomes weren't great.
We're actually still experimenting with this. For example, Evan wanted to put a community member in charge of the debugger, so he did...about a year ago. That experiment hasn't been fruitful (the debugger has not had a substantial release in that period), so we're trying handing it off to someone else. We'll see if that works better based on what we've learned from the previous attempt.
It's easy to say someone else should have taken it over sooner, but at the time there wasn't anyone else who understood the internals well enough to manage it, while also being interested in taking it over. Now there is.
Relatedly, I get that some bosses want to see a higher bus number on the compiler, but functioning teams of compiler authors don't just drop out of the sky. It's a rare specialization, and even among the few people who have the training to do major work on a compiler like Elm's, most are academically oriented and didn't go through a pH.D program so they could performance optimize Haskell code, make nice error messages even nicer, or find ways to remove language features rather than adding that cool new one they read about in a paper.
There's also communication. Evan used to give lots of updates about his progress on upcoming releases, and the main effect was to delay the release. He'd announce some progress and it would instantaneously become a Q&A - at best. Often people would pressure him to give up on whatever the latest impediment was and ship something sooner. If he didn't respond to those responses to his progress update, people would complain that he was unresponsive. So doing public updates strictly increased complaint volume, which of course also takes a toll on Evan, being a human and all.
> But not having an idea of what the roadmap or timeline looks like is a big deal.
The two options here are:
1) Be honest
2) Try to trick bosses
There isn't a world where Elm stakes out a roadmap and a release timeline and then hits it. Elm is trying to do a bunch of things differently than how they've been done before, which means each release is in some ways experimental, and also that each release changes substantially based on lessons learned from the previous release.
So yeah, it'd be possible to make up a bunch of "oh yeah, Feature A is gonna come out in April, and then B will land in July" but anyone could look back a year or two later and realize that the stated roadmap had barely any relationship to what actually happened. (People would complain about that too - that Evan wasn't sticking to the roadmap he'd laid out.)
We know from past releases that this is how it's gone (in my hubris, I told my editor at Manning I predicted Elm 0.19 would be out last summer) so there's no way to publish an official roadmap without knowingly misleading people.
If anyone considers it a red flag that there's no official timeline, well - that's because such a timeline wouldn't mean anything anyway. Evan's approach is to be open and honest about this. 
I don't know how helpful that all is, but maybe it sheds some light on the history of some of these things. :)
Evidence to support your assertions that it’s “stagnant” and “average”?
For anybody to take you seriously, you need to put more effort into it than just being disgruntled.
Furthermore, last I checked the source code doesn't live inside Evan's head like a family recipe. The functional principles and clear Haskell influences won't die if Evan were to go away.
At Real Kinetic we've actually been internally using Elm for 2 years. While at Workiva, I OKed some internal projects to use Elm as well. Your observations are absolutely correct.
We have actually found on-boarding engineers to Elm is fast and relatively easy. There is a very predictable learning curve engineers seem to follow. That's one of the things we like about Elm versus some other solutions. The even bigger observation I've made is that all of the engineers we've exposed have become fans, like Alex.
The lack of resources and other companies contributing to the community and libraries is a challenge, and a concern. As an example, we use Elm Native UI for some projects. It has a limited user-base, which has at times been frustrating. We're hoping to see more adoption of Elm to help mitigate this problem.
Elm still at risk of such changes, witness fundamental change to it's event subscription model after 0.16.
Of cause, such incompatible changes may happen even with popular languages. But at least you know that you are not alone and there will be companies that support your version. Like, for example, the case of Python2, still supported and even installed by default on many systems instead of python3.
It can be a useful filter in both directions. I'm more impressed with prospective employers who have an onboarding plan including some reasonable model of a learning curve than prospective employers who assume "oh, we use popular language/framework/tooling x/y/z, so if we find someone who knows these specific things, onboarding will be a snap or practically take care of itself."
So mixed results, but just because it might not work out isn't reason to not take a risk, just have to work out how appropriate that risk is.
Considering that a lot of code that gets written is thrown away or otherwise doesn't survive for years, a bit of risky experimentation isn't actually as risky as it seems.
Even though I'm one of the never-satisfied/always-seeking-newer-better group (and my list of used and discarded tools/languages is very long), I do sometimes wonder if we would be better off with fewer choices and more effort spent on the concepts and methods of software development rather than on the tools.
Absolutely. Whenever I see a new project, I look at business risk and technology risk. Either one is OK, but both are not. (I picked that up from someone, don't remember who).
I think that there's real value to being a Tom Bombadill (and really learning a language/framework/problem space deeply) as opposed to being a Gandalf. However, one fundamental issue is it's easier be a consultant and speaker if you are focused on the new shiny objects, and so much of what is written is from that perspective.
Perhaps it depends much on the mind of the person; I don't think I could just focus on one thing forever. But while the new shiny tech guys may seem to have more opportunities, I believe the domain experts may get paid more and have more of their career time spent as "recognized leaders".
It's probably good that people are all different, and both types (and all in between) exist.
To analogize, if you are a general carpenter, you can always find work, but it will be at a lower rate. However, it will be varied.
If you are a fine cabinet carpenter, your work will likely be more focused, possibly more repetitive, more lucrative, and harder to find (you'll have to seek out the folks who need really really nice cabinets).
Lack of resources could be an issue. I am hopeful about Elm though as the founder has plenty of cash and passion to keep pushing it forwards, plus a full time job doing just that. Plenty of people who can step in if required. The compiler is written in Haskell so is probably quite maintainable. Much of the functionality is in libraries maintained by a diverse group.
Competent people, not "talent". Talented people are very rare, and the
chances are, you haven't ever seen one in reality.
And there are several things to note about hiring programmers for writing in
less popular languages: (1) it's much more difficult to hire an incompetent
idiot that knows Elm than similar idiot who knows C#, Java, or Python --
signal to noise ratio is much better; (2) there is such thing as Haskell tax,
which pretty much means that writing in Elm can be treated as a job perk; and
(3) you don't need people who know Elm, you only need people who can learn
it in reasonable time.
Especially (3) is important, because learning yet another language of the
same paradigm is not that difficult for a competent programmer.
But I'd add that popular languages have related problems. Java, Python, and Ruby are all ones I've used in production, and I'd say every one has a big problem pushing the language forward. They all have failed me differently in that regard, and I'd still happily use any of them again in the right circumstances.
The talent situation is interesting as well. With a popular language I can find more people who claim to know the language. But of the people who show up, a lot more of them will not be particularly good. In practice, given the work necessary to get somebody up to speed on our domain, our chosen libraries and frameworks, and our own code base, helping them learn a new language doesn't seem like much on top of that.
The big things that keep me from picking novel languages for long-lived production code are libraries and production considerations. It's such a huge advantage to be able to download a decent library rather than having to code everything from scratch. And I don't want to be the company pushing a language into unknown performance territory. It's noble work, but it can be expensive and introduce a lot of volatility that I really don't need.
Contrast that with what would happen if No Red Ink went out of business and the author of Elm couldn't find a job that would allow him to continue to develop it. Things would be fine for months or years but eventually bitrot would set in.
Definitely not trying to spread FUD. I know some great folks that swear by Elm. It's just another risk factor (just like tech debt that might accrue should you use jQuery) to consider.
Edited to correct where the Elm author works.
Nope. jQuery fit(ted) a different use case (spicing up server-side rendered HTML upto small browser based app-bits). Doing a browser-side app in Elm (what it's specifically made for) makes for code base that is so much easier to work on some years from now, than using jQuery to accomplish the same.
What I want to say is, the debt you're going to accrue applying it to Elm's domain will not be a risk, it is impossible not to be destroyed by that debt. Where Elm provides a serious alternatives to the browser app frameworks that are 10 generations younger than jQuery.
Elm's size, OTOH, is certainly a risk factor.
What makes you say Swift is inferior? It seems like a huge improvement over ObjC.
Not the poster, but both of those can simultaneously be true.
What matters more is the quality of the language/framework and relative availability of libraries for the particular usecase (general popularity is not always necessary).
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.
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.
On to the topic of this submission itself, Elm turned out to be a gateway drug to Haskell for me. Similar to Paul Chiusano I decided to switch from Elm to GHCJS (Haskell). I started with https://haskell-miso.org/ (based on the Elm architecture) but I'm currently developing using http://docs.reflex-frp.org/
Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on a page, full of redundancies and boilerplate. In Haskell if you want to make, say, a data type that is either an X or an O (suppose you're writing tic-tac-toe), you could do it in four words: 'data XO = X | O'. (Notice that there's not even a natural way to do that in Java or C, because they don't have sum types; you'd have to make a type that has a flag to indicate whether it is an X or an O. That gets really complicated if they're supposed to have different data associated with it -- but in Haskell, if the X is supposed to carry a float and the O is supposed to carry a string, you just add two more words.)
Pattern matching also helps with terseness. I don't have time even to write the last paragraph so I'll skip this one.
Purity keeps you from tripping up on IO-related errors. It lets you be much more certain that things are working. It also forces you to keep the IO in a thin top-level layer of your program, which might sound like a pain but once it feels natural you'll find yourself moving faster than you could before.
To be sure, Haskell has features that I don't use. But purity, sum types, pattern matching, and the unusually rigorous (it's complete!) type system are all critical to its value to me.
I'm currently dealing with it in a large swift project, and I would much rather go back to the extra verbosity of objective-c than have type inference at this point.
But that was insightful, thank you!
In the case of rust, I suspect one of the biggest issues is the way parametric polymorphism is implemented. Basically, if in your program you end up using e.g. Box<usize>, Box<MyType> and Box<Result<String>>, you're compiling Box 3 times.
I don't know enough about swift to hazard a guess as to where the build is spending its time.
My experience with Haskell is that compile times are neither great nor terrible.
I remember vaguely reading about how at a haskell conference people were basically cornering compiler maintainers about compile speed, but that was several years ago.
My codebase is only a few thousand lines, though.
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.
If you want to approximate the cool things in Haskell with a Python-compatible* language, there's Coconut. In addition to static typing, it offers algebraic data types (how I lived without sum types, I don't know) and pattern matching.
* every valid Python program is valid Coconut
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?
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
- Types are checked before run time
- Type errors are reported
If that's not static typing, what is?
- Most Python expressions and standard library functions would have (nontrivial) types
- It would be unusual for a Python library to come without (nontrivial) types
- It would be unusual for Python code containing type errors to be distributed
- Many classes of runtime errors (e.g. no such method) would be unusual in Python code that does not contain type errors
> Python 3 supports type annotations natively
> the mypy tool is an external typechecker that you can run just like any other static analysis tool
I think I was pretty clear that Python is not statically typed.
Just because mypy is optional doesn't mean it's not static typing.
>You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.
If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those.
Elm helps significantly with the latter.
It's not a good point. It's just unrealistic to rely on standard libraries, even if you're writing Scala or Python. Community size must be an important factor, even for Elm. It is highly unlikely that Elm is so perfect, that community size simply becomes irrelevant.
I think we can all agree that this article isn't finished at all.
Anyway, this is pure speculation on my part, I have yet to dive into either language.
I also use Elixir and it has great community and everything, but somehow Elm is even more.
All the concerns about 'unpopular' languages, lack of tooling, I feel it is quite the opposite. Elm formatter changed how I work and now I started using it in other languages, Elixir and JS are using it more, or maybe I just started paying more attention.
There are other smaller things that I noticed.
I wish I can work more in Elm, not less.
Also one more thing. Elm made me wish to be way better programmer. You are surrounded by smart people and you just need to show more if you want to keep up.
It's got it's issues (mostly that it's incredibly easy to abuse powerful features), but it also has a ton of stuff I really miss in other languages.
I have a web-based party game (CaH clone) I wrote in Scala for the back-end, Elm for the front-end. It's a bit old (I'm planning a rework and update when the next version of Elm comes out), and it's definitely not the best code ever as it's a hobby project, but you might be interested.
I also like the debugger. It allows you to easily capture your steps as you click around your application, save those steps into a file, and send that file to other developers, which allows them to run through your steps on their own machine; seeing Elm's output at each stage. It works like a "steps to reproduce" bug report, only automated, which makes finding and fixing difficult bugs easy.
There is a lot of good documentation for Elm as well. Elm's documentation itself is good. Manning and Pragmatic Programmers both have good books on Elm (both are still early access versions though). Pragmatic Studio also has an excellent video course on Elm for about $60 (https://pragmaticstudio.com/courses/elm), if you're interested in learning it.
The negative part is that Elm's development is rather slow and not pragmatic. This is painful on the short term - specially if you come from JS land..
 An example of a (great) conceptual talk: https://www.deconstructconf.com/2017/evan-czaplicki-on-story...
1 + "1" => "11" is strongly typed, dynamically typed, with a particular type conversion that favours "strings".
But, on reflection, I am probably an pedantic iconoclast.
I mostly agree with your point here, but in this specific example I actually think Perl did the right thing, where
1 + "1"
"1" + 1
1 + 1
"1" + "1"
1 . "1"
"1" . 1
"1" . "1"
1 . 1
This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result), and the operation returns that. Then, if you wanted an int, you can cast your result.
That doesn't work if you want to consider string concatenation to be a form of numeric addition. It isn't. There is no ideal result when adding a string to a number, and if you do one when you meant to do the other, there is no way of producing the data you wanted ("11") from the data you have (2).
Perl doesn't have much of a type system. But it solves the common problem of manipulating strings when you meant to manipulate numbers, or vice versa, by not assigning the same operators to these radically different operations, and I think that was the correct choice, even for languages with stricter type systems.
After further consideration, I believe this is incorrect. This usually isn't done because integers are closed under addition, subtraction, and multiplication, so the "promote according to argument type" C behavior doesn't lose accuracy in those cases. There obviously is a platonic correct result when you divide two integers, but it is not in general an integer, so the C behavior introduces bugs (explaining the popularity of divide_and_return_float() -- I don't care what types the arguments were, as long as I get the result I'm looking for).
I think the point still stands that unpopular frameworks/languages can still be stable and more effective than popular frameworks.
When I started with React/Redux, I didn't know much about functional programming, but I developed a certain interest... A couple years later my React stack was full of tools and libraries that allowed me to write my React apps in a more functional manner. I used TypeScript for the type system, ImmutbaleJS for immutable data structures, Ramda as a FP utility library and Recompose to call React itself in a functional manner. I also used pure stateless components exclusively... Then I switched to Elm and I realized, that the React stack I was working with was a crippled version of Elm. I'm currently writing my first app in Elm and it feels much smoother.
As an Elm developer I would be interested to dive into your implementation and perhaps contribute.
It's not just that it's hard to find people to join you, it's that even engineers who might be considering joining might decide it's not a good career move since they are going to spend years learning a language or a platform that sees no adoption and will not serve their future career.
I wonder if anyone else finds themselves in a similar situation.
+It's a bit more nuanced. We're in a very "MVP" stage; the line of thinking is to use something everyone's more familiar with so we can move fast.
This is all doubly true for a early-stage MVP, where I'd expect a CTO to be technically minded and enthusiastic. Sounds more like "I know JS so we'll do JS."
> It does not speak highly of your CTO
Our CTO is the kind to speak highly about. Strong technical/software engineering skills. Willing to experiment with new/different tech. Business minded. He agreed whole-heartedly to move forward with Elm in the first place. This is actually our 2nd project with Elm now.
> Can’t these things sit side by side? How is re-writing code aligned with moving faster?
Yes; in fact, we’d always had a mix of Elm+JS.
Our product is not a Single Page App. (Very deliberate decision.) We’re only using JS/Elm to make small parts interactive. So there was only a relatively small amount of Elm code that was replaced.
It allows us to move faster because our designer and a couple of junior devs on the team don’t have to struggle through learning Elm.
Elm-html is my biggest criticism of Elm. Why make the contemplating so difficult for the non-programmers to work with? It's holding back Elm adoption for sure.
I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
> I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely interfaces with the DOM, which I believe is mitigated by JSX.
So in some sense the article is more about JQuery/Bootstrap/other legacy solutions being bad.
Neither is even remotely as robust — let alone friendly — as Elm's type system.
Robustness, you're absolutely right, Elm cannot be beat. But it comes at a price: It's pretty limiting/underpowered. Typescript is very expressive these days and you can write some very neat libs that feel dynamic but are actually fully typed, if you bother (to be fair, most people don't bother). On the other hand, Elm usually doesn't provide many ways to do something, and you may even have to cheat and offload some work to dirty-old-JS-land via a port to unblock yourself or simply deliver a functionality on time.
I'm still unsure whether the freedom is worth it or whether the robustness wins at the end of the day; it may depends on what kind of app you're writing and how strong the team is (e.g scala has the same "issue")
You're completely correct, though for whatever reason functional languages almost always have strong type systems.
It's remarkably useful so far. I feel like I have an extra level of protection compared to Ruby or Python.
My point was that 'untyped' should not be conflated with 'dynamically typed'. They're worlds apart.
Better than, say, assembly language.