Software Development

It doesn't work with the concept of processes at all. A process or worker never shows up in your software. In fact, you only need one low level process per node. Your software cannot create or terminate processes. I also do not use bytecode. At least, not in the way VM's use them. There is no fixed set of opcodes or anything like that. ML is functional, so that's out too. You'll never get anywhere with functional programming if you want to deal with concurrency.

To Anonymous (ac):

I'm sure you've already answered this, but please oblige my obvious question. Isn't Erlang a language that "deals with concurrency"? Is it not a functional language? Why will I never get anywhere with functional programming? I think I already have, and had fun doing so.

I understand that concurrent message passing is not "functional"...

You answered your own question. You didn't get anywhere with functional. You did with data flow. In fact, monads, lazy evaluation, map/reduce, arrows and all that stuff is data flow (I like picking on Haskell). If functional was enough, you wouldn't need all this other stuff.

Also, why does the security code always fail on my first attempt to post, but works after refreshing this page?

No clue. I've asked the people at Opera to look at it, but they don't seem concerned. I can't reproduce it, but I do know that problem exists. I'm thinking of switching to my own host. I think I'll do that once Project V is in the beta stage.

...but I'm not always impressed with your arguments. Perhaps you could learn a little from the kind of arguments a lawyer makes.

This article doesn't make any arguments. It just explains my POV at the time. If you want arguments, you have to go to the articles that discuss that particular topic head on. Let me know what you're interested in and I'll point you to it, or I'll discuss it directly with you.

And sorry, but it's impossible to learn anything from lawyers except how to ruin your life and those of everyone around you.

If you disagree with my arguments, please state the errors. I'm always interested in knowing where I made mistakes. But if I'm not holding my breath, it's because it has been my experience that most people have preconceived notions and cannot back them up (and that I keep hearing the same invalid arguments), not that this is the case with you though.

Finally, thank you for your comments about what I'm working on. I hope you remain interested.

My definition of "functional" is: dealing with objects that map an argument to a result in a consistent fashion.

That's too ambiguous. Can you have multiple inputs? (Yes) Can you have multiple outputs? (Doubtful) Can inputs arrive at different times? What are the restrictions on these inputs? How is the mapping or conversions activated? Do you allow side-effects? (You said no, so ok, but often "side-effect" is replaced with other terms) Is the object interchangeable with the result? (I think yes in your case, but again, some change the terms)

That's my problem with "functional". They leave the definition open so that anything cool that comes out, they can claim it's functional. I call BS on that.

Nobody believes you can do anything sane with pure lambda calculus.

Doesn't that work against functional? Even so, that's the first I've heard of this. In all the papers I've read, I've never encountered this. I've seen the opposite quite often. I remember reading a paper by Backus where he supports pure functional. I know you can add types and all that, but still. You may argue for those differences if you wish.

In fact, all cases of data flow programming I've run across are implemented in, or as extensions to, existing functional programming languages

They can work together just fine. That's straightforward data flow. The language used with this doesn't matter. My issue is that data flow is often called functional in these cases. Also, if you use functional programming anywhere at all, you lose out on a lot of power. That's why I don't use it. I can go into details if you wish.

Hmm, seems a little like data flow, doesn't it?

That's because it is. And I have no problem with that. If the day ever comes that it is publicly announced that this is in fact data flow, then what does that say about functional programming? If you look deeper, you'll start to see the failing of functional programming.

I don't see why or how you could pick on Haskell folks, because none of them are fooled by what they're doing.

I need to introduce you to a particular reader of mine. But I think that would be cruel and unusual punishment.

BTW, after what you've said, it seems we understand each other's terminology.

So my actual question here is about how you deal with typing and concurrency. Can you add new nodes during runtime, and can you change the types of messages the nodes communicate during runtime?

There's a new article I just posted. You may want to read that. It has some insights you may be looking for.

By adding nodes, do you mean execution nodes like new machines? The first version won't exactly allow it. But I see no problem with this at all. It'll be in as soon as the prototype is up and running.

The type of messages does alter at runtime, yes. Though I should mention that this only happens when transferring a workload to another node.

If you can, how do you deal with the types? Either you must have runtime types, or something interesting.

Types in Project V would take a book to write about it all. And I do have plans to write one. Like I said, my new article provides more info. You can have runtime types. But all info needed to build an entity is self-contained. Depending on the situation, this information can be stripped away, or it can remain in case it gets transferred to a new machine.

If not, don't you think this looses a lot of good flexibility?

