Langauge Ideas.

[foodchain]

As a function for controlling threading or tasking, do you think such would work? Basically you would derive threads, or tasks, which could encapsulate all the information you want, such as a thread or task to conduct a certain type of accounting. Then separate to this you could develop say a body of data, that contains variables, such as for the accounting thread a variable that encapsulates how much tax money for a certain object in the world. I know I am skipping a lot but I am just trying to get it up and running visually.

Then you could have another function, which sort of acts like matrix algebra in which threads could be called into, and that could be a sort of management function, which then could also allow basically a middleman to exist between threads and the data they operate on in the form of a stack, such as if one thread is calling on an object currently in use by a thread already in the matrix. It would be a bit of a data stack, but such could be a neat tool in itself to run diagnostics on the software’s function or performance, and even be another angle to run security.

 

 

So basically the matrix part would run threads on call, have a stack for total thread running/function, this could allow for many threads to be running at once, and could allow for more safety of whatever data they are running on. I also think such would be a more laid out method to program.

 

Say a command, user enter some data, based on the data you could then have a thread call command, such as say thread user_input(if x=1 do.call(account1(x))), meanwhile the threads running could be on an a more organized basis, such as the gui display even.

 

The threads themselves could have entry and exit attributes for when called, or when to go dormant and ways to communicate with other threads, but the means to control them would be akin to running them in a matrix of sorts based on matrix algebra concepts.

[Pangloss]

I'm afraid I didn't follow this one at all, sorry.

 

Anybody follow that?

[foodchain]

I'm afraid I didn't follow this one at all, sorry.

 

Anybody follow that?

 

Sorry, I know it was a bit rough, its hard to convey an idea on a board without writing to much as to scare people away simply from volume. Its just an idea for a programming language is all, something I was tinkering with around six years ago really. I was sitting in a hallway at college reading a book on matrix algebra and I was wondering how much of a tool such could be if used as a management structure for threading or tasking really. A language that would in itself be composed of basically bodies of objects or data, threads/tasks, whichever word you id better with, and then the management chunk to run it all together.

[timo]

Where/what would the difference to object-oriented programming be? Perhaps a sketch might help understanding what you´re trying to say.

[Pangloss]

A language that would in itself be composed of basically bodies of objects or data, threads/tasks, whichever word you id better with, and then the management chunk to run it all together.

 

That's an almost textbook description of a managed OOP environment (ala Java or .NET).

[bascule]

Sounds like you're describing a concurrent programming language. Concurrent language encapsulate tasks as processes within a shared memory space (which can be implemented as OS LWPs) that can communicate using asynchronous message passing.

 

You may want to check out the Actor Model and see if it's similar to what you're describing:

 

http://en.wikipedia.org/wiki/Actor_model

[foodchain]

Where/what would the difference to object-oriented programming be? Perhaps a sketch might help understanding what you´re trying to say.

 

 

I have not put enough into the idea to develop a visual graph to represent it really, not in anything that would be more definitive then words really.

 

Basically it is the same pretty much as I would understand more object orientated languages. The only different as I could think is that each thread/task would basically be an individual program. Objects of data would also be something separate, then you could develop the control node, say the idea I got from reading on matrix algebra to manage or execute the threads/tasks functions in relation to the data objects or constructs.

 

So Body 1 would be just data objects, body 2 would be threads or tasks, basically individual programs. Then the two would come together with the node abstracted from matrix algebra. When scaling or performing maintenance on the software only parts then would most likely need to be changed, such as some data objects, or a thread or two. The management node could have many variables for it also, one of prime interest is simply following what everything is doing during its spawn of operation, which would be a really nice diagnostic tool I think.

 

So overall its not really a departure in my opinion from current oop methods, as its a departure from how such is developed and maintained. I think such would also be prime for working the areas of compatibility with native hardware or software really. My main point I think is such a structure giving to an oop driving language would really allow for the software to evolve much more easily to needs, from a business application to incorporation the latest content for management of image data, basically a oop language that allows for mass compartmentalization, specialization and of course threading or tasking required program behavior. The management node would basically work on tiers of precedence allowing also for the threads to hold relation to each other in a structure that can control scope, visibility and manipulation of data by the threads. It would be horrific to not, simply because having multiple threads all manipulation data at the same time really cannot be a good, or lasting practice. So its just a play on what’s already existing really as pointed out put into more of a concrete structure such as how the language itself is designed to be programmed.

 

Such as look at this page on matrix algebra.

 

http://www.sosmath.com/matrix/matrix0/matrix0.html

 

Now instead of simply numerical functions with it, you could have more digital ones, such as if object A is changed the node could activate more threads and bring them into queue for operation with that certain data object, which could be flagged easily in every thread and of course in every object, basically leading to having threads running that pertain only to the data being used at the time, and as the equations per say of thread to object data were being executed of course in an open to being programmed status, other thread behavior would not interfere and data could be keep safer from corruption. So you would end up with the node basically executing lines of function, like this “M-N = M + (-1)N “ found in the link, but replace such in the equation with threads and data objects, and the symbolic logic with something more akin to computer commands, such as if x has changed run y, and z thread.

