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

I want to fix programming

jonbho.net

Post reply on HN
Print view View original

141–150 of 163 posts

Re: I want to fix programming

#141

Post by bad_alloc »

I think we're overlooking the fact that programming is hard per se. A program runs on a computer which is nothing more than a calculator with storage and peripherals. In the end everything is just numbercrunching. The whole point of a programming language is to overcome the "old days" where you had to use a computer for what it IS, namely a calculator. We did quite well regarding hiding stuff but as a consequence we lost control over parts of the machine. Setting a pin on your LPT-Port on high in Python? Just no. Doing the same thing in this guys "language"? I don't know if that will be included or even possible (if it is please tell me).

But in the end you're still writing code for a calculating machine. Things will never be as easy as "Sort this array by comparing each element for size" because the underlying hardware still is the same. Unless you figure out how to make that easier, for example by intorducing a "qsort [array]" assembler instruction within a processor, that has hardwired Quicksort logic, you're going to stay where you are: In the low-level lands of C and FORTRAN with some nifty little masquerades, like Python, for the same stuff all over again.

Re: I want to fix programming

#142

Post by jng »

Peaker wrote: post #63
jng wrote: post #22

Earlier quoted context omitted.

Reg, thanks so much for your comment. I'm really happy you appreciate the value. It's very interesting that you put the focus in the descriptive language. I've been working on that for a long time. It's not finished, but some areas are clarified. Indeed, after reading your comment I think I will try to focus on getting somewhere workable with that part first. This whole project is so big. It will be good to do it in…

The "Why Dependent Types Matter" paper at http://www.cs.nott.ac.uk/~txa/publ/ydtm.pdf actually uses an implementation of "sort" as its driving example. The paper starts out with a simple sort implementation, and then adds static proofs of correctness for: A) Totality (Termination/no infinite loops) B) Length of output = Length of input C) Output is sorted It does not prove the one-to-one mapping, and I don't know how…

Thanks Peaker. I know a bit about dependent types, and how complex types sytesm can help a lot. Indeed, the title is a bit over the top (or maybe even too much over the top!). Hopefully the attention will help get some extra hands & brains.

At the very least, all the pointers I'm receiving are really valuable.

I don't claim I can fix it, but I definitely want to fix it, have some ideas, and I'm willing to work, listen and learn!

And if I think I can add something, is that I come from a practical/industrial background. Most of my work has been in C++. I'm looking for practical tools for everyday work.

Re: I want to fix programming

#144

Post by jng »

buff-a wrote: post #113
ChristianMarks wrote: post #64

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

The thing about the halting problem, though, is that it doesn't say "You can't write a program that can determine if another program will terminate". It says "You can't write a program that can determine if any other program will terminate." Case in point: Resharper will tell me "This function never returns" in cases where it obviously wont return, and also offer to simplify methods that only ever return a single val…

This! That's why the halting problem is not an issue. Yes, it's impossible to solve in the general case. It doesn't mean it's definitely possible to solve it in 99% of your everyday programming work. Isn't that valuable? Isn't that worth an attempt at getting there?

Re: I want to fix programming

#145

Post by omaranto »

giberson wrote: post #93
timmaxw wrote: post #80

Earlier quoted context omitted.

There's a bug in your definition of SORT. The OP complains that it's easy to write imperative and functional programs that contain bugs; I don't think that declarative programs are fundamentally better.

Tongue in cheek, you don't know how PSL handles negative array bounds--perhaps it's smart enough to know how to handle the first element.

It has a much, much worse bug than the negative index: your definition of sort says "given x produce a y which is sorted and completely unrelated to x in any way". The implementation "given x return y=[1,2,3]" satisfies your specification...

Re: I want to fix programming

#146

Post by jng »

obiefernandez wrote: post #143

The thought reminds me a bit of what Charles Simoniy has been trying to do for years with Intentional Software

I know about that initiative! I think it points in the right direction. I think the approach they took based on DSLs and editors is what doesn't work.

Re: I want to fix programming

#147

Post by MrMan »

barrkel wrote: post #34

