9 ms·

> What comes after programming languages? I've been working on this for several years, though a startup seems the wrong vehicle for it. I think the description

> What comes after programming languages? I've been working on this for several years, though a startup seems the wrong vehicle for it. I think the description in the RFS is misguided: "We’re interested in helping developers create better software, faster. This includes new ways to write, understand, and collaborate on code, and the next generation of tools and infrastructure for delivering software continuously and reliably." There's a blind spot in prose like this that gets repeated all over the place in our community: it emphasizes writing over reading. I think we have to start with reading. My hypothesis is that we need to reform the representation of programs to address this use case: I download the sources for a tool I use, wanting to make a tweak. How can I orient myself and make a quick change in just one afternoon? This is hard today; it can take weeks or months to figure out the global organization of a codebase. You can't "deliver software continuously and reliably" until you rethink its underpinnings. Before the delivery problem there's a literacy problem: we programmers prefer to write our own, or to wrap abstraction layers over the code of others, rather than first understanding what has come before. More on my approach: http://akkartik.name/about http://akkartik.name/about

fidotron 12y ago
Absolutely, and this problem is so profound because it's become part of the platforms we are supposed to deliver stable products on. Software engineering won't exist as a profession until it really is turtles all the way down, and not a pig on a fish on a tiger etc.
- EdwardCoffin 12y ago
  > a pig on a fish on a tiger etc. Is this a reference to something, or should I point here if I want to reference this idea?
ericHosick 12y ago
I'm also surprised at this one. The software fulfillment process has a lot of issues. We are stuck in a local maxima and jumping the chasm to the next maxima with ideas like "what comes after programming languages" is really really hard. Sadly, one of the biggest hurdles is self preservation because software developers don't want "software development accessible to the widest part of our society". I hate to say it, but there are Luddites among us. So, I tend to agree that a startup is the wrong vehicle for this. > I think we have to start with reading. I agree with this point. People understand things differently. There should be multiple ways for people to read and understand software programs. Unfortunately, there is only one major way now and that is with source code. I do think that tools like IFTTT are moving us towards more accessibility but it is a small step. I like what you are working. Keep the conversation going.
- deleted 12y ago
  [deleted]
- DalekBaldwin 12y ago
  > Sadly, one of the biggest hurdles is self preservation because software developers don't want "software development accessible to the widest part of our society". I hate to say it, but there are Luddites among us. It's a strange form of Luddism that seeks to limit opportunities to integrate the existing skills of the labor force into the structure of production. We don't have much in the way of unions or guilds, so perhaps the only effective way to restrict the labor supply is to keep the tools user-unfriendly.
programminggeek 12y ago
I'm pretty sure that our assumption that programming languages will look like programming languages in the future is sort of like the assumption that phones will always have buttons on them. Once Apple and other companies showed what the world looks like when a phone is a giant touch screen + giant battery, phones with buttons become a niche, not the norm. I don't know what the programming paradigm is that completely changes that, but I do know that I haven't seen it yet and everything we've done so far seems to completely miss the mark. Someone is going to come along with some other radical assumption about what designing/implementing software really is about. I know that it is not about static vs dynamic, functional vs. imperative, etc. like we've traditionally thought. Maybe it will be more like using Excel or Gmail. Maybe it will be more like flowcharts, or maybe just like sketching out a structure and the machine knows how to wire it together for you. Maybe humans won't be involved at all. Speculation is endless, but nobody has had the iPhone unveil of new programming paradigms yet.
- akkartik 12y ago
  Speaking from personal experience, the thought: "Take away languages. Now what do I use instead?" can be paralyzing. I'll suggest an alternative approach that might stimulate your neurons. Look back at the ways that your life is improved reading code today compared to twenty years ago. When I look back, the highlights for me are: a) version control, and b) automated tests Forget all their benefits to the people writing code. For me, the guy with one afternoon to make a tweak to an alien codebase, it has been invaluable to have not just the current snapshot of a codebase but a story of its evolution so that I can see what the skeleton of the program used to look like in a simpler time, and gradually play enhancements forward atop it[1]. It has also been invaluable to be in situations where I can go, hmm why do I need _, why don't I just rewrite it as _, try it, and find a failing test with an enlightening name. What's common to these two ideas is that they are additive. You don't have to give up programming languages. You just need new ways to share information between programmers besides just the code that runs "in production". My current favorite candidate for the next augmentation for codebases is logs. More info: http://akkartik.name/post/tracing-tests http://akkartik.name/post/tracing-tests. If that whets your appetite feel free to get in touch. My email is in my profile. [1] More details of how this helps: http://akkartik.name/post/wart-layers http://akkartik.name/post/wart-layers
