Software Development

Well, the messaging part is not a functional feature. It's a data flow feature if the linking of processes is done outside the process that sends the message and it's imperative if the process decides where to send the message. Again, this shows how data flow concepts are making a surge.

Thanks for the notice whomever you are...

But James Robertson? Seriously? Might as well be Micheal Jackson talking about computers. Ah hee hee. What a complete waste of my time. And that other guy? Ad hominem attacks? WTF? YAWN! Nothing even the least bit clever. Zero entertainment value. I think MJ would have been a little entertaining at least. I'm sure he could sort the men from the boys. For James sake, it's a good thing MJ isn't actually here.

[/B]jRave:[/B] Before dismissing something, perhaps you should read up on them. I have nothing to prove to anyone. I understand these topics better than most (even the so-called greats). If you wish to discuss anything, I'm right here. Let's talk shop if you think I'm wrong. I can tell you right now that I can support and prove everything that I say. Of course, this blog entry is about predictions. So these predictions may not turn out exactly as stated. However, I can defend all the arguments and the facts on which they are based.

Anonymous:

"Not only because 'message' is a term originally invented in the OO-context ..."

No, a message predates computers. A message is anything that can be sent to another party. For example, when you send a letter in the mail, there is no awknowledgment that it was received unless you specifically request that information.

Weave Jester:

"If there's no acknowledgement, how does the sending node know whether a message has been received or lost in transit?"

You're being self-contradictory if you're saying a message must have acknowledgement.

By your definition:
Message = info + ack

Substituting your definition of a 'message' in what you said:

"If there's no acknowledgement, how does the sending node know whether information & acknowledgment has been received or lost in transit?"

Do you see why your question makes no sense. You're using two definitions for your message. And if the message doesn't need to be both info + ack, then you've answered your own question that a message can be info alone without ack. What you do is use another infomation packet (aka message) for the ack. In fact, because of the above, it's impossible for a message to be both information & ack because I've just shown a proof by contradiction.

So what you're actually talking about is a protocol that can be built from several messages. Look at TCP. It sends several packets (messages) to handle this. But UDP has no such requirement, so there's a real world example of messaging without ack.

Anonymous #2:

"Uh .... you do not know a damn thing about Object Oriented Programming. If you did, you wouldn't have made such asinine statements. Locked down technologies that do not change? Fixed set of exposed functionality? What kind of nonsense is that? At least do some reading before throwing around terms you don't understand, and pretending that you do."

I never pretend. I understand and can defend everything I say. If OO is so great, then why is maintenance so difficult. These aren't my words. So if you disagree, then you have the entire computing industry up against you, never mind anything I could ever say. BTW, why do you think interfaces exist in OO? Also, how does one discover what functionality an object has in order to use it? Your questions indicate that you have no clue.

Weave Jester:

"In order to send a message from A to B, you need a bidirectional communications channel."

No, you don't. If you did, communication would actually be impossible because it would imply that BOTH sides would need to activate at the exact same time. We know this is impossible as it would require prior synchronisation, but this sync would require its own communication. No, this is ridiculous. So if BOTH sides activating at the exact same time isn't a requirement, then it means that it's OK for one side to activate before the other which means you don't need bidirectional since there is only one side active.

I just refuted your statement. I hope this is clear. Sending a message does not have to be reliable. Otherwise, nothing would ever get done. Another example is SETI listening for alien messages. There is no way we can respond, so how can we listen for messages if it's impossible without bidirectional communication? UDP? Sending a letter by regular mail? Leaving a note? The list goes on and on.


Everyone:

There's a difference between a message and a protocol. A protocol is built with the use of many messages. Not the other way around. OOP, functional and many other programming techniques have warped this notion so much that people, as seen in the above comments, believe some crazy notions about how information is transferred. One person even said OO invented the 'message'. HAHA. I mean, c'mon. There are serious misconceptions going around and all I'm doing lately is dispelling these things. It's no wonder we are 30 years behind the times.


Look, to anyone commenting who thinks I don't know what I'm talking about, please try to make some sense. I've been around for over a year on this blog and I wouldn't still be here if I was as wrong as some people claim. The 'greats' don't even have anything on me as I understand things they do (or did) not. Just because you've been brainwashed or taught certain things in school or University doesn't mean you are right. In fact, most of the stuff they teach you there is wrong. I know. I've been to University and they don't teach you 90% of the fundamentals. The rest is superficial properties that needs to be taken on faith. Do many of you even know it's possible to write software without functions or any execution point at all?

OOP and functional programming CANNOT do messaging, ok? It's a no brainer. It's not something that's been hidden from people or any big secret. So, if you haven't heard this before, do not blame me for your ignorance. I have nothing to do with that. All this is common knowledge. There's nothing new here. Now, OOP is built on top of imperative programming, so you can manually code up something that can do messaging for you. But there's nothing in the language itself that supports messaging. If you're going to comment on this, please make sure you have your facts straight.

Weave Jester:

TCP is a protocol that support reliable messaging. But TCP itself is NOT a message. It's a protocol that handles messages. It's not rocket science.

