21–30 of 104 posts
If our programming language(s) don't allow for this, see what's wrong and fix it. Lather, rinse, repeat.
It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance. pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp…
Sounds like you have a number of tangible, palpable, feasible ideas for such super-smarter next-gen programming tools -- care to share? (Just hoping what you have in mind isn't UML + SOAP + some unintelligable über-abstracted-meta-code-gen...)
I have some ideas about how it would work, and have looked a little into how it might be implemented and have some seemingly feasible ideas there too. But I'm not an expert in either NLP or programming language development, so what do I know.
A good first step in this direction is the natural programming language for creating interactive fiction, Inform 7. The problem is that it's not general purpose. But you can try reading about it if you think natural language is too ambiguous to ever possibly be a programming language.
I want to write down all my thoughts about this idea, but I thought I'd get some more meat on it before I do that. Also, I haven't mentioned here why I think natural language programming can help, but I'll leave that to your imagination for now.
Once a program grows, you should architecture it so that you only need to keep the piece that you're working on in your head, ie it should be a network of black-boxes and you should only need to open the one you're currently working at, and even when you do things like large scale refactoring, you should be able to selectively and partially open only some of the boxes to do your job - and this is what programming languages and patterns should help you do!
This is so true for me. And not just for big complex programs but also for anything not completely trivial.
The one (applicable to me) part of the joel test (http://www.joelonsoftware.com/articles/fog0000000043.html) that I never made any progress on was having a spec. I just couldn't do it whether through laziness, inability to concentrate or whatever. Actually it's been a bit of a guilty secret of mine.
Generally there'll be some part of the program that I'll be able to solve right away and while I'm doing that I'll be having ideas about how to do something else. Later it might become obvious that a certain part would have been better done another way and if there's a serious benefit to changing things I can do it at that stage.
It's only after a lot of work's already been done that I'd be able to produce some kind of spec for the program
Having a spec that lays everything out beforehand is to me analagous to a mathematician writing the final proof of a theorem before doing all the thinking.
Earlier quoted context omitted.
Sounds like you have a number of tangible, palpable, feasible ideas for such super-smarter next-gen programming tools -- care to share? (Just hoping what you have in mind isn't UML + SOAP + some unintelligable über-abstracted-meta-code-gen...)
I have one: natural language programming. I have some ideas about how it would work, and have looked a little into how it might be implemented and have some seemingly feasible ideas there too. But I'm not an expert in either NLP or programming language development, so what do I know. A good first step in this direction is the natural programming language for creating interactive fiction, Inform 7. The problem is that…
You should never need to hold the entire program in your head ! (except when you actually begin coding it - for this early stage of development I agree with PG). Needing to hold a whole mature program in your head every time you work on it is a code smell that tells you your solution ended up in the shape of the most popular software architecture of all time: the "big ball of mud" ( http://www.laputan.org/mud/ ). Now…
Earlier quoted context omitted.
I have one: natural language programming. I have some ideas about how it would work, and have looked a little into how it might be implemented and have some seemingly feasible ideas there too. But I'm not an expert in either NLP or programming language development, so what do I know. A good first step in this direction is the natural programming language for creating interactive fiction, Inform 7. The problem is that…
One way to solve the ambiguity problem of natural languages is using a controlled natural language, which is a limited subset of a natural language[1]. Some of those are machine transformable to logic. There's even some work to encode legal knowledge using them. [1] http://en.wikipedia.org/wiki/Controlled_natural_language
But I'll note that we humans manage to understand each other just fine without resorting to a controlled natural language. We solve the ambiguity problem basically by taking the most likely interpretation of a given sentence, given the context, or asking questions if too confused. And in fact, there are natural language parsers out there that can predict the mostly like parse reasonably well for single sentences.
The biggest problem here is that programmers like having full control of what's going on, whereas this sort of idea brings in a large dose of unpredictability: how will the parser interpret this sentence? I think this can be solved to some extent by having the parser tell you what it parsed in less ambiguous terms. In fact, you might ask the parser to present a normalized version of the code that is more specific about exactly what's going on (and probably more verbose), and also expanding out phrases to show you exactly what they mean for debugging purposes. Also, when a clear parse cannot be made, the parser can simply ask you to clarify, presenting the multiple parses that it could not decide between.
You should never need to hold the entire program in your head ! (except when you actually begin coding it - for this early stage of development I agree with PG). Needing to hold a whole mature program in your head every time you work on it is a code smell that tells you your solution ended up in the shape of the most popular software architecture of all time: the "big ball of mud" ( http://www.laputan.org/mud/ ). Now…
To avoid "memory overload", I have taken to literally ignoring parts of the system which I currently don't need. I.e., I don't even look at other classes' code before I don't need them. Else, I would have to spend 3 days of understanding it all. That's for very big programs, and of course I do look at the overall structure and what patterns have been used to couple classes together. But if a method promises something…
...that's why I'm currently investigating functional programming as way to make it easier to hold larger parts of programs in your head.
Earlier quoted context omitted.
I have one: natural language programming. I have some ideas about how it would work, and have looked a little into how it might be implemented and have some seemingly feasible ideas there too. But I'm not an expert in either NLP or programming language development, so what do I know. A good first step in this direction is the natural programming language for creating interactive fiction, Inform 7. The problem is that…
One way to solve the ambiguity problem of natural languages is using a controlled natural language, which is a limited subset of a natural language[1]. Some of those are machine transformable to logic. There's even some work to encode legal knowledge using them. [1] http://en.wikipedia.org/wiki/Controlled_natural_language
> There's even some work to encode legal knowledge using them
Where do I learn more about this? What's the name of that language, or research project, or...?