Functional Programming Is Hard, That's Why It's Good • Hacker News Board

Re: Functional Programming Is Hard, That's Why It's Good

#101

Post by Dn_Ab » Sun, Aug 21, 2011, 2:13 PM UTC

barrkel wrote: post #91

thesz wrote: post #54

Earlier quoted context omitted.

You should reconsider your stance. Types allow requirements changes to be propagated through all program. State-of-the-art type systems even allow accounting of effects, like prevent deadlocks by ensuring a specific order of locking: http://www.cs.st-andrews.ac.uk/~eb/writings/fi-cbc.pdf This is just another tool in a toolbox. You can use it. Or you can throw it away as "no one seem to use it".

I never said "no one seems to use it". What I specifically said was that I don't think type theory has a lot to do with programming: i.e., that the majority of work put into type theory in academic contexts does not, on balance, do much to improve the state of programmers writing software, or the quality of our software engineering. "Types allow requirements changes to be propagated through all program" - what does t…

You are right that many people don't need the results of type theory for their work. But that mainly tells on the type of work you do. For example many people think programming does not need math but if you are writing physics engines, graphics engines or doing machine learning then you need some basic level of mathematical sophistication. Similarly, if your work is related to automatic verification or the transformation from code to code then knowing type theory will save you a lot of wasted effort reinventing pitfalls. Type theory gives a foundation and a why basis so that intuition can be augmented beyond rules of thumbs. Language Oriented programming is one which would benefit from such a knowledge. Consider also that the future is not going to be dominated by one platform, powerful code transformation tools will be a strategic advantage. Know that my emphasis is not on the strength of the type system just its consistency and ability to augment human reasoning.

Software engineering is the only field of engineering whose practitioners do not use a basics grounded in math. Electrical people have Maxwell, ohm, gauss etc. Mechanical engineers and dynamics, civil continuums and so on. None of these professions you will note, came after the math. The math came as a result from studying and generalizing on these and then feeding the results back providing a net gain for both. This leads me to believe we are in early stages yet. We have the catapult without trigonometry. We do not have enough understanding to build stuff to withstand earthquakes. You say that most languages don't have well founded types but you fail to note that many of those same projects often have massive teams, massive code bases, fail often, run over time and are insecure.

But all that said, programming is different isn't it? You can get instant feedback and build something that you think is good because it fits all the white swans you put inside it. So I think before we have a foundation we will need tools that are built from and require a basic understanding of category theory and types. These can then be used to quickly iterate tests and do so with strong guarantees without having to write annoyingly tedious constructive proofs. Genetic programming is stupid but what if it could reason about types and try hypothesis on a meta level as well? Or what if tools such as http://lambda-the-ultimate.org/node/1178 were developed into the typical programmers toolchain? But yes, complex types without tools are a hard sell.

Re: Functional Programming Is Hard, That's Why It's Good

#102

Post by thesz » Sun, Aug 21, 2011, 2:59 PM UTC

ThaddeusQuay2 wrote: post #86

thesz wrote: post #42

Earlier quoted context omitted.

>doubts about it's ultimate suitability for iterate-quickly, fail-fast software world. Lest you doubt: http://thesz.mskhug.ru/svn/hiersort/doc/hhm-eng.pdf We did a cycle-accurate prototype of MIPS CPU with some twists. In Haskell. For Haskell to shine in prototyping you have to apply it to some critical and new task, where type system works with you, preventing errors. The novelty is crucial, I think. You will have t…

"You will have to explore the solution space with the help of some sort of theorem prover (type system)." Have you tried ATS (Applied Type System)? http://en.wikipedia.org/wiki/ATS_(programming_language)

No, I haven't. When I looked at it, I didn't see a well-composed thing like Epigram or Agda2.

So I decided to stick to Haskell for a while and then slowly work my way to Agda2, if I would feel the need.

Re: Functional Programming Is Hard, That's Why It's Good

#103

Post by thesz » Sun, Aug 21, 2011, 3:04 PM UTC

dramaticus3 wrote: post #89

cageface wrote: post #64

Earlier quoted context omitted.

As for C++, it's domain shrinks every year. Mobile seems to be generating a resurgence of interest in C++. Squeezing every last bit of performance out of tightly constrained CPU and RAM matters again.

So surely Forth should make a resurgence, it has the most code density, the fastest runtime and the lowest error rate. The only metric is loses on is its high score in impenetrability.

