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

I Don't Like Magic

adactio.com

Post reply on HN
Print view View original

21–30 of 138 posts

Re: I Don't Like Magic

#21

Post by coldtea »

sodapopcan wrote: post #14
vladms wrote: post #11

The advantage of frameworks is to have a "common language" to achieve some goals together with a team. A good framework hides some of the stupid mistakes you would do when you would try to develop that "language" from scratch. When you do a project from scratch, if you work enough on it, you end up wishing you would have started differently and you refactor pieces of it. While using a framework I sometimes have momen…

The problem with this is that it means you have to read guides which it seems no one wants to do. It drives me nuts. But ya, I hate when people say they don't like "magic." It's not magic, it's programming.

Most however are surely capable of understanding a simple metaphor, in which "magic" in the context of coding means "behavior occuring implicitly/as a black box".

Yes, it's not magic as in Merlin or Penn and Teller. But it is magic in the aforementioned sense, which is also what people complain about.

Re: I Don't Like Magic

#22

Post by WJW »

sodapopcan wrote: post #14
vladms wrote: post #11

The advantage of frameworks is to have a "common language" to achieve some goals together with a team. A good framework hides some of the stupid mistakes you would do when you would try to develop that "language" from scratch. When you do a project from scratch, if you work enough on it, you end up wishing you would have started differently and you refactor pieces of it. While using a framework I sometimes have momen…

The problem with this is that it means you have to read guides which it seems no one wants to do. It drives me nuts. But ya, I hate when people say they don't like "magic." It's not magic, it's programming.

Oh no! Reading!

Sorry for the snark but why is this such a problem?

Re: I Don't Like Magic

#24

Post by sixtyj »

james_marks wrote: post #19
tokenless wrote: post #8

The AI pilled view is coding is knitting and AI is an automated loom. But it is not quite the case. The hand coded solution may be quicker than AI at reaching the business goal. If there is an elegant crafted solution that stays in prod 10 years and just works it is better than an initially quicker AI coded solution that needs more maintenance and demands a team to maintain it. If AI (and especially bad operators of…

Doesn’t the loom metaphor still hold? A badly operated loom will create bad fabric the same way badly used AI will make unsafe, unscalable programs. Anything that can be automated can be automated poorly, but we accept that trained operators can use looms effectively.

Loom is a good metaphor.

Re: I Don't Like Magic

#25

Post by farley13 »

pdonis wrote: post #13
xantronix wrote: post #2

Predicated upon the definition of "magic" provided in the article: What is it, if anything, about magic that draws people to it? Is there a process wherein people build tolerance and acceptance to opaque abstractions through learning? Or, is it acceptance that "this is the way things are done", upheld by cargo cult development, tutorials, examples, and the like, for the sake of commercial expediency? I can certainly…

> What is it, if anything, about magic that draws people to it? Simple: if it's magic, you don't have to do the hard work of understanding how it works in order to use it. Just use the right incantation and you're done. Sounds great as long as you don't think about the fact that not understanding how it works is actually a bug, not a feature.

I know magic has a nice Arthur C. Clarke ring to it, but I think arguing about magic obscures the actual argument.

It's about layers of abstraction, the need to understand them, modify them, know what is leaking etc.

I think people sometimes substitute magic when they mean "I suddenly need to learn a lower layer I assumed was much less complex ". I don't think anyone is calling the linux kernal magic. Everyone assumes it's complex.

Another use of "magic" is when you find yourself debugging a lower layer because the abstraction breaks in some way. If it's highly abstracted and the inner loop gives you few starting points ( while (???) pickupWorkFromAnyWhere() )). It can feel kafkaesque.

I sleep just fine not knowing how much software I use exactly works. It's the layers closest to application code that I wish were more friendly to the casual debugger.

Re: I Don't Like Magic

#26

Post by kens »

noelwelsh wrote: post #7

If you have this attitude I hope you write everything in assembly. Except assembly is compiled into micro-ops, so hopefully you avoid that by using an 8080 (according to a quick search, the last Intel CPU to not have micro-ops.) In other words, why is one particular abstraction (e.g. Javscript, or the web browser) ok, but another abstraction (e.g. React) not? This attitude doesn't make sense to me.

Did someone ask about Intel processor history? :-) The Intel 8080 (1974) didn't use microcode, but there were many later processors that didn't use microcode either. For instance, the 8085 (1976). Intel's microcontrollers, such as the 8051 (1980), didn't use microcode either. The RISC i860 (1989) didn't use microcode (I assume). The completely unrelated i960 (1988) didn't use microcode in the base version, but the floating-point version used microcode for the math, and the bonkers MX version used microcode to implement objects, capabilities, and garbage collection. The RISC StrongARM (1997) presumably didn't use microcode.