Hmmm... I don't think in this way exactly. Types are there if they're needed and not if not. I could go into detail if you wish. Like if you want to have an executable, then it's all gone. But if you need a dynamic system that can be updated while "live", then there will be a copy of type information floating around somewhere. It's all handled automatically for you.

That's not what they teach you in law school, and I've learned other things from lawyers that I know personally. Fortunately I've never had to meet one in court. Anyway, this is exactly the kind of statement I was trying to tell you I'm unimpressed with. It's entirely unsubstantiated.

HAHAHA! You seriously think law shcool would tell their students that they'll ruin lives? Lawyers aren't meant to fix things. They're there to keep the damage going. The law is brought in as a last resort when things have fallen apart. This is all lawyers know and this is what they spread around. The law has never solved anything in the history of humanity. By the time it gets to the law, it's already over. And my experience with them confirms that this is true. You may not think so, and I sincerely hope that when you do have to deal with them, you won't lose too much of your soul. Because you will. I also have some free tickets for any lawyers wishing to go to Pakistan.

All professions require a surprising amount of skill in order to not screw up, and no single group of people are worthless or stupid. Including lawyers and functional programmers

Nah. The law is about destroying any chance of a solution. Any law book will tell you the law is of last resort. Programming is about providing solutions. If you need to deal with the law, you've already lost.

Your most recent post seems to indicate that you're dealing with runtime types, and also seems to me to imply that you can't actually change the topology of your nodes during runtime. Have I misinterpreted that? I think I could have misread on both accounts.

The topology can change at any time and it uses runtime types depending on the situation. But what do you mean by node? A software component or an execution node like a new computer. Either way, you can change both at runtime.

You can continue the discussion here. Don't worry about it going OT.

BTW, you can use quote tags a la BBCODE style. [ QUOTE ] bla bla bla [ /QUOTE ] without the spaces inside the tags.

Not really, but you can always return data structures of course.

This were just some of the questions that can come up. Not all them. My point being that it's not clearly defined. Neither is the protocol to send and receive data since it's usually handled by the compiler. That's a show stopper for concurrency.

About your quote, structures have indeed been used in the past. But it's extra complexity. When you look at why software isn't composable (or is problematic to do so), look no further than this.

Can inputs arrive at different times?

Irrelevant to the term as its used. It doesn't really have to do with the particular model of evaluation. They could be evaluated exactly in parallel, from left to right as in Scheme, or on a as-needed-basis, as in Haskell.

This isn't exactly right. Can you use a function with only one argument when it specifies two and have it do something useful? I don't think that's how it works. So it is directly linked to the model of evaluation.

That's the problem with any paradigm, including "object oriented", "constraint based", "functional", "aspect oriented", and "data flow". None of them are precisely defined, and most well informed programmers never actually use the terms unless they're speaking in very general terms.

No, imperative is fairly well defined. So is data flow. I've spoken with the guy that invented it. It's pretty clear what data flow is. I haven't used constraint based too much, but everything I've seen looked clear there too. There is some ambiguity with OO, but again, we can ask Alan Kay what he thinks. And I've linked it many times. He does not call C++ OO.

Ever since I realized that every object oriented language implements their own flavor of object orientedness (common lisp even implements a whole class of object orientedness, and calls it the meta object protocol), I stopped using the stupid term. Same thing should go for data flow programming. Do you mean functional nets? petri nets maybe? functional reactive programming? maybe even message passing? They're all equally meaningless unless you have a well defined logic to go with them.

You first sentence agrees with what I just said above. But this should not apply to everything else. You just pulled a Brooks and used a lawyer tactic. Just because something applies to OO, please do not extend those conclusions to other things such as data flow. Simply go check out JPM's stuff if you want a clear definition. For OO, go check out Alan Kay's stuff.

You can have completely different underlying model than lambda calculus, like for example components and message passing, and still program in what people would call a "functional style" by passing components through channels, and creating new components based on composing existing ones.

That's an unsubstantiated blanket statement and you know it. Please do not associate components as defined in data flow and then claim it is (or can be) functional. This is exactly the kind of thing that I find dishonest about the functional community. The differences between the two styles are not trivial.

Say you're done developing, and runtime types are removed. Now your program spawn a new component and starts feeding data to it. How does the new component know its receiving a valid type?

The new component knows because only valid types can be received if the runtime types have been removed. If something else could arrive, then runtime types (in some form) would remain, even in compiled versions.