Actually, you don't need a Forth implementation to benefit from compact code. Take a look: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.3...

They split program into slow and fast parts, slow parts used compact byte-code interpreter, fast parts were compiled into native code with optimizations.

They didn't used "code compression" like Forters do - Forters refactor common pieces of code into separate definitions. Nevertheless, they made quite balanced system.

Re: Functional Programming Is Hard, That's Why It's Good

#104

Post by dramaticus3 » Sun, Aug 21, 2011, 4:20 PM UTC

thesz wrote: post #103

dramaticus3 wrote: post #89

Earlier quoted context omitted.

So surely Forth should make a resurgence, it has the most code density, the fastest runtime and the lowest error rate. The only metric is loses on is its high score in impenetrability.

Actually, you don't need a Forth implementation to benefit from compact code. Take a look: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.3... They split program into slow and fast parts, slow parts used compact byte-code interpreter, fast parts were compiled into native code with optimizations. They didn't used "code compression" like Forters do - Forters refactor common pieces of code into separate defi…

thanks

Re: Functional Programming Is Hard, That's Why It's Good

#105

Post by dasil003 » Sun, Aug 21, 2011, 5:25 PM UTC

ebiester wrote: post #49

dasil003 wrote: post #29

Earlier quoted context omitted.

You're making the same mistake that the Java loyalists did when Rails came out: judging something based on your distaste for the advocacy around it without any real understanding. I'm not going to pretend to know your motivations here, but often times people throw up this defense mechanism to protect their own professional knowledge; but here's the thing, that does nothing but stunt your own growth. Functional progra…

Here's the problem I have with this: nearly everything I do involves state. It's called a database. Let's take a simple example, a to-do list. Abstracted out to its essentials (a piece of paper), the to-do list is exclusively state. Add a task, complete a task. Now, I can write a program that manages a to-do list in a functional language. There are two options. (Let's assume this is a web app.) First, I can make the…

It seems you didn't read my post at all, because this is a complete non-sequitur. Look at the only sentence in which I emphasized a word and notice that it is exactly the same as the opening sentence your rebuttal.

This tells me that you are operating off of some mental model of what you've heard from FP proponents in the past without actually giving what I said proper consideration. The irony is that in your other comments you decry the religion of such debates with FP proponents, but in this case you are the one bringing a religious view. Nowhere did I say that FP languages are generally superior for real-world problem solving.

Re: Functional Programming Is Hard, That's Why It's Good

#106

Post by brohee » Sun, Aug 21, 2011, 7:08 PM UTC

"Pointers are a very powerful and fundamental abstraction"

An abstraction of what? Can't get much closer to the metal than with pointers. Frankly I'm not sure someone writing this have much insight worth wasting time on.

Re: Functional Programming Is Hard, That's Why It's Good

#107

Post by barrkel » Sun, Aug 21, 2011, 7:39 PM UTC

Dn_Ab wrote: post #101

barrkel wrote: post #91

Earlier quoted context omitted.

I never said "no one seems to use it". What I specifically said was that I don't think type theory has a lot to do with programming: i.e., that the majority of work put into type theory in academic contexts does not, on balance, do much to improve the state of programmers writing software, or the quality of our software engineering. "Types allow requirements changes to be propagated through all program" - what does t…

You are right that many people don't need the results of type theory for their work. But that mainly tells on the type of work you do. For example many people think programming does not need math but if you are writing physics engines, graphics engines or doing machine learning then you need some basic level of mathematical sophistication. Similarly, if your work is related to automatic verification or the transforma…

Code transformation has historically focused on syntax, but fallen down on semantics. The devil is in the fine details; C# might look superficially similar to Java, that you might create a code transformation from one to the other, but you end up falling down in really thorny areas like order of class initializers and finalization semantics, not to mention of course differences in scope and substance of libraries, standard and otherwise. When your code is pure and functional, you can make much stronger statements about it. But I think it's still an open question as to whether functional code can be made practical in the large.