As far as x86, the 8086 (1978) through the Pentium (1993) used microcode. The Pentium Pro (1995) introduced an out-of-order, speculative architecture with micro-ops instead of microcode. Micro-ops are kind of like microcode, but different. With microcode, the CPU executes an instruction by sequentially running a microcode routine, made up of strange micro-instructions. With micro-ops, an instruction is broken up into "RISC-like" micro-ops, which are tossed into the out-of-order engine, which runs the micro-ops in whatever order it wants, sorting things out at the end so you get the right answer. Thus, micro-ops provide a whole new layer of abstraction, since you don't know what the processor is doing.

My personal view is that if you're running C code on a non-superscalar processor, the abstractions are fairly transparent; the CPU is doing what you tell it to. But once you get to C++ or a processor with speculative execution, one loses sight of what's really going on under the abstractions.

Re: I Don't Like Magic

#27

Post by wvenable »

pdonis wrote: post #13
xantronix wrote: post #2

Predicated upon the definition of "magic" provided in the article: What is it, if anything, about magic that draws people to it? Is there a process wherein people build tolerance and acceptance to opaque abstractions through learning? Or, is it acceptance that "this is the way things are done", upheld by cargo cult development, tutorials, examples, and the like, for the sake of commercial expediency? I can certainly…

> What is it, if anything, about magic that draws people to it? Simple: if it's magic, you don't have to do the hard work of understanding how it works in order to use it. Just use the right incantation and you're done. Sounds great as long as you don't think about the fact that not understanding how it works is actually a bug, not a feature.

> Sounds great as long as you don't think about the fact that not understanding how it works is actually a bug, not a feature.

That's such a wrong way of thinking. There is simply a limit on how much a single person can know and understand. You have to specialize otherwise you won't make any progress. Not having to understand how everything works is a feature, not a bug.

You not having to know the chemical structure of gasoline in order to drive to work in the morning is a good thing.

Re: I Don't Like Magic

#28

Post by AlotOfReading »

wa008 wrote: post #4

What I cannot build. I do not understand

I'm not sure this is a useful way to approach "magic". I don't think I can build a production compiler or linker. It's fair to say that I don't fully understand them either. Yet, I don't need a "full" understanding to do useful things with them and contribute back upstream.

LLMs are vastly more complicated and unlike compilers we didn't get a long, slow ramp-up in complexity, but it seems possible we'll eventually develop better intuition and rules of thumb to separate appropriate usage from inappropriate.

Re: I Don't Like Magic

#29

Post by satvikpendem »

piekvorst wrote: post #9
noelwelsh wrote: post #7

If you have this attitude I hope you write everything in assembly. Except assembly is compiled into micro-ops, so hopefully you avoid that by using an 8080 (according to a quick search, the last Intel CPU to not have micro-ops.) In other words, why is one particular abstraction (e.g. Javscript, or the web browser) ok, but another abstraction (e.g. React) not? This attitude doesn't make sense to me.

You can learn JavaScript and code for life. You can’t learn React and code for life. Yeah, JavaScript is an illusion (to be exact, a concept). But it’s the one that we accept as fundamental. People need fundamentals to rely upon.

> You can’t learn React and code for life.

Sure you can, why can't you? Even if it's deprecated in 20 years, you can still run it and use it, fork it even to expand upon it, because it's still JS at the end of the day, which based on your earlier statement you can code for life with.

Re: I Don't Like Magic

#30

Post by hyperhopper »

This person's distinction between "library" and "framework" is frankly insane.

React, which just is functions to make DOM trees and render them is a framework? There is a reason there are hundreds of actual frameworks that exist to make structure about using these functions.

At this point, he should stop using any high level language! Java/python are just a big frameworks calling his bytecode, what magical frameworks!

Post reply on HN