17 ms·

I also wish that programming were a lot different today than it was when I started learning it. That being said, a lot of this article's points are things I've

by weland 12y ago

I also wish that programming were a lot different today than it was when I started learning it. That being said, a lot of this article's points are things I've heard before. They led to the development of Visual Basic & co., mostly by people who had no contact with the Smalltalk and Lisp environment in the 80s, while people who did were shrugging and throwing tantrums like WHY THE FUCK DIDN'T YOU FUCKING LIKE IT TEN YEARS AGO? IMHO, all these things went down to the bottom of history because things like these: > Anon the intern needs to be able to open up Programmingâ„¢ and click 'New Web Form' are adequate for people who usually don't program, and extremely inadequate for people who usually do. Generally, and for good reasons, programmers will dislike a tool that hides implementation details for ease of operation. Past a certain level of complexity, the time spent manually doing the right cruft becomes significantly smaller than the time spent manually cleaning up after a smart tool. I sympathize with Anon the intern, but perhaps he should rethink his expectations about complexity; if discoverability is a problem, perhaps he could switch to something that's better documented? And at the risk of sounding like an elitist schmuck who rants about how things were back in his day, maybe he ought to start with something other than web programming. The size and complexity of that tech stack is humongous, to the extent that a large proportion of those who use it don't understand it more than two layers of abstraction down. Programs are also hard to pack and the environment that runs them is hard to setup. Because it involves at least two servers, possibly with several add-ons in order to allow the server-side languages to run, learning at least three languages (assuming server-side JS is an option), two of which (HTML and CSS) aren't quite being used for their original purpose. This is a beginner's nightmare and it has exactly nothing to do with the development tools. And then there are things that are far harder to solve than they originally seem: > I want to just type 'email' and see a list of functions and libraries relating to email. Related how :-)? Should MIME-related functions, needed to reason about attachments, also come up here? HTML parsing/converting, in case you need to deal with HTML email? Information cluttering does nothing to alleviate the opposite problem of information breadth: if Anon the intern's problem is he doesn't know how to Google for libraries or how to make efficient use of documentation, an IDE that presents him with a gazillion of possibly related things won't help him. Especially when, like all beginning programmers, one of his main difficulties is correctly defining the problem he's working on which, in turn, makes it likely for the solutions presented by the IDE to be nowhere even close to the one he needs, because the IDE (like Anon himself) thinks Anon is trying to solve another problem. There is, on the other hand, a lot more truth in this: > Tightening the feedback loop between writing code and seeing the results reduces the damage caused by wrong assumptions, lightens the cognitive load of tracking what should be happening and helps build accurate mental models of the system. I do think that the real resolution to this problem is writing simpler programs whose state is easier to track. On the other hand, programming tools today suck considerably at presenting program meaning. Things like evaluating what an expression comprising entirely of constants, or at least evaluating it based on the default values of the variables involved, are well within reach for today's tools, and yet programmers' calculators are still employed because 99% of the available IDEs couldn't evaluate ADDR_MASK & IO_SEGMENT if the life of every kid in Africa depended on it. This is wicked cool: http://repository.cmu.edu/cgi/viewcontent.cgi?article=1165&context=hcii http://repository.cmu.edu/cgi/viewcontent.cgi?article=1165&c... . However, I also find myself thinking that the very fact that we need debuggers that are this smart is proof enough that we don't reason about our programs well enough. Except for the fringe case of having to quickly debug a (possibly horrible) codebase I haven't written, I'd much rather prefer being good enough a programmer to avoid the need for a debugger that can tell me why foo is not 8 despite the fact that I fucking said foo = 8 ten lines above, than being a programmer with good enough tools to help me when I'm stupid.