All the stuff you talk about are extra features not necessary for sending information. Reordering, reliable transmission, retransmissions, all that stuff are not necessary for sending a message. Are they beneficial? Sure. But they're part of the protocol, not the message itself.

If you don't understand this, there's nothing anyone can do to explain it. It's common knowledge. Look at how TCP/IP is implemented. There are several packets (messages) exchanged to enable the protocol. But each individual packet IS a message. The collection of these messages is a protocol.

It's not about preference. It's about terminology. A protocol is NOT a message. You're using the wrong terminology.

Weave Jester:

"Why build this transactional protocol on UDP rather than TCP?"

No one said this. Where would you get such an idea?

You don't believe a packet is a message? I'm saying functional can't handle packets and neither can OOP, but here again, you're changing the terminology. A message is and always has been information that moves from point A to point B. A packet has the requirements to be a message.


"Then underneath this, at some low level protocol, there's going to be something like this:"

Yeah, exactly. It's a protocol, not a message. You said it yourself.

"So a unidirectional message is based upon a pair of bidirectional communications (the "info" and "ack" packets) at a lower level."

This is your definition, not anyone else's. A unidirectional message implies one way (as in 'uni' meaning 'one'). So your ack packet cannot be part of your definition since it's a second ('two' aka not 'uni') packet. It's no longer unidirectional. The rest of your argument falls apart because it's based on this incorrect view.

But I'm feeling extremely good today, so I'll continue.

"Also, just to make it clear, whilst you believe that functional programming cannot do messaging, there are many people, myself included, that believe you are wrong. In fact, there's a considerable number of people that see functional messaging systems as the best way to achieve mass parallel computing. Again, I include myself."

That's fine, except you forget that it's not *my* claim. It's a law of physics. The designers of TCP/IP and the Internet understood this. So argue with them if you wish, but I'd rather go with established and proven notions. I mean, this is as basic as you can get.

edit: I missed the last sentence. Functional can only do delegation. Wishful thinking that functional can do distributed computing doesn't make it so. You're in for a HUGE disapointment. And if it could, where have you all been the past 20 years? Where is this great technology? It's nowhere to be seen. Twenty years. How do you explain that? What are you all waiting for?

"Merely saying "functional programming CANNOT do messaging" is no more or less convincing than me saying the opposite."

I did not say that by itself. I've grown tired of repeating myself and others ignoring facts. I've explained this concept on numerous occasions.

"Likewise, claiming that a person who disagrees with you is lying is not usually an effective way to successfully argue ones point."

Fair enough, but really, you have changed definitions more times than Liz Taylor changes husbands. I can only assume you're pulling my leg. There's no way you can believe everything you say when it's so contradicting.

"1. Lists can be evaluated sequentially.
2. Lists don't necessarily have an end.
3. It's often not necessary to evaluate the whole list in order to get an answer.
4. It's often not necessary to know the length of list in order to get an answer.
5. We haven't changed any values in the list throughout our evaluation."

#1 ok
#2 No. You would run out of memory. Items not evaluated do not exist.
#3 See, this is why #2 is not true.
#4 actually, you do. You may not need to count them physically, but you need to have some mechanism for storing each one which constitutes a mechanism for getting the number of items.
#5 Fancy footwork. If you evaluated them, then the list changed. This is what functional says how state changes occur.

"6. It's often not necessary, and sometimes not possible, to know what every value in the list is."

In other words, you can't evaluate everything like NP-complete problems. Sure.

"So if functional programming can describe the history of a messaging network, then it can describe the present and future of the network as well."

No. That's ridiculous. Pass that list to a function twice and you'll get different results. No waiting allowed. Waiting requires mutable state to get out of the waiting state (aka imperative programming).

"You'll have to wait until the messaging system has finished before you can evaluate all the messages that were sent, but you can evaluate in increments; the same way you could tell your boss that the first two letters were 't' and 'p', even though I hadn't yet got around to typing the ending 'd'."

Sorry, but your list is changing on the fly. If I look at item 3 before it was typed, it would not exist. You have mutable state here. You cannot wait for it. How do you know when it arrives? Something must change from going to a waiting state to a non waiting state? What caused this? It's mutable state. This is imperative programming. You've described this a million time. I've asked you before, Why do you think I can't see right through this?

Again, you're trying to convince yourself of these notions so that you can be at peace. You MUST know what you say isn't true. Can you see why this is a lie. There's nothing here even remotely believable. You said yourself it waits!!! That's the very definition of mutable state! You keep describing imperative programming. Please show me a functional concept that handles messaging. I've already agreed that imperative can do messaging. But passing this off as functional programming is deceitful. Not to me, but to yourself.

All I've heard is that so-called functional languages can do messaging by using imperative programming. I'm fine with that. I've been saying this all along. But it's not functional programming.

I'm very flexible with the definition of a message. The only requirement I hold is that information is transferred. From this, you can build other features. Ack would be another message. Reordering is simply manipulation of recived messages. All these things are protocols. Protocols are higher level. That's what OO messages are. That's what functional evaluations are. They all use multiple messages (packets of information). None of them can use a single message. So they can't do messaging in its basic form.

