Re: [Pharo-project] Paradigm change in Smalltalk software engineering visible?
On Oct 31, 2011, at 11:16 AM, Guido Stepken wrote:
Hello!
Some weeks ago i asked, weather code in Smalltalk is an object too or not. The answers were not that clear as i expected! :-(
Now i would like to put up the question, if there is a paradigm change in software engineering slowly coming up in the Smalltalk community towards class factory, code, that generates code, that is jitted immediately to generate further classes to finally be instantiated?
Would that be good? Meta Programming is powerful, but you need to take care that you can produce an un-understandable mess very easily.
E.g. the regexp compilercompiler SmaCC.
Nobody uses SmaCC anymore.
How "dense" has a Smalltalk code system to be that it starts to emerge from itself?
That is another question.
Means: When starts Pharo refactoring its own code or AST parser itself?
PetitParser provides exactly that: A parser has a meta-model to be changed at runtime. With Opal, we use an AST for everything that has transformation support of the RB.
Maybe a too unclear question, but i hope someone can understand what i mean ... :-)
You are always confusing. Marcus -- Marcus Denker -- http://marcusdenker.de
Means: When starts Pharo refactoring its own code or AST parser itself?
PetitParser provides exactly that: A parser has a meta-model to be changed at runtime.
With Opal, we use an AST for everything that has transformation support of the RB.
Maybe a too unclear question, but i hope someone can understand what i mean ... :-)
You are always
Hi Marcus! PetitParser ... Yes. A paradigm chance already. I was thinking of a data flow analysis parser, that "profiles" through a running system, looking out for relevant and irrelevant "data control & logic structures" (like reducing Pharo source from "unused" code), backtracking the growing of finally thrown or unused data, thus reducing the system to the minimum of relevant code by itself. Means - I see a new paradigm change coming up. Is's like sticking "PetitParser" in its own ass, letting PetitParser analyze its own dataflow, automatically replacing PetitParser by its evolutionary child. What source structures could be generated, that are still readable and changeable by humans?? Guido
participants (2)
-
Guido Stepken -
Marcus Denker