What dev topic do you think you should understand, but don't?

Happy Friday, dev.to

Let's get introspective.

We all know this situation: Someone is discussing a tech topic and, suddenly, bam!, they bring up monads or prototypical inheritance. Usually, we are just left there nodding along, hoping we get some time to Google that thing later.

I'd like to know what dev-related topics you don't understand, but are too afraid to ask about. Maybe we can all learn something!

NOTE: If you don't want to post them here, shoot me a DM on Twitter! I'll anonymize and post back here!

I'll start this out! I don't understand the concept of monads. It's made worse by the fact that I feel like I almost understand monads. Anyone want to try and tackle explaining them to me (or linking to somewhere that does), I would really appreciate it!

Comments

[Ciel]

Networking. I am a veteran programmer of 22+ years and expert level in tons of things.

I still struggle with HTTP Headers and Requests.

[Fred Ross]

So, for monads, I wrote up How to think about monads some time back. Here's the gist of it:

In most imperative programming languages, I would expect that writing a = 5; f(a); is the same as writing f(5);. And, a little more obscurely, that g = f; g(5); is the same as f(5);.

There are lots of particular languages that obey those rules, but, just like Java has an interface Map and lots of particular classes that implement it, we want a name for the abstract thing that is a language with those properties. That name is "monad."

[Andy Johnson]

Promises vs Callbacks. Mostly I Google my way out of callback hell, or save the stuff I need from API calls straight to the state in React. And I really don't even know what callback hell is, so also 'Callback Hell'. I am proud that I do know that callback hell exists, even though I don't know what it is.

[Conlin Durbin]

Oh hey, I can actually answer this! Callback Hell is pretty simple - it's when you have a bunch of nested callbacks, making difficult to read the code. Here is an example of what it looks like:

funcWithCallback(someVar, () => {
   anotherFuncWithCallback(someOtherVar, () => {
       yetAnotherFuncWithCallback(aDifferentVar, () => {
           // ... and on and on.
       });
   });
});

The main difference between callbacks and promises is how the render in the call stack. In that example above, the call stack looks kinda like this:

yetAnotherFuncWithCallback
anotherFuncWithCallback
funcWithCallback

Each function has to finish running before the next one will complete. Each of those is a frame in the call stack.

Promises make functions asynchronous and chainable, which is what happens when you call .then(). A promise tells the browser: "Hey, this function will return at some point in the future. When it does, run this next function that I defined in .then.

Does that make sense?

[Andrew T Johnson]

Indeed it does. Functions in a callback chain finish inside to outward. When doing async API calls, I've usually been saving the response (after JSON.parse() ing it) to a global variable like the State in React.

In your example if you want funcWithCallBack to return the results of yetAnotherFuncWithCallback, do you just chain return statements from the inside function to the calling functions?

Like:

funcWithCallback(someVar, () => {
anotherFuncWithCallback(someOtherVar, () => {
yetAnotherFuncWithCallback(aDifferentVar, () => {
return "result";
});
});
});

How do I get result from the innermost function to the top?

[Conlin Durbin]

You can make each callback function return the function before it - like this:

const topLevelData = funcWithCallback(someVar, () => {
  return anotherFuncWithCallback(someOtherVar, () => {
    return yetAnotherFuncWithCallback(aDifferentVar, () => {
      return "result";
    });
  });
});

And then those functions would need to return their callback:

function yetAnotherFuncWithCallback(data, callback) {
  doSomethingWithData(data);
  return callback();
}

Then you should have it outside of the callbacks!

[Andrew T Johnson]

Wow thanks for taking the time to explain that. Much clearer now!

[Pavan Maheshwari]

I really need to understand Regex

[Jay R. Wren]

Skiplists are an interesting data structure. I don't understand how they help.

[rhymes]

So, networking is the interfacing of devices to share information.

Ports are very much like street numbers (or even better apartment numbers). Fun fact: in Italian the word for "door" and "port" are the same word.

Packets go out from one device which has an address and a port, to a destination address and a port.

The combination address and port identify a particular application on the sending or receiving end (the socket).

[George]

Not really sure if it falls under a topic but I really want to be able to understand Ruby. From what I can tell it a great and powerful language that is widely used in a lot of areas, but I haven't had the time to teach myself while having a basic understanding of the language I'd like to expand it by a lot.

[Conlin Durbin]

I learned Ruby by doing, which was a good way, but I had some great people to ask questions to. You might check out Upcase by Thoughtbot. They used to charge for the service, but all lessons are free now! They have a lot of a good RoR stuff, but if you are just starting out it might be a bit above your understand currently. Definitely recommend them when you feel comfortable with Ruby though!

[rhymes]

I would start with the small poignant guide to Ruby: poignant.guide/book/chapter-1.html

:-)

[Sdu]

Derek Banas has a playlist on YouTube about design patterns. Its in java but the concept is the same with most languages. It greatly helped me through some coursework. Best thing is, you could just watch and not practice along and you'd grasp it like that

[Basti Ortiz]

Just to briefly answer two of the design patterns you mentioned:

• Simply put, the Factory Design Pattern involves a method that returns an object based on the arguments given to it. It's basically an encapsulated way of instantiating objects. As a consequence of returning an object when invoking the factory, the new keyword is not needed to instantiate objects because the factory internally does that for you.
• The Singleton Design Pattern is a way to make sure that classes are only instantiated once throughout the program. When attempting to instantiate a singleton, it either returns a new class instance (if it does not exist already) or returns the already instantiated singleton. This is not to be confused with static class properties.

[Simon Bengtsson]

Good object oriented architecture. Countless articles and discussions later I still struggle finding ways to put togethee classes without overusing singletons etc

[rhymes]

Maybe your brain was made for functional programming :)

I remember that one of the inventors of OOP regretted the name, and said that he should have called it "object message passing" or something like that.

OOP at its core is that, sending messages to objects so they can perform actions on their state.

Inheritance is a way for a family of objects to share some of that behavior (and/or some of that state). There's not a single way to implement inheritance of behavior/state.

Encapsulation is a way to hide away some of that state from prying eyes. Not all languages effectively have encapsulation.

I would say the tenent of OOP is really what the author said: sending messages to objects so that they can act.