Top 5 DEV Comments from the Past Week

#bestofdev

This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.

I love a good cathartic rant, and the Sh*tpost: can we stop saying "syntactic sugar"? was no exception. @marek hopped in with some useful thoughts on the subject:

Marek Zaluski • Jan 18 '19 • Edited

It's called syntactic sugar because it doesn't introduce any substantial new feature to the language, it's just a sweeter syntax.

So yes: destructuring and += are examples of syntactic sugar because you could write it in the longer, less clean form, and it would be equivalent.

As a side note, sometimes the verb "to desugar" is used to mean "to turn into the equivalent syntax without sugar" As in this example sentence:

a += b desugars to a = a + b

Async/await is not an true example of syntactic sugar, it's an entire new feature in the language. You can re-write async/code to use then/catch handlers but it's much more than a simple syntax transformation, it's a re-write.

In conclusion, it's called "sugar" probably because it implies it's something you sprinkle onto the language syntax to make it easier, but not a whole new set of features. Under the hood, syntactic sugar could be implemented as a transformation of the syntax tree, so the runtime engine may not even need to know about it.

And I agree with the "diabetes" argument: too much syntactic sugar isn't good, it can definitely be taken too far when it makes code harder to read instead of easier to read.

There was a great conversation where people answered: What do you do while waiting for tests to finish running?. At the top of the thread was a reply from @sergio who described the difference in test speeds for Rails/Elixir:

deleteme deleteme • Jan 16 '19 • Edited

When I work in Rails: Read some news or watch some funny clips on youtube.

When I work in Elixir: No time to do anything really the tests run super quick. My longest time was 7 seconds and that was for about 800 tests.

In at truly great article, 25 years of coding, and I'm just beginning, @tylerlwsmith empathized and described how they related to the author:

Tyler Smith • Jan 17 '19

I absolutely feel this. I quit my job 2 years ago to become a web developer because I had a couple of personal projects I wanted to build. Truthfully, I was probably a competent enough developer to build out an acceptable version within 10 months of becoming a dev, but two things always stopped me:

Shiny object syndrome. I wanted to make the project with the best platform possible, so I switched from WordPress, to Laravel, to Django and then started reading up on serverless. It was a great learning experience, but I got nothing done.
I wanted more features than I could reasonably turn out by myself.

I got stuck for a year without launching anything.

I think what helped me was a combination of reading a bunch of articles about Minimum Viable Products (also known as MVPs) and just getting fed up with not having anything done. I lowered my ambition from ~10 features to 1 feature and built a workable site in WordPress in 14 days. It doesn't matter that it's in WordPress because no one is visiting the site yet anyway so scalability is a total non-issue 🤷‍♂️

I've spent the past two weeks trying to figure out how to promote something that I think is really cool, and even though the codebase is kind of messy, I'm really happy with it and no one cares about the code.

Best of luck as you jump into your projects, if you focus on getting code out the door you'll do great!

In a discussion of Slack's new logo — Slack Has A New Face — @objque basically won the thread 🦆🦆🦆🦆:

Comment Not Found

@derekjhopper rounds things off this week with a wonderful comment about how to think about making a contribution to open source. The entire Open source contribution for beginners?! article and discussion is worth a read:

Derek Hopper • Jan 17 '19

Are there any open source projects you use in any of the work you do? That's a good place to start. Occasionally, I'll look at dependencies in projects I'm working on and see if they have any issues I could help with. It's a good way to give back.

Also, contributions don't need to be large or complex. I've made contributions where the only thing I helped with is to fix some spelling mistakes or fix typos in documentation.

Some general advice when you want to make a contribution:

Start by thanking the author(s) of the project. It always helps to be nice.
Read their contribution guidelines. Most projects have one. For example, some projects don't accept new features.
If you're unsure if they'd accept a change, open an issue and propose your change. Ask them if it's something they'd be interested in.
If you find a bug, submitting an issue with a failing test case helps. Then if they ask if you have time to fix it, you're already on your way.
Try to be available to communicate in a somewhat timely manner. Sometimes a pull request might go back and forth through a few rounds of changes. Timely communication helps and makes the process easier for everyone.
Follow the conventions laid out by the project. If they write tests a certain way, try to follow that instead of your own style.
When you open a pull request, try to explain as much as possible. If the project has a pull request template, follow that.
In general, be nice and easy to work with. No open source maintainer is going to get mad at you for being nice.

Good luck! Contributing to open source is a worthwhile endeavor. If you make it something you do regularly, you'll have a handful of contributions one day.

See you next week for more great comments ✌