"You say that most languages don't have well founded types but you fail to note that many of those same projects often have massive teams, massive code bases, fail often, run over time and are insecure" - are you suggesting that correlation is causation? Of course you aren't. But you might be guilty of thinking that something must be done, powerful type systems are something that seem good, therefore they should be used. And it's precisely this kind of implication that I'm skeptical of. When we start seeing substantial bodies of industrial software using advanced type systems rather than incorporating more limited, less orthogonal and less general subsets, I'll dial back my skepticism; but I'm willing to bet, at this point, that if that does happen, we won't have seen the end of massive software failures. I think that's a social problem, not a technical one. Our reach forever exceeds our grasp.

Re: Functional Programming Is Hard, That's Why It's Good

#108

Post by rvirding » Sun, Aug 21, 2011, 9:43 PM UTC

SoftwareMaven wrote: post #55

nirvana wrote: post #51

Earlier quoted context omitted.

Erlang is easy to read and makes a lot of sense, without requiring much brainpower... if you'll take a few days and read about it. I think its kinda silly that people will just ignore a language because it doesn't look like java/C/pascal. Its not like the syntax of erlang is stupid, or pointlessly obtuse.

IMO, the only really ugly part of Erlang is it's record syntax, but it's binary handling more than makes up for it! Doing Erlang at the day job for the last few months has been awesome. I really wish it would catch on more. Maybe when the JVM supports tail-call optimization and there is a JVM implementation of the runtime...

We know, we know. BUT no one has come up with a better syntax that really works, all the time. There have been suggestions but none have really worked.

Re: Functional Programming Is Hard, That's Why It's Good

#109

Post by ebiester » Mon, Aug 22, 2011, 1:57 AM UTC

dasil003 wrote: post #105

ebiester wrote: post #49

Earlier quoted context omitted.

Here's the problem I have with this: nearly everything I do involves state. It's called a database. Let's take a simple example, a to-do list. Abstracted out to its essentials (a piece of paper), the to-do list is exclusively state. Add a task, complete a task. Now, I can write a program that manages a to-do list in a functional language. There are two options. (Let's assume this is a web app.) First, I can make the…

It seems you didn't read my post at all, because this is a complete non-sequitur. Look at the only sentence in which I emphasized a word and notice that it is exactly the same as the opening sentence your rebuttal. This tells me that you are operating off of some mental model of what you've heard from FP proponents in the past without actually giving what I said proper consideration. The irony is that in your other c…

I'm not the one you replied to originally. You're right, it was a non-sequitur, but mostly because it was a question I'd had since I took a functional programming class in college, and never saw an answer that sat well for me. One of the other commenters gave one, so rather than contribute to the noise I just stayed silent and upvoted.

I was just taking advantage of a heated discussion to get an answer. :)

Re: Functional Programming Is Hard, That's Why It's Good

#110

Post by Dn_Ab » Mon, Aug 22, 2011, 1:14 PM UTC

barrkel wrote: post #107

Dn_Ab wrote: post #101

Earlier quoted context omitted.

You are right that many people don't need the results of type theory for their work. But that mainly tells on the type of work you do. For example many people think programming does not need math but if you are writing physics engines, graphics engines or doing machine learning then you need some basic level of mathematical sophistication. Similarly, if your work is related to automatic verification or the transforma…

Code transformation has historically focused on syntax, but fallen down on semantics. The devil is in the fine details; C# might look superficially similar to Java, that you might create a code transformation from one to the other, but you end up falling down in really thorny areas like order of class initializers and finalization semantics, not to mention of course differences in scope and substance of libraries, st…

As I mentioned in my earlier post I do not think it is the power of the type system that is key but its consistency and the accompanying tools. I am not saying programming in Coq or dependent types are the answer. I am asking, what if programmers had access to a more polished toolkit to create domain specific versions of djinn where it would guide them or help layout some basics? Knowing that the code was derived from sound axioms. Other engineers can quickly protoype the validity of their ideas by mechanically running through some equations, why not software engineers?

Already I use types in Haskell and F# to help me figure out how to layout the code - I write some basic code where I know which function it will feed into, I don't have to think much as I try to get the code to fit the types. Nothing fancy but still highly useful.

As for code transformation I don't mean generic stuff like Visual Basic to Java, I mean having a team able to write the tools themselves with full awareness of the requisite semantic mappings. Or even better, creating a dsl for the domain and then having that map down to appropriate platform specific code. But it need not be traditional development you could extend it to machine learning - say you are doing genetic programming to fit data, using types to have some level of axiomatic reasoning rather than random cross over may be fruitful. There are all sorts of uses where application of basic - not fancy theory is helpful.