[padren]

Are you talking about having the control node actually doing the marshalling of what gets executed, instead of kernal level threads, where it revives pseudo-threads (that exist only in the language, not kernal) based on what data it needs and what data has been manipulated?

 

If you are talking about actual OS threads, then you pretty much have to work with the tools that the OS offers to wakeup/sleep those threads, and you could basically implement this as a framework within many existing languages. My server application in c++ for instance, uses a ThreadLock class that works with the Runnable interface, which handles all transaction locking for data objects, but its still pretty much a standard oop multi-threaded framework.

 

If you are talking about building your own pseudo-threading system within the language, you'll need to break it out into multiple OS level threads anyway if you want to take advantage of duel core systems etc, and I think other hardware level optimizations they take advantage of.

 

Can you clarify if you are referring to OS level threads, or compiler level pseudo-threads?

[foodchain]

Are you talking about having the control node actually doing the marshalling of what gets executed, instead of kernal level threads, where it revives pseudo-threads (that exist only in the language, not kernal) based on what data it needs and what data has been manipulated?

 

If you are talking about actual OS threads, then you pretty much have to work with the tools that the OS offers to wakeup/sleep those threads, and you could basically implement this as a framework within many existing languages. My server application in c++ for instance, uses a ThreadLock class that works with the Runnable interface, which handles all transaction locking for data objects, but its still pretty much a standard oop multi-threaded framework.

 

If you are talking about building your own pseudo-threading system within the language, you'll need to break it out into multiple OS level threads anyway if you want to take advantage of duel core systems etc, and I think other hardware level optimizations they take advantage of.

 

Can you clarify if you are referring to OS level threads, or compiler level pseudo-threads?

 

My understanding of the computer only goes so far:D

 

When I was interested in computers in a more heavy handed tone Microsoft of instance or its OS really had nothing to support threading, I never really worked with Linux or the other vast sea of operating systems in all reality. You can do precedence work with threads though in the language, I remember that much. Basically my idea is no large degree departure from current oop methods, its really not. As I put in the above post its really just how such is structured. I think the benefits again would simply be maintenance, scalability, and of course visibility of program function while its being developed.

 

Okay, this is hard to explain at this point but here is my best shot.

 

Every language has its own set of intrinsic commands right, well that would be what the node is. The commands intrinsic to it would be based on rules you would find in say matrix algebra. So you have all of your threads, all of your data objects right, okay. Then when you go to run the program itself the commands are giving the commands native to the node structure, such as this part from the link I used above.

 

“M-N = M + (-1)N “

 

Now each letter or number in my instance would be a thread being called to action, to perform a function per say. so say you have a gui for someone to do online banking for instance, something like that example above could compromise a large portion of that, say dealing with a savings account. You could just put that in a dowhile loop while that thread in general is active, the saving part. So arguments basically would be writing in that format overall. Nothing but an argument of threads which have scope to objects of data. Now commands like that could be in individuals threads, and the node commands would be open or more would exist then what is present in the example above and of course formatted for a bit more functionality, but in reality if you did it right, you could write a bunch of threads, and data objects for anything, then if you understood exactly what everything was doing, and entire program could be generated from just one line of code then, by embedding.

 

So see, the move is not away from oop as much as simply its more into thread control. This is where I think the scalability, maintenance, and diagnostic aspects of software could get a plus, simply because the commands themselves would reveal exactly where something went wrong, but being its based in a matrix format the actions that lead to the error itself, or where a certain part of code that is doing something at a certain point could become very visible.

 

The hump as I see it is pretty soon it would become a complex issue of embedded threads within threads, within threads, pretty soon based on commands that have to be executed in the context of a matrices. Besides that the main body of a program, or the part that get executed would basically be a compilation of data from the object libraries and the thread libraries put together via the command structure of the node, so it basically in a very general sense would be a large pool of thread commands in that structure repeating basically. There is more to say on it, but I will wait for a reply at this point if you are interested in more, and please remember its just an idea really, something to play with.

[bascule]

As a function for controlling threading or tasking, do you think such would work? Basically you would derive threads, or tasks, which could encapsulate all the information you want, such as a thread or task to conduct a certain type of accounting. Then separate to this you could develop say a body of data, that contains variables, such as for the accounting thread a variable that encapsulates how much tax money for a certain object in the world. I know I am skipping a lot but I am just trying to get it up and running visually.

Then you could have another function, which sort of acts like matrix algebra in which threads could be called into, and that could be a sort of management function, which then could also allow basically a middleman to exist between threads and the data they operate on in the form of a stack, such as if one thread is calling on an object currently in use by a thread already in the matrix. It would be a bit of a data stack, but such could be a neat tool in itself to run diagnostics on the software’s function or performance, and even be another angle to run security.

 

I'm not sure why you're bringing matrices into the picture here. How is what you're describing not fulfilled by a concurrent RDBMS? With concurrency, synchronization, and data storage handled by a single facilitator, the remaining "threads" remain horizontally scalable. The RDBMS can in turn be clustered (for example MySQL's NDB) resulting in fulll horizontal scalability.