About the term... Oh, you mean a prior use in programming. I can't really say if there was such a use, though I know hardware has signals. But you should read up Alan Kay's initial thoughts on coining the term OO. He envisioned cells that could send and receive commands. This is what a message SHOULD have been. This is the accepted concept of a message in the real world. But that's not what happened. What happened is that messages got coupled with the response from that command. If Alan Kay could have resisted this urge and used messages as they were used in the past, then things would have been drastically different. Unfortunately, I doubt even Alan Kay knows what happened. I bet he still thinks his 'messages' are normal. In fact, many are wondering why OO doesn't work well for distributed applications if OO supports messages. Well, I've just told you why.

So your prior art was very short lived. In programming, if the term is incorrectly used, it should be corrected. To be fair, it is composed of two messages. So that's why some would say it still qualifies. I don't because there are some things that an OO message cannot do as explained previously.

Also, I should clear up that because OO is built on top of imperative, it has the ability to use messages a la real world definition. There's just nothing in the concept of OO that supports it. In fact, it can't unless you go the data flow route. This is what Alan Kay ALMOST had on his hands when he designed OO. Man, history got a good kick in the arse on that one.

As for computers, the first message was used at UCLA on October 29, 1969. Unfortunately, OOP was designed before this in the same decade with an alternate definition. Even today, you often see the response part of the OO message omitted from its definition. That's rather revealing in itself.

"This is merely a debate as to whether a programming language based on the principles of lambda calculus (i.e. functional programming) can handle a distributed messaging system.

It's my assertion that not only can it do so, but that it rather well suited to the task."

Nothing so far would indicate so. I've actually proven that it can't be done in functional programming using the concept of work. It is a law of physics. Distributed computing requires physical separation, otherwise it is not distributed. So your sarcasm is not well founded.

"However, when I speak of a distributed message system, I'm talking about one with some guarantee of integrity."

This is not a requirement. In fact, you can never be certain that a message arrives even with 'reliable' protocols.

http://www.artima.com/weblogs/viewpost.jsp?thread=57224

"... and arrive in the exact same order they were sent so long as the system is operational."

In some cases, this is not a requirement. What do you then? Your protocol would unecessarilly wait for no good reason and waste processing time because your protocol is forced to use features you do not want. This is exactly what I'm saying functional has. It has features that are actually detrimental to distributed computing, moreso than the above feature.

"You seem to be suggesting a message system where the messages themselves are lossy, which I guess is a valid place to start from, but I personally don't see the point."

Everything can be built from this. It's strange seeing someone who supports functional programming be against composability. Again, the contradictions continue. You can't have reliable messages anyhow. If you assume this, then your software does not take this into account and then what do you do?

"Mathematicians and functional programmers alike would disagree with you."

After all this time, do you think I care? I'm saying they are wrong and I'm showing you why. Yet, you cling to these people as if they should know better. Bring these people here and let's talk shop.

"Just because I do not know what the 1342th prime number is, does not mean it does not exist, or that it is not a constant value."

Sure it does. It means that you do not have its value. If I have two cars, I can't go around saying that my third car exists if I don't actually own one. I can potentially go buy one, but it doesn't change the fact that at that particular point in time, this third car does not exist. There's a reason potential and kinetic energy are different. They're interchangable, but a process must occur to enable that. What's your process in FP? Evaluations? Right. So there you go. If it existed, you wouldn't need the evaluation.

"Electronic circuitry that waits for a certain event or time has been around far longer than imperative programming."

So you're saying this is functional programming? Again with the contradictions.

"In any case, it doesn't matter what system a functional program is executed under, so long as the functional environment itself adheres to a specific set of rules."

Everything under the Sun is OK according to you. You use imperative when you feel like it with monads and call that functional. You wait for external trigger (obviously a side-effect), yet you say it's perfectly acceptable within functional programming. According to what you say, it's impossible to pinpoint what functional programming is. Even the boundary where state changes are allowed change. Apparently, it's ok outside the software, but not ok outside the function. How does that work? It's self-contradictory.

Let me posit this scenario. If the overall system that enables your software to execute is also functional, then isn't the outside of your software now suddenly INSIDE the overall functional software? Of course it is. So this is a proof that allowing external state changes is contradictory to the notion of functional programming if no side-effects are allowed. Allowing external changes breaks the rules of functional programming for the overall system. QED. This is why I've always said that the boundary you chose for 'external' is ridiculous. It's completely arbitrary and contradictory. It's up to you how you will reconciliate these anomalies.

"You've yet to provide a valid proof as to why this set of rules is not internally consistent."

I just did above as I've done many times over. You just ignore them as if I didn't. Again, you are not being honest to yourself or to others.

"Further, if we ban waiting, then even the simplest of calculations becomes impossible. Even the act of adding to numbers together takes time, so if you're going not allow a function to wait for the return value from another, then you're pretty much screwed from the get-go."

HAHAHA! Now, you're backtracking. I was talking about waiting on side-effects and you know it. Besides, if a function is computing something, then your software is active, not in the waiting state.

