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 hilaire@drgeo.eu 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."
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 tudor@tudorgirba.com:
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 hilaire@drgeo.eu 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 Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi Thierry,
On Jan 9, 2017, at 4:31 PM, Thierry Goubier thierry.goubier@gmail.com 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 tudor@tudorgirba.com: 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 hilaire@drgeo.eu 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 Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Hi Doru,
Le 09/01/2017 à 16:45, Tudor Girba a écrit :
Hi Thierry,
On Jan 9, 2017, at 4:31 PM, Thierry Goubier thierry.goubier@gmail.com 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 tudor@tudorgirba.com: 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 hilaire@drgeo.eu 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 Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
_______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-
Thierry Goubier -
Tudor Girba