Live data from Hacker News

Speak English to me: The secret world of programmers

github.com

211–220 of 334 posts

Re: Speak English to me: The secret world of programmers

#211
post #88

Earlier quoted context omitted.

There are three variants: #1. They are just stupid. #2. They don't care about work other than bare minimum to not get fired. They have better things in their life to care about. #3. They are as smart as you are, but they put their efforts elsewhere that you don't directly observe. May be they don't know how to operate Linux environment, but they spent days reading about DSP math and they can apply this knowledge to o…

You forgot one variant: they just don't like it. Like me. I use the command line all the day, compiling AOSP and kernels, and drivers, firmware, and all kind of related things for embedded. But I don't like it. To me, it feels archaic and counterintuitive (I'm autodidact). Same goes for command line editors or Vi, Vim, Emacs, etc. It's not 1985 anymore. Microsoft and Apple built an empire based on coherent (up to som…

I don’t think compiling kernels would really gain anything from being outside a terminal?

Ultimately it’s just an interface to programs that output mostly text. It took me a really long time to wrap my head around that. Programs that have a GUI and programs that run in the terminal use the same building blocks.

Re: Speak English to me: The secret world of programmers

#212

The problem is mainly one of discoverability. The non-programmer in the examples says "simple" when they mean "discoverable". The programmer says "simple" when they mean "not much code complexity". Of course you disagree. All the examples - installing and using a package manager, running a command line program - are "simple" from a software point of view, but they're not at all "discoverable". To understand the steps…

I feel like there's a fundamental understanding of man-pages that we are just missing. I find myself in the same boat quite often.

Re: Speak English to me: The secret world of programmers

#213

Earlier quoted context omitted.

> I'm frequently stumped by man pages, and end up having to hunt down an example of how to use a particular command line application on Stack Overflow. If you're not aware of tldr [0], I highly recommend it. [0] https://tldr.sh/

man(1) pages on linux are almost all terrible. Unworthy of inclusion in any manual. Proper manuals have examples of use. Many linux man pages don't even discuss (or list, even!) return codes or failure modes.

Some of the manpages for utillinux (e.g., chsh, useradd) are pretty barebones and don't include examples, but off the top of my head I can't think of a major GNU utility that doesn't have EXAMPLES sections in its manpages. GNU coreutils, find, sed, and grep all have such a section in their manuals.

What are you thinking of that is example-less?

Re: Speak English to me: The secret world of programmers

#214
post #114

Earlier quoted context omitted.

One thing I learned in my 41 years is that nobody thinks like me (or you). It's not that I 'think better' or that I am 'better at thinking'. But sometimes I deal with variables that I can't correctly communicate or translate. I often think that people deals with the same information as me, and will follow my same path of reasoning. Perhaps the dev thought it should be a tool that you will be using every day, or a thi…

Building the long-term solution first is often wrong even when you need one. I use the quick and dirty method until I know I'll do that task more regularly and I know enough about the problem so I don't need to make wild guesses about the design.

> I use the quick and dirty method until

I use it until I realize it’s not quick after all. Now I default to writing one off scripts.

Re: Speak English to me: The secret world of programmers

#215

    "Oh, you're a programmer, Can't you do $THING"
I always respond with "I don't really know how to do $THING. It's kind of like asking the piano tuner to play a sonata. They might be able to, but just because you can tune a piano doesn't mean you can perform a piece of music on the piano."

Re: Speak English to me: The secret world of programmers

#216
post #78

Literally everything I write is in Markdown because it’s so simple to me. I use it for blogposts, presentations, documentation, todos, internet comments. But this article doesn’t strike a chord with me. The author fails to understand that it seems easy to us because we’re familiar with it. Of course we know how to transform it into PDF or HTML. But this knowledge isn’t basic, and it’s understandable that people want…

> just pick up Excel Pandas are free; Excel is not.

LibreOffice is free

Re: Speak English to me: The secret world of programmers

#217
post #59

As for markdown I showed it to my girlfriend and this is now what she uses for everything. She is a designer and loves that here she does not have to bother with design, just with markup. She hates Microsoft Word with a passion. People who used formatting in any 2000s internet forum know in principle how to use markdown. That aside, I see it as a problem that tech people fail to anticipate the needs of their peers. I…

This isn't a programming problem, or exclusive to our field. Go talk to any expert in their field about something in that field, and have the same reaction.

I tried my hand at blacksmithing, and had to learn (what seemed like) a lot of metallurgy before half of what my mentors were saying made any sense at all.

Sometimes it's on the expert to make it clear to the non-expert. Other times it's on the newbie to learn the basics so they understand the answer to their question. .

Re: Speak English to me: The secret world of programmers

#218

As an intensely tech guy I completely despise the tendency that some engineers have to speak in ambigu-ese and tech-ese making less reacheable what the fr*eak they are talking about and establish themselves as "essential experts" when they could easily speak in normal-ese with minimal effort making concepts reachable for colleagues. BTW this can happen to any field, not just tech. It can happen with intellectuals, ph…

The AI also regularly misuses terms and gets things wrong

Not only that, it often lies, and does it in a "convincing" way.

Re: Speak English to me: The secret world of programmers

#219

Earlier quoted context omitted.

man(1) pages on linux are almost all terrible. Unworthy of inclusion in any manual. Proper manuals have examples of use. Many linux man pages don't even discuss (or list, even!) return codes or failure modes.

Gnu stuff tends to be properly documented in info, not man. But yeah, loads of stuff just isn't well documented.

Stallman's sad devotion to that ancient religion... ITS has been effectively dead for how many decades now, but by god we're gonna force everybody to use a port of their online documentation system if we can!

At least we're past the bad old days when you'd open a man page and it would just be a stub saying "look at the info docs, IDIOT"

Re: Speak English to me: The secret world of programmers

#220
post #211
post #88

Earlier quoted context omitted.

You forgot one variant: they just don't like it. Like me. I use the command line all the day, compiling AOSP and kernels, and drivers, firmware, and all kind of related things for embedded. But I don't like it. To me, it feels archaic and counterintuitive (I'm autodidact). Same goes for command line editors or Vi, Vim, Emacs, etc. It's not 1985 anymore. Microsoft and Apple built an empire based on coherent (up to som…

I don’t think compiling kernels would really gain anything from being outside a terminal? Ultimately it’s just an interface to programs that output mostly text. It took me a really long time to wrap my head around that. Programs that have a GUI and programs that run in the terminal use the same building blocks.

> I don’t think compiling kernels would really gain anything from being outside a terminal?

I remember compiling, flashing and debugging Windows CE images (10? maybe 15 years ago?) from an IDE (Visual Studio). It was super comfortable. Setting breakpoints, jumping to any kernel thread, navigating the call stack, watching memory and variables. All from the IDE. The development process was super fast.

Now between dmesg and logcat, I have to debug reading and grepping thousands of lines of log. Also adding printk, ALOG and all sort of logging functions to the code, recompiling, reflashing using a terminal with ADB, etc.

> Ultimately it’s just an interface to programs that output mostly text

For example, double-clicking on a compilation error and showing the error in an IDE is priceless. I know there should be some Vim plugin that does that, but it's out-of-the-box on every decent/modern coding IDE out there (VScode + ssh, which I use for AOSP, for example). Even better if the IDE shows only the errors/warnings the compiler emitted.

Also, try to find the error line between 10000's lines of building log when you compile a kernel/AOSP in parallel with -j20.

Post reply on HN