"Physical laws don't enter into this."

Of course it does. Physical separation is a requirement of distributed computing. It's not an analogy. It's a physical reality.

"Lambda calculus is a fixed set of rules. To prove that a programming language based on these principles cannot send messages involves firstly quantifying the set of rules used by a message-passing system, and then demonstrating that these rules are incompatible laid out by lambda calculus. Vigorous hand waving is not an effective substitute."

I did all that. Just because I use plain English doesn't make it any less valid.

But if you wish.

Say you have two functions:

f(x) = g(x)

After evaluating g(x), call it y, this result will take the place of g(x). You end up with:

f(x) = y

So all of x, y and g(x) have to be in the same physical location as the function f relatively speaking. If they are in the same location, then they cannot be physically separated as required by distributed computing.

The only thing that can be at a different location is the part between g(x) being converted to y. That part need not be local and this is why delegation is possible.

Do you want something more technical? This is so mindboggingly simple to me that I can't believe anyone would want something more involved than this.

"I suggest you find out the difference between integrity and reliability."

I'm trying to tell you that both are features that can be built on top of basic messages.

"So I can prove it exists even if I do know what it is. Merely because I do not know it's value, does not mean I can't prove that it does have one."

Wow, way to confuse yourself. When ones says a list or a value exists (as it appears you are saying it), one usually talks figuratively. Just like when I say the playoff finals of hockey consists of two teams. But right now, those finals do not exist. As teams get eliminated, I can more readily predict and narrow who it will be. I can even tell you that Buffalo and Ottawa will NOT both be in the finals. But until we get there, we cannot say that either finalist exists. Because they don't. It hasn't been determined yet. See, you're using the viewpoint that if Buffalo ends up in the finals, then they existed all along even if we could not tell beforehand. Well, no. The criterion is Buffalo as a finalist. That combination did not exist until the end. For your example of a prime number, all the numbers DO exist. But until we can determine which one is the Xth prime, then it doesn't exist in our computer. We know there will be one if we look long and hard enough. We can predict some of its features. This is what you seem to be talking about. But that's a far cry from it actually existing in our hands or in our computer.

"The flow of electricity through a conductor is no more functional than it is imperative."

Well, actually it's closer to being imperative because imperative can take an input from one device and send it on to another device. Also, flow of electricity through a conductor is definitely not functional in any way, shape or form. Even so, what's the point of your comment? I was saying you can't use hardware to support that it's ok for functional to wait on external inputs because hardware is not functional in nature.

"Maybe that's because it is functional. As I've pointed out before, a monad is nothing but a type class that implements a standard set of functions."

But it has mutable state with external side-effects. This is contrary to what functional programming claims to be.

About state change boundaries,
"The boundary is black and white, but where the limits are depend on the environment."

You can't make such an arbitrary distinction. I proved why you can't and you've ignored my proof yet again just because it's in plain English. If function f executes your software g, then f is your external environment. If you allow external state change to g occuring in f, then f has local mutable state not allowed by functional programming. This is as simple as it gets.

Your claims of hand waving are baseless. If you ignore my proofs, then what is your purpose here? I show you exactly why things are the way they are and you turn your head and claim I'm doing some handwaving. Why do you do this?

"Not at all. Your proofs because they are not proofs at all, merely strongly worded arguments. Repeatedly claiming that they consist proofs do not actually make them that."

So just because it's written in English, you don't accept my proofs? C'mon, that's just asinine. Of course what I'm stating are proofs. I don't need to use special notations for them to be so. Besides, they are so simple that requiring some other notation is trite. Basically, you're saying my arguments are valid, but you're ignoring them because then your arguments would fall flat.

"If the inner functional program produces side effects in the outer functional system, all that says is that the outer system is not a pure functional system."

EXACTLY!!!!! Thus functional programming CANNOT BE THIS EXTERNAL OUTER SYSTEM if you use monads. You said it yourself. So functional programming cannot exist by itself as I've said all along and your use of monads is dubious.

"It proves nothing about the purity (or lack thereof) of the inner program. "

No need. My purpose was to show how the entire system cannot be functional if you use monads. But it does show exactly what you say it doesn't. It shows that if the external system isn't functional, then the inner program is what is causing it not to be pure. By induction (through nesting), or by construction, the inner program cannot be pure either as it's been established that mutable state has occured.

"Nor does it prove you cannot have a pure functional program running in a pure functional system."

Actually, it does. If you use monads, then the entire system cannot be functional. If you don't use monads, then you cannot do I/O. And if you cannot do I/O, where does the original input for your software come from? What does the I/O to pass to your software if you cannot use monads? Nothing. It's not possible.

"In fact, your argument proves absolutely nothing at all."

It proves everything. You're just willfully ignoring it. That's your choice.

About waiting on external state changes,
"What's the difference? From the standpoint of the calling function it amounts to the same thing; whether you're calculating a billion digits of pi or asking the user to press a key, there's still going to be a delay of an indeterminate amount of time."

