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

Burn the Programmer

antipope.org

Post reply on HN
Print view View original

221–230 of 254 posts

Re: Burn the Programmer

#221

Post by ignoramous »

flor1s wrote: post #218
3pt14159 wrote: post #194

Earlier quoted context omitted.

Someone whose name I no longer remember was a teacher of mine in highschool. Even though I knew how to program and had a nights / summers / weekends job programming I treated the CPU / motherboard as "magic". As if there was this dividing wall between the pure mathematical construct of a software program and the physicality of the bits moving through the motherboard. The teacher taught us how to use NPN and PNP trans…

I used to think the same way about the CPU, even after getting a masters in Computer Science! About a year ago I read the book Code by Charles Petzold and watched some lectures about Computer Science by Robert Sedgewick which really opened up my mind.

Are those lectures in the public domain? If so, could you pls link to them? Thx.

Re: Burn the Programmer

#222

Post by [deleted] »

everyone wrote: post #21
marsrover wrote: post #3

You know, us programmers like to refer to ourselves as wizards but I really wonder if non-programmers think the same or is it just like any other profession they're not knowledgeable of? I don't know anything about chemical engineering but I've never considered chemical engineers to be magical. I do like thinking of myself as a wizard, though.

I felt that wizard thing when I was just starting out, for most of my career though, i've thought an apt analogy is tradesman. eg. carpenter or metalworker. We get commissioned to build something that does X. Then we design and build it. With experience we develop our own tools / practices and a familiarity with our materials. Experienced masters might experiment and develop completely novel things or masterworks. So…

[deleted]

Re: Burn the Programmer

#223

Post by jimbokun »

sanderjd wrote: post #126
jimbokun wrote: post #52

Earlier quoted context omitted.

This is exactly the reason I despise Spring with a deep and abiding passion. "Just add this dependency, and add these annotations to your class, and it will all Just Work." "But...what do those annotations actually do ?" "Stop asking so many questions!" I mean, I know the answers are out there, it's open source after all. But so much of it seems deliberately designed to obfuscate the flow of execution and make reason…

I agree with annotations like this making it harder to reason about control flow, but I don't really get the consternation about "what do these annotations do?" so much. You can go read their documentation or source yourself to answer that question. How is that different than anything else? Same thing with "rails magic": yes, it sucks that you can't grep for method definitions, but you can go peruse the has_many meth…

"I agree with annotations like this making it harder to reason about control flow"

That is precisely my consternation. Much, much easier to reason about abstractions in the core Java language, like methods and objects, then to discover what code is being injected by an annotation. Java has outstanding IDEs that excel at navigating, analyzing, and debugging Java code, but putting so much logic in annotations is almost like you are trying to deliberately keep much of the code secret from the IDE.

Re: Burn the Programmer

#224

Post by jimbokun »

Jach wrote: post #138
jimbokun wrote: post #52

Earlier quoted context omitted.

This is exactly the reason I despise Spring with a deep and abiding passion. "Just add this dependency, and add these annotations to your class, and it will all Just Work." "But...what do those annotations actually do ?" "Stop asking so many questions!" I mean, I know the answers are out there, it's open source after all. But so much of it seems deliberately designed to obfuscate the flow of execution and make reason…

When I'm really disturbed by how something actually works, my approach is to try to implement something similar myself. Object oriented C (structs with function pointers) long ago gave me some insights including why Python has an explicit 'self' for everything. There's a similar exercise you can do in C to better understand the prototype chaining way of doing OOP. Have you tried to make a simple version of e.g. @Auto…

"without explicit injection?"

In many, many applications explicit injection works just fine and is exactly what you want. But once you say "I am going to write a Spring Boot application", you are pretty much stuck with a big part of your application logic stuck in annotations, even when there is very little benefit over explicit code.

Re: Burn the Programmer

#225

Post by jimbokun »

le-mark wrote: post #182
jimbokun wrote: post #52

Earlier quoted context omitted.

This is exactly the reason I despise Spring with a deep and abiding passion. "Just add this dependency, and add these annotations to your class, and it will all Just Work." "But...what do those annotations actually do ?" "Stop asking so many questions!" I mean, I know the answers are out there, it's open source after all. But so much of it seems deliberately designed to obfuscate the flow of execution and make reason…

This is exactly the reason I despise Spring with a deep and abiding passion. It's interesting you took the time to post this. As the sibling to this comment indicate, there's a lot of 'magic' in many languages and frameworks. not just Spring. You don't off an example of a tech stack you do favor so one can only guess. I will say that when I have encountered developers and teams who also disdain otherwise popular fram…

"You don't off an example of a tech stack you do favor so one can only guess."

I think annotations are used many times in Java where abstractions like first class functions would be used in other languages.

I also find Lisp macros easier to reason about. "This compile time source code expands to this run time source code, which executes like so."

Perhaps surprisingly, I even find Ruby magic easier to reason about. "This method causes these three other methods to be defined to do x, y, z." It can get confusing, and final behavior highly dependent on the order in which the code executes, but I still feel like I have a mental model of how everything executes.

With annotations, depends on the code processing the annotations. You could have different code doing different thing with the exact same annotations. Your IDE can take you to the annotation declaration, but not directly to the code the annotation causes to execute. In the debugger, you can see the code in the call stack that was generated, but no link back to what annotation caused it to be generated.