Stwerner 12y ago
I've really enjoyed your writing on your blog at http://akkartik.name http://akkartik.name which I found through your guests posts at Ribbonfarm. Have you been writing anywhere else about your work or thoughts about readable programs?
- akkartik 12y ago
  Thanks! No new projects/demos/prototypes yet beyond the links at the bottom of http://akkartik.name/about http://akkartik.name/about, but I have a half-baked project in the works. Let's chat more offline; I sent you an email.
ChuckMcM 12y ago
That has got to be one of the most awesome mission statements I've read in a long time. Clear, directed, actionable, all good things. FWIW I think you are exactly right, it made me sad that Google expected people to be 'useless' for anywhere from 6 to 9 months of their early employment as they tried to get their head around the code base and tools. Having the ability to eliminate that spin up time would probably triple their productivity numbers.
joshpadnick 12y ago
This is a great point. I am always struck by how there are so many times where, if I could sit down with the original program author for 5 - 10 minutes, I could understand more from that interactive back-and-forth than several hours of reading code in solitude. This tells me it's not that understanding how that code works is intellectually difficult; rather it's discovering how it works is time-consuming. It would be amazing if you could "interact" with the code about its structure and intent the same way you might interact with its author.
- akkartik 12y ago
  As it happens, I've been working on something like that. Still pretty half-baked, but send me an email and I'll show you what I have. Email in profile. "There are so many times where, if I could sit down with the original program author for 5 - 10 minutes, I could understand more from that interactive back-and-forth than several hours of reading code in solitude." Peter Naur wrote a paper in 1985 where he conjectured that this seemed to be a universal law. No matter how much documentation authors provided, new programmers still needed to talk to them. http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn,+Musashi%22 http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn...
  - joshpadnick 12y ago
    Would love to. Email sent.
- mrfusion 12y ago
  I always thought it would be cool to record audio the whole time the editor is open, and the programmer would just talk the whole time about his thought process. Then the audio would be broken up and indexed with the source code. So you could choose to hear what the author was saying right when he was working on a certain area of the code. (You'd normally turn it off, but if you're really stuck it might be a good last resort.)
  - Swizec 12y ago
    I do this with a notebook. When I'm coding I always jot down notes and thoughts. As long as you can remember the date when something was coded, you can see what I was thinking while writing it. Has helped me figure out what the hell I'm doing many a time.
tdaltonc 12y ago
I’ve seen a good example of this recently. Nipype [1] produces network visualization of neuroimaging processing code[2]. They still look like a gnarled nest, but, for other neuroimaging people, they’re a lot easier to read then the actual code. 1 http://nipy.sourceforge.net/nipype/ http://nipy.sourceforge.net/nipype/ 2 http://nipy.org/nipype/0.4.1/_images/graphviz-01bb1b88b33f7cc9c2eabcc158962c2384ae6552.png http://nipy.org/nipype/0.4.1/_images/graphviz-01bb1b88b33f7c...
Dn_Ab 12y ago
I think you're correct in that what you're working on comes before what comes after programming languages†; you're working on the penultimate paradigm. Being able to trace, visualize, give context to and zoom in and out of the relationships of code would be a significant multiplier in the way it will allow accelerated understanding of novel and forgotten code. The value of this can't be overstated. In key ways, which the smalltalk people are very diligent in making sure no one forgets, we've gone backwards in this area. But are you sure the RFS actually disagrees with you? What you're working on covers 2/3 of what the RFS deems worth focusing on. Collaboration and understanding. †I think it's clear what comes after programming languages. A return to their roots. Programming a computer today is like moving by telling every single muscle what to do. To make writing code easier we want to be able to do more with less, to have the code figure out from context what the best thing to do is. We want more intelligence in our compilers. It is telling how powerful the notion of AI is when so many world changing ideas (functional programming, OOP, search, Databases [influence goes: prolog -> datalog -> SQL]) are compromises, failed attempt and detritus of AI projects.
- akkartik 12y ago
  I think you're absolutely right. But the penultimate step is worth highlighting separately, the way the right lemma can render a proof obvious. Especially given how difficult a proposition this penultimate step is. It's like saying you want a better algorithm for multiplication when you use roman numerals. So I'll stand by my statement that the RFS's phrasing is -- not wrong, but rather -- misguided as stated. Or maybe "misleading" would be better, but that carries connotations of malice.