Don't try and change the topic. You know full well that I was talking about waiting on external state change. The difference is that one is mutable state not allowed by functional programming, and that the other is state transformation by a function allowed by functional programming.

Weave Jester:

"I'm not changing the topic, and yes, I know you're talking about external state change. What I'm saying is that the difference you describe only exists outside of the functional environment, and therefore is irrelevant." - Weave Jester

You cannot say the external environment is irrelevant because it makes your system inconsistant. Functional is useless if you chose to stick by this notion. If you continue to say this, then you've proven my point that functional has side-effects. Arbitrary boundaries. So I chose external environment to check for side-effects. I can chose this because it's arbitrary.

"Delegation is no different from two way message passing when combined with a recursive data type. Consider the following code:"

Yay, you know that delegation involves two way messages. Everything afterwards just proves my point even more. You just refuse to see the onsequences of this. I'm trying to show you WHY functional cannot handle distributed computing OTHER THAN delegation. Showing me how it can do delegation is rather pointless.

"Note that the middle two evaluations do not return to main. "

Of course they do. The last line goes back to main afterwards. BTW, delegation can be nested as you've shown. Like I said, this is all pointless. We all agree on delegation.

About your monads, you're being defensive again and trying to make as if you didn't use monads for I/O. I don't care what they do. I just care about mutable state in the external environment. You say it doesn't matter. If you chose to accept that view, then so be it. It's called imperative programming. Just because you turn your head and ignore it doesn't make that mutable state go away. It's still there no matter what.

Nate:

"we can split our function/reduction pair across a communication link and we get one-way messaging while still within a lambda paradigm. As far as I can tell." - Nate

Not unless you use imperative programming along the way. I don't see any other way to leave data on a machine without causing a side-effect unless you accept WJ's notion that the external environment doesn't matter. But that implies that this external environment cannot be functional. This effectively ends the dicussion.

Note that you can uncouple certain functions to be one-way, but because it remains within the functional environment, it doesn't amount to much as it only enables delegation of a containing function meaning that there will eventually be another one-way communication in the other direction eventually, thus cancelling everything out.

"A large amount of the reason why I hang out here on this blog is that so few people are talking about dataflow and massive (instruction-level) parallelism at all, and it's such an obvious and appealing idea to me. Ever since I first met Occam around my high school years I thought 'this is the way of the future' and wondered why it's been taking so long."

After trying, rather unsuccessfully, to explain these concepts, I've narrowed it to several reasons why it's taking so long. I'm not impressed by these reasons... meaning that I wish it weren't so.

1. Programmers believe too many incorrect or improperly defined notions.
2. The effects of execution are not well understood.
3. Too much assumption that anything new will fail (no silver bullet).

Functions are an example of #1. On the surface, a function looks like it takes an input and produces an output. But the way it's used has extra requirements that aren't part of the official definition. So when a different way of processing comes out, people have a difficult time understanding why it's different because they assume that input and outputs are all that's there.

The execution point is something that no one really studies. There should be a course on it in University or College, but there is not. Some people still believe that there is no execution in functional programming. It just happens to be coupled with data. Because they are never separate, you never see execution alone. But it is there as shown by tail call elimination.

#3 should be obvious. People dismiss things right away because they think that the greats of computer science could not have missed anything. This is not true. In fact, they understood very little about the implications of the execution point as seen by the very long time it took for control structures to show up.


Weave Jester:

"In terms of one-way versus two-way, I'm not clear why everyone's making a big deal out of it."

Because one of them (one-way) makes distributed computing possible and the other (two-way) does not. It's the key to everything. I've been trying to show you why, but apparently I've failed miserably.

"The architecture of current computing devices isn't suited for mass parallelism at the instruction layer."

That's not the point though. It's about new hardware that is coming out and will become the norm. In 6 years, 32 cores will be the minimum you can purchase. A few years after that and you're into so many cores that there's no way you can manually split up your software anymore. What I'm working on can handle this. If I thought functional could handle it, I wouldn't bother. Realise that as we got more nodes, the less functionality will be available on them. Eventually, they will only support one operation. At this point, you're dealing with instruction level parallelism and my software in Project V will continue to work just fine. I don't have the same optimism with other types of software development.

Weave Jester:

"Okay, so we agree that delegation can be used to create any distributed bidirectional network.

But that covers just about everything, no?"

No. I've been saying all along that functional can do delegation. But it's not the full class of distributed problems. This is what I've been talking about this whole time. It's too bad you only got this now after all this time. My apologies. I never know which one of the concepts I find second nature are more obscure for others.

"Imperative programming is a method of describing computation as a series of statements that change a program's state. The thing is, this is just a theoretical model; it doesn't correspond to any physical phenomenon."

What? Are you serious? Imperative came about because hardware costs were high, so they only put one of each component in the computer. You access the ones you want with opcodes. By sequencing the correct activation of components, you can recreate any hardware layout. That sequencing is what we know as imperative programming. It also follows well from how humans do thing with lists (like shopping lists and TODO lists). "It doesn't correspond to any physical phenomenon"???? Wow! Really? Could you elaborate? I'm really interested in hearing all about this.

