Falcon 2.0
2017-12-23
It has been a while since I was able to properly dedicate time to developing Falcon as I wished to. I have been forced by circumstances to be reserved, so I could not share much of my ideas, or about my life, in this blog or anywhere else. Which, in the era of social network, equates more or less to social death.
It has been a while since I was able to properly dedicate time to developing Falcon as I wished to. I have been forced by circumstances to be reserved, so I could not share much of my ideas, or about my life, in this blog or anywhere else. Which, in the era of social network, equates more or less to social death.
Moreover, for the last few months, I suffered of a health condition that left me with barely enough energy to focus on my daily job.
Now that all this is finally past, I have been free to think at where I left the project and how to proceed to bring it back on track.
First of all, I had to face a question that is at the base of the problem itself: after the world has moved forward, is there still a place for The Falcon Programming Language?
And yes, especially with the new virtual machine, natively parallel and virtualized with respect to system resoruces, Falcon has already something other scripting languages don’t have. But today more than ever, its polymorphic abilities, which could make very easy to evolve symbolic programs to solve the most complex AI problems of our times, Falcon has unique capabilities, unmatched by other languages.
As for the points where I was left: a version 1.0 was basically ready, and I wanted to see if there was any chance to kill some of the deepest idiosyncratic problematics that were lingering in the engine since the inception of the first prototype I made in three days, back some 15 years ago. In particular,
* the splitting of number types (integer/double) into two different item types
* the ugly differentiation between flat and deep items
* the compile-time symbol resolution, which caused the new dynamics in the 1.0 VM to be uglier than needed.
And then, a host of choiches that came out of this early design, like the idea of having class cacllbacks operating directly on the deep pointer of items, unless said items were flat, or the idea of having the PSteps blind to the source that generated them.
And finally, some naming choices that looked ok in the beginning, but were actually confusing in the hindsight, like the choice of naming the item handlers as “classes”, with the even more confusing differentiation between FalconClass, HyperClass, MetaClass etc.
All this were details in the grand scheme of the complexity of this project, but kept bogging me until I finally decided that I didn’t have the mental resource to face both my challenging job and come at a final decision about them.
Now that my job is finally on track, and that my health conditions have been resolved, I had a couple of weeks in which I was able to make a plan for the next development cycle.
As it would be useless to write the plan here after this long list of excuses no one is really going to read (this is more a letter to myself than anything else), I will add another entry with the plan details later in this afternoon.
It has been a while since I was able to properly dedicate time to developing Falcon as I wished to. I have been forced by circumstances to be reserved, so I could not share much of my ideas, or about my life, in this blog or anywhere else. Which, in the era of social network, equates more or less to social death.
Moreover, for the last few months, I suffered of a health condition that left me with barely enough energy to focus on my daily job.
Now that all this is finally past, I have been free to think at where I left the project and how to proceed to bring it back on track.
First of all, I had to face a question that is at the base of the problem itself: after the world has moved forward, is there still a place for The Falcon Programming Language?
And yes, especially with the new virtual machine, natively parallel and virtualized with respect to system resoruces, Falcon has already something other scripting languages don’t have. But today more than ever, its polymorphic abilities, which could make very easy to evolve symbolic programs to solve the most complex AI problems of our times, Falcon has unique capabilities, unmatched by other languages.
As for the points where I was left: a version 1.0 was basically ready, and I wanted to see if there was any chance to kill some of the deepest idiosyncratic problematics that were lingering in the engine since the inception of the first prototype I made in three days, back some 15 years ago. In particular,
* the splitting of number types (integer/double) into two different item types
* the ugly differentiation between flat and deep items
* the compile-time symbol resolution, which caused the new dynamics in the 1.0 VM to be uglier than needed.
And then, a host of choiches that came out of this early design, like the idea of having class cacllbacks operating directly on the deep pointer of items, unless said items were flat, or the idea of having the PSteps blind to the source that generated them.
And finally, some naming choices that looked ok in the beginning, but were actually confusing in the hindsight, like the choice of naming the item handlers as “classes”, with the even more confusing differentiation between FalconClass, HyperClass, MetaClass etc.
All this were details in the grand scheme of the complexity of this project, but kept bogging me until I finally decided that I didn’t have the mental resource to face both my challenging job and come at a final decision about them.
Now that my job is finally on track, and that my health conditions have been resolved, I had a couple of weeks in which I was able to make a plan for the next development cycle.
As it would be useless to write the plan here after this long list of excuses no one is really going to read (this is more a letter to myself than anything else), I will add another entry with the plan details later in this afternoon.