dasmithii 12y ago
With any improvement in programming language technology, we narrow the disparity between human and computer representations of logic. In it's simplest form, this is the premise of language designers. The biggest difficulty with current languages is their reliance on absolute determinacy. Programmers must express in exact form what computations ought be performs, and the languages possesses no intelligence in themselves. I think this needs to change. Inference should have applications outside type declaration, and the vast knowledge base that is the Internet should be taken into account. At this point, there are two promising pursuits that I've seen. First is Wolfram Language, which you've all heard of. The other is Escher, which enables "programming in analogies". It's on early stages right now, but I'd encourage you to check it out at https://github.com/gocircuit/escher https://github.com/gocircuit/escher.
- dasmithii 12y ago
  The problem with analogy-based programming is the lack of determinacy. There are no guarantees when it comes to abstract, knowledge-based inference. And so many concepts in modern programming would have to be abandoned to make this shift. Unit tests, for instance, would lost value dramatically. In the end, an analogy-based approach seems inevitable though, especially once natural language-based inexact. grow popular. Everyday speech is littered with ambiguities, and programming "languages" need to handle these. They can't throw compilation errors upon each inexact command.
  - akkartik 12y ago
    I'm not as confident as you, but yes I've been watching Escher development for some time.
- rcfox 12y ago
  Declarative approaches (like answer set programming, or satisfiability modulo theories) revolve around expressing what the final result should look like, with no regard for how the result is achieved.
dkarapetyan 12y ago
We already have the tools to deliver software continuously and reliably. They are called containers and virtual machines. The problem as usual is not with the technology. If you look back we had SmallTalk virtual machines some time ago that you could pause, ship over the network, and pick up where you left off. Reading is not the issue as well because most code is terrible and it doesn't matter how easy you make it to read the code I'm still going to waste my time reading it. So I'd say that the problem again lies elsewhere. Few people have the aesthetic sense to write elegant code. It doesn't matter how many tools and abstractions you throw at the problem there are still going to be people writing terrible code. Writing and reading code or doing anything else with it is in many ways like art. It is also like science and craft and a bunch of other things that require creativity. Even with the accessibility of paints and all the accompanying technology we still don't have the likes of Michaelangelo and Picasso being any more prevalent than they were around the time those guys were alive. Literature is another good example. We teach everyone to read and write but it doesn't matter how much money or technology you throw at it (ebooks, libraries, etc.) we still don't have any more great writers than we did a century ago. This is not a technology problem. It is a culture and human problem for which you are not likely to find a technical solution.
- akkartik 12y ago
  I didn't say we need to teach people to write elegant code. See my examples at http://akkartik.name/post/tracing-tests http://akkartik.name/post/tracing-tests. I take this perverse joy in coming up with ugly code that is suited to its surroundings, and I'm extremely well-suited for programming because when it comes to code our aesthetics are like George Costanza's instincts (http://en.wikipedia.org/wiki/The_Opposite http://en.wikipedia.org/wiki/The_Opposite). I want programming to be like reading, with most people able to skim most article-length pieces of prose -- even if it's poorly written -- and get a sense for its global organization. That doesn't require teaching everyone to write like Shakespeare.
  - dkarapetyan 12y ago
    Good luck. I'm still not going to read terrible code no matter how easy it is. It took me a while to come to this realization but aesthetically unpleasant code is indicative of the author's abilities and without elevating the level of all programmers I don't see how making code easier to read is going to make much difference. Some tooling might make it easier/faster to come to the conclusion that some piece of software is not worth investing more time in but with enough experience that judgement is not hard to make. Note that LibreSSL was a fork and rewrite of OpenSSL. Even if it was easier to navigate OpenSSL it still would have been the correct decision to scrap large swaths of it because it was horrendous code, easy to read or not.
wukix 12y ago
I am the founder a developer tools startup and I've thought a lot about the future of programming. To be honest, the developer tools market is extremely competitive ("everything must be free") and it is not for the faint of heart. That said, if anyone wants to chat sometime in the Bay Area about future dev tools and/or startups around them, I'd be happy to meet. (contact info at https://wukix.com/contact https://wukix.com/contact)
- akkartik 12y ago
  Hi Wes! I enjoyed your talk on Mocl at the Bay Area Lisp meetup last year.
  - wukix 12y ago
    Thanks! I hope there is another BALisp meetup soon. The recent Parallac thing was cool, although it clearly needed more Lisp :)