"So yes, once you work your way up to the hardware layer, the external environment is not functional, but nor is it imperative."

Huh? I thought you would say that you need a machine that works sequentially in order for imperative to work (as I thought you were hinting before). But to say this? Here's the reality. Imperative comes from the hardware layer. That's where it was born. Even if it was thought up before, the machine would have made this a requirement anyways because hardware components cost too much at the time.

"I'd be surprised if 32 cores was the minimum in just 6 years. That would imply a much larger average, and most current software does not lend itself to being parallelised easily. I can't see hardware forging on ahead that far;"

That's why I'm the futurist. Moore's Law has held so far and if it is to continue holding, there will be 32 cores (low end or minimum) in 6 years. We're already at 2 or 4 right now. Three more doublings and we're there. They happen at 18 month intervals, so that makes 4.5 years. Another year and a half after that for another doubling and I'll be surprised to see anything below 16 cores available in new computers. I still stick by my 32 core prediction though. We'll be at 64 for sure at that time.

"...to some degree, hardware advancement is limited by what software is available. For instance, look how slowly 64 bit architectures are taking hold, or look at how long the x86 processor architecture has been around."

No, this isn't how it works other than in gaming. Games require better hardware. But for the common PC, hardware manufacturers never wait for software. They can't. The 386 came out in 1986. 32 bit software didn't become common until much later, yet the 386 did take hold. But we still had backwards compatibility. This time around, we won't have that luxury for ALL the processing power. This is why many are claiming that there'll be a software crisis. The current hardware per processing node just isn't getting faster as much as it used to.

"What makes you so certain this will be the case? Trends are not necessarily asymptotic, and it could be that an architecture with small multi-operation cores will be more efficient than an architecture with single-operation cores."

I'm so sure because of a little factor called MONEY. Simpler is cheaper. If a node only has one instruction, then it's super cheap. Single operations will always be cheaper than multi-operation cores because there's no execution unit. Plus, it can be used in nanotechnology that can combine and create computing devices at any given time and location. This is a hot ticket. Especially in medecine. I'm sure other uses will become known once people realise that this technology is possible.


Nate:

I'm a huge fan of adventure games. One thing I've found interesting is how you can combine items to produce a new one. Or how one can be applied to another in order to enhance it or modify it in some way. There's a lot of transmutting. Also, a lot of the environment changes too. Describing these changes, I've found to be oddly similar to compiler construction as far as types are concerned. Yet, types rarely change in static languages. Or if they do, there's a conversion process and always the same mechanisms.

Anyways, what I'm saying as that classification of both real objects (not the OO kind), and of actions or combinations thereof are difficult to represent. In Project V, I've talked to you about the type system before. It will have a classification system and a way to change or even include an item in multiple classifications at once. Anything that requires a certain classification can be used by any object that has that classification. This operation likewise has certain properties that it takes this classification as an input. The operation itself can likewise be in a classification of its own. So you can mix and match a lot of different operations together. As well, each object can have local properties for each classification it is in, with possibly appropriate defaults according to the object in question.

Anyways, I think you can see the advantages just in those features listed here. Can an object be picked up? Check the classification (I gotta come up with a shorter word). Is the object actually in your inventory? Inventory is a classification too. Backpack would be an object that contains the Inventory classification within it. That sort of thing. Is that useful to you? I have the need for easier manipulation of these sort of things for components. So that's why these features are there. Oh, you can set up things like mutually exclusive classifications. I'm just making this up, but it shows what you can do. If you store an item in another mutually exclusive classification, you can set it up to automatically remove it from the other.

These are some of the features I will have for my version of templates. Actually classifications are templates. Haha, there's a shorter word for them.

