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.
Replying to If you could change one thing about learning to code, what would it be?, @cjbrooks12 talks about the focus on the two extremes: content for absolute beginners and total subject-matter experts, and the voide in-between:
I felt like there was a plethora of content out there for absolute beginners, and plenty of highly specific/advanced topics, but not nearly as much content for intermediate developers. It felt like a real challenge getting past the "hello world"s of various frameworks into real-world development topics without getting deep into theory and design patterns that aren't necessary for 90% of apps.
You don't need to use the most bleeding-edge technologies and design patterns for the vast majority of projects that a beginning developer would be doing. They serve a great purpose for experienced devs doing professional development, but for beginners/hobbyists, it becomes a real blocker to even getting started.
And on the extreme end of things, it trains developers to just copy-and-paste solutions to get something to work without teaching them why it should be done that way, and as a result, it becomes harder for devs to actually take a step back and think through the problem they are trying to solve.
@mortoray offered some substantial insight in the ELI5: How does someone write a new computer language? thread. As soon as I saw the thread title, I had hoped that Edaqa would jump in:
There's no way to truly ELI5 this without obscuring details, so I'll opt for simplifying, yet trying to stay correct.
Vocabulary
A language starts with a human level description of what the language can do. You decide on a vocabulary, and how that'll look inside a text file. That is, without considering the hardware/software for a moment, you create an agreement on what the words in your language will accomplish.
Once you've done that you'll write a compiler for the language. This is something that is going to let the computer understand your vocabulary.
The compiler consists of several parts.
Parsing
That text file may be readable by you, but the computer won't be able to make any sense of. Parsing translates that text into a form that the computer understands. This is the abstract syntax tree (AST).
At this point the compiler has read your code, but does not yet understand it.
Semantics / Typing
Once the compiler has an AST, it needs to make sense of this. In this stage it goes through and determines what the code does. It figures out what the function names are, and how to call them. It determines what are variables, and how to store data in them. It figures out the conditions for if statements and loops.
At this point the compiler understands your code.
Translation / Lowering
The compiler will now translate the code into a new form, a form that the computer understands. This is often called "lowering" as it takes your high-level language and brings it closer to the machine language the computer understands.
Compilers do this in a variety of stages, often lowering to one or more intermediate languages (IRs), and then finally to the machine code of the machine.
A simple compiler may choose to "lower" to another high-level language, such as C++. This provides a quick way to implement some new languages.
Linking
Your code doesn't live in isolation, it needs to interact with the target machine. In addition to translating the code, the compiler will also setup tables of names and resources. These are how your code will attach to other components on the system.
Host Language
But you may be wondering in what language you write the compiler? This can be any language. The job of the compiler is to translate from your high-level code, to a known low-level language. It doesn't matter what language the compiler itself is written in.
It's relatively easy to write a compiler for a simple language. Complex languages take more effort.
I encourage everybody to write a language once. I've written several of them, from basic domain specific languages, to full modern languages like C++.
This description focuses on a compiled language, and is best understood with imperative or functional languages. The details, and terminology, tends to change as we get into other paradigms, like declarative languages, or interpreted languages. Most of the stages still exist though.
Do I Need A Computer Science Degree To Get A Job In Tech? @_adam_barker talks about why a degree is not a requirement, and highlights some qualities that employers look for:
Great article! I'm a firm believer in that the single biggest quality someone can have when becoming a developer is a desire to learn.
The desire and ability to learn pretty much trumps everything else for me. Relying on a CS degree as a substitute is not going to work. Nothing gives me more confidence than speaking to an enthusiastic candidate who has a Github account full of projects or experiments in different languages that they put together in their spare time.
I found our latest hire on Instagram and knew very quickly she had a passion for learning that would benefit us in the long run. She was working a full-time job in retail yet found the time to dedicate to (and finish) projects to demonstrate her learning.
Serving as an in-thread ELI5 (explain like I'm five) GitHub announces GitHub Package Registry, @0xrumple talks about what purpose a package registry serves:
Let's say you're working in a restaurant...
You, as a chef, don't wanna take the recipes from other chefs and cook it by yourself everytime you wanna create that delicious plate (that needs many recipes).
You would love if you had a kitchen that serves some ready-to-eat commodity food and compose it into your special plate.
Now, the lovely thing about that kitchen is that it keeps old commidity food with labels because some chefs prefer the old taste of that commodity food, and the kitchen is only allowed to enter for the chefs of that restaurant (because you don't wanna share your trade secrets with other restaurants).
Now change the above story wording:
Restaruant = your organization
Chefs = other developers/teams in your organizations
Recipe = package code (raw)
Kitchen = registry
Commodity food = packages (ready to be consumed)
Plate = your app
Labels = versions of those packages (to ensure new version won't affect apps using previous version of that package)
Finally, in 10 Questions You Should Ask In A Web Dev Interview @perigk brings up a few reverse-interview questions that will help reveal company culture:
Nice list. I would also add
What it is the training policy of the company? A company with no training policy or benefits, at least in the software sector, is completely worthless ( unless we are speaking for early startups where I can excuse them)
How do you handle absurd customer demands? You don't want to work with a company that has no idea how to push back
See you next week for more great comments ✌
Top comments (4)
Congrats to @cjbrooks12 , @mortoray , @_adam_barker , @0xrumple , and @perigk for making the list this week!
Thank you :D
Thanks Peter!
I found these comments very helpful. Thanks Peter