DSingularity 12y ago
Emphasis on reading. In my experience writing good code or effecient writing/debugging of code only came after: 1. Learning to read the project code i.e. understanding idioms, structures, execution paths, project syntax+language 2. Learning to extrapolate i.e. anticipating answers or making good guesses for inevitable questions during code writing. Questions like where/when should I do this or where/when is this info I need actually available Both those things literally only came after reading so much code! No shortcuts from the Dev environment (idea, docs) aside from navigation and search!
saturdayplace 12y ago
I just started a new job and have hopped into the first codebase I'll need to work with that I didn't write from scratch myself. I've just been pining for a way to browse through this code as easily as documents in a web browser. Maybe that's the wrong paradigm, but man, there's got to be a better way to read code that lends itself to understanding what's going on. Even though my IDE can "find usages" and I can set breakpoints and step through things, the breakpoints get hit so fast that it's hard to internalize things before hitting "play" again. But stopping for too long breaks the real-time nature of the system. Which I guess is too many words which essentially mean, "I've recently felt this pain, and I agree."
- woah 12y ago
  I recently had that experience as well... felt that the code was pretty terrible but didn't want to say anything as the new guy. Toiled at patching it for a month and a half before sitting down and having a talk with some of the more senior developers about my issues. Turns out that I kind of vocalized what a lot of people had been thinking and we rewrote it in less than half the number of lines in about 3 weeks. Not sure what the moral is here, other than that some code is bad.
