[Inspiration] Toward a better programming
This is a nice write down: http://www.chris-granger.com/2014/03/27/toward-a-better-programming/ with a nice demo of a prototype: https://www.youtube.com/watch?v=L6iUm_Cqx2s Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo: | input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort. Sven
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-) | input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
Beautiful demo. This should be our game, yet others are playing it :(. Doru On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com "Every thing has its own flow"
Sure, guy just repeating almost same thesis as in the original Self demo dated back in '95, "direct manipulation with objects errr.. data".. except that now in crappy web-based environment.. and still missing the point.. because it is not about data, it is about objects. On 29 March 2014 18:20, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
https://www.youtube.com/watch?v=Ox5P7QyL774 On 29 March 2014 18:28, Igor Stasenko <siguctua@gmail.com> wrote:
Sure, guy just repeating almost same thesis as in the original Self demo dated back in '95, "direct manipulation with objects errr.. data".. except that now in crappy web-based environment.. and still missing the point.. because it is not about data, it is about objects.
On 29 March 2014 18:20, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Hi, Sure he is repeating things. And sure he is reinventing half of what we already have. However, he is likely to get more traction because he reinvents the UI, not the core concepts. You could say it is not an essential contribution. But, it is. Doru On Sat, Mar 29, 2014 at 6:28 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Sure, guy just repeating almost same thesis as in the original Self demo dated back in '95, "direct manipulation with objects errr.. data".. except that now in crappy web-based environment.. and still missing the point.. because it is not about data, it is about objects.
On 29 March 2014 18:20, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Every thing has its own flow"
On 29 March 2014 18:35, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Sure he is repeating things. And sure he is reinventing half of what we already have.
However, he is likely to get more traction because he reinvents the UI, not the core concepts. You could say it is not an essential contribution. But, it is.
The general misconception is that visual manipulation with objects can fully replace the coding. It won't and never will. Except from very simple cases (like computing the average :) You can try to visually express things like branching, conditional loops, common programming patterns, but i doubt you will find it convenient to program it in "visual" way rather than coding.
Doru
On Sat, Mar 29, 2014 at 6:28 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Sure, guy just repeating almost same thesis as in the original Self demo dated back in '95, "direct manipulation with objects errr.. data".. except that now in crappy web-based environment.. and still missing the point.. because it is not about data, it is about objects.
On 29 March 2014 18:20, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
I was using Pharo today for a maths expo that my wife organized for her school day. Feedback from the whiz kids: "That nice if one wants to control its environment. But I am learning C first because I want to understand how the machine works and I got lost by using all kinds of languages and mastering none. (He uses Python, C, C# and had a run on Pharo on his own)." So, Pharo + PharoVM + NB + Slang could be a good combo. Phil Le 29 mars 2014 18:41, "Igor Stasenko" <siguctua@gmail.com> a écrit :
On 29 March 2014 18:35, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Sure he is repeating things. And sure he is reinventing half of what we already have.
However, he is likely to get more traction because he reinvents the UI, not the core concepts. You could say it is not an essential contribution. But, it is.
The general misconception is that visual manipulation with objects can fully replace the coding. It won't and never will. Except from very simple cases (like computing the average :) You can try to visually express things like branching, conditional loops, common programming patterns, but i doubt you will find it convenient to program it in "visual" way rather than coding.
Doru
On Sat, Mar 29, 2014 at 6:28 PM, Igor Stasenko <siguctua@gmail.com>wrote:
Sure, guy just repeating almost same thesis as in the original Self demo dated back in '95, "direct manipulation with objects errr.. data".. except that now in crappy web-based environment.. and still missing the point.. because it is not about data, it is about objects.
On 29 March 2014 18:20, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the
article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
Yes. It is harmful to throw away semantic in favor of high-level abstractions. As well as opposite.. You need to use (and master) both. IMO smalltalk environment, as such, is capable to demonstrate that is is possible to achieve this golden middle, where abstraction(s) meet low-level semantics, without competing each other. Hence, of course, my contribution to it - NativeBoost, because this is my vision. On 29 March 2014 19:02, phil@highoctane.be <phil@highoctane.be> wrote:
I was using Pharo today for a maths expo that my wife organized for her school day.
Feedback from the whiz kids:
"That nice if one wants to control its environment.
But I am learning C first because I want to understand how the machine works and I got lost by using all kinds of languages and mastering none. (He uses Python, C, C# and had a run on Pharo on his own)."
So, Pharo + PharoVM + NB + Slang could be a good combo.
Phil Le 29 mars 2014 18:41, "Igor Stasenko" <siguctua@gmail.com> a écrit :
On 29 March 2014 18:35, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Sure he is repeating things. And sure he is reinventing half of what we already have.
However, he is likely to get more traction because he reinvents the UI, not the core concepts. You could say it is not an essential contribution. But, it is.
The general misconception is that visual manipulation with objects can fully replace the coding. It won't and never will. Except from very simple cases (like computing the average :) You can try to visually express things like branching, conditional loops, common programming patterns, but i doubt you will find it convenient to program it in "visual" way rather than coding.
Doru
On Sat, Mar 29, 2014 at 6:28 PM, Igor Stasenko <siguctua@gmail.com>wrote:
Sure, guy just repeating almost same thesis as in the original Self demo dated back in '95, "direct manipulation with objects errr.. data".. except that now in crappy web-based environment.. and still missing the point.. because it is not about data, it is about objects.
On 29 March 2014 18:20, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the
article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
It has already happened , and there 2 rather huge commercial examples a) Native Instrument's Reaktor -> http://www.native-instruments.com/en/products/komplete/synths-samplers/reakt... b) Softimage ICE -> https://www.youtube.com/watch?v=do1kzR6gVYk And those are not your everyday examples. Reaktor is THE modular audio synthesis environment , by far the most popular. With its close competitor being MAX/MSP. Softimage on the other hand has been the dominant 3d app for 80s and 90s movies,but even for other 3d apps node setups are a must have. Though all 3d apps come with python APIs and python having a reputation of being very much liked by people new to coding, artist in both sides , music and 3d graphics prefer foremost node setups. For example Houdini a very popular 3d app has full integration with nodes , anything the user can make can be controlled by nodes. Generally speaking I am not a big fan of the infinite "cannot". There is no way to predict something unless you seriously try it. But in the end any problem can be overcome. Text based coding has prevailed because early computer could not handle graphics well. There is definitely a recent shift to more visual coding and I doubt that text code is doing anything else than slowly shrinking in significance. The way I see it, text coding has become less and less managable , visual coding offers really good alternative managing very complex structures being closely tied to the GUI. Not that text coding cannot do this, but people associating with it, tend to not be designers and you need designers to improve workflow at least on the user level. Languages also will play a less significant role seeing the appearance of more and more specialized tools like it has already happened in music and 3d industry. On Sat, Mar 29, 2014 at 7:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 March 2014 18:35, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Sure he is repeating things. And sure he is reinventing half of what we already have.
However, he is likely to get more traction because he reinvents the UI, not the core concepts. You could say it is not an essential contribution. But, it is.
The general misconception is that visual manipulation with objects can fully replace the coding. It won't and never will. Except from very simple cases (like computing the average :) You can try to visually express things like branching, conditional loops, common programming patterns, but i doubt you will find it convenient to program it in "visual" way rather than coding.
Doru
On Sat, Mar 29, 2014 at 6:28 PM, Igor Stasenko <siguctua@gmail.com>wrote:
Sure, guy just repeating almost same thesis as in the original Self demo dated back in '95, "direct manipulation with objects errr.. data".. except that now in crappy web-based environment.. and still missing the point.. because it is not about data, it is about objects.
On 29 March 2014 18:20, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the
article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
This is mostly for given verticals. Same as sound, with Guitar Rig or Ableton https://www.youtube.com/watch?v=kMP8onefhoQ But yes, it is cooler to work with the blocks than with code. Now, you need the code to do the block. Phil On Mon, Mar 31, 2014 at 10:26 AM, kilon alios <kilon.alios@gmail.com> wrote:
It has already happened , and there 2 rather huge commercial examples
a) Native Instrument's Reaktor -> http://www.native-instruments.com/en/products/komplete/synths-samplers/reakt...
b) Softimage ICE -> https://www.youtube.com/watch?v=do1kzR6gVYk
And those are not your everyday examples. Reaktor is THE modular audio synthesis environment , by far the most popular. With its close competitor being MAX/MSP.
Softimage on the other hand has been the dominant 3d app for 80s and 90s movies,but even for other 3d apps node setups are a must have. Though all 3d apps come with python APIs and python having a reputation of being very much liked by people new to coding, artist in both sides , music and 3d graphics prefer foremost node setups. For example Houdini a very popular 3d app has full integration with nodes , anything the user can make can be controlled by nodes.
Generally speaking I am not a big fan of the infinite "cannot". There is no way to predict something unless you seriously try it. But in the end any problem can be overcome. Text based coding has prevailed because early computer could not handle graphics well. There is definitely a recent shift to more visual coding and I doubt that text code is doing anything else than slowly shrinking in significance. The way I see it, text coding has become less and less managable , visual coding offers really good alternative managing very complex structures being closely tied to the GUI. Not that text coding cannot do this, but people associating with it, tend to not be designers and you need designers to improve workflow at least on the user level.
Languages also will play a less significant role seeing the appearance of more and more specialized tools like it has already happened in music and 3d industry.
On Sat, Mar 29, 2014 at 7:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 March 2014 18:35, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Sure he is repeating things. And sure he is reinventing half of what we already have.
However, he is likely to get more traction because he reinvents the UI, not the core concepts. You could say it is not an essential contribution. But, it is.
The general misconception is that visual manipulation with objects can fully replace the coding. It won't and never will. Except from very simple cases (like computing the average :) You can try to visually express things like branching, conditional loops, common programming patterns, but i doubt you will find it convenient to program it in "visual" way rather than coding.
Doru
On Sat, Mar 29, 2014 at 6:28 PM, Igor Stasenko <siguctua@gmail.com>wrote:
Sure, guy just repeating almost same thesis as in the original Self demo dated back in '95, "direct manipulation with objects errr.. data".. except that now in crappy web-based environment.. and still missing the point.. because it is not about data, it is about objects.
On 29 March 2014 18:20, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the
article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"Every thing has its own flow"
-- Best regards, Igor Stasenko.
2014-03-31 9:26 GMT+01:00 kilon alios <kilon.alios@gmail.com>:
artist in both sides , music and 3d graphics prefer foremost node setups.
Who? Sources?
Text based coding has prevailed because early computer could not handle graphics well.
I´m sure that the fact that text is easily manipulable has had more to do with it. But I have no sources right now to back up my assertion. There is definitely a recent shift to more visual coding and I doubt that
text code is doing anything else than slowly shrinking in significance.
Where? By who? Shrinking? Sources, please. Not that text coding cannot do this, but people associating with it, tend
to not be designers and you need designers to improve workflow at least on the user level.
Are there statistics? Languages also will play a less significant role seeing the appearance of
more and more specialized tools like it has already happened in music and 3d industry.
Two sectors out of who knows how many. Cheers, Sergi PS: I´m not yelling at you, I just think that you made a lot of affirmations based on opinion rather than facts.
The last part of my post is opinion yes. My opinion is that visual coding will slowly and steadily penetrate other markets as its has for music and Computer Graphics. Its not a fact, nor I have experience with other sectors to offer a solid opinion on them. Its more like a logical conclusion. I could be wrong but I seriously doubt it. The first part are facts that I have collected with over a decade of personal experience with these fields. Its not that hard to prove just go to youtube and search for coding articles for python or other script languages for 3d apps vs node setups on the same apps. Nodes are actually new to 3d apps, when I first starting using 3d studio max in 2000 there was no nodes back then but there was a C API and Maxscript. Nowdays nodes are heavily used. Reactor has been a dominant tool since 1996 for musicians. If you are musicians that wants to create highly modular audio setups then Reactor and MAX/MSP are 2 most popular choices. This is not a thing I created our of my head and you can ask around for confirmation to my claims. You can ask those people if they find text easier to handle than nodes. So yes I made an opinion with assumptions but I have based it on facts and personal experience. But then in the end it comes down to personal taste. On Mon, Mar 31, 2014 at 11:51 AM, Sergi Reyner <sergi.reyner@gmail.com>wrote:
2014-03-31 9:26 GMT+01:00 kilon alios <kilon.alios@gmail.com>:
artist in both sides , music and 3d graphics prefer foremost node setups.
Who? Sources?
Text based coding has prevailed because early computer could not handle graphics well.
I´m sure that the fact that text is easily manipulable has had more to do with it. But I have no sources right now to back up my assertion.
There is definitely a recent shift to more visual coding and I doubt that
text code is doing anything else than slowly shrinking in significance.
Where? By who? Shrinking? Sources, please.
Not that text coding cannot do this, but people associating with it, tend
to not be designers and you need designers to improve workflow at least on the user level.
Are there statistics?
Languages also will play a less significant role seeing the appearance of
more and more specialized tools like it has already happened in music and 3d industry.
Two sectors out of who knows how many.
Cheers, Sergi
PS: I´m not yelling at you, I just think that you made a lot of affirmations based on opinion rather than facts.
On 31 Mar 2014, at 10:51 , Sergi Reyner <sergi.reyner@gmail.com> wrote:
2014-03-31 9:26 GMT+01:00 kilon alios <kilon.alios@gmail.com>: artist in both sides , music and 3d graphics prefer foremost node setups.
Who? Sources?
Hereâs a good example, from one of the premier game engines: https://www.youtube.com/watch?v=F7xRc-iSLXg Unity & CryEngine are still in the âwrite your own/select a pre-made shaderâ territory though. Something to think about for Roassal3D, Ronie? ;) (Not necessarily as a visual tool, but as basic domain model for programming shaders using a Smalltalk DSL) Cheers, Henry
I cannot resist to jump on this. Indeed, we have the moral obligation to promote what we have crafted over the year. Producing a high-quality video has been on my todo list for quite some times already. As you probably know, we did some intent already (videos about Roassal, GraphET, and other tools), but we were too young maybe. Within the next few weeks we will work on a cool video to promote Roassal2, and our goal is to reach users beyond the Smalltalk boundary. We have everything so far. The moose distribution is a wonderful toolbox that can literally blow away any example shown in this video. As you may have seen, we have worked on Roassal2 which includes a new geographical map builder, tabular table importer, GraphET2, fancy curves, html and amber exporter. A video carefully orchestrated has the potential to kick away Aurora, Light Table, Wolfram and all their friends. We will soon get there... Alexandre On Mar 29, 2014, at 2:20 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
How about impact of this: http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx... I would agree it is quite complex for any beginner, but utility of a programming language on these lines seems cut out for the future.. On Mon, Mar 31, 2014 at 6:56 AM, Alexandre Bergel <alexandre.bergel@me.com>wrote:
I cannot resist to jump on this. Indeed, we have the moral obligation to promote what we have crafted over the year. Producing a high-quality video has been on my todo list for quite some times already. As you probably know, we did some intent already (videos about Roassal, GraphET, and other tools), but we were too young maybe.
Within the next few weeks we will work on a cool video to promote Roassal2, and our goal is to reach users beyond the Smalltalk boundary. We have everything so far. The moose distribution is a wonderful toolbox that can literally blow away any example shown in this video.
As you may have seen, we have worked on Roassal2 which includes a new geographical map builder, tabular table importer, GraphET2, fancy curves, html and amber exporter. A video carefully orchestrated has the potential to kick away Aurora, Light Table, Wolfram and all their friends.
We will soon get there...
Alexandre
On Mar 29, 2014, at 2:20 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Impressive. Now, let's get back to our work, as "what matters in the end is what people choose to do." And we'll for sure still learn a lot making Pharo a great platform (we do not have Wolfram's 700 individuals engineering force). I'd vote for a Pharo integration like they show for Python and Java. Who knows someone over there? Phil On Mon, Mar 31, 2014 at 6:21 AM, S Krish <krishnamachari.sudhakar@gmail.com>wrote:
How about impact of this:
http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx...
I would agree it is quite complex for any beginner, but utility of a programming language on these lines seems cut out for the future..
On Mon, Mar 31, 2014 at 6:56 AM, Alexandre Bergel <alexandre.bergel@me.com
wrote:
I cannot resist to jump on this. Indeed, we have the moral obligation to promote what we have crafted over the year. Producing a high-quality video has been on my todo list for quite some times already. As you probably know, we did some intent already (videos about Roassal, GraphET, and other tools), but we were too young maybe.
Within the next few weeks we will work on a cool video to promote Roassal2, and our goal is to reach users beyond the Smalltalk boundary. We have everything so far. The moose distribution is a wonderful toolbox that can literally blow away any example shown in this video.
As you may have seen, we have worked on Roassal2 which includes a new geographical map builder, tabular table importer, GraphET2, fancy curves, html and amber exporter. A video carefully orchestrated has the potential to kick away Aurora, Light Table, Wolfram and all their friends.
We will soon get there...
Alexandre
On Mar 29, 2014, at 2:20 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar@gmail.com> wrote:
How about impact of this:
http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx...
I would agree it is quite complex for any beginner, but utility of a programming language on these lines seems cut out for the future..
Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory. It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them. Thanks for sharing the link. Sven
Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part. The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable. Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals. There is so much to build. Let's be bold. Doru On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar@gmail.com> wrote:
How about impact of this:
http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx...
I would agree it is quite complex for any beginner, but utility of a
programming language on these lines seems cut out for the future..
Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory.
It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them.
Thanks for sharing the link.
Sven
-- www.tudorgirba.com "Every thing has its own flow"
Hey Doru, I was going to ask "so is that a language or a library?"... On 4/1/14 23:12 , Tudor Girba wrote:
Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part.
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals.
There is so much to build. Let's be bold.
Doru
On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar@gmail.com <mailto:krishnamachari.sudhakar@gmail.com>> wrote:
> How about impact of this: > > http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx... > > I would agree it is quite complex for any beginner, but utility of a programming language on these lines seems cut out for the future..
Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory.
It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them.
Thanks for sharing the link.
Sven
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Definitely the latter⦠Norbert Am 02.04.2014 um 09:11 schrieb Andres Valloud <avalloud@smalltalk.comcastbiz.net>:
Hey Doru, I was going to ask "so is that a language or a library?"...
On 4/1/14 23:12 , Tudor Girba wrote:
Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part.
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals.
There is so much to build. Let's be bold.
Doru
On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar@gmail.com <mailto:krishnamachari.sudhakar@gmail.com>> wrote:
> How about impact of this: > > http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx... > > I would agree it is quite complex for any beginner, but utility of a programming language on these lines seems cut out for the future..
Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory.
It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them.
Thanks for sharing the link.
Sven
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Both. But, does it really matter? :) Doru On Wed, Apr 2, 2014 at 9:49 AM, Norbert Hartl <norbert@hartl.name> wrote:
Definitely the latter...
Norbert
Am 02.04.2014 um 09:11 schrieb Andres Valloud < avalloud@smalltalk.comcastbiz.net>:
Hey Doru, I was going to ask "so is that a language or a library?"...
On 4/1/14 23:12 , Tudor Girba wrote:
Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part.
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
Another thing I like in Wolfram's work is attention to details:
http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals.
There is so much to build. Let's be bold.
Doru
On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar@gmail.com <mailto:krishnamachari.sudhakar@gmail.com>> wrote:
> How about impact of this: > >
http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx...
> > I would agree it is quite complex for any beginner, but utility of a programming language on these lines seems cut out for the
future..
Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory.
It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them.
Thanks for sharing the link.
Sven
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Environmentally aware is nice indeed. We can have this. Phil Le 2 avr. 2014 11:11, "Tudor Girba" <tudor@tudorgirba.com> a écrit :
Both. But, does it really matter? :)
Doru
On Wed, Apr 2, 2014 at 9:49 AM, Norbert Hartl <norbert@hartl.name> wrote:
Definitely the latter...
Norbert
Am 02.04.2014 um 09:11 schrieb Andres Valloud < avalloud@smalltalk.comcastbiz.net>:
Hey Doru, I was going to ask "so is that a language or a library?"...
On 4/1/14 23:12 , Tudor Girba wrote:
Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part.
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
Another thing I like in Wolfram's work is attention to details:
http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is
crucial
to keep our eyes on the phenomenal long term goals.
There is so much to build. Let's be bold.
Doru
On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
On 31 Mar 2014, at 06:21, S Krish < krishnamachari.sudhakar@gmail.com <mailto:krishnamachari.sudhakar@gmail.com>> wrote:
> How about impact of this: > >
http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx...
> > I would agree it is quite complex for any beginner, but utility of a programming language on these lines seems cut out for the
future..
Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory.
It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them.
Thanks for sharing the link.
Sven
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
Yes, having grand, ambitious goals is important. It is all to easy to get lost and demotivated in the day to day details, but on the other hand, that work must be done. I just read the piece about their design process and reviews. It is indeed amazing that they can have such a complex system with just one global namespace (at least for the command language and top level interface). Of course, getting there is a lot of work. On 02 Apr 2014, at 08:12, Tudor Girba <tudor@tudorgirba.com> wrote:
Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part.
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals.
There is so much to build. Let's be bold.
Doru
On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar@gmail.com> wrote:
How about impact of this:
http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx...
I would agree it is quite complex for any beginner, but utility of a programming language on these lines seems cut out for the future..
Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory.
It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them.
Thanks for sharing the link.
Sven
-- www.tudorgirba.com
"Every thing has its own flow"
Le 02/04/2014 08:12, Tudor Girba a écrit :
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
I see two barriers in the current Pharo to be able to reach that: - Lack of clear documentation of the underlying code management structure and facilities. It takes ages to get into the gritty details of things like RPackage and the refactory framework, documentation is very often limited to "this is the way Nautilus does it", and "no worry about changing it, Nautilus developpers are the same guy" which ends up being very painful for someone outside that core group. - GUI conservatism. The choice made in Pharo in the overall look is to be conservative and business-like, and so blame the too-advanced, too-fancy Morphic (and at the same time have Roassal pushing the enveloppe, but outside the normal toolkit :) which means someone would find it probably hard to do Roassal-based development tools). Glamour, Spec and GTToolkit are interesting to look at along that "conservatism" in GUI.
Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals.
I'm less convinced by that. Refining, trying, fiddling, spending hundreds of iterations on making drag and drop or scrolling perfect, yes. Redesigning whole chunks of the low-level facilities without really seeing where we will end up, at at the same time presenting a very conservative view on top of it, not much. For example, I know of a GTInspector use case which is entirely justified by deficiencies in the standard system browser ;)
There is so much to build. Let's be bold.
+100 Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Yes, RB would immensely benefit from some doc. See other thread on that. I will start something pnce I get it wotking for my case. Phil Le 2 avr. 2014 13:30, "Goubier Thierry" <thierry.goubier@cea.fr> a écrit :
Le 02/04/2014 08:12, Tudor Girba a écrit :
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
I see two barriers in the current Pharo to be able to reach that:
- Lack of clear documentation of the underlying code management structure and facilities. It takes ages to get into the gritty details of things like RPackage and the refactory framework, documentation is very often limited to "this is the way Nautilus does it", and "no worry about changing it, Nautilus developpers are the same guy" which ends up being very painful for someone outside that core group.
- GUI conservatism. The choice made in Pharo in the overall look is to be conservative and business-like, and so blame the too-advanced, too-fancy Morphic (and at the same time have Roassal pushing the enveloppe, but outside the normal toolkit :) which means someone would find it probably hard to do Roassal-based development tools). Glamour, Spec and GTToolkit are interesting to look at along that "conservatism" in GUI.
Another thing I like in Wolfram's work is attention to details:
http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals.
I'm less convinced by that. Refining, trying, fiddling, spending hundreds of iterations on making drag and drop or scrolling perfect, yes. Redesigning whole chunks of the low-level facilities without really seeing where we will end up, at at the same time presenting a very conservative view on top of it, not much.
For example, I know of a GTInspector use case which is entirely justified by deficiencies in the standard system browser ;)
There is so much to build. Let's be bold.
+100
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 02/04/2014 13:58, phil@highoctane.be a écrit :
Yes, RB would immensely benefit from some doc.
+100. SmaCC makes use of RB, and there are a few things I'd need help with.
See other thread on that.
I've seen it. Try to do a RB environment selecting what you want and loop on all classes over it, renaming them one by one.
I will start something pnce I get it wotking for my case.
By the way, is there any news about Gisela Decuzzi work on a GUI for RB? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 02 Apr 2014, at 13:31, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 02/04/2014 08:12, Tudor Girba a écrit :
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
I see two barriers in the current Pharo to be able to reach that:
- Lack of clear documentation of the underlying code management structure and facilities. It takes ages to get into the gritty details of things like RPackage and the refactory framework, documentation is very often limited to "this is the way Nautilus does it", and "no worry about changing it, Nautilus developpers are the same guy" which ends up being very painful for someone outside that core group.
I agree but who is writing doc beside me and sven? Do you think that this is easy to write doc on something that you did not write. For Rpackage this is not that complex and you do not want to document the part that glue inside announcement and other.
- GUI conservatism. The choice made in Pharo in the overall look is to be conservative and business-like, and so blame the too-advanced, too-fancy Morphic (and at the same time have Roassal pushing the enveloppe, but outside the normal toolkit :) which means someone would find it probably hard to do Roassal-based development tools). Glamour, Spec and GTToolkit are interesting to look at along that "conservatism" in GUI.
You cannot clean Morphic without removing experimental stuff. Once we will have a better morphic then we can be more adventurous. You probably did not spend enough time in morphic if you do not think that Iâm right. :) Now this is clear that Roassal is a bit reinventing Morphic to some extend but this is like that.
Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals.
I'm less convinced by that. Refining, trying, fiddling, spending hundreds of iterations on making drag and drop or scrolling perfect, yes. Redesigning whole chunks of the low-level facilities without really seeing where we will end up, at at the same time presenting a very conservative view on top of it, not much.
For example, I know of a GTInspector use case which is entirely justified by deficiencies in the standard system browser ;)
There is so much to build. Let's be bold.
+100
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 02/04/2014 22:51, Pharo4Stef a écrit :
On 02 Apr 2014, at 13:31, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 02/04/2014 08:12, Tudor Girba a écrit :
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
I see two barriers in the current Pharo to be able to reach that:
- Lack of clear documentation of the underlying code management structure and facilities. It takes ages to get into the gritty details of things like RPackage and the refactory framework, documentation is very often limited to "this is the way Nautilus does it", and "no worry about changing it, Nautilus developpers are the same guy" which ends up being very painful for someone outside that core group.
I agree but who is writing doc beside me and sven?
Not me :(
Do you think that this is easy to write doc on something that you did not write. For Rpackage this is not that complex and you do not want to document the part that glue inside announcement and other.
Well, yes and no. Any exposure to RPackage and you understand that you have to know about the glue. Trust me on that one ;)
- GUI conservatism. The choice made in Pharo in the overall look is to be conservative and business-like, and so blame the too-advanced, too-fancy Morphic (and at the same time have Roassal pushing the enveloppe, but outside the normal toolkit :) which means someone would find it probably hard to do Roassal-based development tools). Glamour, Spec and GTToolkit are interesting to look at along that "conservatism" in GUI.
You cannot clean Morphic without removing experimental stuff. Once we will have a better morphic then we can be more adventurous. You probably did not spend enough time in morphic if you do not think that Iâm right. :) Now this is clear that Roassal is a bit reinventing Morphic to some extend but this is like that.
Morphic itself is still (how many years since Self we are at now?) experimental. Big chunks of what made Morphic what it is are gone from Pharo. Even Pharo by example requires loading extensions. And in normal, business GUI stuff, Morphic capabilities are underused and get in the way. Now, there is Alain Plantec work. That will be interesting... Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Now this is clear that Roassal is a bit reinventing Morphic to some extend but this is like that.
Indeed, Roassal offers facilities that clearly looks like the ones of Morphic. However, Roassal is not meant to build GUI (for now). The primary uses of Roassal is visualizing data. And yes, you can made a small UI to drive a visualization, and the UI is best done in Roassal directly than in Morphic. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
"...Coherent and robust philosophy..." We got to be aware of the fact that Wolfram is recognized as a renegade scientist with a great work in Mathematica but the work on cellular automata and his theory on New kind of Science is controversial to put it lightly. What appeals to me as ideas / concepts that will make a great impact in Pharo if we can bring it in, without crossing swords on IP / patents..!!.. Kind of pick on priori art on all of them. http://www.wolfram.com/language/principles/ *For Pharo:* The great work done in Pharo so far and with core roadmap ahead.. this will probably be add on to the core / or as an extension: * *Cloud/ distributed processing*: A semi connected distributed language / programming environment that is knowledge aware of each node, scalably working with one or more nodes available at any given time. Backend data awareness linked to any type of data storage: RDBMS, NoSQL, flat files.. * *Power of algorithmic computation:* The framework for distributed AI algorithm that works with available knowledge base in time defined manner ( synchronous or asynch ) of the defined "execution". The power user can then plugin additional algorithms, modify and create a web as reqd * *Symbolic Expressions*: Syntactically cryptic but like a DSL it makes sense to have power user the brevity in his daily grind, though it can be left to the power user group to evolve the same given a foundation of a framework that makes it quick work to get it stitched together. * * Flexible Presentation*: DSL or the scripting driven quick presentation capability that can be any from a html / morphic / image / video / textual presentation. Kind of moldable, flexible to the core with defaults that feel almost intuitive to the processing * *NLP*: Natural language processing that is incremental, perhaps smalltalk already has been there in a small measure and static for a very long time, need to make it really NLP.. http://emerge.mc.vanderbilt.edu/natural-language-processing-nlp-survey-tools... <http://www.nltk.org/> * *Numerical computation*: Fast, highly efficient perhaps Native Boost enabled all kinds of maths: calculus, statistical computation, image processing et als. All the above are greatly relevant in the enterprise world development and will be a great fit to Pharo's capability with the GTInspector, Rossal+Athens presentation along with Morphic, meta programming, debugger that is live and can be interconnected with fuel, syntatically as close to NLP to any mainstream language can be ... *-Skrish* On Wed, Apr 2, 2014 at 11:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part.
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals.
There is so much to build. Let's be bold.
Doru
On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar@gmail.com> wrote:
How about impact of this:
http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx...
I would agree it is quite complex for any beginner, but utility of a
programming language on these lines seems cut out for the future..
Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory.
It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them.
Thanks for sharing the link.
Sven
Hello, Currently on the VM one of the next step is to speed up numerical computation, it should happen in around a year. Right now it would not worth it because even in arithmetic intensive benchs (I'm talking abut floating pointer benchs) the VM spends most of its time in the GC or iterating over collections, but once both of these 2 performance bottlenecks will be fixed (the new GC is about to be integrated, but the VM still needs to be ported to 64 bits to have more efficient floating pointers and collection speed-ups will be ready in 11 months), the next step is to speed up arithmetics, especially floating-pointers arithmetics. Distributed / Cloud processing is kind of a work in progress too. For that we need the threaded FFI working with the new GC to have #forkAndExec which spawn an image and fork the process in it efficiently. It's a 3-months project for a competent guy but no one is planning to do that on the short term AFAIK (there are other things to do first with the current resources). In addition for this problem we need things as a well identified kernel to spawn another image quickly (but thanks to Pavel we kind of have it). I guess in a few year we will have a framework to spawn new images and having them communicating through sockets efficiently. The communication layer would be inspired from Metatalk. A prototype was done with Metatalk (named ImageWorker) but the VM does not have support for #forkAndExec so this part was done with OSProcess, unfortunately making it a toy instead of a real framework... About Flexible Presentation, Spec is on the way as it has a morphic back end and a native UI back end. I guess at some point it will have a web back end too (maybe with amber ?). We "just" need to find someone willing to do it... So I think we kind of are doing what you expect. 2014-04-06 19:01 GMT-07:00 S Krish <krishnamachari.sudhakar@gmail.com>:
"...Coherent and robust philosophy..."
We got to be aware of the fact that Wolfram is recognized as a renegade scientist with a great work in Mathematica but the work on cellular automata and his theory on New kind of Science is controversial to put it lightly.
What appeals to me as ideas / concepts that will make a great impact in Pharo if we can bring it in, without crossing swords on IP / patents..!!.. Kind of pick on priori art on all of them.
http://www.wolfram.com/language/principles/
*For Pharo:*
The great work done in Pharo so far and with core roadmap ahead.. this will probably be add on to the core / or as an extension:
* *Cloud/ distributed processing*: A semi connected distributed language / programming environment that is knowledge aware of each node, scalably working with one or more nodes available at any given time. Backend data awareness linked to any type of data storage: RDBMS, NoSQL, flat files..
* *Power of algorithmic computation:* The framework for distributed AI algorithm that works with available knowledge base in time defined manner ( synchronous or asynch ) of the defined "execution". The power user can then plugin additional algorithms, modify and create a web as reqd
* *Symbolic Expressions*: Syntactically cryptic but like a DSL it makes sense to have power user the brevity in his daily grind, though it can be left to the power user group to evolve the same given a foundation of a framework that makes it quick work to get it stitched together.
* * Flexible Presentation*: DSL or the scripting driven quick presentation capability that can be any from a html / morphic / image / video / textual presentation. Kind of moldable, flexible to the core with defaults that feel almost intuitive to the processing
* *NLP*: Natural language processing that is incremental, perhaps smalltalk already has been there in a small measure and static for a very long time, need to make it really NLP.. http://emerge.mc.vanderbilt.edu/natural-language-processing-nlp-survey-tools... <http://www.nltk.org/>
* *Numerical computation*: Fast, highly efficient perhaps Native Boost enabled all kinds of maths: calculus, statistical computation, image processing et als.
All the above are greatly relevant in the enterprise world development and will be a great fit to Pharo's capability with the GTInspector, Rossal+Athens presentation along with Morphic, meta programming, debugger that is live and can be interconnected with fuel, syntatically as close to NLP to any mainstream language can be ...
*-Skrish*
On Wed, Apr 2, 2014 at 11:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part.
The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable.
Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals.
There is so much to build. Let's be bold.
Doru
On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar@gmail.com> wrote:
How about impact of this:
http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sx...
I would agree it is quite complex for any beginner, but utility of a
programming language on these lines seems cut out for the future..
Wow, this is really powerful stuff, a long read, but well worth it. By recombining and reusing all their technology they seem to be able to move into more and more territory.
It is closed source and (very) expensive, and I don't like the syntax, but we sure can get good ideas from them.
Thanks for sharing the link.
Sven
Looking forward to it. Yes, I think you and your team have done a lot to move in the right direction, thanks a lot. If you want to reach a larger audience, try to go as light as possible on the actual Smalltalk code, even if you have to cheat a bit by choosing good looking examples - the effect is more important than the actual syntax, but complex foreign code scares away everyone. On 31 Mar 2014, at 03:26, Alexandre Bergel <alexandre.bergel@me.com> wrote:
I cannot resist to jump on this. Indeed, we have the moral obligation to promote what we have crafted over the year. Producing a high-quality video has been on my todo list for quite some times already. As you probably know, we did some intent already (videos about Roassal, GraphET, and other tools), but we were too young maybe.
Within the next few weeks we will work on a cool video to promote Roassal2, and our goal is to reach users beyond the Smalltalk boundary. We have everything so far. The moose distribution is a wonderful toolbox that can literally blow away any example shown in this video.
As you may have seen, we have worked on Roassal2 which includes a new geographical map builder, tabular table importer, GraphET2, fancy curves, html and amber exporter. A video carefully orchestrated has the potential to kick away Aurora, Light Table, Wolfram and all their friends.
We will soon get there...
Alexandre
On Mar 29, 2014, at 2:20 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Go go go! Roassal2 (with Athens) can change the face of Pharo. Stef
I cannot resist to jump on this. Indeed, we have the moral obligation to promote what we have crafted over the year. Producing a high-quality video has been on my todo list for quite some times already. As you probably know, we did some intent already (videos about Roassal, GraphET, and other tools), but we were too young maybe.
Within the next few weeks we will work on a cool video to promote Roassal2, and our goal is to reach users beyond the Smalltalk boundary. We have everything so far. The moose distribution is a wonderful toolbox that can literally blow away any example shown in this video.
As you may have seen, we have worked on Roassal2 which includes a new geographical map builder, tabular table importer, GraphET2, fancy curves, html and amber exporter. A video carefully orchestrated has the potential to kick away Aurora, Light Table, Wolfram and all their friends.
We will soon get there...
Alexandre
On Mar 29, 2014, at 2:20 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Exactly. And it is of critical importance to have these tools directly supported by the IDE :) Doru On Tue, Apr 1, 2014 at 10:57 AM, Pharo4Stef <pharo4Stef@free.fr> wrote:
Go go go! Roassal2 (with Athens) can change the face of Pharo.
Stef
I cannot resist to jump on this. Indeed, we have the moral obligation to promote what we have crafted over the year. Producing a high-quality video has been on my todo list for quite some times already. As you probably know, we did some intent already (videos about Roassal, GraphET, and other tools), but we were too young maybe.
Within the next few weeks we will work on a cool video to promote Roassal2, and our goal is to reach users beyond the Smalltalk boundary. We have everything so far. The moose distribution is a wonderful toolbox that can literally blow away any example shown in this video.
As you may have seen, we have worked on Roassal2 which includes a new geographical map builder, tabular table importer, GraphET2, fancy curves, html and amber exporter. A video carefully orchestrated has the potential to kick away Aurora, Light Table, Wolfram and all their friends.
We will soon get there...
Alexandre
On Mar 29, 2014, at 2:20 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Beautiful demo. This should be our game, yet others are playing it :(.
Doru
On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 29 Mar 2014, at 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
Damn spelling correction ;-)
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com "Every thing has its own flow"
On 29 Mar 2014, at 11:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
Shorter, simpler using #squared : | input | input := #(2 4 4 4 5 5 7 9). ((input - input average) squared sum / (input size - 1)) sqrt. I just found out that we already have #stdev in the 3.0 image : #(2 4 4 4 5 5 7 9) stdev. ;-)
excellent thread. Thanks for sharing. Here Iâve posted some thoughts that might contribute with some reflections: http://sebastianconcept.com/brandIt/its-about-objects-isnt-it sebastian o/ On Mar 29, 2014, at 6:38 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This is a nice write down:
http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
with a nice demo of a prototype:
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Luckily, the horrible C++ code computing standard deviation in the article can be written quite elegantly and directly in Pharo:
| input | input := #(2 4 4 4 5 5 7 9). (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
Sven
participants (15)
-
Alexandre Bergel -
Andres Valloud -
Clément Bera -
Goubier Thierry -
Henrik Johansen -
Igor Stasenko -
kilon alios -
Norbert Hartl -
Pharo4Stef -
phil＠highoctane.be -
S Krish -
Sebastian Sastre -
Sergi Reyner -
Sven Van Caekenberghe -
Tudor Girba