4 ms·
Speaking as a dev who started with Java 1.2, I actually much prefer to write code that doesn’t rely on magic unseen effects. The only exception to this is depe
by AlEinstein 7y ago
Speaking as a dev who started with Java 1.2, I actually much prefer to write code that doesn’t rely on magic unseen effects.
The only exception to this is dependency injection via annotations but for god’s sake use it in moderation.
But then I still prefer to write for loops rather than streams because I know what the jit compiler is doing.
- raverbashing 7y agoUnless you're writing assembly or maybe C then "magic" is happening
- saagarjha 7y agoAssembly and C have plenty of magic to go around, don't worry.
- earenndil 7y agoC yes, assembly--where? Its mapping to machine code is relatively straightforward, and as is the mapping from machine code to ELF. Or do you mean all the magic the CPU does to make it go fast?
- saagarjha 7y agoYes, along with complications that arise as you interact with your OS and other programs.
- kryptiskt 7y agoIt's black magic that summons spectres.
- EmpirePhoenix 7y agoYeah, in the best case. In the worst case it is more like this: https://news.ycombinator.com/item?id=5261598 https://news.ycombinator.com/item?id=5261598 which is pretty magic.
- jacques_chester 7y agoAssembler code used to be a close mapping of what the CPU does. But it too is now a high-level language with a funny syntax, it's just that the complexity is hidden by the CPU frontend instead of by a language compiler.
- todd8 7y agoWell, it’s turtles all the way down. [1] Even the assembly language programmer is running on top of the OS. The OS is deep magic: runtime interrupts happening to make the floating point hardware handle certain edge cases correctly. Fork system calls that semantically provide a copy of the parent’s address space in almost no time by using virtual memory tricks (copy on write pages). Virtual memory itself. The OS lets the user space assembly language programmer touch some of the hardware directly, but not all of it. [1] https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down
- nosianu 7y agoYou are just rearranging electrons and holes anyway, and nobody understands what's happening on the quantum level of billions of tiny structure elements in silicon (plus "stuff"). When I program I always envision something like a gigantic planet sized steam punk engine, and wonder about the equally gigantic apparent disconnect between my code and what is actually happening. I'm moving matter around on an incredibly tiny scale, along unseen paths, rearranging it in different patterns, billions of times per second in the middle (CPU), collecting some in pools to which I occasionally refer (memory). It also helps me to remind myself that I'm not doing something abstract, that every thing I do has a cost and takes energy. The more stuff (matter) I have to move around, the more costly. And whether I engage a giant sub-machine for a given task or manage to build a small one that achieves the same matters. Yes, plenty of magic. And then I look at biological systems, not even the brain yet, just biochemical pathways. Also lots of structure, mixed in with lots of... mixing, and lots of molecules mix and sometimes match. The whole thing is much slower than man-made electronics - but many orders of magnitude more parallel. And probabilistic. And I wonder how to go from programming the man-made stuff to describing those machines in a similar way. Right now we are only tinkering at the far edges of it. Whenever somebody posts about a revolutionary new programming languages I think to myself, you are still just working with the exact same machine. It's like when you zoom in to a flat surface, that under a microscope looks ragged. The only reason we see a huge difference between various programming languages is because we are waaayyyyy zoomed into one paradigm. In a biological system the elements doing the work are many different molecules with distinct shapes. In CPUs there only are shapeless electrons, so unlike the molecules which meet and match all the time based on probabilities the electrons don't actively contribute to the computing themselves. Also, the molecules are almost all active, all the time, in computers our "code" lies dormant and waiting in pools (memory) doing nothing most of the time. In comparison, only an incredibly tiny fraction of our human-made computing elements are actually doing something at any point! In nature/biology shape and structure on the nano level are the major design factor. Shapes of molecules and shapes of the structures used to separate or guide or hold them. Most of the process is determined by those shapes. In human-made computing we are extremely limited in what shapes we use under the hood. We use higher frequencies and limiting ourselves to few goals, otherwise nature would outcompute us by many orders of magnitude (and that's only true because we decide to ignore most of the computation going on in biological systems as not relevant "it's just random noise with no purpose"). I see a disconnect between how we program and what is going on. We think it's a vital "abstraction". I think that abstraction is a blessing, sure, but also a great hindrance. In the end those shapes and structures matter a lot. If somehow we could get a translation into more and more flexible (nano) shapes/structures than now, where we have a 100% fixed structure and only electrons (so, no shapes)... even biological systems are actually quite limited in what kinds of shapes they use, there was a path-dependency on which random path evolution took. I think it would be possible to far exceed biological systems, but we would have to get down to the shapes (molecules and nano-structures). That is far away from now, where it takes us years to come up with one fixed structure and shapeless moving point-forms inside of it.
- jacques_chester 7y ago> The only exception to this is dependency injection via annotations but for god’s sake use it in moderation. Dependency injection comes in two varieties: constructor injection and future pain injection. Choose wisely.