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

What Color Is Your Function?

journal.stuffwithstuff.com

Post reply on HN
Print view View original

131–140 of 153 posts

Re: What Color Is Your Function?

#131

Post by ufo »

tel wrote: post #126
munificent wrote: post #120

Earlier quoted context omitted.

Recursing can build up very long promise chains if you aren't careful and also just isn't a natural way for many programmers to express many kinds of code. Even simple branching gets nasty in many cases if, for example, one branch does something async while the other does not. You also lose try/catch.

Yeah, agreed. It's functional, but technically weak. This might be a place to introduce functional pipelines like Haskell's Pipes, Machines, Conduits. They solve the effectfull iteration and streaming problem, but the mechanism is heavily transformer based.

The problem is that while you can introduce FP abstractions to structure your programs, they are not the same abstractions that you use in the synchronous (imperative) code. You still end up in a situation where your programs is written in two colors that don't play nice with one another (for example, a "foreach" combinator doesn't work on both sync callbacks and async callbacks)

Re: What Color Is Your Function?

#132

Post by dllthomas »

proveanegative wrote: post #106
lmm wrote: post #104

Earlier quoted context omitted.

You can write very safe code by using structs (even 1-element structs) for everything. But there's no generics system and very little in the way of safe tools for making one; writing a safe "generics runtime" and macros to use it puts you halfway to writing a new language.

>structs (even 1-element structs) for everything. Are there any large C projects written in this style?

I don't recall the LOC, but I used this style at a recent position. Basically, the idea is not to use bare primitive types anywhere - instead wrapping them in something semantic. Probably the two biggest wins from this approach were distinguishing types of indexes and (in the particular project) distinguishing price from quantity.

It does add a bit of boilerplate. For the indexes in particular, foo_lookup(foo, idx) is substantially safer than foo[idx.value] - but then you've gotta write the lookup functions (which may just be a macro but is still a bit of cruft). Locally, if using var.value everywhere in math is getting ugly, you can of course pull things out into temporary primitive variables - enforcing things at the boundaries between functions provides almost all of the benefit.

Re: What Color Is Your Function?

#133

Post by dllthomas »

tel wrote: post #101
JoshTriplett wrote: post #66

Earlier quoted context omitted.

It's a good type system. Many programming languages don't support this kind of type information, notably C.

I'm always curious how far a sufficiently motivated masochist could go with C... I guess it's just C++ ;)

I intend to write a blog post on this at some point... but I recently colored functions in C by passing an empty struct as the first argument, with a standard name and annotated with __attribute__((unused)). The propagation was manual, but trivially easy, and it proved a major help in refactoring when I had to move some functionality to a differently colored context. I was even able to get some (extremely limited) polymorphism using unions to express "any of these colors". It could even be marginally nicer if C allowed passing one union as another if the first was a subset of the second - which I think would be correct - but really parametric polymorphism would be the bigger win...

Re: What Color Is Your Function?

#134

Post by chriswarbo »

rntz wrote: post #77
Nitramp wrote: post #73

Earlier quoted context omitted.

Effect Typing and Monads are yet another colour for the lipstick you put on the pig. You still have non-composability (i.e. the async monad spreads through your code), you still have the complexity, you still don't have proper tracebacks without special runtime support, and you still have the inefficiency that Bob didn't actually mention (unwinding all those stacks all the time). Languages with threads (Java, C#) don…

Go's "good, pragmatic engineering" solution to the problem - lightweight threads, channels, and the communicating sequential processes model - is built on the back of decades of academic research, including programming languages research. And now for some computer language geekery: Go solves one "code color" problem (concurrency/asynchrony), by hard-coding the solution into the language. Go programs are written in a…

> This hard-coding solution has very concrete advantages.

True, but you missed the major disadvantage of doing everything in a monad: there may be horrible side-effect demons lurking in every line of code!

In my experience, the most egregious offenders are shared mutable state (AKA multithreading) and exceptions. Introducing multithreading or exceptions into an application which previously shunned them feels like switching to a whole different language; one where all our intuitions and guarantees can be undermined at any time.

Re: What Color Is Your Function?

#136

Post by jongraehl »

Roboprog wrote: post #130

Funny. I thought he was talking about Java 8 for a while. We (eventually, when the rest of the stack catches up) get functors / lambdas, but: * red = instance methods. * blue = static methods, which cannot call an instance method.

That's not true. You can call an instance method from anywhere given an object. There's just no implicit 'this' in a static method.

Re: What Color Is Your Function?

#137

Post by JoshTriplett »

tel wrote: post #101
JoshTriplett wrote: post #66

Earlier quoted context omitted.

It's a good type system. Many programming languages don't support this kind of type information, notably C.

I'm always curious how far a sufficiently motivated masochist could go with C... I guess it's just C++ ;)

The Linux kernel is a good example of just how far you can push C (plus GCC and Sparse extensions), including type system enhancements (__user and __kernel), pseudo-OO (kobject, many structs of function pointers), and other safety features.

Re: What Color Is Your Function?

#138

Post by Roboprog »

jongraehl wrote: post #136
Roboprog wrote: post #130

Funny. I thought he was talking about Java 8 for a while. We (eventually, when the rest of the stack catches up) get functors / lambdas, but: * red = instance methods. * blue = static methods, which cannot call an instance method.

That's not true. You can call an instance method from anywhere given an object. There's just no implicit 'this' in a static method.

Er, what's that? I seem to have lost a receiver for your message...

Once you go functional, instance methods start to look like a special klugery for currying the first argument to a function. Go and Nim (for instance) hint at this more than a little, as well, with their OOP syntax.

Bundling two kinds of methods within a "class" starts to feel weird when you start using individual functions.

Re: What Color Is Your Function?

#139

Post by [deleted] »

z3t4 wrote: post #112
Sharlin wrote: post #82

Earlier quoted context omitted.

It helps syntactically but does nothing about the main problem: composability. Each of your functions has to know which function to call next, instead of just having one function that invokes n other functions in order. That's what next() is meant for.

For composability in JS I use small utility modules like "inOrder": function beforeWifeComesHome() { takeTheTrashOut(); function takeTheTrashOut() { inOrder([openDoor, goOut, emptyTrash, goIn, closeDoor]); } } But it would be easier to let the compiler take care of the async calls and insert callbacks automatically so that you can think synchronously while the program works asynchronously. And if you want to run stuf…

[deleted]

Re: What Color Is Your Function?

#140

Post by seanmcdirmid »

tel wrote: post #102
seanmcdirmid wrote: post #79

Earlier quoted context omitted.

Also, what about Koka ? http://koka.codeplex.com/ and http://research.microsoft.com/en-us/projects/koka/ From the latter: > The Koka project tries to see if effect inference can be used on larger scale programming. The language is strict (as in ML), but seperates pure values from side effecting computations (as in Haskell). Through the effect types, there is also a strong connection to its denotational semantics, whe…

I just wanted to say that I've finally taken a look at Koka after hearing you mention in on HN many times. It's very nice! I appreciate how it provides most of the bang of effect types much more conveniently than one might expect with the explicit monadic structuring going on in Haskell. Have you looked at Frank [0] by any chance? It has a very similar row-effect type (I guess these were both first explored in Eff?)…

I'm not versed in this area, but I listen to Daan talk about Koka a lot. You might want to ask him directly about Frank.
Post reply on HN