On 6/6/2011 12:29 AM, Casey Ransberger wrote:
I've heard of an IDE called VisualAge (I think?) that was written in
Smalltalk but could parse and to a degree reason about other
languages, but I've never seen it.
Have you looked for that thing, or was it just not so great?
not really looked at VisualAge...
was intending here to look some at "Code::Blocks", since I got thinking
about IDEs some.
personally, I have not been as much into Smalltalk, due mostly to my
apparent inability to understand it when looking at it (look at syntax
reference, look at code, feel utterly confused as to just what I am
looking at...). (like, somehow, my brain can't really parse it or make
much sense of it).
I have taken some ideas off of both Smalltalk and Self, although in the
form of a language I can more easily understand though...
granted, there are other languages like this (like my apparent inability
to really make sense of Haskell either).
although, I can generally read/understand Forth and PostScript
acceptably well, so I really don't know sometimes.
although, recently when writing documentation for some parts of my
language, and made an observation:
str="Hello";
s=str;
while(*s)
printf("%c", *s++);
printf("\n");
basically, along the lines of:
"holy crap... my language still retains a fair amount in common with C...".
this was not originally intended (mostly, I was trying to implement
ECMA-262 and add ActionScript and Java like features), just the
combination of "little things" (implementing stuff, thinking "oh well,
this would be nifty...") happens to allow a few C-like constructions to
be written.
also:
buf=new char[256];
str="Hello";
t=buf; s=str;
while(*t++=*s++);
funny how this works sometimes...
or such...
On Jun 5, 2011, at 11:55 PM, BGB <cr88...@gmail.com
<mailto:cr88...@gmail.com>> wrote:
On 6/5/2011 11:03 PM, C. Scott Ananian wrote:
On Sun, Jun 5, 2011 at 8:35 PM, BGB <cr88...@gmail.com
<mailto:cr88...@gmail.com>> wrote:
I would personally like to see an IDE which was:
more-or-less language neutral, to what extent this was practical
(more like traditional standalone editors);
not tied to or hard-coded for particular tools or build
configurations (nearly everything would be "actions" tied to
high-level scripts, which would be customizable per-project, and
ideally in a readily human-editable form);
not being tied to a particular operating system;
...
This is Eclipse. Granted, it's an IDE which is
designed-by-committee and hard to love, but it answers all of your
requirements.
--scott
I don't believe Eclipse is it, exactly...
it handles multiple languages, yes, and can be used with multiple
operating systems, and supports multiple compiler backends, ...
however, AFAIK, pretty much all of the logic is written in Java-based
plugins, which is not ideal (and so, essentially the logic is tied to
Eclipse itself, and not to the individual projects).
I was imagining something a little different here, such as the
project control files being more like Makefiles or Bash-scripts, and
so would be plain-text and attached to the project (along with the
source files), where it is possible to control things much more
precisely per-project. more precisely, I had imagined essentially a
hybrid of Makefiles and Bash.
also imagined was the possibility of using JavaScript (or similar) as
the build-control language, just using JS in a manner similar to
Make+Bash, likely with some special-purpose API functionality (to
make it more usable for Make-like purposes).
a difficulty with JS though is that, normally, IDEs like things to be
fairly declarative, and JS code its not declarative, unless the JS is
split into multiple parts:
info about the project proper is stored in a JSON-based format, and
then any build logic is JS files attached to the project.
so, the IDE would mostly just manage files and editors, and invoke
the appropriate scripts as needed, and many IDE actions essentially
just call functions, and so one causes something to happen by
replacing the default action functions (such as in a script loaded by
the project file).
actually, conceptually I like the JS route more, even if it would
likely be a little more verbose than a Bash-like syntax.
IMO, the next best alternative is SciTE, so what I was imagining
would be a more "expanded" version of SciTE.
then there is also CMake, ...
there is also SCons, which is conceptually related to the prior idea,
but it based on Python.
but, for the most part, I have mostly just ended up sticking with
good old text editors and makefiles, as these have served me well,
despite their drawbacks (the cost of switching to an alternative
strategy likely being somewhat higher than that of doing nothing and
staying with the present strategy). IOW, the "if it aint broke, don't
fix it" strategy...
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org <mailto:fonc@vpri.org>
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
