Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Hard Things Easy

jvns.ca

Post reply on HN
Print view View original

181–190 of 202 posts

Re: Making Hard Things Easy

#181

Post by JacobSeated »

Thanks for this. It is similar to how I feel these days; I am currently learning vue.js, and working on 3 different components at the same time (I should probably have focused on a single component, but the boss kept finding things that needed improvements).

I also never worked with vue before. At one point I found myself utterly confused; opening up a file to do something, and instantly forgetting what I was doing, having to go back and re-read code. I was super tired after an near all-nighter at this point, but felt like I had sleep deprived induced dementia or something. In occasional brief moments, I was totally unable to focus or remember what I was doing. Very interesting feeling actually.

When you have not worked with something before, and you are on a deadline, it is just a pretty awful experience. Vue, however, is supposed to be simple and make things easier for the developer. Well, not if you come from a back-end PHP background, with only moderate JavaScript experience, and there is literally no documentation on how things work in the CMS I am currently working with. Have to read existing code and try to replicate things. It is nasty beyond nasty!

Re: Making Hard Things Easy

#182

Post by grumblingdev »

corobo wrote: post #136
grumblingdev wrote: post #125

Earlier quoted context omitted.

We should stop using Bash, and use TypeScript instead. Bash is terrible.

well this shell is just broken > ls -al .ts:4:1 - error TS2304: Cannot find name 'ls'. 4 ls -al ~~ .ts:4:5 - error TS2304: Cannot find name 'al'. 4 ls -al ~~

Easy...

    $`ls -al`
or

    ls('al')
And, transpile shortcut strings on-the-fly to TS code:

    ls({
      all: true,
      oneEntryPerLine: true,
    })

Re: Making Hard Things Easy

#183

Post by yourapostasy »

vaughan wrote: post #122
justin_oaks wrote: post #83

The part that resonated most with me is "Show things that are normally hidden". Tools that do this make things clearer almost immediately. Consider the developer tools in a web browser. Do you remember the "dark ages" before such things existed? It was awful because you had to guess instead of seeing what was going on. Tools like Wireshark that show you every last byte of network packets that it has access to AND par…

My dream is to make everything visualizable at runtime. I think all of computing becomes very simple and much less complex if we can do this. We are visualizing things in our head already. And any explanation of anything in computing is a diagram. But we have zero diagrams when coding. Just dynamically instrument all code to send messages to a GUI.

>My dream is to make everything visualizable at runtime.

Check out demos of the old Lisp Machines, [1] is a brief overview demo, [2] links to a timestamp with a view of some simple diagramming, but I’ve seen TI-Symbolics beasts routinely display complex relationships in Lisp code on their massive (for the time) bitmapped screens. The limitation was the end user managing the visualization complexity.

With open source llvm, clang and similar making available abstract syntax trees and even semantic analysis and type checking results, LLM’s assisting with decompiling binary blobs, and modern hardware (goggles, graphics cards, and so on), I sometimes wonder how close we can come to reproducing that aspect of the Lisp Machine experience on open source operating systems.

[1] https://youtu.be/o4-YnLpLgtk

[2] https://youtu.be/jACcgLfyiyM?t=43m52s

Re: Making Hard Things Easy

#184

Post by vitus »

thelittleone wrote: post #179
AceJohnny2 wrote: post #147

Earlier quoted context omitted.

Are the Ethernet frame checksums even visible to Wireshark, which hooks into the IP layer? would some of the ethernet stuff be only visible within the ethernet card itself, not to the software stack?

Wireshark works at the data link layer (L2).

Well...

ethhdr only has 14 bytes: 6 for dest mac address, 6 for source mac address, 2 for ethertype (e.g. IPv4 vs IPv6).

Any bad checksums that Wireshark can detect are predominantly at the transport layer (L4; TCP / UDP).

You'd have to explicitly turn on FCS, which I don't know if you can even do on, say, Windows.

Re: Making Hard Things Easy

#185

Post by corysama »

karmakaze wrote: post #39
zvmaz wrote: post #16

