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

31–40 of 57 posts

Re: Yep, Programming Is Borked

#31

Post by tadfisher »

evincarofautumn wrote: post #24
derekp7 wrote: post #17

Earlier quoted context omitted.

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.

Your first statement is patently false. You miss the meaning not only of “result-oriented”, but also “declarative”. Besides, Turing-completeness is not a difficult criterion to meet in a language—in fact it’s almost more difficult to avoid it.

I'm reminded of TeX, where Knuth struggled to keep it declarative-only for years until the macro system added tail-recursion, becoming a Turing-complete language in its own right.

Re: Yep, Programming Is Borked

#32

Post by shasta »

evincarofautumn wrote: post #12
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.

Your "results oriented" is what everyone else means by "declarative". It is true that functional and logic programming are not fully declarative because you end up having to worry about the way your declarations will be evaluated, but the same issue will apply to your language. That's what you swept under the rug in your remark along the lines of "if we're careful what constraints we choose, we can get a good running time."

Re: Yep, Programming Is Borked

#33

Post by growingconcern »

There's been a couple of these types of articles on here lately. All of them break down into "Programming is broken because I can't just say to a computer what I want and have it created for me". We have to specify the process gets something done because it takes a hell of a lot of smarts to do this. Even things that seem very easy and straightforward to say out loud are filled with unknowns, assumptions and inconsistencies. Maybe all these "programmers" can stop whining about how programming is broken when we've created an AI that will understand what they want and just write the program for them. And as for constraint satisfaction programming - if you've ever actually programmed in prolog you'd realize that properly defining the problem such that you get a proper answer back is a hell of a lot of work. Prolog has it's place, but if it saved a huge amount of work and was easy to use people would be using it more often.

Re: Yep, Programming Is Borked

#34

Post by apsp »

Could you support your claim that running times are irrelevant? I understand you want to keep your blog post (or "blarticle") short. But maybe you could elaborate here? I am genuinely interested in your argument.

I think there are other caveat of specifying only the results.

You posted earlier on the halting problem

http://evincarofautumn.blogspot.com/2011/10/solving-halting-...

That post also contains a statement which I believe to be false. You state that the "Haltability problem" (where you are given a program P and want to determine if there exists an input on which it halts) is decidable but its not.

Basically, I can just hardcode any input I of my choosing into P so that it always does the same thing (run P on I) regardless of the actual input I' you provide it. Thus, I can use an algorithm for the Haltability problem to solve the halting problem.

I know that does not pertain to this post directly but the halting problem does. Given a program written in this new language, how can you determine if what the programmer specified can even exist as a program?

In fact, suppose you specify the properties of this new language you current wish to construct (in say, English and assume that everything is interpreted correctly). How do you know such a language could potentially exist (never mind implementing it)?

I also don't even want to think about debugging in such a language. More specifically, I would rather have a library for the example you described because if I make a mistake in my specification, I have ways to find the error in it. But I guess this goes back to my previous question: what does your compiler produce on an incorrect (or outright impossible) specification (i.e., piece of "code")?

Its certainly interesting to read about thoughts on potential new languages but I wish there were more solid theoretical foundations for posts like these. Otherwise, I feel that the same energy would be better spent on improving existing languages with some subset of the features you want.

Re: Yep, Programming Is Borked

#35

Post by shasta »

SomeCallMeTim wrote: post #11

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…

This is exactly right, and why people like languages that support DSL building. You do want to let programmers encode their concerns in a natural way as outlined in the article. But then assuming that the implementation of these all of these concerns is going to handled by some super language strikes me as unrealistic. The hard problem is picking good abstractions for encoding the concerns that are amenable to efficient implementation.

Re: Yep, Programming Is Borked

#36

Post by mjwalshe »

growingconcern wrote: post #33

There's been a couple of these types of articles on here lately. All of them break down into "Programming is broken because I can't just say to a computer what I want and have it created for me". We have to specify the process gets something done because it takes a hell of a lot of smarts to do this. Even things that seem very easy and straightforward to say out loud are filled with unknowns, assumptions and inconsis…

The sort of people who write these sort of posts don’t seem to have actually worked in real technical computing. Its interesting that the article mentions Newtonian mechanics. Years ago (early 80s) I worked for a RnD organisation and we where analyzing the efficiency and droplet dispersion of water sprinklers used in fire suppression.

