Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yep, Programming Is Borked

evincarofautumn.blogspot.com

Post reply on HN
Print view View original

11–20 of 57 posts

Re: Yep, Programming Is Borked

#11

Post by SomeCallMeTim »

The example given with acceleration, velocity, and position? How is a compiler going to deal with that?

With an Euler integrator, you say? (every frame, p=p+time_scaled(v), v=v+time_scaled(a) ). Note there's an implied time, as well as frames per second, in there, but a compiler can know about time. Unless when you're saying "acceleration" you're not talking about real time, but calculating where something will be at a future time...but I digress.

What about a Verlet integrator? [1] Maybe you'll also want to add springs, and Verlet works better for springs. Or maybe a Runge-Kutta [2] integrator? You can get more accuracy out of one of those. Though some people claim that a higher frequency Euler integrator can do as good of a job, possibly with more stability.

And how many times per frame should the system run the integrator? Because the stability of a system can depend a lot on the interval size. In fact, you might want to experiment with different integrators, and different time intervals, to get the result that's best for your application.

These are all choices that a PROGRAMMER typically needs to make, and they can be different for every problem. More than that, unless your compiler can DERIVE all of the above equations and more, at least one and probably several would need to be built in to the compiler.

This "problem" hasn't been solved because, short of creating strong AI, it's not solvable. This can only work when you're writing something like a "game builder" app: A domain-specific problem solver that is designed to deal with a very specific problem -- and which is coded using a traditional approach.

[1] http://en.wikipedia.org/wiki/Verlet_integration [2] http://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods

Re: Yep, Programming Is Borked

#12

Post by evincarofautumn »

Symmetry wrote: post #9

this is orthogonal to the issue of “declarative versus imperative” Wait, you're saying that I could make an imperative results-oriented language as easily as a declarative one? Perhaps the author meant "is not identical to" rather than "orthogonal"?

I did mean orthogonal, though the difference between a declarative result-oriented language and an imperative one is perhaps not immediately apparent. In an imperative result-oriented language, sequence would become less significant—as in a declarative language—but imperative operations would still be allowed, because sometimes “what you mean” is fundamentally imperative.

Re: Yep, Programming Is Borked

#13

Post by crazygringo »

The problem is, simple examples like a trivial sprite-based game are not generally found in the real world, or else already have libraries built for them. (Or you should build a new library yourself.)

In the real world, you write programs that connect to databases, transform parameters, perform a bunch of linear algebra calculations, invalidate caches, and output results to a webpage (for example).

The overall specification of what the webpage is, from start to finish -- is simply the program you wind up writing! You have to specify what information you're getting from the DB (the query), with what parameters, the equations to perform after it returns (using a numerical library), how to invalidate which caches (a bunch of specific function calls), and how the webpage should be constructed (the HTML template).

Writing all this in a "declarative" way seems to make as much sense as throwing away your cake recipes and just using cake photos instead, because that's the "result" you want.

The cake photo is useful for two things only:

1) Mentally, having an overall idea of what it is you want to make (lacking many details, however) 2) After you baked the cake, making sure it looks like the photo

Analagously, declaring things at a higher level in a programming project works marvelously in two areas:

1) Designing what you want to build, in a big picture 2) Testing that what you built satisfies the top-level constraints

When artificial intelligence is a smart as humans, they'll we'll have computers that can write our programs for us, and we'll have "declarative" programming. But of course, we'll blame the computers when the programs don't work, just like users blame programmers now... :)

Re: Yep, Programming Is Borked

#15

Post by evincarofautumn »

crazygringo wrote: post #13

The problem is, simple examples like a trivial sprite-based game are not generally found in the real world, or else already have libraries built for them. (Or you should build a new library yourself.) In the real world, you write programs that connect to databases, transform parameters, perform a bunch of linear algebra calculations, invalidate caches, and output results to a webpage (for example). The overall specif…

