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

A different view on Functional Programming

matiasmorant.wordpress.com

Post reply on HN
Print view View original

71–80 of 100 posts

Re: A different view on Functional Programming

#71

Post by tigershark »

dvt wrote: post #23
wvlia5 wrote: post #14

Earlier quoted context omitted.

A good analogy would be music notation (pentagram) I could describe a piece of music in English prose, telling you were to put your fingers and for how long. The language itself would be easier to understand, but the efficiency of information transmission would be very low. Chinese looks complicated, unless you know Chinese. The ultimate criteria to judge a language should be how efficiently (concisely) it expresses…

> The ultimate criteria to judge a language should be how efficiently (concisely) it expresses the concepts of the subject matter. Some might say that the ultimate criteria to judge a language should be how quickly an inexperienced user starts to be fluent in it. I studied math (so the syntax isn't really an issue), but I think functional programming is completely inappropriate for general purpose programming tasks (…

Do you mean like purescript or ReasonML that is the foundation of Facebook messenger or F# that is used for plenty of iphone apps?

Re: A different view on Functional Programming

#72

Post by maxxxxx »

jjaredsimpson wrote: post #58
maxxxxx wrote: post #9

Earlier quoted context omitted.

I always envy people who can work on something that can be expressed with math or some other kind of consistent logic. Most company problems are inherently messy and you just end up with a litany of convoluted code.

Example please? Because I'm tempted to respond that there are no inherently messy problems, only insufficient solutions. What problem could possibly exist that only could be implemented in a convoluted way? Sounds more like: me and my team made trade offs that were, in retrospect, bad and now we don't know how to transform our code into a new program will fulfills the same requirements but is easier to inspect and un…

In big companies requirements often change when strategy changes or some top manager has set his mind to something. So you are always behind the curve and you never get a set of stable requirements. Unfortunately that's reality in many companies.

I pity people who have to work with SOAP or Salesforce.

Re: A different view on Functional Programming

#73

Post by dahart »

SwellJoe wrote: post #63
dahart wrote: post #57

> it’s usually defined by some of its features, such as: reification of functions, avoidance or banning of functions with side-effects, use of higher-order functions and so on. But, doesn’t that sound like a collection of random features? What’s the motivation behind them? It's a bummer to pose that question as though there isn't an answer, when the answer is well known and very important. The motivation of avoiding…

"The APL & J examples aren't very enticing to me. I'm curious about them, but I wouldn't want to work in a codebase where if you don't know what the name of the function means, you can't figure out what it does." Is it possible that APL and J fail this test only because you (and I) don't know how to read APL or J? I think there are some languages that end up being difficult to read due to failings of the language, bu…

> Is it possible that APL and J fail this test only because you (and I) don't know how to read APL or J?

Yes and no. :) Its a great point; familiarity and practice is a big part of comfort and productivity, absolutely.

I love playing code golf in Python. You can make Python very concise, and very unreadable. But I don't write professional code that way, and I definitely don't have a goal of making production code as concise as possible. Conciseness is good for very small projects, for the 5 minutes while I'm working in the code. Conciseness is awesome for Project Euler. Too concise, and when I come back to my own code days/weeks/months later, I can't understand it at all. Anyone who's coded for long enough on big projects will know the feeling of coming back to clean, well commented, semantically explicit code years after writing it, only to have no clue what it's doing or how it works.

I also know how to read math, and math (typically... almost always) has this very problem. The conciseness is good for proofs and multi-step algebra, you need it while deriving things and working with the math. Once you codify it into a process, the conciseness is a big obstacle to understanding and code safety. I make lots of mistakes with math because it's too abstract. The mistakes are usually easy to fix because it's only a line or two at a time, but it'd be unworkable and unreadable if I had many thousands of lines of math the same way I have with regular code.

Re: A different view on Functional Programming

#74

Post by mikebenfield »

mrob wrote: post #55
mikebenfield wrote: post #26

Earlier quoted context omitted.

> aren't particularly fond of deciphering complicated math equations? But it's not complicated. One of the great things about mathematical expressions is that they are simple . But two of the other great things are that they are concise and unambiguous, and it's those two that unfortunately lead many students to think they are complicated.