They had come up with a neat solution involving really tight depth of field and doubly exposed file with two different colour filters a short time apart. So we had a slice though the droplet cloud.

I was told oh we have brought an A0 digitizer (costing about twice my salary at the time) work out how to interface to that PDP and develop a system to locate the droplets in the xy plane.

To solve that you actually have to know real engineering to get this to work the actual programming is the easy bit. I also had to work out how to write a interrupt driven driver to interface the tablet to the computer – Luckily RT11 did have some basic multitasking functionality built into it.

PS we did also use prolog on other projects so it does have its uses

Re: Yep, Programming Is Borked

#37

Post by Detrus »

I haven't been programming long and don't get the nuances of functional and declarative paradigms. But I have a hunch that even if people made some new languages that balanced out the various concerns of complex compilers, programmer control, LOC, boilerplate, ugly syntax etc, it wouldn't fix much.

So, using research into how people best solve problems, I’m making a tool that helps people solve the problem of having an idea and not being able to make it a reality.

Novices will still have lots of problems. They don't really think about how sprites move in a game, they think they want to make a game kinda like Asteroids or more like Mario. What will really help them is a well organized, well documented template.

The problem is with documenting, organizing and making available the multitude of libraries and solved problems. Making them accessible through visual examples and natural language.

http://blog.wolfram.com/2010/11/16/programming-with-natural-...

The Wolfram approach of writing a query, seeing the output, confirming or rejecting it is the right direction. Memorizing syntax is a big problem.

  [1,2,3].byPairs == [[1,2]];
  [1,2].byPairs == [[1,2]];
  [1].byPairs == [];
This doesn't solve syntax memorization.

  split array by pairs == arrayPairTransform([1,2,3]) == [[1,2]]
  make array of pairs == arrayPairTransform([1,2]) == [[1,2]]
This is closer imho. You don't really have to worry about the [1,2].byPairs being prettier than splitArrayIntoPairs([1,2]). You can use your queries as the pretty documentation. You can choose which lower level language to use in the code column, without having to remember its particular syntax. You don't have to worry about naming as much, you're using tags instead.

A lot of novice programming is looking up code samples and libraries, getting them to run. Organizing existing code in libraries and samples for a specialized natural language search engine like in Mathematica seems like it would change some design decisions of the lower level language.

It's not as important if the lower level language is a bit more verbose. Your priorities for it would be performance, control, parallelism/concurrency, regularity. Expressiveness/verbosity can matter less if you offload it to another layer.

Re: Yep, Programming Is Borked

#38

Post by snprbob86 »

To me, the fundamental issue with pure declarative or functional languages is that they ignore the simple fact that both the problem and solution domains of the set of all possible problems are, fundamentally, heterogenous.

Sometimes, "what" I want is a program to do this that and the other thing in this given order. ie the "how". Other times, I don't care, I just want these properties to hold. Yet other times, I have no idea what I want at all and have to experiment and see what happens.

I want a language that solves the composition problem between these distinct solution spaces. The best programming language for any given task is the one who's world view best matches the preconceived spec in the programmer's head.

Most research languages take a key idea (everything is a list! or no side effects! or something like that) to a logical extreme. That's a great way to study a set of phenomenon in a particular little universe, but most practical languages find a happy median of thought-pure and just-fucking-works. We need to get some of these wins from high concept languages back into just-fucking-works languages.

Re: Yep, Programming Is Borked

#39

Post by haberman »

Bridge building is broken, I can't just say "I need a bridge from here to there with 8 lanes across 2 decks that can carry 1000 cars weighing 2 tons each and survive wind storms" and have a computer design it for me.

Re: Yep, Programming Is Borked

#40

Post by pnathan »

zackmorris wrote: post #28
gintas wrote: post #27

Earlier quoted context omitted.

> 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. That would be Lisp. > 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. That's function application (if at runtime) or macro expansion (if at compile time).

Ya but both of those don't work in the real world, at least not very well (or beginners would be able to use them). I'm not trying to be negative, just pointing out that existing options are not living up to expectations. I think I'm talking more about readability than sophistication. I want to write in a high level language like Hypertalk (from the HyperCard days) and let the compiler create a series of permutations…

Actually, Lisp works fine for beginners. It's simply not the current fad.

I use Lisp by preference because it's so much easier to express my ideas without whacking on the syntax mole.

Post reply on HN