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

41–50 of 57 posts

Re: Yep, Programming Is Borked

#41

Post by drostie »

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…

I have to say, I don't know his actual response, but he gives a hint within the article that perhaps, when one wants to get performance in algorithms, one will start to look at the way the constraints are phrased.

So when you've got to write a sort, you probably start in our hypothetical dream language by saying:

"sort permutes a list so that a Now "permute", with predicates, is probably built into the system and the constraint solver probably turns this into a variant of bubble sort, O(n^2). [That is, when you now query list[0] it does a reverse bubble-sort by looking for the least element rather than the greatest element, moving that to the lowest position.]

Now you come into this and say "hey, I've got a huge list, I need O(n log n) power." What do you use? Perhaps merge sort.

"sort zips together, least-element first, the sorted first half of input and the sorted second half of input -- unless len(input) If you can establish a consistent syntax for these sorts of claims which a constraint solver can follow, then the simplicity of the constraint solver, and your ability to guess what it will do, will allow you to determine which algorithm you use to perform the same task.

So it doesn't require strong AI and the programmer is still making the choice -- that's what I'm trying to say. The programmer is merely making the choice in a different framework: rather than making the choice in some wrapper for blocks of assembly language, you are making the choice in some wrapper for a constraint solver.

Now let me turn from where I think you're wrong to where I think you're right: I have the feeling that you're going to see something less revolutionary than claimed, because it will be like C's inline assembler support; in this hypothetical language you can probably "drop back down" to the pre-constraint-solver level when you can't figure out how to articulate the problem with constraints. (Something like "The constraint is, it has to come from applying this function to those lists!")

Re: Yep, Programming Is Borked

#42

Post by dougws »

Most well-written functional programs I've seen actually look like your examples--or rather, the very top-level does. The rest of the code is devoted to telling the language enough about your domain that it's possible to express your goals.

Re: Yep, Programming Is Borked

#43

Post by drblast »

Warning: I'm about to get all opinionated on you.

This "programming sucks" thing could get old quickly. Most of the problems mentioned in these articles are already solved in some language or another. And many of them are too specific. Like wouldn't it great to eliminate for loops? Well, yes, for the specific cases where the alternative would work.

More pressing problems include lack of a REPL as a primary development environment, no decent way in most languages to organize and update libraries in a seamless manner without breaking anything, no good way for multiple programmers to collaborate in real time, lack of run-time interactivity and in-place replacement of components of a running program, etc.

In other words, I applaud your motivation, but if you want to reinvent programming, please don't reinvent Lisp, Prolog, or Haskell. It's just syntax, and that's been done to death. Reinvent Smalltalk and Erlang instead.

Edit: By the way, Microsoft Excel has many of the features these blog posts talk about. Type in Jan, Feb, Mar, then draw a box around those and drag to the right. Magic! However, the utility of these things in a small number of cases doesn't mean the idea can scale to a more general solution. The same idea in MS Word is the awful numbered list creator that never does what you want. I think you'll run into those edge cases much more quickly than you think.

And now, as a programmer, I don't just have to remember foreach..., I have to remember 1500 different ways to iterate through a list. I'd much rather have the general foreach tool and write my own "pairs" function. It takes one minute.

Re: Yep, Programming Is Borked

#44

Post by Scybert »

evincarofautumn wrote: post #7
justindocanto wrote: post #6

"I’m almost 21, and I’ve been programming for over a decade now"

What? It’s necessary context. I started programming early because it’s interesting. It has taken many years of hard work to get to where I am, to develop the skills and opinions I have. Don’t think I’m gloating, because there is nothing whatever to gloat about.

This programmer is broken. The part that made it necessary to state an age.

Re: Yep, Programming Is Borked

#45

Post by gmartres »

jgeralnik wrote: post #30
howeyc wrote: post #16

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))

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.

In these examples, lisp verbosity only comes from a lack of syntaxic sugar, which can be easily added.

Re: Yep, Programming Is Borked

#46

Post by 83457 »

I propose MTPL, the mechanical turk programming language. It is a declarative language where you can essentially write what you would like the program to do, not how you want it done. When you click compile there is a call out to a powerful computer that is a bit slow but in a reasonable period of time will return a working program. This is an iterative compiler though where you may have to adjust your code slightly and compile multiple times to get the right result.

Re: Yep, Programming Is Borked

#47

Post by ThaddeusQuay2 »

It seems that every generation rediscovers the old stuff. Being only 20 years old, you missed out on the 5GL craze.