Mathematical notation is highly ambiguous. See recent discussion of the alleged proof of the ABC conjecture ( https://news.ycombinator.com/item?id=15971802 ). If it was really unambiguous then we could parse it like computer code and decide if it is correct or not without all the controversy about what it really means.

Well, mathematical notation is written for humans, not computers. With a bit of context, and comparing to human language (not code), it is very much not ambiguous.

Re: A different view on Functional Programming

#75

Post by mikebenfield »

kortex wrote: post #61
mikebenfield wrote: post #28

Earlier quoted context omitted.

> J is even worse. I stared at the J code for a full minute without any comprehension of the language syntax or what was being accomplished. That code isn't readable or maintainable. It is bad code. But why does code need to be readable to someone who doesn't know the language? Yes, it's true that Python and some other languages are pretty readable even to people who haven't written any of that language, and that is…

Look at the top 7 languages used in industry: C/++/#, Java, JS, Python, and VB.NET. They all more or less follow "C-like syntax". In fact compare APL or J to any of the Tiobe 20, and you'll see they are wildly different in look and feel. https://www.tiobe.com/tiobe-index//

Well, I'm definitely aware of what mainstream programming langauges look like. But I think the popularity of a language is only loosely related to its technical attributes.

Re: A different view on Functional Programming

#76

Post by mort96 »

ASipos wrote: post #36
jlg23 wrote: post #13

Earlier quoted context omitted.

Understood. Just to be clear: I am saying that in most scenarios nobody understands the problem; people figure it out on the go. Overall I really like the article because it spells what is an essential feature of fp for me much better than I could have. It is just that it is too far from reality of most programming jobs (unless you happen to be Peter Norvig, working on the Mars rover).

I would be interested in seeing some more examples of that kind of jobs

Well, say you're writing code to interface with a mostly undocumented hardware h264 video encoder. Partly through spotty documentation about general use of the video4linux system, partly through that one piece of example code which exists to interface with the particular encoder, you make something which, if given a buffer of a raw I420 video frame, produces a buffer of encoded h264 video frame.

Now, you figure out that the decoder which will decode the video expects the video stream to look different (specifically: the encoder produces only one picture parameter set and sequence parameter set at the beginning of the stream, but the decoder only understands the video if every key frame contains its own copy of the PPS and SPS). After a mix of reading source code and talking to people online, you figure out that there's an (undocumented) way to configure the encoder to include a PPS and SPS with every key frame. You figure that this is really something which must be specified by the h264 specification, so either the decoder is breaking the specification, or the hardware's encoder is; but at the end of the day, it's your fault if the encoded video isn't displayed on the receiver.

Then, you figure out that while you're trying to encode 1920x1080 video, the encoder is only able to encode 16x16 chunks, so the output image is actually 1920x1088. This isn't documented anywhere, but after speaking with the person who wrote the driver for the hardware encoder in IRC, you learn that there's no way to make the driver handle it properly, at least not yet. Therefore, you extract the picture parameter set produced by the encoder, make some changes to have it include information about how the picture should be cropped by the decoder, and splice the modified PPS into the buffer for the encoded frame.

That is what I've been doing at work (with some modifications; the above example is derived from working with two separate hardware video encoders). Even if it was possible to obtain exact documentation on how the encoders worked, sitting down and thinking really hard about how to describe the problem mathematically before writing the code would've been really hard, but because nothing really is documented, I will go so far as to claim it's impossible.

Re: A different view on Functional Programming

#78

Post by wvlia5 »

skywhopper wrote: post #59

This is an interesting post, and the code sample from APL got my attention. I have questions. How do I learn/get/run APL or J? How do I even type the APL code given? What does the J code even mean? As for the content... "makes code super concise (less room for bugs)" Unfortunately, while this sounds great, it does not logically follow. And while geometric mean is well-defined and understood, most functions I'm probab…

>How to type APL characters

They are unicode characters. Type them the way you would type any unicode character. If you have not yet found a practical way of doing it, there are plugins for editors to help you type APL characters with no hassle.

>How to learn APL?

There's a Dyalog APL manual which is quite clear, Google it. Also, you can use the GNU APL interpreter. I would recommend learning APL first, only by reading the Dyalog manual and writing programs with pencil an paper, then learn J in detail.

> How do I learn J?

Jsoftware provides a free interpreter. They also have a sleek interpreter app for Android. I would recommend to download this app and go through the project Euler problem set. Jsoftware provides all the documentation you will need in their webpage

http://code.jsoftware.com/wiki/System/Installation

> what good will J do for me?

The best would be to learn it and see it for yourself. Sadly, you find yourself in Paul Graham's Blob Paradox.I can't get you out.

Re: A different view on Functional Programming

#79

Post by skybrian »

naasking wrote: post #33
skybrian wrote: post #7

Have you considered that many people aren't particularly fond of deciphering complicated math equations? For them, your argument is in favor of avoiding functional languages. Too math-like! A step-by-step procedure might be simpler to understand.

> Too math-like! A step-by-step procedure might be simpler to understand. A step by step procedure is exactly a mathematical process. Mathematical notation is just a shorthand for some procedures so you don't have to spell out every single step every time. You'd be well served by learning them!

Mathematically equivalence has little to do with readability. Readability is both important and subjective. Sadly, few people investigate what their audience actually finds easy to read.

Re: A different view on Functional Programming

#80

Post by agumonkey »

Arainach wrote: post #20
wvlia5 wrote: post #14

Earlier quoted context omitted.

A good analogy would be music notation (pentagram) I could describe a piece of music in English prose, telling you were to put your fingers and for how long. The language itself would be easier to understand, but the efficiency of information transmission would be very low. Chinese looks complicated, unless you know Chinese. The ultimate criteria to judge a language should be how efficiently (concisely) it expresses…

Understandability is more important than conciseness in a team environment. In a team, you're not writing code for you - you're writing code to be reviewed by other people, integrated with other people's code, and maintained by other people in the future. In the example from this article, all developers I've ever worked with would understand what the "good old C" example is doing within seconds. Most would understand…

Forget it. It's a different culture, it's void to try to understand this without leaving your previous point of view.

And for the laughs, I've been taught java first, and read a lots of C code, and I had a very bad understanding of what was going on. APL or similar don't cause that confusion. Actually, after years of FP, I now get C a lot more. To quite Hickey, it's not easy but it's simple. There's a set of primitives and operations, a clear system. It fits some peoples brain. For others, imperative state machine are just what they like.

Post reply on HN