sqs 12y ago
Yes times 1,000! This is what we're trying to address at Sourcegraph (https://sourcegraph.com/ https://sourcegraph.com/). 80% of programming is about reading and understanding code, not writing code. Why don't existing tools focus more on helping people read and understand code--and, more broadly, collaborate on a development team? Things like: * seeing everywhere a function or class is used, in context (like https://sourcegraph.com/github.com/joyent/node/.CommonJSPackage/node/.def/commonjs/lib/fs.js/-/readFile https://sourcegraph.com/github.com/joyent/node/.CommonJSPack... on the right side) * seeing who at your company knows the most about an area of your codebase * seeing the history of changes, in terms of functions/modules added, not just lines (like https://sourcegraph.com/github.com/fsouza/go-dockerclient/.commits/bf1b46533545b707ef2df1e6fbad239a08b76df4 https://sourcegraph.com/github.com/fsouza/go-dockerclient/.c...) * having a long-lived discussion about a module/class/function that doesn't vanish after a commit is merged or the file's lines shift around So far, most of the innovation in programming tools has been in editors or frameworks, not in collaboration and search tools for programmers. While there are great editors and frameworks, the lopsidedness is unfortunate because making it easier for programmers to learn and reuse existing code and techniques, and to collaborate on projects, can have a much bigger impact than those other kinds of tools. That's because, in my experience, the limiting factors on a solo developer's productivity are the editors and frameworks she uses, but the limiting factor on a development team's productivity is communication (misunderstanding how to use things, reinventing the wheel, creating conflicting systems, not syncing release timelines, etc.).
- eropple 12y ago
  FWIW, I think this is absolutely fucking genius and everyone should check it out... ...but I can't give you money without Java/Scala support. Roadmap? Pleeeeease? =)
  - vishnugupta 12y ago
    Yes please! Also, I didn't see bitbucket support; hopefully you folks are working towards that?
    - 12y ago
fizixer 12y ago
I feel very strongly about this and have very crude ideas about what I want (e.g., expressed here: https://news.ycombinator.com/item?id=8283025 https://news.ycombinator.com/item?id=8283025). Would love to get in touch with you.
- akkartik 12y ago
  Yes, I have opinions on this approach. In its favor, Charles Simonyi's working on it: http://en.wikipedia.org/wiki/Intentional_programming http://en.wikipedia.org/wiki/Intentional_programming. But let's discuss it over email. Mine is in my profile.
- dkarapetyan 12y ago
  That comments sounds earily close to what is shown in this video http://www.infoq.com/presentations/tools-language-workbench http://www.infoq.com/presentations/tools-language-workbench. It's all working and I think the eclipse website is already hosting most of it.
  - fizixer 12y ago
    Thanks for this, exactly what I wanted to see. It has dragged my thinking forward by miles. I should invest time in MPS, embeddr etc.
spyder 12y ago
There are some interesting ideas that could help with reading and writing programs: from Bret Victor: http://worrydream.com/LearnableProgramming/ http://worrydream.com/LearnableProgramming/ and intentional programming from Charles Simonyi: http://en.wikipedia.org/wiki/Intentional_programming http://en.wikipedia.org/wiki/Intentional_programming https://www.youtube.com/watch?v=tSnnfUj1XCQ https://www.youtube.com/watch?v=tSnnfUj1XCQ
- farazhaider 12y ago
  The first article is a great read.

fidotron 12y ago

Absolutely, and this problem is so profound because it's become part of the platforms we are supposed to deliver stable products on. Software engineering won't exist as a profession until it really is turtles all the way down, and not a pig on a fish on a tiger etc.

EdwardCoffin 12y ago
> a pig on a fish on a tiger etc. Is this a reference to something, or should I point here if I want to reference this idea?

ericHosick 12y ago

I'm also surprised at this one. The software fulfillment process has a lot of issues. We are stuck in a local maxima and jumping the chasm to the next maxima with ideas like "what comes after programming languages" is really really hard. Sadly, one of the biggest hurdles is self preservation because software developers don't want "software development accessible to the widest part of our society". I hate to say it, but there are Luddites among us. So, I tend to agree that a startup is the wrong vehicle for this. > I think we have to start with reading. I agree with this point. People understand things differently. There should be multiple ways for people to read and understand software programs. Unfortunately, there is only one major way now and that is with source code. I do think that tools like IFTTT are moving us towards more accessibility but it is a small step. I like what you are working. Keep the conversation going.

deleted 12y ago
[deleted]
DalekBaldwin 12y ago
> Sadly, one of the biggest hurdles is self preservation because software developers don't want "software development accessible to the widest part of our society". I hate to say it, but there are Luddites among us. It's a strange form of Luddism that seeks to limit opportunities to integrate the existing skills of the labor force into the structure of production. We don't have much in the way of unions or guilds, so perhaps the only effective way to restrict the labor supply is to keep the tools user-unfriendly.

programminggeek 12y ago

I'm pretty sure that our assumption that programming languages will look like programming languages in the future is sort of like the assumption that phones will always have buttons on them. Once Apple and other companies showed what the world looks like when a phone is a giant touch screen + giant battery, phones with buttons become a niche, not the norm. I don't know what the programming paradigm is that completely changes that, but I do know that I haven't seen it yet and everything we've done so far seems to completely miss the mark. Someone is going to come along with some other radical assumption about what designing/implementing software really is about. I know that it is not about static vs dynamic, functional vs. imperative, etc. like we've traditionally thought. Maybe it will be more like using Excel or Gmail. Maybe it will be more like flowcharts, or maybe just like sketching out a structure and the machine knows how to wire it together for you. Maybe humans won't be involved at all. Speculation is endless, but nobody has had the iPhone unveil of new programming paradigms yet.

akkartik 12y ago
Speaking from personal experience, the thought: "Take away languages. Now what do I use instead?" can be paralyzing. I'll suggest an alternative approach that might stimulate your neurons. Look back at the ways that your life is improved reading code today compared to twenty years ago. When I look back, the highlights for me are: a) version control, and b) automated tests Forget all their benefits to the people writing code. For me, the guy with one afternoon to make a tweak to an alien codebase, it has been invaluable to have not just the current snapshot of a codebase but a story of its evolution so that I can see what the skeleton of the program used to look like in a simpler time, and gradually play enhancements forward atop it[1]. It has also been invaluable to be in situations where I can go, hmm why do I need _, why don't I just rewrite it as _, try it, and find a failing test with an enlightening name. What's common to these two ideas is that they are additive. You don't have to give up programming languages. You just need new ways to share information between programmers besides just the code that runs "in production". My current favorite candidate for the next augmentation for codebases is logs. More info: http://akkartik.name/post/tracing-tests http://akkartik.name/post/tracing-tests. If that whets your appetite feel free to get in touch. My email is in my profile. [1] More details of how this helps: http://akkartik.name/post/wart-layers http://akkartik.name/post/wart-layers

Stwerner 12y ago

I've really enjoyed your writing on your blog at http://akkartik.name http://akkartik.name which I found through your guests posts at Ribbonfarm. Have you been writing anywhere else about your work or thoughts about readable programs?

akkartik 12y ago
Thanks! No new projects/demos/prototypes yet beyond the links at the bottom of http://akkartik.name/about http://akkartik.name/about, but I have a half-baked project in the works. Let's chat more offline; I sent you an email.

ChuckMcM 12y ago

That has got to be one of the most awesome mission statements I've read in a long time. Clear, directed, actionable, all good things. FWIW I think you are exactly right, it made me sad that Google expected people to be 'useless' for anywhere from 6 to 9 months of their early employment as they tried to get their head around the code base and tools. Having the ability to eliminate that spin up time would probably triple their productivity numbers.

joshpadnick 12y ago

This is a great point. I am always struck by how there are so many times where, if I could sit down with the original program author for 5 - 10 minutes, I could understand more from that interactive back-and-forth than several hours of reading code in solitude. This tells me it's not that understanding how that code works is intellectually difficult; rather it's discovering how it works is time-consuming. It would be amazing if you could "interact" with the code about its structure and intent the same way you might interact with its author.

akkartik 12y ago
As it happens, I've been working on something like that. Still pretty half-baked, but send me an email and I'll show you what I have. Email in profile. "There are so many times where, if I could sit down with the original program author for 5 - 10 minutes, I could understand more from that interactive back-and-forth than several hours of reading code in solitude." Peter Naur wrote a paper in 1985 where he conjectured that this seemed to be a universal law. No matter how much documentation authors provided, new programmers still needed to talk to them. http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn,+Musashi%22 http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn...
- joshpadnick 12y ago
  Would love to. Email sent.
mrfusion 12y ago
I always thought it would be cool to record audio the whole time the editor is open, and the programmer would just talk the whole time about his thought process. Then the audio would be broken up and indexed with the source code. So you could choose to hear what the author was saying right when he was working on a certain area of the code. (You'd normally turn it off, but if you're really stuck it might be a good last resort.)
- Swizec 12y ago
  I do this with a notebook. When I'm coding I always jot down notes and thoughts. As long as you can remember the date when something was coded, you can see what I was thinking while writing it. Has helped me figure out what the hell I'm doing many a time.

tdaltonc 12y ago

I’ve seen a good example of this recently. Nipype [1] produces network visualization of neuroimaging processing code[2]. They still look like a gnarled nest, but, for other neuroimaging people, they’re a lot easier to read then the actual code. 1 http://nipy.sourceforge.net/nipype/ http://nipy.sourceforge.net/nipype/ 2 http://nipy.org/nipype/0.4.1/_images/graphviz-01bb1b88b33f7cc9c2eabcc158962c2384ae6552.png http://nipy.org/nipype/0.4.1/_images/graphviz-01bb1b88b33f7c...

Dn_Ab 12y ago

I think you're correct in that what you're working on comes before what comes after programming languages†; you're working on the penultimate paradigm. Being able to trace, visualize, give context to and zoom in and out of the relationships of code would be a significant multiplier in the way it will allow accelerated understanding of novel and forgotten code. The value of this can't be overstated. In key ways, which the smalltalk people are very diligent in making sure no one forgets, we've gone backwards in this area. But are you sure the RFS actually disagrees with you? What you're working on covers 2/3 of what the RFS deems worth focusing on. Collaboration and understanding. †I think it's clear what comes after programming languages. A return to their roots. Programming a computer today is like moving by telling every single muscle what to do. To make writing code easier we want to be able to do more with less, to have the code figure out from context what the best thing to do is. We want more intelligence in our compilers. It is telling how powerful the notion of AI is when so many world changing ideas (functional programming, OOP, search, Databases [influence goes: prolog -> datalog -> SQL]) are compromises, failed attempt and detritus of AI projects.

akkartik 12y ago
I think you're absolutely right. But the penultimate step is worth highlighting separately, the way the right lemma can render a proof obvious. Especially given how difficult a proposition this penultimate step is. It's like saying you want a better algorithm for multiplication when you use roman numerals. So I'll stand by my statement that the RFS's phrasing is -- not wrong, but rather -- misguided as stated. Or maybe "misleading" would be better, but that carries connotations of malice.

dasmithii 12y ago

With any improvement in programming language technology, we narrow the disparity between human and computer representations of logic. In it's simplest form, this is the premise of language designers. The biggest difficulty with current languages is their reliance on absolute determinacy. Programmers must express in exact form what computations ought be performs, and the languages possesses no intelligence in themselves. I think this needs to change. Inference should have applications outside type declaration, and the vast knowledge base that is the Internet should be taken into account. At this point, there are two promising pursuits that I've seen. First is Wolfram Language, which you've all heard of. The other is Escher, which enables "programming in analogies". It's on early stages right now, but I'd encourage you to check it out at https://github.com/gocircuit/escher https://github.com/gocircuit/escher.

dasmithii 12y ago
The problem with analogy-based programming is the lack of determinacy. There are no guarantees when it comes to abstract, knowledge-based inference. And so many concepts in modern programming would have to be abandoned to make this shift. Unit tests, for instance, would lost value dramatically. In the end, an analogy-based approach seems inevitable though, especially once natural language-based inexact. grow popular. Everyday speech is littered with ambiguities, and programming "languages" need to handle these. They can't throw compilation errors upon each inexact command.
- akkartik 12y ago
  I'm not as confident as you, but yes I've been watching Escher development for some time.
rcfox 12y ago
Declarative approaches (like answer set programming, or satisfiability modulo theories) revolve around expressing what the final result should look like, with no regard for how the result is achieved.

dkarapetyan 12y ago

We already have the tools to deliver software continuously and reliably. They are called containers and virtual machines. The problem as usual is not with the technology. If you look back we had SmallTalk virtual machines some time ago that you could pause, ship over the network, and pick up where you left off. Reading is not the issue as well because most code is terrible and it doesn't matter how easy you make it to read the code I'm still going to waste my time reading it. So I'd say that the problem again lies elsewhere. Few people have the aesthetic sense to write elegant code. It doesn't matter how many tools and abstractions you throw at the problem there are still going to be people writing terrible code. Writing and reading code or doing anything else with it is in many ways like art. It is also like science and craft and a bunch of other things that require creativity. Even with the accessibility of paints and all the accompanying technology we still don't have the likes of Michaelangelo and Picasso being any more prevalent than they were around the time those guys were alive. Literature is another good example. We teach everyone to read and write but it doesn't matter how much money or technology you throw at it (ebooks, libraries, etc.) we still don't have any more great writers than we did a century ago. This is not a technology problem. It is a culture and human problem for which you are not likely to find a technical solution.

akkartik 12y ago
I didn't say we need to teach people to write elegant code. See my examples at http://akkartik.name/post/tracing-tests http://akkartik.name/post/tracing-tests. I take this perverse joy in coming up with ugly code that is suited to its surroundings, and I'm extremely well-suited for programming because when it comes to code our aesthetics are like George Costanza's instincts (http://en.wikipedia.org/wiki/The_Opposite http://en.wikipedia.org/wiki/The_Opposite). I want programming to be like reading, with most people able to skim most article-length pieces of prose -- even if it's poorly written -- and get a sense for its global organization. That doesn't require teaching everyone to write like Shakespeare.
- dkarapetyan 12y ago
  Good luck. I'm still not going to read terrible code no matter how easy it is. It took me a while to come to this realization but aesthetically unpleasant code is indicative of the author's abilities and without elevating the level of all programmers I don't see how making code easier to read is going to make much difference. Some tooling might make it easier/faster to come to the conclusion that some piece of software is not worth investing more time in but with enough experience that judgement is not hard to make. Note that LibreSSL was a fork and rewrite of OpenSSL. Even if it was easier to navigate OpenSSL it still would have been the correct decision to scrap large swaths of it because it was horrendous code, easy to read or not.

wukix 12y ago

I am the founder a developer tools startup and I've thought a lot about the future of programming. To be honest, the developer tools market is extremely competitive ("everything must be free") and it is not for the faint of heart. That said, if anyone wants to chat sometime in the Bay Area about future dev tools and/or startups around them, I'd be happy to meet. (contact info at https://wukix.com/contact https://wukix.com/contact)

akkartik 12y ago
Hi Wes! I enjoyed your talk on Mocl at the Bay Area Lisp meetup last year.
- wukix 12y ago
  Thanks! I hope there is another BALisp meetup soon. The recent Parallac thing was cool, although it clearly needed more Lisp :)

DSingularity 12y ago

Emphasis on reading. In my experience writing good code or effecient writing/debugging of code only came after: 1. Learning to read the project code i.e. understanding idioms, structures, execution paths, project syntax+language 2. Learning to extrapolate i.e. anticipating answers or making good guesses for inevitable questions during code writing. Questions like where/when should I do this or where/when is this info I need actually available Both those things literally only came after reading so much code! No shortcuts from the Dev environment (idea, docs) aside from navigation and search!

saturdayplace 12y ago

I just started a new job and have hopped into the first codebase I'll need to work with that I didn't write from scratch myself. I've just been pining for a way to browse through this code as easily as documents in a web browser. Maybe that's the wrong paradigm, but man, there's got to be a better way to read code that lends itself to understanding what's going on. Even though my IDE can "find usages" and I can set breakpoints and step through things, the breakpoints get hit so fast that it's hard to internalize things before hitting "play" again. But stopping for too long breaks the real-time nature of the system. Which I guess is too many words which essentially mean, "I've recently felt this pain, and I agree."

woah 12y ago
I recently had that experience as well... felt that the code was pretty terrible but didn't want to say anything as the new guy. Toiled at patching it for a month and a half before sitting down and having a talk with some of the more senior developers about my issues. Turns out that I kind of vocalized what a lot of people had been thinking and we rewrote it in less than half the number of lines in about 3 weeks. Not sure what the moral is here, other than that some code is bad.

sqs 12y ago

Yes times 1,000! This is what we're trying to address at Sourcegraph (https://sourcegraph.com/ https://sourcegraph.com/). 80% of programming is about reading and understanding code, not writing code. Why don't existing tools focus more on helping people read and understand code--and, more broadly, collaborate on a development team? Things like: * seeing everywhere a function or class is used, in context (like https://sourcegraph.com/github.com/joyent/node/.CommonJSPackage/node/.def/commonjs/lib/fs.js/-/readFile https://sourcegraph.com/github.com/joyent/node/.CommonJSPack... on the right side) * seeing who at your company knows the most about an area of your codebase * seeing the history of changes, in terms of functions/modules added, not just lines (like https://sourcegraph.com/github.com/fsouza/go-dockerclient/.commits/bf1b46533545b707ef2df1e6fbad239a08b76df4 https://sourcegraph.com/github.com/fsouza/go-dockerclient/.c...) * having a long-lived discussion about a module/class/function that doesn't vanish after a commit is merged or the file's lines shift around So far, most of the innovation in programming tools has been in editors or frameworks, not in collaboration and search tools for programmers. While there are great editors and frameworks, the lopsidedness is unfortunate because making it easier for programmers to learn and reuse existing code and techniques, and to collaborate on projects, can have a much bigger impact than those other kinds of tools. That's because, in my experience, the limiting factors on a solo developer's productivity are the editors and frameworks she uses, but the limiting factor on a development team's productivity is communication (misunderstanding how to use things, reinventing the wheel, creating conflicting systems, not syncing release timelines, etc.).

eropple 12y ago
FWIW, I think this is absolutely fucking genius and everyone should check it out... ...but I can't give you money without Java/Scala support. Roadmap? Pleeeeease? =)
- vishnugupta 12y ago
  Yes please! Also, I didn't see bitbucket support; hopefully you folks are working towards that?
  - 12y ago

fizixer 12y ago

I feel very strongly about this and have very crude ideas about what I want (e.g., expressed here: https://news.ycombinator.com/item?id=8283025 https://news.ycombinator.com/item?id=8283025). Would love to get in touch with you.

akkartik 12y ago
Yes, I have opinions on this approach. In its favor, Charles Simonyi's working on it: http://en.wikipedia.org/wiki/Intentional_programming http://en.wikipedia.org/wiki/Intentional_programming. But let's discuss it over email. Mine is in my profile.
dkarapetyan 12y ago
That comments sounds earily close to what is shown in this video http://www.infoq.com/presentations/tools-language-workbench http://www.infoq.com/presentations/tools-language-workbench. It's all working and I think the eclipse website is already hosting most of it.
- fizixer 12y ago
  Thanks for this, exactly what I wanted to see. It has dragged my thinking forward by miles. I should invest time in MPS, embeddr etc.

spyder 12y ago

There are some interesting ideas that could help with reading and writing programs: from Bret Victor: http://worrydream.com/LearnableProgramming/ http://worrydream.com/LearnableProgramming/ and intentional programming from Charles Simonyi: http://en.wikipedia.org/wiki/Intentional_programming http://en.wikipedia.org/wiki/Intentional_programming https://www.youtube.com/watch?v=tSnnfUj1XCQ https://www.youtube.com/watch?v=tSnnfUj1XCQ

farazhaider 12y ago
The first article is a great read.