So long as the problem you are trying to solve is constrained by the ease with which you can express the problem, this will help. But it will not help when the constraints are elsewhere: memory, network, CPU, heterogeneous interoperability; all still relevant in these times of mobile and distributed computing. When you are operating to these other constraints, you need control - or rather, consistency and predictabil…

i came here to upvote this comment. it touches on the real problems concisely without just sneering about reinventing declarative programming. metaprogramming is worth pursuing, but the considerations hinted at above point to why it is so difficult to realize.

one thing everyone who is hating on the idea is missing is that if one compiler somewhere finds a solution on the Pareto front, for a sub-problem, that pattern can be uploaded to the cloud and re-used by other compilers. this would over time tend to help with the practical problem of how to conserve resources in the face of such a hard overall problem.

Re: I want to fix programming

#148

Post by nnq »

apl wrote: post #127
nnq wrote: post #117

Why not fix the problem with 2 languages? Let me explain. You would have: 1. a language for your actual code - the real code of your application (imagine an application programmed in Python or C++) 2. a language to concisely describe what the code does - the code for your "tests" (imagine the tests written in a simplified Haskell or some dialect of mathematical language) There would be different constrains for the tw…

How does that differ from, say, Haskell's QuickCheck [1] and its ten thousand counterparts in other languages? [1] http://en.wikipedia.org/wiki/Quickcheck

Thanks, I took a better look at that and realized there are 2 implementations of QuickCheck for Python... I'm not really a Haskell developer so I didn't knew much about QuickCheck.

Though I still think none of our current programming languages are good "test" languages... I just gave Haskell as an example, but there are probably tons of things that would make it annoying for writing descriptive versions of an algorithm that could be used as tests...

And at least the Python version of QuickCheck I just looked at are far from a descriptive "implementation" of a function... they seem more like some test-automation that could only prevent most of the bugs that might not crop up in typed language...

Re: I want to fix programming

#149

Post by onemoreact »

overgard wrote: post #138
raganwald wrote: post #132

Earlier quoted context omitted.

SQL is declarative, and that's it's strength. The optimization, indexing, and other tweaking of the implementation is separated from the code that declares the result needed.

I'm not convinced you can really separate those things in a practical context. Inevitably you end up with a leaky abstraction and the opaqueness of what's actually going on makes it harder to diagnose. I think declarative is the right default, since it shows the intent over the mechanics, but I deeply distrust any system that won't let me be very specific about the mechanics if I need to be.

The problem is not that SQL is slow, the problem is people push the system until it becomes slow.

It's just as easy to write 'JOIN this billion row table with that billion row table' as it is to forget how hard that is. We may complain that creating indexes is painful, but take some huge complex and slow query and try recreating it in C++ correctly and at least as fast and you quickly enter a world of pain.

PS: It's awesome to be able to write something and then optimize it without worrying that you are going to break something. When it comes to efficiency being able to select performance trade-offs even in an arcane fashion beats testing everything from scratch by a huge margin.

Re: I want to fix programming

#150

Post by giberson »

omaranto wrote: post #145
giberson wrote: post #93

Earlier quoted context omitted.

Tongue in cheek, you don't know how PSL handles negative array bounds--perhaps it's smart enough to know how to handle the first element.

It has a much, much worse bug than the negative index: your definition of sort says "given x produce a y which is sorted and completely unrelated to x in any way ". The implementation "given x return y=[1,2,3]" satisfies your specification...

The negative index issue is a valid bug concern because when I was typing out the _fictional_ PSL code I missed the negative index hence my reply that said language could be smart enough to handle that (ie, tongue in cheek). However, your bug is not legit, because you've introduced extra wording for an assumption you can't make since you're not the creator of my fictional language. For PSL, "Given SET(x), Find SET(y)" implies that SET(y) is a resultant set of SET(X). SET(y) could have a case where the elements are different than SET(x) but only where explicitly indicated by the requirements. The requirements specified by the where clause in this case do not dictate a transformation on the elements, only a re-ordering. So no, it's not a bug.

It's funny that despite it being a passing pseudo example to make a point about programs being compositions of tasks that I'd be this vested in defending the code correctness of my pseudo code but I can't help it.

Post reply on HN