It all just feels more like memorizing spells at Hogwarts, and less like an engineering process.

Re: Burn the Programmer

#226

Post by sanderjd »

jimbokun wrote: post #223
sanderjd wrote: post #126

Earlier quoted context omitted.

I agree with annotations like this making it harder to reason about control flow, but I don't really get the consternation about "what do these annotations do?" so much. You can go read their documentation or source yourself to answer that question. How is that different than anything else? Same thing with "rails magic": yes, it sucks that you can't grep for method definitions, but you can go peruse the has_many meth…

"I agree with annotations like this making it harder to reason about control flow" That is precisely my consternation. Much, much easier to reason about abstractions in the core Java language, like methods and objects, then to discover what code is being injected by an annotation. Java has outstanding IDEs that excel at navigating, analyzing, and debugging Java code, but putting so much logic in annotations is almost…

Yeah. In principle, IDEs could show you what an annotation is doing, but at least in my experience that aren't particularly good at this.

Re: Burn the Programmer

#227

Post by kbenson »

ronald_raygun wrote: post #212
3pt14159 wrote: post #194

Earlier quoted context omitted.

Someone whose name I no longer remember was a teacher of mine in highschool. Even though I knew how to program and had a nights / summers / weekends job programming I treated the CPU / motherboard as "magic". As if there was this dividing wall between the pure mathematical construct of a software program and the physicality of the bits moving through the motherboard. The teacher taught us how to use NPN and PNP trans…

I had a very similar experience when I took a processor design class in college. At first in the class we started learning the binary codes for each instruction, which bits were the registers, instruction bits etc. It seemed so pointless at the time. When we finally got to the end and it clicked that those bits were physically turning on and off gates, it blew my mind.

In my class, circa 2001, we were taught about an adder, then used cheap chips in a breadboard with wires and bulbs to show it, then used Logicworks to create a simple version in software. Rinse and repeat for other components, and the final project was to copy and paste those components into a larger logicworks project and hook them up together into a simple 4 bit CPU with a few dozen bytes of RAM. It could understand four instructions if I recall correctly, so very simple programs could run from that RAM.

I don't really remember how to do any of it anymore (but I have no doubt I could research it without much trouble) but it certainly was a good way to demystify a CPU, given you had fully simulated one at the gate level by the end.

Re: Burn the Programmer

#228

Post by kemonocode »

I think it's less of an issue of programmers in general in danger of being seen as witches and more of a certain breed of programmer. You know the type. Not even the obviously "bad guys" and "hackers" induce that much of a visceral reaction.

The sort of kid so detached from their community that yes, they might as well live in a haughty ivory tower with a handful of their peers and bring their arcane gizmos wherever they go and look down upon muggles in disdain. Those are I'm worried about giving the rest of us spellweavers a bad rap.

Re: Burn the Programmer

#229

Post by tedeh »

3pt14159 wrote: post #194
japhyr wrote: post #174

I teach high school math and science, and I fully recognize that most of my students will not end up in math and science-focused careers. So I think pretty carefully about my goals for these students. One clear purpose in everything I ask students to do: take away the sense of "magic" in technological things. I just finished teaching a math class, where the final project was a 3d modeling exercise. Students didn't al…

Someone whose name I no longer remember was a teacher of mine in highschool. Even though I knew how to program and had a nights / summers / weekends job programming I treated the CPU / motherboard as "magic". As if there was this dividing wall between the pure mathematical construct of a software program and the physicality of the bits moving through the motherboard. The teacher taught us how to use NPN and PNP trans…

I'm going to have to chime in for the book/course Nand2Tetris - Building a Modern Computer from First Principles (http://nand2tetris.org/) which has been posted back and forth here on HN for quite a few years and is of course where I discovered it as well.

It was really eye opening to me (being a web programmer) to see how you can actually build a real computer with a C-like programming language and compiler just by starting out with simple logic gates. I mean, the damn thing eventually ends up running Tetris! All by essentially combining logic gates for computation and flip-flops for memory. How amazing is that, really?

Re: Burn the Programmer

#230

Post by shostack »

flor1s wrote: post #218
3pt14159 wrote: post #194

Earlier quoted context omitted.

Someone whose name I no longer remember was a teacher of mine in highschool. Even though I knew how to program and had a nights / summers / weekends job programming I treated the CPU / motherboard as "magic". As if there was this dividing wall between the pure mathematical construct of a software program and the physicality of the bits moving through the motherboard. The teacher taught us how to use NPN and PNP trans…

I used to think the same way about the CPU, even after getting a masters in Computer Science! About a year ago I read the book Code by Charles Petzold and watched some lectures about Computer Science by Robert Sedgewick which really opened up my mind.

I am partway through Code (can't seem to get through some of the heavy combinatorial math just by reading...it's somewhat of a slog), but it oddly enough made me think of coding as even more magical.

We harness mana (electricity) to run it through circuits (runes), and craft spells (code) that generate effects (magic).

Just reading the start of it is humbling because it makes you realize that people had to come up with these principles in the first place, and figure out the initial abstraction layers that let everything else click into place.

Post reply on HN