Earlier quoted context omitted.

> The SQL part seems to double-down on a conceptual failure rather than demystifying it though. She talked about a mental model to help her understand the query (it can be useful), and mentioned that it probably is not how the database actually processes the query.

My point is that there should be two mental models. One for getting the correct results. Then another for doing so performantly. Being able to write many different forms of obtaining the same correct results is where this leads to combined understanding and proficiency. An example of where muddling these ends up with real questions like "how does the db know what the select terms are when those sources aren't even de…

You would like https://halide-lang.org/

Re: Making Hard Things Easy

#186

Post by anjanb »

zvmaz wrote: post #9
thwarted wrote: post #7

Earlier quoted context omitted.

I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection. The man pages are readily available. The bash man page is huge and hairy, but comprehensive, I've found it pretty valuable to be familiar with the major sections and the visual shape of the text in the man page so I can pag…

> The man pages are readily available. True, but I find the man pages not easy and quick to parse.

I've used a small bash function. example : to search grep's manual for "lines", I type gm grep "lines"

gm () { man $1 | col -b | grep --color=always "$2" }

I also have something similar for grepping a command's help

gh () { $1 --help | grep --color=always $2 }

I usually try gh(grep help) and if I don't get what I'm looking for, I run gm(grep man).

It appears that I can also use tldr

Re: Making Hard Things Easy

#187

Post by anjanb »

lazide wrote: post #106
imp0cat wrote: post #17

Earlier quoted context omitted.

Right. I don't think you're supposed to read them top-to-bottom. Use `/` and search for the things of interest (keywords, arguments, options, etc...). Use n/N to quickly jump forward/back.

Find has a particularly bad man page to find things that way.

you can grep the man page contents by using the following command

man | col -b | grep "search_string"

Re: Making Hard Things Easy

#188

Post by torginus »

jzwinck wrote: post #95
justin_oaks wrote: post #83

The part that resonated most with me is "Show things that are normally hidden". Tools that do this make things clearer almost immediately. Consider the developer tools in a web browser. Do you remember the "dark ages" before such things existed? It was awful because you had to guess instead of seeing what was going on. Tools like Wireshark that show you every last byte of network packets that it has access to AND par…

Wireshark is great but it does not show you every byte the network carried. For example it never shows Ethernet preambles, only sometimes shows Ethernet frame checksums, and never shows interpacket gaps (which are a required part of the Ethernet protocol). So yes it comes close but it just goes to show you, there is always more detail hiding somewhere!

My biggest problem with Wireshark is that it can't do anything with HTTPS traffic - which is most of the traffic I'd be interested in. I understand that's kind of the point of HTTPS, and a MITM proxy with cert replacement is somewhat out of the scope of Wireshark, it still limits the usefulness of the program.

Re: Making Hard Things Easy

#189

Post by derefr »

shellcheck is a great idea. But you know what’d be even better? Not having to write bash in the first place.

Julia is right: computers are great at remembering trivia. One of the best demonstrations of this, is compilers: they take in a high-level abstract program, and use a vast repertoire of knowledge about instruction sets, to transform the high-level abstract description of a program, into a program executable on a machine that’s much more awful to program for directly, with many more gotchas.

(Here’s where you say “Hey, wait a minute.”)

Why are we writing bash, when we could be writing programs in a higher-level language that compiles to bash? One with exceptions, at the very least.

(Yes, such a language would need a runtime that wraps every common binary and lifts its stdout + stderr + exit code -based semantics into safe, high level semantics. So what? That’s only 10000 “FFI bindings” or so for anything a normal person or sysadmin would want to call. For everything else, just ensure that writing your own FFI binding, inline to a script, is easy.)

Re: Making Hard Things Easy

#190

Post by Aerbil313 »

I do not agree that education is the way to make hard things easy. Make hard things easy is putting in more work and actually making hard things into easy things. I understand that maybe no one has the power to change things as big as DNS or HTTPS or Bash or Javascript now, but everyone can contribute to some little thing.
Post reply on HN