That’s a fair assessment, but it misses the point somewhat. All I’m saying is that we should be able to write programs that clearly express our intent, and a result-oriented language would make that easier than a process-oriented one.

“The overall specification of what the webpage is, from start to finish—is simply the program you wind up writing!”

This is not true; the implementation is very far removed from the specification. It is not easy to look at a bunch of SQL and PHP code and deduce precisely what the requirements of the site are. But in a different sort of language, it could be.

Re: Yep, Programming Is Borked

#16

Post by howeyc »

How is your Prog different from lisp? This is what I see...

Prog : which (1..10) > 5

LISP : (remove-if #'(lambda (n) (Prog : each (1..5) 2

LISP : (mapcar #'(lambda (n) (expt n 2)) '(1 2 3 4 5))

Re: Yep, Programming Is Borked

#17

Post by derekp7 »

evincarofautumn wrote: post #15
crazygringo wrote: post #13

The problem is, simple examples like a trivial sprite-based game are not generally found in the real world, or else already have libraries built for them. (Or you should build a new library yourself.) In the real world, you write programs that connect to databases, transform parameters, perform a bunch of linear algebra calculations, invalidate caches, and output results to a webpage (for example). The overall specif…

That’s a fair assessment, but it misses the point somewhat. All I’m saying is that we should be able to write programs that clearly express our intent, and a result-oriented language would make that easier than a process-oriented one. “The overall specification of what the webpage is, from start to finish—is simply the program you wind up writing!” This is not true; the implementation is very far removed from the spe…

The problem is that a results oriented / declarative language would by definition not be Turing complete. And in order for a language to be able to express any problem type, it would have to be Turing complete. SQL is an example of this -- it is declarative, but you can't write a web server or an arcade game in just SQL.

Re: Yep, Programming Is Borked

#18

Post by InclinedPlane »

Translating specifications from fuzzy human-friendly language into an ultra-precise implementation that runs on computer hardware is the core, irreducible complexity of software engineering. The compiler isn't going to do it for you, ever.

With DSLs and advanced programming techniques (FP, macros, AOP, well composed OOP, etc.) you can reach a state where the intention of high-level code is stated clearly, but you're never going to be saved from getting your hands dirty with the details.

Re: Yep, Programming Is Borked

#19

Post by oconnore »

> "The world would be better with a SSC (sufficiently[1] smart compiler)"

Agreed, but there are good reasons that one hasn't been built yet, and they have nothing to do with lack of motivation.

[1] Sufficient for all possible measures of sufficient.

Re: Yep, Programming Is Borked

#20

Post by zackmorris »

I've come to the same conclusion and wrote a series of posts on it a few months back:

http://zackarymorris.tumblr.com/post/10973087527/the-state-o...

I'm thinking that if you chop a program up into many small pieces, each part is simple enough that it can easily be solved by the compiler with something like genetic programming (or better yet, methods in languages like Prolog that already work for small problems).

So much of what we work on now is a waste of time (I'd say well over 90%), things like syntax errors, makefiles, DLL hell, code repo weirdness, managing web servers, concurrent programming, just on an on and on, that I gave up on working on real problems over a decade ago (the kind we learn in school in lisp/Matlab/Mathematica etc).

I would really like to write an entire program sometime as a big tree, that would be convertable back and forth to something simple like JSON. Then the compiler would go through and convert my simple statements like "when this sprite touches this sprite, give them opposite speeds) into the underlying code so I don't have to waste my time with it. I know we think that we work on more complex stuff than that, but I think if most programmers audit their time, they'll find that very little of it goes into the mathematics of solving problems (10%). I realize the logic may not be solved anytime soon, but maybe the minutia can be. If we don't obsess on finding the perfect algorithms, but allow ourselves a floor of say O( n^2 ), I think our productivity could go up substantially.

Maybe it's time for a bunch of geeks like us to be willing to unlearn what we have learned, basically scrap everything, and try working backwards from what the solution will look like (what people will be using in a few decades).

Post reply on HN