http://en.wikipedia.org/wiki/Fifth-generation_programming_la... (Fifth-generation programming language)

It was led by Japan.

http://en.wikipedia.org/wiki/Fifth_generation_computer_syste... (Fifth generation computer)

Re: Yep, Programming Is Borked

#48

Post by tikhonj »

snprbob86 wrote: post #38

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 hav…

I think you, like many others, don't understand the practical ramifications of a completely pure language. Let's take Haskell as an example--it is, after all, the poster-child of purely functional research languages!

And yet, from a practical standpoint, Haskell is not pure. The underlying abstractions are pure, sure, but the language makes working with impure computation feel just like writing an impure program. The magic of Monads and do-notation may sound complex, but in reality it's just a neat way to write impure code in a pure way (sounds like a paradox, but it isn't).

Look at this snippet:

    main = do name
This trivial program is technically purely functional. And yet it is also imperative from the programmer's point of view! It looks just like something you might write in Python with slightly different syntax.

So you say, what is the advantage to writing a program this way rather than using an impure language? The answer is simple: Haskell lets you mark impure code using the type system. This is similar to the Scheme/Ruby convention of 'do!' functions being unsafe, but actually enforced.

This sequestering helps you avoid bugs by not having implicit mutation and IO everywhere and it helps the compiler do clever optimizations like running your code in a different order. And yet, if you need it, you have IO and State and fancy things like STM right there, with only a little bit of complication.

Of course, learning to think in this admittedly roundabout way is tricky. But learning is a one-time cost; using a less expressive or harder-to-maintain language is a recurring cost.

In other words, there is no reason why a language focusing on one idea can't be a "just-fucking-works" language as well. In my experience, Haskell and Lisp are just as practical as others; the only difference is in the initial learning period. Look at Common Lisp: you can't get more "just-fucking-work"ing than that!

I think that one should usually ignore a one-time cost like learning in favor of recurring benefits, but others naturally disagree.

Re: Yep, Programming Is Borked

#49

Post by Arelius »

evincarofautumn wrote: post #7
justindocanto wrote: post #6

"I’m almost 21, and I’ve been programming for over a decade now"

What? It’s necessary context. I started programming early because it’s interesting. It has taken many years of hard work to get to where I am, to develop the skills and opinions I have. Don’t think I’m gloating, because there is nothing whatever to gloat about.

His point is that what seems like gloating to you, in fact, speaks of inexperience to many. Having been programming since you were ~10 is nothing new or unique around here.

Your post would be strengthened by omitting that detail.

Re: Yep, Programming Is Borked

#50

Post by snprbob86 »

tikhonj wrote: post #48
snprbob86 wrote: post #38

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 hav…

I think you, like many others, don't understand the practical ramifications of a completely pure language. Let's take Haskell as an example--it is, after all, the poster-child of purely functional research languages! And yet, from a practical standpoint, Haskell is not pure . The underlying abstractions are pure, sure, but the language makes working with impure computation feel just like writing an impure program. Th…

I understand the practical ramifications quite well:

It's complicated as all hell to implement some very simple, and well known algorithms which rely on mutation and explicit memory management.

Take, for example, QuickSort:

"sorta looks like quick sort" http://www.haskell.org/haskellwiki/Introduction#Quicksort_in...

"actual quick sort w/ in place memory mutation" http://www.haskell.org/haskellwiki/Introduction/Direct_Trans...

The short, few-liner Haskell version is beautiful. It's also not the same algorithm. So then you whip out the larger "direct translation" version and, suddenly, you're wishing for C.

This story repeats itself over and over again. For example, try implementing the Fisher-Yates shuffle.

Now, in practice, you don't need in-place swaps. And you can argue code style and YAGNI and pre-mature optimization and practical implications and day to day use and parallelization and whatever etc. Yada yada yada.

I'm not saying there is anything wrong with Haskell. I'm saying that foundation of Computer Science lies in the study of data structures, algorithms, and computability.

Software Engineering basically boils down to a search and optimization problem: Find the data structures and algorithms which (1) minimize the weighted average of costs and (2) maximize the value that the solution generates.

Haskell's approach to Software Engineering presupposes the cost savings to isolating mutation (and other purity concerns) as a requirement. I'm simply advocating future language developers consciously address the problem of finding those optimal data structures and algorithms in minimal time, with an eye for the fact that data structures and algorithms are a fundamental law of computation.

Post reply on HN