These features have very little to do with parralel computing. There are a LOT of dependencies here and is mostly used for manipulating the environment (which could be your adventure game's virtual environment) rather than the logic of the software (ie. what your game is supposed to do). I just find the ability to manipulate templates like a regular data item to be quite powerful.

What I really want is that after you get the prototype for your adventure game going, as you're walking around, you can edit the environment using the visual editor that comes with Project V.

"And since they represent objects in a story that can be saved, restored and undo-ed at will, you can't just use system objects for them - you need some kind of multi-level transactional ability built into the fabric of the runtime environment."

I have checkpoint components that are applied on another layer to your software (like transparencies). The checkpoints save everything incoming until it reaches the outgoing checkpoint. You can have many and control them any which way you desire. This is used across networks because you can never guarantee that something is transmitted, so although the checkpoint is on another computer, Project V takes care of the details for you.

Templates (classifications) can be of use here too. Your checkpoints can respond only to certain templates or in special ways for each one. This is on another layer, so you have the freedom to do what you want without messing up the main logic of your software. Templates can also have certain events attached to them like autosave and anything else you can think of.

"So, all the base-level rules describing a world need to be reified in the language and environment as objects themselves - and they need to be able to be manipulated either at compile or early runtime."

You can subclass (in a manner of speaking) templates or anything else in Project V. This means you can override the base class. In effect, you can use this to override the base rules. Since this subclass is also a template, you can change the 'type' of the rules at any time to use your overriden rules. You can also trigger it as to when and where it should revert. Runtime and compile time... it's all the same to me.

"You need the ability for one software library to refer to another and say 'This library requires libraries X and Y, but overrides rules P, Q and R'. Hardly *any* current languages even think this is a good thing, let alone allow you to express it."

In Project V, requiring libraries X and Y is simply a regular type definition. Overriding rules is just subclassing, but not regular subclassing. It's more like another layer (or type) that is applied temporarilly on top and takes over certain parts for that time. I need this to be able to ship components (requires X and Y) and I need it for versioning (overriding) as I need the original version to keep working as is for older code. So it seems you can use this for what you want as well.

I haven't looked into it, but I'm amazed that this would not be thought as a good thing. I need it. So that ends any argument from me or by me. I must implement it if what I'm doing is going to work. Doesn't matter what anyone could possibly say against it.

"You need the ability for a character to make plans, look at the state of the world, understand and reason about the *rules* which make up the world (and, most especially, form *faulty* hypotheses based on incomplete and inferred knowledge..."

I have a system in place to ask questions about categories and properties. Sometimes, it's impossible to know for sure. For example, over a distributed network, you never know if you have the most up to date component. A new one can come up at any time. So I have to set up rules that within a certain amount of time based on previous release dates, what is the likelihood of there being a new version out and if the IDE should go out and check. You don't wanna be checking all the time because that wastes bandwidth for no good reason. This requires manual setup, but the system can report "I don't know" or you can make it report "76.5% percentile that there is a new version out". You can likewise link different things together to monitor the correlation. If package X comes out, there is a 95% probability that package Y is also out. Stuff like that. So you know why I need this part. Perhaps this will be useful to you too. For example, checking a new version would be the incorrect thing to do. A character in a game could likewise end up with incorrect assumptions, but perhaps be correct a lot of the time. It can also evolve over time and notice correlations on its own if you enable this. Takes more processing power and resources though.

"And then having produced a game file, you need to be able to store and distribute it in a standardised manner, as easy as playing a Flash or HTML file"

I've talked about this before. Not sure how easy it will be for the initial setup. For Project V, you'll need to get at least the minimum required code. Maybe a browser plugin. After that, it's very simple. You can also allow only certain components so that nothing devious can be done. I'm writing all this to be fully portable and I'm working on the GUI now. The GUI will eventually work with SDL on Linux. I'm hoping that later on, 3D interfaces will also be available. Native GUI's will likewise be available.

"and why for the most part, they don't even realise that they're failing"

I've mentioned my guesses before. But for me, I'm writing Project V because there are things I simply cannot do in other languages. Not whith the level of ease I'm talking about. I'm really focusing on having editors for components. So you can visually pick and chose settings or have components set themselves up with the least amount of effort on your part. In game, or in development, editing is part of this. Being able to connect different tools into the IDE is something I really want. Your game has 3D models? The editor is your favourite 3D app... but using it in-development. Want to link in some external data? Just connect it to the IDE and link it where it's supposed to go with the ability to modify the input with components. You can have different panels for different tasks such as editing, 3D object design, outputs from certain components for testing, chat, etc.

Everything can be done with distributed computing, but where you don't deal with that side of it directly unless you want to.

"In other words, I'm getting more and more resigned to the fact that probably what I want is Common Lisp"

Is that air I hear seeping out?

Luckily, if you ever change your mind, Project V can use anything that's out there. Even Lisp.

But if you need something now, Project V isn't going to be released at least for another 3 months as I'm trying to gather some funds for it. My attention is needed elsewhere for the next month at least as I have another project I must complete. Hopefully, we can get the final bit of funding for that one too. Anyone want to double their money? Let me know. No joke either. We start construction as soon as the work permit comes back and is approved. Any little bit helps. Contact me for details.

Ok, I've plugged Project V and my construction project. I think that's a good day.

Weave Jester:

"Then why not provide an example of a network of information flow that cannot be represented by a bidirectional "pull" graph?"

Email. P2P. Chat.

"Moore's law merely says that the number of transistors we can fit on a piece of silicon doubles every 18 months. Doubling the number of transistors does not necessarily imply a doubling of cores."

Maybe not. But do you think that doubling cores is easier, or harder, than doubling the number of transistors on the same piece of silicon?

"What if there is extra overhead associated with communication between nodes?"

Communication will have to be dealt with anyways no matter what we use. If you need a specific task to complete right away, then sure, you can have custom hardware just for that. But there will come a time when the communication overhead will be so minor that it just won't matter anymore. The extreme parallel nature of this will compensate for any overhead.

You've perhaps heard that doubling the number of cores cannot double the speed of your software. This is not true. It can actually get MORE than twice as fast because of something called the cache and/or registers. If you look at latencies for level 2 cache and RAM, it can get quite slow. We've already seen in the past how doubling the number of registers (or doubling the size of each register) can achieve more than twice the speed. Project V will enable this exponential speedup of multiple cores whenever possible.

"Regardless of our differences in opinion, I'd like to see how it turns out when it's finished."

Frankly, I know we both see the same things. I just don't think your way of defining them are realistic. But hey, you probably think the same thing about me.

About Project V, I wanna see how it turns out too. haha. I'm currently working on my construction project to get some money so that I can pay expenses to continue work on Project V. This will allow me to set up my business for Project V and have a source of income whenever I need it through either business. Regardless of what happens, this summer is gonna rock. I'm positive Project V will see the light of day soon enough.

Nate:

"Sounds similar to multiple inheritance"

Maybe. Inherintance only allows a direct overriding of another entity's properties. Categories (or classifications) are groupings where you can build any kind of software network to determine what entities are within it. You can request info from a category or you can ask an entity what properties it holds in relation to any categories. Although both can be manipulated at runtime, inheritance is non-destructive (overlaps new properties that can be reverted) whereas categories are changed for good. You still have 'undo', but you must request it. It's not automatic as it is with inheritance because inheritance can revert to a base type automatically if using external networks that only work with that.

Oddly enough, categories can inherit from other categories or be in another category itself.

"Which is to say: I don't want a language with a restricted non-Turing-complete sublanguage for making limited 'type' assertions"

Well, the way it works is that there are predefined components that specify what classification each type or value is in. So you can register any component you wish to make this assertion. You can also register this in any way you wish by building a software network to handle it. Not only is it Turing complete, but it's also fully distributed.

Things like Inform 7 can be built within Project V as a panel. Panels can be run as independant applications if you wish, but having the tools of the IDE can be beneficial as you can customise what features you want. Panels are used to provide different interfaces for the same software network. BTW, I don't find Inform 7 too impressive. Maybe I just don't get it.

I think perhaps you don't understand how Project V is meant to work. Project V's IDE is integrated into your application. In current IDE's, you build an app and your IDE remains separate. OTOH, Project V IS your application. You just add what you want and ship the parts you need for your application. The way you add functionality is by expanding the IDE because one panel is your default output screen. So if you want a compiler and there's one available that you like, then you can use that component. You can use that component as stand-alone if you wish. In that case, none of the IDE features will be used except for the output panel. Every part of Project V is replacable too. So you can pick and chose what you like. Every application is a customization of Project V itself (leaving the original Project V intact for the IDE of course, but that runs on another full screen panel). Separate panels can be different user's screens. Tons of stuff you can do... and because there's no difference between Project V and your application, you can develop, test and play in a distributed fashion too. Remember, ALL 100% of Project V will eventually be components. There will be nothing that is hidden or not under your total control. Eventually, there will be people using Project V completely with components that I don't know about and looks completely different for uses I cannot imagine. This is because Project V IS all apps, just customized. It's like the chicken and the egg. I provide the entire chicken so that you can make your own creation and throw out what you don't need.

I'm baffled that today's IDE's come with graphics and neat tools, but you can't use them all. Why is that? In Project V, all of its power is available to you.

Weave Jester:

"printed to Alice's screen"

side-effect. Not functional.

Nate:
"So something like a predicate class?"

I was not aware of the term predicate or its common usage. I do know that templates in C++ can do this and was looking at it earlier last week. I did not see the name predicate though. Are there more examples of this?

To answer your question, the answer is yes from what I saw. In Project V, a type is like any other piece of data. You can apply any transformation you wish to it. Keep in mind that a type definition is able to reconstruct its structure (if not its values). So the type of a type is NOT a generic super class (like Class in Java). Each type actually has a meaning.

"If you're just looking at the GUI, though, you're probably missing a lot."

That's what I figured too. To me, it just looked like a glorified rules based engine. These are tough to get right, but that's all it looked like to me. I'm not denigrating the work they've done. I can't imagine the work they had to do.

"Ah, the Smalltalk approach. I hope you provide a way to strip out the IDE and GUI components for production; I don't want to have to ship an entire GUI framework for a webserver."

It's not really the SmallTalk approach, though there are definite similarities. 100% of Project V is replacable or removable (not so with SmallTalk). Any part you do not use is removed from your application. This is for standalone apps. For me, I have a much bigger vision that all software is part of one global super connected software. So software running on a computer is just a small part of that global image. And Project V is the catalyst that will enable this. There's no need to use Project V at all if you can communicate with this global system. And injecting custom communication systems is very much possible. So the Project V IDE is more like a system monitering device that allows you to make changes to this global interconnected software. Project V will take parts of itself and inject itself in order to produce these changes, often leaving parts of itself behind to be used by the global software. Any code, or programming technique can likewise be used in this system. There is nothing that cannot be taken advantage of. In fact, no part of Project V need be used at all. I just need a starting point. Anyways, that's just what I see in the future. The web and all that crap is really minor compared to what I envision.

If this were to come out and shown to work on any kind of distributed networks, I think there are some in the computing industry that would be none too happy as there's been a concerted effort in the past 20-30 years to lock people into proprietary systems. Even the OSS community still has no standard intercommunication protocol for software.

"What happens to this value after it is returned is none of the functional program's business."

I've said a million times that you can't use that argument. I've shown why you can't use it time and again.