happy and bold new year
Locked
 
|
Happy New Year, everyone!
Over the last year, I went through a rather extensive tour and I directly exposed Moose, GT and Pharo to some 2000+ technical people through various sessions and trainings at conferences and companies. The tour will continue this year. Most of the sessions are not directly about Moose, GT or Pharo, but about broader topics that are served through what we do around here. These topics can relate to solving problems without reading code, to steering agile architecture, or more recently, to even broader topics like software environmentalism. If you are wondering what software environmentalism is, please take a look at this talk: https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA I now have the confirmation that there is a whole space which is unaddressed by mainstream technologies. Often people find themselves frustrated having to build their systems on top of opaque technologies with not much hope of understanding what is going on under the hood both because they do not have access to what is behind and because they are provided lack the tools to investigate. You see, developers are suppose to have the coolest job on the planet, and many of them are unhappy. This has to change, and we can do that. In a conversation I had with a highly respected researcher, after explaining how our tools allow us to work, he noted reluctantly “so, you are claiming that you are practicing a fundamentally different software engineering?”. This question took me a little by surprise because the only answer I found myself being able to provide was “yes”. I sent him this talk: https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA It is strange to be in the position to tell the world that we are constructing something fundamentally better, but I really do believe that we are. I wish you a happy and bold new year! Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: [Pharo-dev] happy and bold new year
|
|
Hi Hilaire,
GT is essentially a project that takes the relevant parts of Moose and make them applicable to plain Pharo. Pharo ships with only the core tools, but the complete configuration of GT also brings with it Roassal and a couple of other goodies. There are still more interesting things in Moose, but you can get quite far with only GT. About your particular question, it’s true that Pharo does not have static types, but that does not make it harder to understand. Only different. The first thing to realize is that Pharo is not about code, but about objects. That is why my advice is to not try too long to understand Pharo code statically because this is not where the power of Pharo is. You are in a much better position to understand a system when it’s running. So, the tools that I use the most are the inspector when I need to understand structural relationships or contracts between objects, and the debugger when I need to understand some algorithmic steps. Even when I look for code structure patterns, I mostly use the inspector because it allows me to query. Then you augment these tools with custom views and you get quite far. I know this sounds abstract, but I am practicing this since several years and I still find it amazing. I tried to provide a hint of how it works in the ESUG 2016 talk. Cheers, Doru > On Jan 9, 2017, at 2:02 PM, Hilaire <[hidden email]> wrote: > > Hello Doru, > > I am curious. > Yesterday I had a look to MessageBrowser, and realize I understand > nothing of it. I saw there is a mix of SpecXXX, models, Navigation > browser, Announcement, etc, then I knew I will have to spend a lot of > time browsing (multiple window again) to understand a bit how these > objects are related, and may be be able to change it in the way I want. > Does the Moose & al tools could help me understand code I don't know about? > > Given the fact Pharo/Smalltalk are not typed makes it harder for code > analysis, don't you? > > Happy new year to you too. > > Hiaire > > Le 09/01/2017 à 10:30, Tudor Girba a écrit : >> Happy New Year, everyone! >> >> Over the last year, I went through a rather extensive tour and I directly exposed Moose, GT and Pharo to some 2000+ technical people through various sessions and trainings at conferences and companies. The tour will continue this year. >> >> Most of the sessions are not directly about Moose, GT or Pharo, but about broader topics that are served through what we do around here. These topics can relate to solving problems without reading code, to steering agile architecture, or more recently, to even broader topics like software environmentalism. If you are wondering what software environmentalism is, please take a look at this talk: >> https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA >> >> I now have the confirmation that there is a whole space which is unaddressed by mainstream technologies. Often people find themselves frustrated having to build their systems on top of opaque technologies with not much hope of understanding what is going on under the hood both because they do not have access to what is behind and because they are provided lack the tools to investigate. You see, developers are suppose to have the coolest job on the planet, and many of them are unhappy. This has to change, and we can do that. >> >> In a conversation I had with a highly respected researcher, after explaining how our tools allow us to work, he noted reluctantly “so, you are claiming that you are practicing a fundamentally different software engineering?”. This question took me a little by surprise because the only answer I found myself being able to provide was “yes”. I sent him this talk: >> https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA >> >> It is strange to be in the position to tell the world that we are constructing something fundamentally better, but I really do believe that we are. >> >> I wish you a happy and bold new year! >> >> Cheers, >> Doru >> > > -- > Dr. Geo > http://drgeo.eu -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: [Pharo-dev] happy and bold new year
|
|
Hi,
In my opinion, Pharo provides the strongest infrastructure for understanding a system from all technologies I have seen. So, if you say that Pharo is a bit "under featured in, then I think we are not referring to the same thing :). May I ask how you are using the inspector? For example: - do you extend the inspector? - do you construct visualizations about your system in the inspector? - do you write queries about code in the inspector? Cheers, Doru > On Jan 9, 2017, at 3:42 PM, Hilaire <[hidden email]> wrote: > > I know this path of understanding code while it is running (inspector or > debugger), but it is still a tedious path, and I feel Pharo is a bit > under featured on that specific department, therefore my question on Moose. > > Hilaire > > > > Le 09/01/2017 à 15:09, Tudor Girba a écrit : >> That is why my advice is to not try too long to understand Pharo code statically because this is not where the power of Pharo is. You are in a much better position to understand a system when it’s running. So, the tools that I use the most are the inspector when I need to understand structural relationships or contracts between objects, and the debugger when I need to understand some algorithmic steps. Even when I look for code structure patterns, I mostly use the inspector because it allows me to query. Then you augment these tools with custom views and you get quite far. > > -- > Dr. Geo > http://drgeo.eu > > -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: [Pharo-dev] happy and bold new year
|
|
Hi Doru,
Happy new year and best wishes for your objectives. Interesting questions you are asking back Hilaire. They are also interesting because of the questions you are not asking him. why don't you ask: - Do you build a model of the application in a way or another? - Do you track the queries you are doing over the code? extending / building vizualizations / writing queries could be a step after those, isn't it? The Message Browser is an interesting piece of code. I replaced it, but it has a very strange API with users happily hacking into the internal representation of the message browser, so, even determining what is the API of that damn thing is ... interesting. There are some things the original message browser does very well, but I'm not sure it was intended. It's a very nice todo-list, for example. Works very well in a query some code/modify everything that match. I'm not sure it works that well as a discovery/navigation code tool. Regards, Thierry 2017-01-09 16:09 GMT+01:00 Tudor Girba <[hidden email]>: Hi, _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: [Pharo-dev] happy and bold new year
|
|
Hi Thierry,
> On Jan 9, 2017, at 4:31 PM, Thierry Goubier <[hidden email]> wrote: > > Hi Doru, > > Happy new year and best wishes for your objectives. > > Interesting questions you are asking back Hilaire. > > They are also interesting because of the questions you are not asking him. > > why don't you ask: > - Do you build a model of the application in a way or another? > - Do you track the queries you are doing over the code? > > extending / building vizualizations / writing queries could be a step after those, isn't it? Not in my view. A system has no shape. Yet, we need a shape to reason about it. As that shape is provided by tools, the tools we use are essential for how we think about our system. It is for this reason that we need to control those tools, and they cannot be static. You see, Smalltalk claimed to be highly dynamic since a long time, but all these years the tools did not change. You move from one system to another, and the tools are the same. We got stuck in one shape and could not get out of it. I build views and queries all the time. Just like the way a test looks like informs me about the suitability of the domain design, the elegance of a query or of the code of a visualization informs me about the same thing as well, only from different angles. I also throw most of these visualizations away. You never quite know which shape is insightful and that is why it is important to control the cost of a view. The cost should be so cheap that it should be faster to create the view than to talk about the problem. Once you reach that place, the game changes. Visualization is not a replacement for design. It is only a way to learn about what does or does not work. But, it is an essential one. > The Message Browser is an interesting piece of code. I replaced it, but it has a very strange API with users happily hacking into the internal representation of the message browser, so, even determining what is the API of that damn thing is ... interesting. > > There are some things the original message browser does very well, but I'm not sure it was intended. It's a very nice todo-list, for example. Works very well in a query some code/modify everything that match. I'm not sure it works that well as a discovery/navigation code tool. I do agree that the Message Browser is a nice todo list for methods. We have a long way ahead of us :). Cheers, Doru > Regards, > > Thierry > > 2017-01-09 16:09 GMT+01:00 Tudor Girba <[hidden email]>: > Hi, > > In my opinion, Pharo provides the strongest infrastructure for understanding a system from all technologies I have seen. So, if you say that Pharo is a bit "under featured in, then I think we are not referring to the same thing :). > > May I ask how you are using the inspector? For example: > - do you extend the inspector? > - do you construct visualizations about your system in the inspector? > - do you write queries about code in the inspector? > > Cheers, > Doru > > > > On Jan 9, 2017, at 3:42 PM, Hilaire <[hidden email]> wrote: > > > > I know this path of understanding code while it is running (inspector or > > debugger), but it is still a tedious path, and I feel Pharo is a bit > > under featured on that specific department, therefore my question on Moose. > > > > Hilaire > > > > > > > > Le 09/01/2017 à 15:09, Tudor Girba a écrit : > >> That is why my advice is to not try too long to understand Pharo code statically because this is not where the power of Pharo is. You are in a much better position to understand a system when it’s running. So, the tools that I use the most are the inspector when I need to understand structural relationships or contracts between objects, and the debugger when I need to understand some algorithmic steps. Even when I look for code structure patterns, I mostly use the inspector because it allows me to query. Then you augment these tools with custom views and you get quite far. > > > > -- > > Dr. Geo > > http://drgeo.eu > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of reality." > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Value is always contextual." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: [Pharo-dev] happy and bold new year
|
|
Hi Doru,
Le 09/01/2017 à 16:45, Tudor Girba a écrit : > Hi Thierry, > >> On Jan 9, 2017, at 4:31 PM, Thierry Goubier >> <[hidden email]> wrote: >> >> Hi Doru, >> >> Happy new year and best wishes for your objectives. >> >> Interesting questions you are asking back Hilaire. >> >> They are also interesting because of the questions you are not >> asking him. >> >> why don't you ask: - Do you build a model of the application in a >> way or another? - Do you track the queries you are doing over the >> code? >> >> extending / building vizualizations / writing queries could be a >> step after those, isn't it? > > Not in my view. > > A system has no shape. Yet, we need a shape to reason about it. As > that shape is provided by tools, the tools we use are essential for > how we think about our system. It is for this reason that we need to > control those tools, and they cannot be static. You see, Smalltalk > claimed to be highly dynamic since a long time, but all these years > the tools did not change. You move from one system to another, and > the tools are the same. We got stuck in one shape and could not get > out of it. I'm not entirely sure. The system tools provide a shape for you to use to work with the code, shape that I'd call "basic". Additional stuff build on it to explore a particular application (for example, the SmaCCBrowser, or many of the GT inspector extensions) or exploration technique (the Jejak trace viewer) provide additional shapes and concepts. So we're not stuck with the tools shape; with a model of the application and / or domain we can extend the tools. The system has been extendable since the very beginning, but I can't avoid thinking what was fit for the small smalltalk systems of the 80's is not anymore today, and that a strong conservatism has gone into it. That and a significant increase in the system complexity making it harder to change. > I build views and queries all the time. Just like the way a test > looks like informs me about the suitability of the domain design, the > elegance of a query or of the code of a visualization informs me > about the same thing as well, only from different angles. I also > throw most of these visualizations away. You never quite know which > shape is insightful and that is why it is important to control the > cost of a view. The cost should be so cheap that it should be faster > to create the view than to talk about the problem. Once you reach > that place, the game changes. I can relate to that. Even if I don't see the perfect place where to set the necessary views in the kind of things I do... But I've already been in the places where one has to design something to "make it inexpensive" a certain set of activities, and, when you carefully research that set of activity, to cover it significantly forces you to build a DSL that's so complex that you end up throwing it away because nobody uses it (but everybody says you must be able to do this, and that corner case, and, and...). Now, if the code tools we're working with in the Smalltalk space could stop being so monolithic (huge chunks of code) and focuses instead on simple, core functions, that could be combined for browsing / exploring / coding instead! For example, Nautilus is just an interactive vizualization of a code structure on top of a code pane; the message browser is another one; one of the GT pane (the meta one) is trying to be all that in one pane; the finder is that too. > Visualization is not a replacement for design. It is only a way to > learn about what does or does not work. But, it is an essential one. Do you think so? I've seen the power of interactive coding vizualizations (vizualizations that are used to code) and I certainly think they can do a lot more than just understanding a structure. They, when used to code, force you to code in a certain way... >> The Message Browser is an interesting piece of code. I replaced it, >> but it has a very strange API with users happily hacking into the >> internal representation of the message browser, so, even >> determining what is the API of that damn thing is ... interesting. >> >> There are some things the original message browser does very well, >> but I'm not sure it was intended. It's a very nice todo-list, for >> example. Works very well in a query some code/modify everything >> that match. I'm not sure it works that well as a >> discovery/navigation code tool. > > I do agree that the Message Browser is a nice todo list for methods. > We have a long way ahead of us :). I'm a few hundreds lines away for a replacement covering the todo-list aspect. There isn't much to it, really. Regards, Thierry > Cheers, Doru > > > >> Regards, >> >> Thierry >> >> 2017-01-09 16:09 GMT+01:00 Tudor Girba <[hidden email]>: Hi, >> >> In my opinion, Pharo provides the strongest infrastructure for >> understanding a system from all technologies I have seen. So, if >> you say that Pharo is a bit "under featured in, then I think we are >> not referring to the same thing :). >> >> May I ask how you are using the inspector? For example: - do you >> extend the inspector? - do you construct visualizations about your >> system in the inspector? - do you write queries about code in the >> inspector? >> >> Cheers, Doru >> >> >>> On Jan 9, 2017, at 3:42 PM, Hilaire <[hidden email]> wrote: >>> >>> I know this path of understanding code while it is running >>> (inspector or debugger), but it is still a tedious path, and I >>> feel Pharo is a bit under featured on that specific department, >>> therefore my question on Moose. >>> >>> Hilaire >>> >>> >>> >>> Le 09/01/2017 à 15:09, Tudor Girba a écrit : >>>> That is why my advice is to not try too long to understand >>>> Pharo code statically because this is not where the power of >>>> Pharo is. You are in a much better position to understand a >>>> system when it’s running. So, the tools that I use the most are >>>> the inspector when I need to understand structural >>>> relationships or contracts between objects, and the debugger >>>> when I need to understand some algorithmic steps. Even when I >>>> look for code structure patterns, I mostly use the inspector >>>> because it allows me to query. Then you augment these tools >>>> with custom views and you get quite far. >>> >>> -- Dr. Geo http://drgeo.eu >>> >>> >> >> -- www.tudorgirba.com www.feenk.com >> >> "We can create beautiful models in a vacuum. But, to get them >> effective we have to deal with the inconvenience of reality." >> >> _______________________________________________ Moose-dev mailing >> list [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ Moose-dev mailing >> list [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- www.tudorgirba.com www.feenk.com > > "Value is always contextual." > > > > > _______________________________________________ Moose-dev mailing > list [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
Happy New Year to Everyone and to you Doru,
I think you are right. I am also thinking that Moose, Pharo and Roassal enable me to work with complex software applications in a fundamentally different way. I work in software maintenance, so I needed one additional tool (that could be used for any languages) http://www.smalltalkhub.com/#!/~RainerWinkler/RW-Moose-Diagram . This was too complex for me to develop, before I learned of Moose, Pharo and Roassal. All this tools together allow me now to work with complex legacy code in a completely different way. Analyzing, understanding and visualizing code is much easier and faster then before. When I have to touch a part of an application, it is now much faster to create a diagram of the objects that have to care for. It was possible before, but needed much more manual work and time. Now it is much easier, so I can do it much more often. I use Moose and Pharo therefore nearly every day in my projects to do this. Thank you all for this wonderful treasure box of tools and ideas. Cheers, Rainer -----Original-Nachricht----- > Von: "Tudor Girba" <[hidden email]> > An: "Moose-related development" <[hidden email]>, "Pharo Development List" <[hidden email]> > Cc: "Any question about pharo is welcome" <[hidden email]> > Datum: 01/09/17 10:30 > Betreff: [Moose-dev] happy and bold new year > > Happy New Year, everyone! > > Over the last year, I went through a rather extensive tour and I directly exposed Moose, GT and Pharo to some 2000+ technical people through various sessions and trainings at conferences and companies. The tour will continue this year. > > Most of the sessions are not directly about Moose, GT or Pharo, but about broader topics that are served through what we do around here. These topics can relate to solving problems without reading code, to steering agile architecture, or more recently, to even broader topics like software environmentalism. If you are wondering what software environmentalism is, please take a look at this talk: > https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA > > I now have the confirmation that there is a whole space which is unaddressed by mainstream technologies. Often people find themselves frustrated having to build their systems on top of opaque technologies with not much hope of understanding what is going on under the hood both because they do not have access to what is behind and because they are provided lack the tools to investigate. You see, developers are suppose to have the coolest job on the planet, and many of them are unhappy. This has to change, and we can do that. > > In a conversation I had with a highly respected researcher, after explaining how our tools allow us to work, he noted reluctantly “so, you are claiming that you are practicing a fundamentally different software engineering?”. This question took me a little by surprise because the only answer I found myself being able to provide was “yes”. I sent him this talk: > https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA > > It is strange to be in the position to tell the world that we are constructing something fundamentally better, but I really do believe that we are. > > I wish you a happy and bold new year! > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing should have the right to be different." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |