DEV Community

Joe Clay
Joe Clay

Posted on

What makes you want to stick with a programming language?

My previous post generated a load of really interesting comments, so I'm back with another language design question - albeit this time a bit more of an abstract one!

What factors make you want to keep investing time into a programming language beyond writing "Hello, world"? Or conversely, what things make you drop a language like a ton of bricks and run back into the warm, inviting arms of ${FAVOURITE_LANGUAGE}?

For me, the biggest thing that keeps me motivated through the early stages is documentation - in particular, well written guides/tutorials, rather than simple API docs. I've noticed there's been a bit of a trend in recent years towards languages coming with a 'book' which goes through all the features of the language, and I'm a really big fan of that concept! The prime example of this is The Rust Programming Language, which is so good I might order the print copy when it comes out <3

On the opposite end of the spectrum, I think the main thing that puts me off a language is bad tooling (package management, command line tools, editor extensions, etc.). It's enough to put a damper on my enthusiasm for otherwise wonderful languages - I love Lua's design, but I find myself really missing code completion whenever I use it!

How about everyone else?

Top comments (17)

Collapse
 
rhymes profile image
rhymes • Edited

It's cheesy but one of the things that "kept me" around Python back when I started was the Python "zen philosophy" python.org/dev/peps/pep-0020/

You can also get it from the REPL:

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Collapse
 
17cupsofcoffee profile image
Joe Clay

While Python isn't my cup of tea personally, I love the ethos behind its design! Definitely a lot of stuff there other languages could take on board.

Seeing the PEP link reminds me - I also really like when languages have a well-defined process for proposing changes, rather than just 'submit a PR and hope for the best'. A lot of languages (and some libraries too, like React) are moving in that direction, and I think Python was ahead of the curve in that regard.

Collapse
 
rhymes profile image
rhymes • Edited

Yeah, the PEP process has been contested a lot of times in the past but I think PEPs, plus ethos and its community (and obviously the creator) is what kept Python relevant and kept it from exploding throughout all these years.

Python is 27 years old and it had two main versions that changed the language: Python 2 which is 18 years old and Python 3 which is 10 years old.

Ten years later people are still complaining about the fact that Python 3 is not compatible with Python 2. It's kind of hilarious but it makes you understand how hardcore the core team is :-)

Collapse
 
perigk profile image
Periklis Gkolias

As I say in my profile description, I love tech that solve problems and not testing my patience.

So I would say:

  • Easy to set up projects
  • Clear feedback on errors
  • Not much boilerplate(Java anyone?)
  • Great community
  • Appealing syntax
  • 'Magic' tricks. I love Ruby loops, for example. I also love list comprehensions in Python. Really handy features for me.
  • Good documentation
Collapse
 
jdsteinhauser profile image
Jason Steinhauser

The friendliness of the community, as well as how much I enjoy the language itself, keeps me around a lot. F# and Elixir have fantastic communities, and I enjoy them both!

Collapse
 
17cupsofcoffee profile image
Joe Clay

Absolutely, I'm much more likely to stick with a language if the community is welcoming! Saves you feeling like you're on your own if you run into an issue and need to ask for help.

Collapse
 
ben profile image
Ben Halpern

I stick with Ruby because it rarely trips me up in the middle of crafting something new. It has a great REPL environment and the feedback cycle is fast. What I give up in terms of type-driven certainty I make up for in creativity-driven productivity. It's flexible when I need it to be.

I come back despite the headaches that come with its warts. I also come back for the sensible community attitude towards problem solving and the fact that I have a certain type of problem I gravitate towards solving. Ruby gives me the productivity that comes with maturity but the tooling seems to have enough "modern" appeal.

I keep expecting to do less Ruby but I keep coming back for the niceties.

Collapse
 
polentino911 profile image
Diego Casella • Edited

Reasons why I moved, a now am happily sticking, to Scala:

  • easy to understand for people with knowledge of Java/C++ like me;
  • compiles down to java bytecode, aka it runs on any machine with a JVM;
    • which means you can freely mix any Java/Scala library, and it just works (in my company for example, we're using Spring + other java libs);

  • lean syntax for variables/methods declaration, even leaner with respect to generics cough C++ and Java cough (0);

  • but still, it's statically typed: it's just that Scala's type inference is so good that you can omit most of the type declarations (still, for a public facing API you'd better explicitly define the types!). And I really wonder why people would throw away such beautiful mechanism to check if "can this variable be passed to that method?" at compile time, instead of having unexpected errors at runtime;

  • you can choose whether to program in functional style, or good'n old object oriented way, or mix the two as you wish (0);

  • REPL to the rescue if you have to implement/check something quick (0);

  • again, functional programming style! The moment you get the hang of it, you'll realize how immutable data plus data manipulation function definition will make your code much more robust than hiding complex state behind an object;

  • no more NPEs: stop returning nulls and use Option instead. If you're dealing with Java libraries that do return null, wrap the result into an Option (0);

  • powerful, compact and typed pattern matching that would otherwise translate in many nested levels of Java if(){} statements

  • case classes to model data in a one liner, instead of POJOs that spans tens of lines

  • traits and mixins

(0) yes, yes, Java 8/9 did catch up a bit, even though it's doesn't feel as intuitive and simple as Scala. And keep in mind, most of those features were already available since day zero Scala (2004).

Collapse
 
17cupsofcoffee profile image
Joe Clay

I definitely want to check out Scala (and Kotlin, for that matter) at some point! I write Java all day at work, and while I quite like the JVM as a platform the actual language itself just feels really... heavy, for lack of a better word. Not my least favourite, by any means, but if there's languages that would give me the same upsides but feel less clunky I'm all for it :)

Collapse
 
polentino911 profile image
Diego Casella

Yes, I think it's worth it :)
And quite honestly, after reading so many positive articles about Kotlin, if I were to decide between Scala and Kotlin today, I'd give a go to the latter.
Have fun() !

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

In the initial stages I rely on documentation and examples. I need to quickly see how to do things. I don't care about basic things either, I need actual usable patterns and stuff that gets things done -- I may venture into non-basic territory quite fast.

As long as I can be productive I'll tend to stick with a language a while. My dislike tends to grow as my projects grow and I realize the features that it's missing, or I start to notice the redundancy or inconsistencies in a language. It takes a fairly long time to get to this point.

If frustration comes early I'll be disuaded from the language. This has been my story with Rust so far -- were it not for my stream where I'm forcing myself to learn it, I would have abandoned Rust within the first month or so. I also find it's documentation to be extensive, but quite bad. Lots of filler, not much usable material.

IDE features never factor in for me. As I jump between so many languages I've just come to expect limited and incomplete tooling.

Collapse
 
17cupsofcoffee profile image
Joe Clay

I need actual usable patterns and stuff that gets things done

Definitely, I think a lot of languages neglect the examples beyond the "here's how you use the syntax" ones - ideally there should be some complete projects too, so you can get a vibe of what it's like to actually develop something substantial.

I totally understand your frustration with Rust from time to time - it's one of those languages where everything's wonderful when things are working well, but then you have those days where you end up in borrowcheck hell and nothing seems to work and you want to throw your computer out of the window. I think Rust could use some more documentation for the latter case.

Collapse
 
dmerand profile image
Donald Merand • Edited

It's hard to pin down exactly, but the thing that makes me want to stay with a language is what it feels like to look at my code after 6 months away.

In my work, I make a lot of prototypes, and then forget about them, and then come back and tweak them after much time has passed. I need the code to be maintainable at that point, and the language I'm using can have a dramatic effect on usability after I leave my "flow state".

I've found my Elixir and Elm projects to be the easiest code to return to. I think it might have something to do with documentation being a first-class citizen in both languages, and excellent tooling.

Collapse
 
belhassen07 profile image
Belhassen Chelbi

because it's javascript hah, well, I love the ecosystem which may be sometimes (a lot of times actually) overwhelming but the thing is, we just have to use what we need so the feeling of being really overwhelmed will faint. The community is really cool and I'm really comfortable with writing JavaScript and I can do a lot with it, on the front-end or on the back-end.
Still, If I'll need to use another programming language, I'd love to, I'll pick the 'best' one for me, the one I feel comfortable with, and the one who has a good community.
Actually it's like dating a star, the more the fans , the more you love it, well I guess dating stars doesn't go that way but, get the idea? lol

Collapse
 
17cupsofcoffee profile image
Joe Clay

The front-end/back-end thing is what really attracts me to JavaScript, despite the quirks of the language - it's really nice to not constantly be flitting between two different syntaxes if you're developing on both sides of the fence!

I definitely agree with you about the community, too, there's a lot of really good people in the JS world.

Collapse
 
jandedobbeleer profile image
Jan De Dobbeleer

Documentation, a vibrant and accessible community and offering a solution for the problem at hand are my criteria. This means I work with quite a bit of languages I stick with, each with their advantages and disadvantages so I can switch based on the thing I'm trying to solve.

Currently C#, Python, GO, PowerShell and Ruby fit that description imho.

Collapse
 
itsjzt profile image
Saurabh Sharma

for javaScript,

You can love it, you can hate it, but you can't ignore it.

It has the monopoly in the web, used in desktop apps, can be used to make mobile apps.