3) You have some sort of strange incomprehensible mixture of runtime and static types (which intuitively doesn't seem possible).

Huh? C++ does this. It's not rocket science. If you have all the type info you need, you strip it out. If not, you keep it in and inject some of the compile time code into your binary. That's what C++ does. Pascal/Delphi does the same. I'm sure others do the same.

If you're talking about 100% new components, then there are ways to deal with that too, but again, the compiler will know if your design needs it and will make the appropriate decision on what to do.

Actually, I might go so far to say (and this might be really stupid, so don't quote me) that anything that implements the concepts of category theory could be called functional. [...] You can very very easily implement the rules of category theory in any language, but then you're fighting against existing language constructs if it's not "functional".

I use ZFC. For predicates, I use properties (kind of like members, but changes the meaning of the type) as well as data flow components to spcify the relation between entities. In this way, I can stream data through predicates, something not possible in functional style of programming. After having looked at this intensively with the help of some of my other readers, I can say that the argument that category theory being "functional" doesn't hold much water with me. In fact, there is a name for doing category theory similar to what I'm doing. Unfortunately, I can't remember what it is called right now. When I do remember it, I'll post it so you may inspect it and see that even established literature on the topic would disagree with your assertion.

As a side-note, my use (often limited) of ZFC and data flow predicates is what allows me to infer information about types and if they are needed at runtime. I'm betting some of my readers are shocked that I'm using established (though perhaps less known data flow predicates) to form the basis of my system.

Many languages stick with morphisms, and don't bother with functors (e.g. PHP and Java) (I hope I have my terminology straight), and many other languages simply throw out morphisms entirely and mainly use procedures (like C and common lisp).

I understood morphisms as already being linked to the data (where this data stay intact). So I don't consider that PHP or Java except maybe for some containers. Perhaps that is what you mean and not the ability to dynamically attach morphisms to data. I'm afraid you've confused me even more by lumping C and lisp together. Or do you mean that they don't have the ability to group many transformations together with the data structure? That would make sense I guess.

Anyways, I can tell you what I did with Project V. There is a certain class of components called storage components. These retain their data. So any outgoing data can be transformed by linking up your own components. The end of this chain can be used as a morphism. Remember how I said that properties can change the meaning of a type. Well, you can use a morphism in place of a static value. Because frankly, a static value is equivalent to a storage component without any intermediary transformations. You can use morphisms in place of members variables too.

Morphism will only be included in the next version, but they have been planned for a while now. The reason it must wait is because it works in a fundamentally different way than the rest of the data flow network. It works on requests for information instead of data moving forward on its own (push vs. pull). Morphisms serve to trigger the completion of that network. Once the circuit is closed, then data will start moving on its own as usual.

Functional programming is just applied category theory.

No, it's only one specific kind of category theory. Sorry.

If you're not already familiar with category theory, here's a really good introduction I found on Reddit a bit ago:

http://math.ucr.edu/home/baez/week73.html

Gotta love reddit, eh?

You'll have to forgive me if I instead look elsewhere. For instance, Wikipedia does have a few gems on the Morphism page.

In category theory, morphisms need not be functions at all and are usually thought of as arrows between two different objects (which need not be sets).

A category C is given by two pieces of data: a class of objects and a class of morphisms.

My favorite part is "need not be functions at all". Brilliant! I seem to be the only one that actually LOOKS at these differences and what the consequences are.

Anyway, as long as your morphisms and functors abide by the rules in that link above, you definitely have a functional programming language. That's how general the term is.

No, I already showed how this isn't so. But it does show how functional programmers like to make things more general than they actually are in order to consume anything that looks good and then incorrectly call it functional. In fact, logic programming would have a way better claim to category theory than anything functional.

But before you invest a lot of time in to something like that, I'd really like to see something in the form of a research paper that just states the logic behind the type system, and maybe throws out a few examples.

Can you think critically? Can you determine whether a paper is valid or not without using the fact that it's been published? Most of the stuff out there is bunk. At the same time, I often get the impression people think I pull this stuff out of my ass.

Looks like only registered members can use bbcode style tags.

About the comment, I was just asking because you said you wanted to see some references or something. From my POV, that's irrelevant. Look at it and decide if it's good or not.

edit: I should add that if there is existing stuff written on the topic, then yeah, it's worth checking out. But about judging something based on other people's opinions (and that's all most papers are) is not the best way to go about deciding the quality of something.

Oh, sorry! I completly misunderstood. I thought you meant you wanted to see something already written by someone else (because a lot of people won't accept anything that isn't published by someone else). I get this kind of criticism all the time and incorrectly assumed you were saying the same.

I'd be glad to write something like that. That's actually a good idea.