4 ms·

I've been having that exact thought for quite some time now. It seems that the art of programming - or at least, the practice of it, equivalent to "proficiency

I've been having that exact thought for quite some time now. It seems that the art of programming - or at least, the practice of it, equivalent to "proficiency" or "competency" - has shifted from fundamentals of the machine and the language's intrinsic semantics, which allowed you to actually create something anew, to spending 90-95% of the time trying to figure out someone else's API. In other words, the real skill now is reading reference material, and trying to figure out how to fashion a bunch of opaque, prebuilt Lego blocks together. It's just no fun that way, and it relies on very different mental faculties than the ones present in fundamentals-based programming. Writing low-level backend processes in C may have taken a lot more work for boilerplate and nontrivial data primitive/data structure support, but it was real creation - using the actual power of the language to get something done. Now it's all about figuring out how the SynchronousIOGoatSoapBubbleVectorManagerFactory interacts with the SynchronousIOGoatSoapBubbleVectorReflectorParserTransformer.

Retric 17y ago
There is still plenty of work to be done on impeded systems for sensors and other simple devices. Some of theses systems are powered by a watch battery for years, they might have more or less processing power than an apple II but far less ram which tends to limit code bloat. EX: A new 8 bit CPU from 2008: The triple clock enables the selection of the most suitable clock frequency from 32.768 kHz, 500 kHz, and 4 MHz according to the processing type, thus minimizing the operating current. These power-management functions help prolong battery life and reduce product size. ... RAM 2 KB (http://www.okisemi.com/en/866/869/000576.html http://www.okisemi.com/en/866/869/000576.html) And yes some people are really working on an 8 bit cpu at less than 40khz due to power limitations.
- rbanffy 17y ago
  Don't confuse powerful with power-hungry
  - Retric 17y ago
    It's just physics. For a given transistor, more transistors @ higher frequency = more power. At the ultra low end people are using processors that run using energy collected from stray radio waves. While a better design and instruction set help unlike desktop computing the standard is already lean.
    - rbanffy 17y ago
      Still, accounting for the vast differences in process, I think a full 45nm Apple II could run on stray radio waves
      - Retric 17y ago
        I don't know if anyone makes a 45 nm 8 bit cpu. Intel makes 8 bit chips, and has 45 nm and smaller fabs, but I don't the market is there yet. Still the original Apple II was 1Mhz, with 4kb of ram which is significantly faster and more powerful than many micro controllers in use today. For many solutions the power savings of sub 40khz speeds is still worth it so I don't think we are at the point where stray radio waves could power a system that fast.
mechanical_fish 17y ago
I know where you're coming from, but I wonder if this observation is just a classic language rant waiting to be born. In other words: I wonder if the problem is not that all higher-level APIs necessarily suck, but that the ones you have suck, and your language platform is too impoverished to profitably work around that. API design is hard. It's like composing poetry, or trying to design the game of chess. ("I know, the queen should be able to jump like a knight if she's on a white square!") It is bound to take thousands of little trials and errors in order to get things right. And my suspicion is that certain languages and platforms make it especially difficult to tinker with existing APIs, or wrap them while minimizing the leaks, or replace one part of them and leave the others alone, or build them in a way that makes it easy to compose complex higher-order objects and behaviors out of little pieces. When working with those systems, the most efficient way to solve any given problem is to just slog through, trying to make lemonade out of slightly-spoiled lemons by hand-sorting and hand-squeezing each lemon. And that can be effective -- at least it's more efficient than trying to use genetic engineering to construct a lemon out of raw amino acids -- but it's not always fun. There are high-level APIs that are a joy to use. I love jQuery, for example, which is a layer of Javascript atop more Javascript atop an absolutely scary C program atop Unix or Windows and yet somehow manages to feel lightweight and elegant and composeable. But for every elegant API there are dozens of clunky ones. The lovely thing about low-level C or assembly is that the building blocks tend to be simple, understandable, and composeable -- and, if they aren't, it's not so much work to rewrite them. (Though, as jgc points out, in modern times even assembly is hardly immune to complexity. The idiosyncrasies of modern processor architectures are so baroque that it takes years for optimizing compilers to be refined to take advantage of them.)
- jacquesm 17y ago
  jquery is a good example to use, I've only been into it for a couple of days now (after asking on HN what would be a good js library), and after a few days I already like what it does: It hides the mess! Most software is so absolutely messy. Just the other day there was an argument that it is perfectly ok to see the user interface that results from interpreting a spec'd document as an approximation. Computers are supposed to be deterministic, you're supposed to get exactly the results you want and not something 'good enough for government work'. Elegance breeds excellence, bloat breeds badness. Cellphones that crash (who would have ever accepted that), computers that need to be periodically reinstalled and APIs that have manuals 10 times the size of the operating system components they interface to. Complexity is a given, so, then we should strive to make the complex simple, instead of more complex.
asciilifeform 17y ago
Much of my blog is devoted to precisely this subject. (See for instance: http://www.loper-os.org/?p=16 http://www.loper-os.org/?p=16) I believe that the only solution to the complexity plague is a from-scratch reboot of all of computing.
- jacquesm 17y ago
  I share your belief. At the same time I think it is going to be like trying to replace the automobile piston engine with something better. The amount of money and time invested in the way we do things today is going to be a very large stumbling block to overcome in order to create a clean slate.
  - nazgulnarsil 17y ago
    rotary engines are pretty cool. http://www.youtube.com/watch?v=6BCgl2uumlI http://www.youtube.com/watch?v=6BCgl2uumlI each time each piston reverses direction you're losing energy in a standard piston engine.
    - jacquesm 17y ago
      For some reason my brain showed me the picture of a star piston engine when you said 'rotary', my bad :) We call those 'Wankel' engines here. Pretty cool stuff. Beautful animation by the way!
- limmeau 17y ago
  I believe the complexity comes inevitably with code reuse and abstraction. Once you've got your ethernet driver working, you discover that your routable point-to-point packet exchange is useful in many places, so you extract an IP component, and before long, you're writing web applications in a high-level framework in a dynamic programming language again.
tybris 17y ago
There will always be a gap between what's technologically interesting and what's economically interesting. Web applications stopped being technologically interesting a while back. I've seen everything from in-browser HD-video to AJAX-powered e-mail clients before 2001. After the major technical challenges had been solved the industry kicked in and started mass-producing. Today the mobile phone platform is sort of like the Web of 1999: a technological wild west. Fart Apps can still make you rich, while useful bluetooth apps hardly exist. If that's not adventurous enough for you, there's plenty more. I spend most of my time on vehicle robotics for automated roads (C) and divide the rest over Arduino/AVG programming (C) and VMM hacking (C/IA32). You can be sure you won't find any "rich APIs" there. Also there's no chance it will make you rich, you need to be in the proven areas for that. (unless...)

Retric 17y ago

There is still plenty of work to be done on impeded systems for sensors and other simple devices. Some of theses systems are powered by a watch battery for years, they might have more or less processing power than an apple II but far less ram which tends to limit code bloat. EX: A new 8 bit CPU from 2008: The triple clock enables the selection of the most suitable clock frequency from 32.768 kHz, 500 kHz, and 4 MHz according to the processing type, thus minimizing the operating current. These power-management functions help prolong battery life and reduce product size. ... RAM 2 KB (http://www.okisemi.com/en/866/869/000576.html http://www.okisemi.com/en/866/869/000576.html) And yes some people are really working on an 8 bit cpu at less than 40khz due to power limitations.

rbanffy 17y ago
Don't confuse powerful with power-hungry
- Retric 17y ago
  It's just physics. For a given transistor, more transistors @ higher frequency = more power. At the ultra low end people are using processors that run using energy collected from stray radio waves. While a better design and instruction set help unlike desktop computing the standard is already lean.
  - rbanffy 17y ago
    Still, accounting for the vast differences in process, I think a full 45nm Apple II could run on stray radio waves
    - Retric 17y ago
      I don't know if anyone makes a 45 nm 8 bit cpu. Intel makes 8 bit chips, and has 45 nm and smaller fabs, but I don't the market is there yet. Still the original Apple II was 1Mhz, with 4kb of ram which is significantly faster and more powerful than many micro controllers in use today. For many solutions the power savings of sub 40khz speeds is still worth it so I don't think we are at the point where stray radio waves could power a system that fast.

mechanical_fish 17y ago

I know where you're coming from, but I wonder if this observation is just a classic language rant waiting to be born. In other words: I wonder if the problem is not that all higher-level APIs necessarily suck, but that the ones you have suck, and your language platform is too impoverished to profitably work around that. API design is hard. It's like composing poetry, or trying to design the game of chess. ("I know, the queen should be able to jump like a knight if she's on a white square!") It is bound to take thousands of little trials and errors in order to get things right. And my suspicion is that certain languages and platforms make it especially difficult to tinker with existing APIs, or wrap them while minimizing the leaks, or replace one part of them and leave the others alone, or build them in a way that makes it easy to compose complex higher-order objects and behaviors out of little pieces. When working with those systems, the most efficient way to solve any given problem is to just slog through, trying to make lemonade out of slightly-spoiled lemons by hand-sorting and hand-squeezing each lemon. And that can be effective -- at least it's more efficient than trying to use genetic engineering to construct a lemon out of raw amino acids -- but it's not always fun. There are high-level APIs that are a joy to use. I love jQuery, for example, which is a layer of Javascript atop more Javascript atop an absolutely scary C program atop Unix or Windows and yet somehow manages to feel lightweight and elegant and composeable. But for every elegant API there are dozens of clunky ones. The lovely thing about low-level C or assembly is that the building blocks tend to be simple, understandable, and composeable -- and, if they aren't, it's not so much work to rewrite them. (Though, as jgc points out, in modern times even assembly is hardly immune to complexity. The idiosyncrasies of modern processor architectures are so baroque that it takes years for optimizing compilers to be refined to take advantage of them.)

jacquesm 17y ago
jquery is a good example to use, I've only been into it for a couple of days now (after asking on HN what would be a good js library), and after a few days I already like what it does: It hides the mess! Most software is so absolutely messy. Just the other day there was an argument that it is perfectly ok to see the user interface that results from interpreting a spec'd document as an approximation. Computers are supposed to be deterministic, you're supposed to get exactly the results you want and not something 'good enough for government work'. Elegance breeds excellence, bloat breeds badness. Cellphones that crash (who would have ever accepted that), computers that need to be periodically reinstalled and APIs that have manuals 10 times the size of the operating system components they interface to. Complexity is a given, so, then we should strive to make the complex simple, instead of more complex.

asciilifeform 17y ago

Much of my blog is devoted to precisely this subject. (See for instance: http://www.loper-os.org/?p=16 http://www.loper-os.org/?p=16) I believe that the only solution to the complexity plague is a from-scratch reboot of all of computing.

jacquesm 17y ago
I share your belief. At the same time I think it is going to be like trying to replace the automobile piston engine with something better. The amount of money and time invested in the way we do things today is going to be a very large stumbling block to overcome in order to create a clean slate.
- nazgulnarsil 17y ago
  rotary engines are pretty cool. http://www.youtube.com/watch?v=6BCgl2uumlI http://www.youtube.com/watch?v=6BCgl2uumlI each time each piston reverses direction you're losing energy in a standard piston engine.
  - jacquesm 17y ago
    For some reason my brain showed me the picture of a star piston engine when you said 'rotary', my bad :) We call those 'Wankel' engines here. Pretty cool stuff. Beautful animation by the way!
limmeau 17y ago
I believe the complexity comes inevitably with code reuse and abstraction. Once you've got your ethernet driver working, you discover that your routable point-to-point packet exchange is useful in many places, so you extract an IP component, and before long, you're writing web applications in a high-level framework in a dynamic programming language again.

tybris 17y ago

There will always be a gap between what's technologically interesting and what's economically interesting. Web applications stopped being technologically interesting a while back. I've seen everything from in-browser HD-video to AJAX-powered e-mail clients before 2001. After the major technical challenges had been solved the industry kicked in and started mass-producing. Today the mobile phone platform is sort of like the Web of 1999: a technological wild west. Fart Apps can still make you rich, while useful bluetooth apps hardly exist. If that's not adventurous enough for you, there's plenty more. I spend most of my time on vehicle robotics for automated roads (C) and divide the rest over Arduino/AVG programming (C) and VMM hacking (C/IA32). You can be sure you won't find any "rich APIs" there. Also there's no chance it will make you rich, you need to be in the proven areas for that. (unless...)