SolarNet 12y ago
I think what we are missing is smarter tools. I think that's the argument here. What we really need is the ability to say something like "I want a data structure D holding objects of type Q, with an ordering using this key-accessor(A) called Alpha, and an index with this key-accessor(B) called Beta" and then later in the code say "I want to observe D for the following conditions ..." and let the compiler figure out how to store that data in memory, how to most efficiently build a data structure to trigger those conditions, etc. (Instead of saying List<> or IList<> or writing a custom data structure, etc). And then if you really care (and this is where the non-text/denser ASTs come in; as well as a deeper understanding of computer science and programming) you can add annotations to your description of the data structure like "I want reverse traversal of ordering Alpha to be O(n)", annotations could even cause a compile error like, "I want to insert via index Beta in O(1) time, with an O(n) in order traversal time of Beta". And even fine grained annotations like "For index Beta use a red-black tree" or more specifically "To implement index Beta use module 'foo.bar.baz' by 'FancyBeansCorp', using class 'AwesomeEnterpriseIndex'" Let the tools do the heavy lifting! Let data structure and systems programming experts write data structure implementation strategies. Hell, I bet you could build a marketplace of code just for optimized data structures, if it was easy to swap them in and out. Heck those sorts of dependencies should be at the company level, without even touching the project in question (a company level code policy to use a specific library of data structure implementation strategies, regardless of project being build (unless the project or user overrides it)). Let alone a market place of implementations for algorithms, general code patterns (conditionals, whiles), AI, networking, UI, etc. Compilers should take a long time. A very long time. Sure we can short circuit them for debugging, and just use the best workable code we got in a few seconds, so we can test (and besides, with constant compilation, it should have already solved most of the problems reasonably well by the time you click run). Our compilers should be smart enough they can change their output for different machines not just at an assembly optimization level (better intrinsic, etc), but for different cache sizes, for different memory performance characteristics (changing between intensive memory data algorithm to intensive processor algorithm) as necessary. And yes, I expect it to be deterministic for every platform.
- jamii 12y ago
  Absolutely. This is actually part of our plan. We're writing mid-level-ish specifications in a logic language and then compiling them into an incremental dataflow network. Our current prototype just uses the same implementation for each rule but later we intend to be able to pick and choose different data structures and join algorithms per index/rule. I have a lot to say about separating specification from implementation and trying to better capture programmer intent (eg http://www.freelists.org/post/luajit/Ramblings-on-languages-and-architectures-was-Re-any-benefit-to-throwing-off-lua51-constraints http://www.freelists.org/post/luajit/Ramblings-on-languages-...) but the blog post was already pretty long.

by weland 12y ago

SolarNet 12y ago

I think what we are missing is smarter tools. I think that's the argument here. What we really need is the ability to say something like "I want a data structure D holding objects of type Q, with an ordering using this key-accessor(A) called Alpha, and an index with this key-accessor(B) called Beta" and then later in the code say "I want to observe D for the following conditions ..." and let the compiler figure out how to store that data in memory, how to most efficiently build a data structure to trigger those conditions, etc. (Instead of saying List<> or IList<> or writing a custom data structure, etc). And then if you really care (and this is where the non-text/denser ASTs come in; as well as a deeper understanding of computer science and programming) you can add annotations to your description of the data structure like "I want reverse traversal of ordering Alpha to be O(n)", annotations could even cause a compile error like, "I want to insert via index Beta in O(1) time, with an O(n) in order traversal time of Beta". And even fine grained annotations like "For index Beta use a red-black tree" or more specifically "To implement index Beta use module 'foo.bar.baz' by 'FancyBeansCorp', using class 'AwesomeEnterpriseIndex'" Let the tools do the heavy lifting! Let data structure and systems programming experts write data structure implementation strategies. Hell, I bet you could build a marketplace of code just for optimized data structures, if it was easy to swap them in and out. Heck those sorts of dependencies should be at the company level, without even touching the project in question (a company level code policy to use a specific library of data structure implementation strategies, regardless of project being build (unless the project or user overrides it)). Let alone a market place of implementations for algorithms, general code patterns (conditionals, whiles), AI, networking, UI, etc. Compilers should take a long time. A very long time. Sure we can short circuit them for debugging, and just use the best workable code we got in a few seconds, so we can test (and besides, with constant compilation, it should have already solved most of the problems reasonably well by the time you click run). Our compilers should be smart enough they can change their output for different machines not just at an assembly optimization level (better intrinsic, etc), but for different cache sizes, for different memory performance characteristics (changing between intensive memory data algorithm to intensive processor algorithm) as necessary. And yes, I expect it to be deterministic for every platform.

jamii 12y ago
Absolutely. This is actually part of our plan. We're writing mid-level-ish specifications in a logic language and then compiling them into an incremental dataflow network. Our current prototype just uses the same implementation for each rule but later we intend to be able to pick and choose different data structures and join algorithms per index/rule. I have a lot to say about separating specification from implementation and trying to better capture programmer intent (eg http://www.freelists.org/post/luajit/Ramblings-on-languages-and-architectures-was-Re-any-benefit-to-throwing-off-lua51-constraints http://www.freelists.org/post/luajit/Ramblings-on-languages-...) but the blog post was already pretty long.