> One solution to the problem of partial functions is to
> make values as types. A range type from X to Y, for
> example, can only statically accept a value that is within
> the range; at run time, if we have a value that may be out
> of range, we statically promote the value to the X..Y if
> the value is inside the range, and we declare an
> alternative action when the value is outside of the range.
> For example (in C++ parlance):
>

I think X10 is trying to solve this... I am convinced X10 is the real java++ after reading the specification (not scala).

http://dist.codehaus.org/x10/documentation/languagespec/x10-175.pdf

> > I'm also not sure functional programming is as much
> > awkward as it is unfamiliar to the mainstream. I.e., it
> is
> > awkward to people because they are unfamiliar with it.
> I
> > find it awkward sometimes, especially when I would need
> to
> > use recursion to be full-on functional. I do use
> recursion
> > sometimes, but since I'm working in Scala, I can also
> just
> > use a while loop and a var, and I do that from time to
> > time. I make sure it is all local, so each thread would
> > get its own copy, then it's perfectly fine to do it the
> > way its done in Imperative-stan.
> >
> > If you forget the word "functional" and just say final
> > variables, immutable objects, and methods that just
> return
> > a value based on just the passed data without having
> any
> > side effects, that really doesn't sound that unfamiliar
> or
> > awkward. String is an immutable object. Is
> > java.lang.String awkward for Java programmers to use?
> How
> > about String.valueOf(5)? That's a pure function. I just
> > operates on its input, returns a value, has no side
> > effects. I doubt that's awkward for Java programmers,
> and
> > neither are final variables. What is awkward, probably
> > however, is using recursion instead of looping.
> Recursion
> > isn't that hard to understand and I figure most Java
> > programmers know what it means and how to do it, but
> it's
> > not the way we usually have done things in
> > Imperative-stan, so we're not used to it.
>
> That's good for simple things like a string, but if more
> ambitious things are tried, then FP gets very complex
> quickly. Just witness how difficult it is to manipulate
> trees (search for Huet's zipper pattern), for example...I
> seriously doubt that the majority of programmers will ever
> understand such things as the zipper. And then there are
> other complex stuff...for example, in trying to program a
> game in Haskell, one has to use something like
> Haskell/Arrows and be familiar with concatenative
> programming...pure FP certainly isn't for the common folks.
>
That may be true. I don't know. I've never heard of "the zipper," and don't know Haskell. I'm not sure pure FP is what anyone was talking about here. Is Clojure trying to be pure FP? I don't know Clojure much yet, but it looks from the outside like it offers ways to do mutation. It just tries to make it more explicit. Scala for sure isn't pure FP. Behind an actor, for example, you can do things just as imperative as you want so long as you're sure not to share that mutable data with other actors or threads. In fact you can write Scala in the same way you write Java if you want.

What I find has made my code better is not going pure FP, which I've never done, but turning the knob more towards the functional style. I haven't experienced that the functional style added complexity, possibly because I've been doing a hybrid functional/imperative style. Actually I was always doing a hybrid. It's just prior to my exposure to Scala I wrote more imperative and less functional. Now it is the other way around.

Well, the other nice thing about Scala is that you get to argue/defend with both sides.

On topic: There's a Clojure lecture about concurrence on http://blip.tv/file/812787

> > That's good for simple things like a string, but if
> more
> > ambitious things are tried, then FP gets very complex
> > quickly. Just witness how difficult it is to manipulate
> > trees (search for Huet's zipper pattern), for
> example...I
> > seriously doubt that the majority of programmers will
> ever
> > understand such things as the zipper. And then there
> are
> > other complex stuff...for example, in trying to program
> a
> > game in Haskell, one has to use something like
> > Haskell/Arrows and be familiar with concatenative
> > programming...pure FP certainly isn't for the common
> folks.
> >
> That may be true. I don't know. I've never heard of "the
> zipper," and don't know Haskell. I'm not sure pure FP is
> what anyone was talking about here. Is Clojure trying to
> be pure FP? I don't know Clojure much yet, but it looks
> from the outside like it offers ways to do mutation. It
> just tries to make it more explicit. Scala for sure isn't
> pure FP. Behind an actor, for example, you can do things
> just as imperative as you want so long as you're sure not
> to share that mutable data with other actors or threads.
> In fact you can write Scala in the same way you write Java
> if you want.

Having coded more trees by hand in Java and C and C++ than I care to admit, I'll say that Huet zippers are far simpler and easier to use than traditional approaches.

But anyway, no, clojure is not aiming to be pure FP -- it has top-notch Java interop features, and so therefore is not pure FP in a definitional way, regardless of other design decisions. As for it 'offering ways to do mutation', the point is that it offers a framework in which the semantics of change are known, and simpler than anything-goes imperative mutation. Of course, if you don't want to buy into that, go ahead and fiddle with any Java libraries you want (this becomes necessary when doing work in Swing, for example).

- Chas

This sounds promising to me.

It seems to me that all advancements with respect to languages have somehow been rooted in removing choice. GC, a now trite example I think, said to developer's "Managing your own memory is hard. No, really, it's hard. Trust me. So I am not going to let you do it."

C said, "Dealing with registers (say) is hard. No really, it's hard. Trust me. So I'm not going to let you do it." (Yes, I know the old (useless) register keyword. Please, this is a forest discussion not a trees discussion).

This perhaps explains why I don't find any new language that I've seen so far in the wild as particularly compelling. For example, and this is not a troll, Scala seems to me to be the C++ of Java. It certainly allows me to do some things more easily than I can in java (easily might simply mean succinctly) but it doesn't force me into something that makes my life easier. Indeed, it seems quite the opposite.

I'm not sure what's next. I'm not sure where Hickey's perspective might eventually lead, if anywhere, but I'm seriously attracted to the that's-hard-so-I-disallow-it proposition it suggests.

Finally, I have to say I'm not convinced that are many, if any, mechanical changes that can be made to software development that will make it better (a multi-dimensional statement to be sure). The truly hard problems I have (had) to deal with almost never have to do with my individual ability to express myself. Rather they are around others understanding my expression in an unambiguous fashion. But that's probably more a lack of imagination on my part rather than a truism.

---Rick

> And yet, despite it all, the vast majority of useful
> software is built using the old imperative/mutable
> warhorses.
>

Sure, but this is sort of a horrible argument isn't it? I could just as easily have said with respect to the car, "And yet, despite it all, the vast majority of transport is provided by the good ol' horse and wagon." Horses totally, totally worked. The problem was all the shit that came with the solution.

---Rick

> > And yet, despite it all, the vast majority of useful
> > software is built using the old imperative/mutable
> > warhorses.
> >
>
> Sure, but this is sort of a horrible argument isn't it? I
> could just as easily have said with respect to the car,
> "And yet, despite it all, the vast majority of transport
> is provided by the good ol' horse and wagon." Horses
> totally, totally worked. The problem was all the shit that
> came with the solution.

I'm just making the observation that, as far as side-effect free functional programming goes, people have been advocating it for decades now and, empirically, imperative programming languages have been where most of the application work gets done.

Maybe the right tipping point hasn't been reached. Maybe there will be a cascade to that style of programming when everyone realizes that they get parallelization "for free." Maybe that's a total illusion, since the vast majority of enterprise apps spend a lot of time down in the needly bits of domain models, with small, sequential problems that don't lend themselves to parallelization anyway. I don't know.

Take it back to the title: "Time is the new memory." When memory got solved, I barely even noticed: I kept making the same mistakes I always had with memory management, but I got to make them everywhere! When I see a parallel solution of similar costs to the end user, *then* I'll be impressed. Changing our entire programming model to solve a problem most of us don't have?

No thanks.

OTOH, you know my take on modern cars... :)

Cheers,
Carson

> Take it back to the title: "Time is the new memory." When
> memory got solved, I barely even noticed: I kept making
> the same mistakes I always had with memory management, but
> I got to make them everywhere! When I see a parallel
> solution of similar costs to the end user, *then* I'll be
> impressed. Changing our entire programming model to solve
> a problem most of us don't have?

You'll have that problem *today*. Your code will be going along, check that the state of some object is Bar, carry on, and then fail or do the wrong thing because the state of the "same object" is Baz 14 lines later as a side effect of one of the 146 methods your code called in the interim that you didn't know about or forgot about when you wrote the code originally.

Just sayin'. :-)

- Chas

> You'll have that problem *today*. Your code will be going
> along, check that the state of some object is Bar, carry
> on, and then fail or do the wrong thing because the state
> of the "same object" is Baz 14 lines later as a side
> effect of one of the 146 methods your code called in the
> interim that you didn't know about or forgot about when
> you wrote the code originally.
>
> Just sayin'. :-)

Sorry, man. It just doesn't come up that much in my day to day programming. Since I'm down in the gronky bits of domain models most of the time anyway, there just isn't a lot of parallelism to be extracted.

There are certainly places where I might adopt a very defensive programming model wrt to threading, but, for the most part, the web server threading model and optimistic concurrency at the database layer do me just fine.

No fuss, no muss, no Haskell.

Cheers,
Carson

Ugh. I hate that I can't edit posts:

Second sentence should start "And since" rather than "Since" (I'm making a secondary point since it doesn't directly respond to... Oh never mind.)

Cheers,
Carson

> > You'll have that problem *today*. Your code will be
> going
> > along, check that the state of some object is Bar,
> carry
> > on, and then fail or do the wrong thing because the
> state
> > of the "same object" is Baz 14 lines later as a side
> > effect of one of the 146 methods your code called in
> the
> > interim that you didn't know about or forgot about when
> > you wrote the code originally.
> >
> > Just sayin'. :-)
>
> Sorry, man. It just doesn't come up that much in my day
> to day programming. Since I'm down in the gronky bits of
> domain models most of the time anyway, there just isn't a
> lot of parallelism to be extracted.

The point of my last message was that parallelism is a similar but unrelated issue to the scenario I described, which can and does happen in single-threaded code all the time.

- Chas

> The point of my last message was that parallelism is a
> similar but unrelated issue to the scenario I described,
> which can and does happen in single-threaded code all the
> time.

Huh. I guess I see your point. But when that comes up I typically find it pretty easy to set a breakpoint on the thing in question and see why it got updated. The only time I'll occasionally find myself pulling my hair out is when there is a threading issue, which is when I'll switch over to a more defensive programming model to isolate the, er, isolation.

Same thread updates aren't something that I find hurting me very often, and seem pretty easy to track down.

Cheers,
Carson

> The above does not have a problem, because a 32-bit word
> will be set with one instruction, and so invariant
> violation can not be achieved.
> So the problem clearly is not mutability.


augh.

i really respect Achilleas but... :-)

we all need to do a better job understanding what the issues are with concurrency! otherwise we are just saying stuff that is plain wrong.

the problems with concurrency are multi-levelled. at the low-level it is "internal" race conditions, which is what Achilleas was pointing out.

but at the higher level, it is "external" race conditions because one often wants to test-and-set, and if the test and the set are not in the same "transaction" then you get that "external" race that can make things fubar.

sincerely.

> > One solution to the problem of partial functions is to
> > make values as types. A range type from X to Y, for
> I think X10 is trying to solve this... I am convinced X10
> is the real java++ after reading the specification (not
> scala).

pretty please, anybody who is interested in this, go read up on <a href="http://www.google.com/search?q=site%3Alambda-the-ultimate.org+dependent+t ypes">dependent types</a>. Achilleas knows of that stuff i believe.

and then go read (which i cannot find right now bloody heck) Xavier Leroy's claim that it just makes your code suck, and you should just use an external prover instead. of course he's all about Coq so maybe it should be taken with a grain of salt.