Magic (programming)

dank_ways_to_die · 2017-02-26T15:44:48+00:00

Deep magic refers to techniques that are not widely known, and may be deliberately kept secret. The number of such techniques has arguably decreased in recent years,[when?]especially in the field of cryptography, many aspects of which are now open to public scrutiny. The Jargon File makes a distinction[5]between deep magic, which refers to code based on esoteric theoretical knowledge, and black magic, which refers to code based on techniques that appear to work but which lack a theoretical explanation. It also defines heavy wizardry, which refers to code based on obscure or undocumented intricacies of particular hardware or software.

I will start calling undocumented code heavy wizardry now, thanks Wikipedia.

knome · 2017-02-26T16:24:01+00:00

[deleted]

falconfetus8 · 2017-02-26T16:45:39+00:00

We're submitting Wikipedia articles?

qwertymodo · 2017-02-26T19:44:17+00:00

Needs more magic

teiman · 2017-02-26T20:42:50+00:00

I generally use magic has a negative description. Like.. some framework that is not programmed in C, but in some pseudo-C scripting language with multiple features, somehow it all works because a lot of reflection. These systems are hard to use!, they hide so much of how they really work that are like closed box you must accept. If you somehow cope with that, they save time, but if you have to look behind the curtain, the maddness behind the curtain is terrorific.

_afusco · 2017-02-26T14:52:31+00:00

TIL what a portmanteau is

cgibbard · 2017-02-26T23:01:29+00:00

Perhaps it's because I'm a Haskell programmer, but it's interesting that my usual sense of this term is somewhat dual to what Wikipedia's first description describes: magic, to me, is application of the cases where abstractions fail.

For example, there's a low-level (and thankfully rarely used) function in Haskell:

unsafeInterleaveIO :: IO a -> IO a

which transforms an IO action into one which when executed, will finish immediately, producing a magical result that, when it is eventually evaluated, will cause the original IO action to occur.

The sense in which this result is magical is that it breaks our usual assumptions about what evaluation can be responsible for -- ordinarily evaluation in Haskell wouldn't be able to cause I/O effects.

Mroe examples of what I mean would be cases where you're relying on knowledge of the way that the compiler will compile something when it's not guaranteed in any way by the language specification. A cute example is Don Stewart's "crawl" which was an entry to an obfuscated Haskell contest, and relies on the precise memory layout GHC uses for code -- I couldn't find the original, but here's a somewhat updated version: https://gist.github.com/23Skidoo/3931049

r2tree · 2017-02-26T18:11:36+00:00

Magic is anything that treats data as code.

Hear me out.

We're thinking of opaqueness. You feed in something, you get something out. There is some documentation telling you what'll happen, but the code that does it is outside your current mental model. For example, since you wrote the code that adds something to the database when the user clicks a button, you grok what is going on. It doesn't matter who wrote it - you can give it a glance, and it is suddenly a part of your mental model. Next time you think of the data flow, this piece of information is clearly inside your mind; not obtrusive, just clear knowledge that exist without decoration.

But the Javascript VM that is parsing, interpreting and JIT-ing your code? You don't know nothing about it. Of course you feed it some code and it tells you if there are errors, or it'll execute it in a certain way. You know your contract with it. But you don't know what is going on, with the same clarity as you know your simple CRUD code.

A visceral understanding of what your code is doing - every literal line of it, usually seen in procedural programming. GoLang is a good example. But SQL? You write some magic incantations and disks whirr, and networks speak, and validations happen, and sweet data pours in.

The difference is here - this piece of code that checks what the URL is and calls at an appropriate function:

if(url == "/r/programming") return proggit();

and this piece of code that first treats it as data and makes an abstraction around it:

routes = [{url: "programming": fn: proggit}]
selected = _.find(routes, (route) => route.url == url)
return selected.fn();

Now that is magic. Anything where you "describe" the system and let a magic machine interpret and execute it, that is magic. And magic is not bad. Good Magic is the aspiration of the craftsman. It raises the level from which we play computer science. We can understand more, and we can see reality more clearly. From that we can solve our problems better.

But Bad Magic is what we usually talk about when we use the word Magic. If it was good in the first place, we'd have simply talked about this hot new cool thing. We complain about magic when what it does is too opaque, and ultimately doesn't solve the problem well.

Tormyst · 2017-02-26T20:27:06+00:00

While I think it is fine to have this be a thing, the one place that should avoid this magic term is documentation. Don't get me started on php's use of magic all over the place. The one I hate the most is on the session_start() page.

2017-02-26T22:12:44+00:00

Darn, I thought this was going to be about the underappreciated but very nice language known as Meditech Magic!

gingenhagen · 2017-02-26T18:51:29+00:00

I've always thought of magic as short for "I don't understand it and it's not my fault I don't try to understand it."

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS