[Goe-dev] Re: GOE

[<rb...@ce...>]

On Thu, 14 Jun 2001, Jay McCarthy wrote:

|
| On Wed, 13 Jun 2001 13:31:11 -0700 (MST), rb...@ce... said:
| > ...
|  the closeness of squeak is what i was thinking was probably the reason for it.
| i was talking to one of my friends about me experimenting with smalltalk and he
| said to me "what's the point of smalltalk? it's just one of those languages
| people waste their time with and never write anything in". whether this is true
| or not i couldn't verify but it wouldnt surprise me if people just used it for
| research.

There are quite a few companies that use it in-house, but I can't think of
any end user commercial programs at all. Mostly it is used for prototyping
a project, and once the concept is sold they move to a different platform.

|  the squeak people seem proud of the closeness, this is gather from the quote
| on the page "You start a fork every time you save an image", maybe they see
| that as a good thing.... i dunno.
|  i have squeakland open in another window, i'll be looking at it.

That quote was in quite a bit of context, but yes in ways they are proud
of being closed. Or rather some of them are. The more extreme perspective
among them is that squeak is the perfect world and tainting it is bad. But
there are others that share my sentiment, that if they ever want people to
use it they'll have to play nice with others.

| >  In smalltalk the tree-like pane is an object inheritance heiarchy. In Goe
| >  it is just a package heiarchy, not indicating what each package (Object)
| >  inherits from, but only some package structure. I think that both
| >  Inheritance heiarchy views and Package heiarchy views are important, but
| >  my philosophy is that the Package Tree is more important for most
| >  development. In the browser I'm making now (the re-write) the view will be
| >  configurable so you can see any panes you want. By default I think it will
| >  first have the Package Tree, then the Inheritance Tree (listing all the
| >  things that the current Package inherits from), and then the method list.
| >  The method "group" is just a way of organizing methods, and isn't
| >  mandatory at all. You would use this to further organize, seperating I/O
| >  methods from member access methods, for instance.
| >
|  good explanation, i get it now. are the inherited from packages displayed for
| only information ? when you select one will you be looking at that package's
| main view and thus have "climbed up" the hierarchy?

I think that when browsing with the package tree being primary the
inheritence tree will be mostly for adding / removing parent classes. It
would also be able to browse the parent packages, on a double click or a
right-click menu option for instance.

| i like the idea that you
| can customize the views and create groups of related functions. configurability
| is key in every aspect of the system - this is why things like X and emacs
| succeed, because every aspect can be change by someone (relatively easily i
| mean, obviously anyone can change the source but most people prefer to change
| the "data" that describes how the system works).
|  another configurable aspect that would be useful to have would be different
| ways to export your packages. as one package... broken up by sub object, or
| whatever.

Yes, I agree. I hope that not only will the system itself behave in that
way, but also will lend itself to easily create programs that do so as
well.

| >  Hey, did you look at / think about the Inline thing?
| ya, i grabbed the module and some of the supported languages and checked out
| the C cookbook. its a good idea but i failed to think of practical applications
| of it. the only one that occurred off the top of my head would be quick
| wrappers around C libraries but, i have a feeling that would be rather slow and
| it would make more sense to just do an XS (which i have never done... so i dont
| know how hard that is). so, as it stands on its own i dont see much useful
| about Inline - however, in relation to GOE i think that it can be really
| useful. Basically, GOE could have language 'modes' and be able to produce
| code/comments/object heirarchies for an of the supported languages - and this
| could be done in a couple ways....
|  for native object oriented languages (c++, perl, python) there are parsers
| that can pull out information about the objects/class, and such.
|  for languages that can simulate object oriented languages (c, c++ was
| originally a C++ to C translator as you may know) - there will be either: *
| embedded comments that describe the object and how it relates to the rest (and
| this will be parsed) - or possible something based on files or function names.
|  basically. Inline could compliment this by being able to execute the code
| inside of the program, rather than having to resort to outside programs.... or
| GOE could generate "on-the-fly" code to have your perl programs interface other
| C/Python/etc programs/functions that are within the GOE universe/project.
|  this would be turning GOE into a full environment for multi-language
| developement and integration - is that where you want to go?

XS is terrible, you could almost think of this as an intelligent
replacement for XS in some situations. But you're right, the more
important thing I was thinking about is in regards to Goe.

The main thing that I am thinking is along the multilingual development
and integration path. The only thing I see differently than you write
above is about non-OO languages. The way I'm trying to write Goe is along
with Perl's More Than One Way approach. There is nothing enforcing the
object orientedness that I'm currently using, I just choose to write the
system that way. Just parsing those languages down to the file / function
level would be good enough, I think. Just like in perl I can pretend,
simply by calling functions without using magical -> sytax, that I am not
Object Oriented at all (though I think I'm really pretending the other way
around). Make sense?

| -----
| currently as i understand it GOE is just the browser but hopes to be a full gui
| wrapper/editor/source broweser/project organizer.
| too many projects are just going for "IDE" - either for Gtk or Tk. i
| persronally have never worked on a perl project with a GUI and i have been
| working with perl for years. it's not something im interested in. what I AM
| interested in is an environment to better organize my projects. this is what
| was first attractive about GOE, i think it's a great idea to seperate each
| package and be able to address each method individually - that is key.
| so based off that i envision the class browser to just be able to be an
| instance of the browser of a project with many different packages making it
| up....

I'm not sure exactly what you mean in the last sentence. But... yeah :)

| other things that would be interesting....
|  running the program - simply opening up a terminal and running it
|  debugging - opening up a graphical debugger or a console (btw, have you looked
| at Devel::ptkdb - a perl tk debugger, really cool)
|  test running - write tests that you can run against a program/package to test
| that it is working as it should
|  cvs update/commit/add/remove frontends - nothing too complicated
|
| obviously it would be a good idea to be able to have a user specify
| modules/packages/plugins that they will use which will add entries to the
| menus, all the above things may be examples.
|

See, this project is just a generator of ideas! My theory is that since we
are using the project to work on itself a lot of needs, wants, and
problems will become obvious to us while we build it all up.

| i dont know if this is the direction you want to go. what is your "vision" for
| GOE?

One thing that I thought of while reading this stuff is how well Goe will
interface with other programs / systems. I don't want to be sucked in to
the same trap that so many of the SmallTalk people have. And I want to use
vim (embedded, preferably) as a plug-in editor :)

I talk a bit about my vision for Goe in my webpage. The thing is that the
project can shoot off in so many different directions. I want it to be a
very pleasant programming environment, meaning well organized and easy to
use and things like that. And I think that is where I'll start.

I mention GUI wrappers. I want that so that I am liberated from having to
use one GUI kit (gtk, win32, tk, qt,...). Inline will liberate me from
having to use one language. The very customizable browser, along with any
other tools we add, will liberate me from having to use inneficient
programming environments. So... I guess overall I seek liberation. Perl
itself has been a great starting point. Hm... liberation and cleanness.

--Brock