"You'll never find a programming language that frees you from the burden of clarifying your ideas." [0]
Yep, Programming Is Borked
21–30 of 57 posts
Re: Yep, Programming Is Borked
#22Why is this such a big deal, sometimes I like to contemplate the monkey dance that is coding and I come to the same conclusions, try coding a webpage in Haskell, yes its possible but programming is very compartmentalized you still need different languages for different objectives.
Re: Yep, Programming Is Borked
#23Same deal as the other post. The easy part of creating a declarative language is describing it. The hard part is actually implementing it.
Re: Yep, Programming Is Borked
#24Earlier quoted context omitted.
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.
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.
Re: Yep, Programming Is Borked
#25I see a problem with language here. At the end of the day, you have to make a computer understand what you want. Sure, you can increase the expressiveness of your computer language. You can even have it pick an algorithm for you under lots of circumstances (f.ex. logic programming). But you still have to explain what you mean.
Re: Yep, Programming Is Borked
#26Earlier quoted context omitted.
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.
Why do you say by definition it wouldn't be Turing complete?
Re: Yep, Programming Is Borked
#27I'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…
> 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).
Re: Yep, Programming Is Borked
#28I'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…
> 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 under the hood that I could review and say "yes that one works, use it" and then maybe the compiler could annotate my code with more precise limits on what I said. So for example I tell it I want to sort a list, it shows me algorithms that sort numbers, strings and objects, and I say "yes strings are good enough" and it shows me the updated version of my code showing that it requires strings.
I know that sounds a little weird but this is 90% of the minutiae that I deal with on a daily basis and I am thoroughly disgusted with how myopic and restrictive tools have become today. They break when I forget a semicolon, when I would much rather have them show me an edge case of my algorithm that is incorrect.
Re: Yep, Programming Is Borked
#29We've got machines with memory, registers, instruction pointers, and such, and they are here to stay. As long as the world runs on Von Neumann machines, someone will always have the job of converting intentions into machine code, at some level.
If you come up with some sufficiently-liberating declarative language, you still need an amazingly smart compiler to use it. People will invent new types of these languages, as the style catches on, and there will be lots of people writing the runtimes and the algorithms that you (the one taking the declarative route) depend on to get a reasonably-performing program out of the whole process.
Re: Yep, Programming Is Borked
#30How 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))
Um, two languages being able to do the same thing does not mean there is no difference between them. Particularly when one is much less verbose than the other.