I want to fix programming
81–90 of 163 posts
Re: I want to fix programming
#82Jon, you're looking for haskell. But there's a catch -- programming in haskell is HARD, and expert haskellers are the best of the best, thus EXPENSIVE. many customers don't want correct programs, they want cheap programs. Some people in finance care about correctness, maybe you should check them out.
Dusting, thanks for the suggestion, but I'm not looking for Haskell. It's not what I'm looking for. What I want is declarative, not functional. There is an inherent limitation in the functional approach, I hope to cover why that is in a further article in the series. I am not after correctness per-se. I am actually more after "cheapness" at least in programmer time. But I do think a lot of the programmer time is spen…
You repeat yourself like this several times in your article, and I find it tedious.
Re: I want to fix programming
#83Re: I want to fix programming
#84The most common declarative programming language used in SQL. In theory the optimizer takes my declaration and builds an optimum (or at least decent) set of step in the database engine to accomplish what I have declared. With all the work in this limited area, database optimizers get it really wrong quite a lot (Sybase 12.5 was bad enough on big data that forcing order of joins and indexes was needed). I am not sure…
Re: I want to fix programming
#85So, over the years I've played with many things that claim to be "declarative", and here's why I now shy away from them like the plague. There's no such thing as "declarative". No matter what you type into the computer, at some point it's going to turn into instructions that do the thing you want done. Trying to create a declarative language is a way of making it extraordinarily opaque as to what the machine is actua…
What if you created a declarative language which allows you to override the algorithms in a functional/imperative? You could create a public algorithm repo that auto-pulls into your local machine on setup. Could search for algorithms by declarations. That would be a lot of reuse.
We have that. They're called libraries. If I need to sort a collection, I don't write an imperative chunk of code, I just do:
sort(myCollection)
Looks pretty declarative to me.Re: I want to fix programming
#86Are you trying to reinvent prolog? Also, I don't really understand how a compiler for your language would actually figure out the efficient algorithms for getting the answer. EDIT: I see there's already a bunch of people talking about prolog here. Anyway, the second question is still open :)
Re: I want to fix programming
#87I once read a programming book on Elliptic Curve Cryptography, which was invented by Dr. Neal Koblitz. So the book said - whatever is in the next 200 pages is considered trivial by mathematicians working in number theory. If you write it in the form of equations, this entire book will occupy less than half a page. It is basically a lemma and a few theorems. But this book is 200 pages long. Why ? Because it tells you…
But what's your point? Code can do more wide ranging things and does so with fewer available symbols (no superscript for pow() operations), so it's wordier, but really it's not so far different. It may take a computer 200 pages of explained C++ but it takes a child months and years of schooling.
Re: I want to fix programming
#88I think you're on the right (or at least an interesting) track here, one that I have been thinking about a bit myself.
For me these thoughts came after working for a few years on a clean room reimplementation project for a software component with a large set of automated tests (thousands). Slowly I got the feeling that each of those tests could be seen as an image of an unknown object, and that my job was to construct that object. Looking at just a few pictures it might be easy to find an object that could be projected onto planes to create those images, but looking at thousands of images it can be a very intellectually challenging task to find a single object that matches all of them. It's also a problem that has far more dimensions than the 3D world we live in.
In agile programming you may call those images "user stories". Agile basically says "there is no way to know all the images beforehand (because that depends e.g. on a market response), so just start with the most important images and build the simplest possible object that fits with them". Each time you add in a new image there's a risk that you have to make major changes to the object (to make it fit with the new image while remaining "compatible" with the previous images). That's what's called refactoring.
The really irritating thing with programming is that the effort of building a program does not scale linearly with the number of images (at least not in most cases). There is really no limit to how much work you may have to do to make the object fit with one or several new images, while remaining compatible with all the previous ones. That's because imperative code is a description of the object and not a description of the images.
What a programmer does is really solving the global optimization problem of constructing a minimal object that fits a number of images, and then writing that down in code. The better the programmer the more images they can handle, the more beautifully the images will match the object and the simpler the object will be.
It must be possible for a machine to do this. Don't get me wrong; it's a formidable optimization problem - and there are certainly sets of images for which no (reasonable) object can be constructed - but in principle it must be possible.
In fact there is a machine that does this for simple x-ray images and physical 3D objects: a Computerized Axial Tomography machine, or CAT scan as they call them in hospitals. Basically, what these machines do is take a series of x-ray images of an unknown object and then compute "backwards" what that object must be like on the inside in order to have created those x-ray images. I bet a really good programmer would be great at manual tomography, and that when you have implemented your new programming paradigm it will be a sort of CAT scan for software. :)
I'd love to talk more about this on occasion!
Re: I want to fix programming
#89The problems the OP wants to solve are formally undecidable and reducible to the halting problem. 1. Given a formal specification, find a program that meets the specification. 2. The apparently simpler problem of checking whether a given program meets a specification. Both are undecidable. That said, there is an extensive literature on practical approaches to this problem. They generally suffer from intractability. h…
Re: I want to fix programming
#90Sure, he didn't have to be taught how to fetch a particular kind of beer in a particular house, but then again, when I make a new e.g. Starcraft map, I don't have to change the code to teach units to move from a coordinate to another. The learned algorithm is just general enough that it applies to any object that fits a certain interface.
And humans make a lot of errors to correct their internal spacial navigation algorithms. To correctly fetch a beer, it took years of bumping into stuff and falling down until the algorithm was robust enough.
Seems to me that a system with hand-written imperative algorithms and a general mechanism of iteratively improving them by trial-and-error is much more close to what we humans to than a compiler that simply comes up with algorithms from scratch from just reading intents and goals.