Baby talk for computers (It's all key: value pairs)

HTML is in disguise

Most people looking to get into 'coding' or whatever they think this "tech" industry is... inevitably take some terrible online course or tutorial where they memorize some 'tags' and learn "how to write HTML."

There's an opening tag and a closing one... ok... I get it... I learned HTML - now what should I learn?

Unfortunately - this is really terrible for everyone. Not only does it stifle the "content strategy" conversation - it also sets them up to think of HTML, CSS, and JS as 'different' - when they are really all the same. These three things end up splitting into 3 wildly distorted mental models. It's really hard to rehabilitate these people.

We're just describing things to a very simple machine - in the best way we know how

We don't consciously think about it that much (from what we've heard from students and all the humans who aren't brain scientists) - but our brains are just taking in information / sights, sounds, smells - and collecting patterns and stuff - at a rate which literally blows our mind - stack overflow - and... (well, we just don't understand it).

If we stop and really really force ourselves to think about it - we can make that crazy magic mess form something simple - kinda like this:

My name is Ivy. I'm not telling you my age. I currently have no cats, but I want one, I am currently 'alive' (I think), and I'm unsure when that will stop being a thing...

So - as "smart" and creative the people who thought up the computery stuff were/are --- in the end / they are trying to emulate our brains - but since hardware isn't sentient / we have to describe EVERYTHING to it.

We end up creating various forms of baby talk to try to get some shared concepts between human and machine. Why? So that we can have a conversation. (we want to instruct it to do stuff we can't do... (like memorize crazy numbers and do calculations and stuff - but really - almost always - just steal personal data and use it to extort people and destroy the economy so we can get rich enough to survive the end of civilization) (to dark?)

FOCUS!

Pseudo code (just pretend code)

Concept (start)
  key: value
  name: Ivy
  age: older than you think
  alive: true
  cats: 0
  death date: unknown
(end)

This is just an attempt to write out those things I said above in the blockquote... but - we can look at some real languages

I'll start with CSS. It's really just a strong 'suggestion' of how you'd like things to behave visually - but it's a "description"

CSS

Describe how you want it presented visually (a "rule")

.ivy {
  key: value;
  color: wheat;
  height: 64in;
}

Ruby

Describe this 'concept' (a "hash")

ivy = {
  :key => "value",
  :name => "Ivy",
  :cats => 0
}

(you can also write this in a few ways / see next example)

JavaScript

Describe this 'concept' (an "Object")

var ivy = {
  key: value,
  name: "Ivy",
  cats: 0,
};

PHP

Describe this 'concept' (an "Associative Array")

$ivy = array(
  "key" => "value",
  "name" => "Ivy",
  "cats" => 0
);

Python

Describe this 'concept' (a "dictionary")

ivy = {
  "key": "value",
  "name": "Ivy",
  "cats": 0
}

HTML

Describe this content (an element / or "document")

<h1 class='page-title' id='top-anchor' rel='someJsThing'>Welcome to the page!</h1>

Oh... uh... - this is just some HTML... (that annoying thing I have to do so I can install a bunch of node packages and get to fixing all the "bugs"(just bad code) I'm about to write)

HTML (another look)

<h1
  key='value'
  class='page-title'
  id='top-anchor'
  rel='someJsThing'>
    Welcome to the page!
</h1>

Wait a second here... this ALSO looks like key:value pairs...

DOM (pretend syntax) (Document Object Model)

The browser is going to build it's own representation of the document from that HTML file

- THISNODE
  - key: value
  - element: h1
  - textContent: "Welcome to the page!"
  - classList: ['page-title'],
  - id: "top-anchor"
  - rel: "someJsThing"

In theory - the DOM can be presented differently - but for our purpose / you can just think of it as a JavaScript object. HTML - "looks" different... because the way we "mark" the start and ending of each bit of content - but we're just "describing" the content...

{ // start
    // description of the concept
    key: value // pairs
} // end

You have to define the boundaries of a 'concept' or it'll leak all over the kitchen floor.

they are all the same -

So, instead of memorizing syntax - think about WHAT you want to do. Think about WHY! Are you sure that a 'calculator' is the right thing to build? Then you can think about what you need to describe.

Before writing ANY code: We recommend that you read: "The Elements of User Experience" and "Don't make me think." Then, when it's time to learn programming: grab "Exercises for Programmers." Here's a video explaining why.

Sure - there are 'functions' - but those are just lists of actions - that describe a larger action. Sure, there are events - but those are just descriptions of what to pay attention to - and what to do in different scenarios.

By becoming a "Designer" - instead of a coder, you can learn to think about your goals and you ideas as the design process - and the code as a bag of tools to help you get to your goal. You just need to describe it all - to the computer... which is definitely tricky! (but also fun and it pays well!)

It's all baby talk. It's not magic! and that is OK!

Now, lets use this stuff to make the world better - instead of drive us insane.

Comments

[Eric Haynes]

Some babies are jerks, though...

import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.annotation.JsonPropertyOrder;

import javax.validation.constraints.Min;
import javax.validation.constraints.NotEmpty;
import javax.validation.constraints.NotNull;
import java.util.Objects;

@JsonPropertyOrder({"key", "name", "cats"})
public class ThingDto<T> {
    @NotNull()
    @JsonProperty()
    private T key;

    @NotNull()
    @NotEmpty()
    @JsonProperty()
    private String name;

    @NotNull()
    @Min(0)
    @JsonProperty()
    private int cats;

    public T getKey() {
        return key;
    }

    public void setKey(T key) {
        this.key = key;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getCats() {
        return cats;
    }

    public void setCats(int cats) {
        this.cats = cats;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        ThingDto<?> thingDto = (ThingDto<?>) o;
        return cats == thingDto.cats && Objects.equals(key, thingDto.key) && Objects.equals(name, thingDto.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(key, name, cats);
    }
}

ThingDto ivy = new ThingDto<String>();
ivy.setKey("value");
ivy.setName("Ivy");
ivy.setCats(0);

[Drew Bragg]

Don't forget Ruby hash.

ivy = {
  key: "value",
  name: "Ivy",
  cats: 0
}

The old way used => instead of : but same basic concept.

[perpetual . education]

Had to draw the line somewhere! : ) - but yeah / "hash" is a good one. When we started using Ember everyone was calling everything a hash / probably because they were from rails backgrounds - and we were like... isn't that an Object? haha. "Dictionary" seems like a pretty good word... but there's probably a better name for this 'concept.'

[Shannon🦖]

Thanks for sharing! I'm for sure one of those that fall into the class of "I'm in tech, I should learn HTML". This was such a useful explanation of the languages for a real newbie like me! Thank you!

[perpetual . education]

We hate to say it's "simple" - but it's manageable... and that's really important to stay comfortable with! There is good reason to be confident. : )