The coolest thing since sliced bread

ruby-talk
1

Ugh! Free write forces users into a new editor? I’m lost without Vim.

···

-----Original Message-----
From: MikkelFJ [mailto:mikkelfj-anti-spam@bigfoot.com]
Sent: Tuesday, December 10, 2002 9:16 PM
To: ruby-talk@ruby-lang.org
Subject: The coolest thing since sliced bread

The coolest thing since sliced bread is a piece of sandwich bread which is
sliced to 1/3 of the original thickness then polished for crumbs by rotating
the slice on a breadboard. The slice is then cut into small triangles which
are covered by a thin layer of sugar and fried until the sugar becomes
caramel and the triangles curve. Served on home made icecream - that’s whats
I learned on telly today anyway.

The other thing I learned today was that humans may genetically have carried
the ability to carve tiny animals out of bone for about 50.000 years before
actually doing so. How about software 50.000 years from now? Grep will
propably work as it ever did. Emacs, no - stop that thought.

I meant to write that FreeRide that is the coolest thing since sliced bread
before getting distracted by broadcast media but now it can only be the
second coolest thing since sliced bread. I was impressed with the Eclipse
plugin design. I was happy that FreeRide was build in Ruby (rather then
being an Eclipse plugin) but chose to follow some of the design principles
of Eclipse. Eclipse is large and bulky in size, yet it is also some of the
best Java GUI around partially due to the SWT GUI and partially due to the
plugin design.

I don’t yet know how FreeRide turns out, but I have followed the project on
the sideline peeking at source code, documentation and screenshots.
My expectations are high - I have been following various software
technologies - and also experimented with different principles myself - I
have looked at many technologies. On my shortlist of technologies are Ruby,
Fox, Scintilla, YAML, bidirectional or publish/subscribe based design,
decoupling of GUI from logic, message passing, automated testing, local
responsibility, proper dependency handling (see also SCons build tool). The
key points here is being unbloated, efficient and in control of what is
happening.
I’m not sure about the unit-testing part of FreeRide, but then GUI testing
is non-trivial - but otherwise FreeRide is packed with what I consider great
technologies and principles. It really shows how time spend at doing a
proper initial design pays off - at any rate an IDE this flexible in the
given timeframe and the given manpower is fairly impressive. If only a
number of known operating systems had put as much thought into the core
design, many things would be easier. I’d mention one operating sytem which
seem to have got this right though: QNX. In fact QNX uses message passing in
its tiny core and most services are user processes connected via a namespace
that covers the entire network. QNX scales massively and runs happily across
many machines (it has problems such as security and hard realtime not
necessarily being good for desktops - but there you are). Actually the pipes
of Unix was designed out of a similar vision of plugability, and they
certainly have been useful.

On a conceptual level FreeRide demonstrates some interesting aspects of
software development:
I was never into Ruby because it was all objects - A while back I changed my
view of software as more organic than what can be represented as objects and
class hierachies - after all - what a thing is depends on who looks at the
thing - not the ancestor of the thing. But then I never though Ruby was only
useful for strictly object oriented design. In fact the Array protocol is a
key example - how many collections are derived from Array? They may use
Array and they may even Mix In Array, but they are rarely derived from
Array.

Try pick a UML tool an document the design of FreeRide. Sure you can
describe the each class involved using object and class diagrams. Better yet
you may capture the intialization scenario of some plugin - but how do you
capture the essence of FreeRide?
FreeRide is based on a DataBus where plugins hook up and sence the presence
of other pieces based on patterns of connectivity that lives on the Bus, not
in any single object. It’s like Suns mantra: the network is the computer
(they got that right). I really believe this on the path of next generation
software development (even if some of principles are age old) - the DataBus
was designed and implemented, but could have been an integral part of a
software tool as it works at a deeper level than the actual application.
Some of the success of XML related to similar pattern based connectivity
that cannot be formulated in “simple” class relations, at least not in a way
that readily convey the essence of the relationships. Rubys MixIn and Duck
Typing principles also follows these more organic patterns which in turn
originate from Lisp and SmallTalk as I understand.

Now I mentioned the organic aspect - genetically a bird is designed to sit
on a branch of a tree - so why do all birds sit on electrical wires these
days? Its because a bird recognizes a certain feature set as being a branch
useful for sitting for. If these conditions are met, the bird could not care
less whether the branch originates from a tree of the pine-tree family or
not. Which puts us back to duck typing. If it walks like a duck and quacks
like a duck, it is a duck.

As some may have noticed another technology on my shortlist is the
statically type language OCaml - so how does the work in an organic setting?
This langauge basically works on graphs of pieces of data each of which are
statically typed, but they can be recombined in endless ways - we are
essentially short-circuiting the type concept by focusing the types and
basic operations which much like a language grammar allows us to produce
these many combinations which in turn happens to be studied in real life
organisms such as tree growth (L-grammer systems as I recall). Instead of
creating a tree object we a designing branch constructing functions etc.
Thus static typing does not necessarily have anything to do with being
organic or not. A good demonstration of OCamls dynamic nature is the Lexer
module - it’s just a record of six or so fields, but some of these fields
are functions that can be completely customized for example reading buffers
by morsecode from the spacebar instead of ASCII from standard input. Lexer
is given to the parser. In a twisted version of the bird analogy, the parser
is the bird and the lexer is the branch. The Ocaml lex/yacc parser is among
the most flexible parsing tools around and still the only type safe parser I
know of. Ruby really needs a Lexer module btw. Thus I’ll maintain the claim
that static typing can be organic.

I’ve recently been “forced” do (D)HTML (it’s called work) - and JavaScript
(ECMA / JScript) has many of the same organic aspects of both Ruby and
functional languages - it’s dynamically typed and is heavy on closures. You
can do pretty cool stuff in this otherwise fairly limited language.

I see FreeRide as hands on example of how this kind of organic programming
paradigm works. I just hope it does not turn out to be dog slow, bulky and
buggy… In case it is not - it will be an example of dynamic typing versus
the fairly fixed world of Java. It’s not quite fair though - there’s Java
Messaging and JavaSpaces but who uses that anyway?

Whether you actually send messages as in QNX or you call functions with
context (closures) as in functional programming, or call methods in Ruby or
SmallTalk, the essence is that whatever you call can be dynamically replaced
thus decoupling dependecies and support plugability in ways not to be
predicted just like the birds new favority hangout - the electric wire.
FreeRide provides its own communication model via the DataBus based on this
line organic software principles. Thus - where will FreeRide be 50.000 years
from now?

I’d like to introduce the term Organic Oriented Design & Programming
(OOD/OOP), but I guess it’s taken so what about Organic Software Behavior
(OSB). In the end it’s not about design or programming, but about how
software interacts with other software and the enviroment.

I have to mention Ant Based Optimization: Ants are dumb, they follow simple
rules that happen to work, or rather, they follow feromone tracks. Turns out
to be an efficient way to solve the rather hard travelling salesman problem.
Keywoard is localized decoupled behaviour with an appropriate sensing input
and output. Giving up global control (such as systematic searching) gives
access to scalability and adaptability. It doesn’t quite fit into the
concepts being addressed here, but it is nice to have in mind as the next
thing in software agents communicating over a bus (or over a virtual ant
trails).

I’ve spend a fair bit of time thinking about and implementing various
aspects of organic software development in my spare time after having seen
the same software being developed over and over again with slightly
different names in yet another collection class.
I’m both embarrassed that FreeRide jumps in and does it fairly simple in
Ruby and thrilled that the concept seems to be workable in practice
(although it’s not exactly what I’m looking into). I’d love to be part of
FreeRide but then I’m in over my head with my own projects and work.

I hope FreeRide works out really well and perhaps I may also one day use
FreeRide for developing in other languages - I’m already using Scite for
most development as long as I’m not debugging.

Mikkel

2

Garriss, Michael wrote:

Ugh! Free write forces users into a new editor? I’m lost without Vim.

Sounds like an opportunity to me!

Some Vim lover out there (maybe, you?) could easily create a FreeRIDE plugin
to implement Vim key bindings.

Curt

···

-----Original Message-----
From: MikkelFJ [mailto:mikkelfj-anti-spam@bigfoot.com]
Sent: Tuesday, December 10, 2002 9:16 PM
To: ruby-talk@ruby-lang.org
Subject: The coolest thing since sliced bread

The coolest thing since sliced bread is a piece of sandwich bread which is
sliced to 1/3 of the original thickness then polished for crumbs
by rotating
the slice on a breadboard. The slice is then cut into small
triangles which
are covered by a thin layer of sugar and fried until the sugar becomes
caramel and the triangles curve. Served on home made icecream -
that’s whats
I learned on telly today anyway.

The other thing I learned today was that humans may genetically
have carried
the ability to carve tiny animals out of bone for about 50.000
years before
actually doing so. How about software 50.000 years from now? Grep will
propably work as it ever did. Emacs, no - stop that thought.

I meant to write that FreeRide that is the coolest thing since
sliced bread
before getting distracted by broadcast media but now it can only be the
second coolest thing since sliced bread. I was impressed with the Eclipse
plugin design. I was happy that FreeRide was build in Ruby (rather then
being an Eclipse plugin) but chose to follow some of the design principles
of Eclipse. Eclipse is large and bulky in size, yet it is also some of the
best Java GUI around partially due to the SWT GUI and partially due to the
plugin design.

I don’t yet know how FreeRide turns out, but I have followed the
project on
the sideline peeking at source code, documentation and screenshots.
My expectations are high - I have been following various software
technologies - and also experimented with different principles myself - I
have looked at many technologies. On my shortlist of technologies
are Ruby,
Fox, Scintilla, YAML, bidirectional or publish/subscribe based design,
decoupling of GUI from logic, message passing, automated testing, local
responsibility, proper dependency handling (see also SCons build
tool). The
key points here is being unbloated, efficient and in control of what is
happening.
I’m not sure about the unit-testing part of FreeRide, but then GUI testing
is non-trivial - but otherwise FreeRide is packed with what I
consider great
technologies and principles. It really shows how time spend at doing a
proper initial design pays off - at any rate an IDE this flexible in the
given timeframe and the given manpower is fairly impressive. If only a
number of known operating systems had put as much thought into the core
design, many things would be easier. I’d mention one operating sytem which
seem to have got this right though: QNX. In fact QNX uses message
passing in
its tiny core and most services are user processes connected via
a namespace
that covers the entire network. QNX scales massively and runs
happily across
many machines (it has problems such as security and hard realtime not
necessarily being good for desktops - but there you are).
Actually the pipes
of Unix was designed out of a similar vision of plugability, and they
certainly have been useful.

On a conceptual level FreeRide demonstrates some interesting aspects of
software development:
I was never into Ruby because it was all objects - A while back I
changed my
view of software as more organic than what can be represented as
objects and
class hierachies - after all - what a thing is depends on who looks at the
thing - not the ancestor of the thing. But then I never though
Ruby was only
useful for strictly object oriented design. In fact the Array
protocol is a
key example - how many collections are derived from Array? They may use
Array and they may even Mix In Array, but they are rarely derived from
Array.

Try pick a UML tool an document the design of FreeRide. Sure you can
describe the each class involved using object and class diagrams.
Better yet
you may capture the intialization scenario of some plugin - but how do you
capture the essence of FreeRide?
FreeRide is based on a DataBus where plugins hook up and sence
the presence
of other pieces based on patterns of connectivity that lives on
the Bus, not
in any single object. It’s like Suns mantra: the network is the computer
(they got that right). I really believe this on the path of next
generation
software development (even if some of principles are age old) -
the DataBus
was designed and implemented, but could have been an integral part of a
software tool as it works at a deeper level than the actual application.
Some of the success of XML related to similar pattern based connectivity
that cannot be formulated in “simple” class relations, at least
not in a way
that readily convey the essence of the relationships. Rubys MixIn and Duck
Typing principles also follows these more organic patterns which in turn
originate from Lisp and SmallTalk as I understand.

Now I mentioned the organic aspect - genetically a bird is designed to sit
on a branch of a tree - so why do all birds sit on electrical wires these
days? Its because a bird recognizes a certain feature set as
being a branch
useful for sitting for. If these conditions are met, the bird
could not care
less whether the branch originates from a tree of the pine-tree family or
not. Which puts us back to duck typing. If it walks like a duck and quacks
like a duck, it is a duck.

As some may have noticed another technology on my shortlist is the
statically type language OCaml - so how does the work in an
organic setting?
This langauge basically works on graphs of pieces of data each of
which are
statically typed, but they can be recombined in endless ways - we are
essentially short-circuiting the type concept by focusing the types and
basic operations which much like a language grammar allows us to produce
these many combinations which in turn happens to be studied in real life
organisms such as tree growth (L-grammer systems as I recall). Instead of
creating a tree object we a designing branch constructing functions etc.
Thus static typing does not necessarily have anything to do with being
organic or not. A good demonstration of OCamls dynamic nature is the Lexer
module - it’s just a record of six or so fields, but some of these fields
are functions that can be completely customized for example
reading buffers
by morsecode from the spacebar instead of ASCII from standard input. Lexer
is given to the parser. In a twisted version of the bird analogy,
the parser
is the bird and the lexer is the branch. The Ocaml lex/yacc
parser is among
the most flexible parsing tools around and still the only type
safe parser I
know of. Ruby really needs a Lexer module btw. Thus I’ll maintain
the claim
that static typing can be organic.

I’ve recently been “forced” do (D)HTML (it’s called work) - and JavaScript
(ECMA / JScript) has many of the same organic aspects of both Ruby and
functional languages - it’s dynamically typed and is heavy on
closures. You
can do pretty cool stuff in this otherwise fairly limited language.

I see FreeRide as hands on example of how this kind of organic programming
paradigm works. I just hope it does not turn out to be dog slow, bulky and
buggy… In case it is not - it will be an example of dynamic
typing versus
the fairly fixed world of Java. It’s not quite fair though - there’s Java
Messaging and JavaSpaces but who uses that anyway?

Whether you actually send messages as in QNX or you call functions with
context (closures) as in functional programming, or call methods
in Ruby or
SmallTalk, the essence is that whatever you call can be
dynamically replaced
thus decoupling dependecies and support plugability in ways not to be
predicted just like the birds new favority hangout - the electric wire.
FreeRide provides its own communication model via the DataBus
based on this
line organic software principles. Thus - where will FreeRide be
50.000 years
from now?

I’d like to introduce the term Organic Oriented Design & Programming
(OOD/OOP), but I guess it’s taken so what about Organic Software Behavior
(OSB). In the end it’s not about design or programming, but about how
software interacts with other software and the enviroment.

I have to mention Ant Based Optimization: Ants are dumb, they
follow simple
rules that happen to work, or rather, they follow feromone
tracks. Turns out
to be an efficient way to solve the rather hard travelling
salesman problem.
Keywoard is localized decoupled behaviour with an appropriate
sensing input
and output. Giving up global control (such as systematic searching) gives
access to scalability and adaptability. It doesn’t quite fit into the
concepts being addressed here, but it is nice to have in mind as the next
thing in software agents communicating over a bus (or over a virtual ant
trails).

I’ve spend a fair bit of time thinking about and implementing various
aspects of organic software development in my spare time after having seen
the same software being developed over and over again with slightly
different names in yet another collection class.
I’m both embarrassed that FreeRide jumps in and does it fairly simple in
Ruby and thrilled that the concept seems to be workable in practice
(although it’s not exactly what I’m looking into). I’d love to be part of
FreeRide but then I’m in over my head with my own projects and work.

I hope FreeRide works out really well and perhaps I may also one day use
FreeRide for developing in other languages - I’m already using Scite for
most development as long as I’m not debugging.

Mikkel

3

[…]

Some Vim lover out there (maybe, you?) could easily create a FreeRIDE
plugin to implement Vim key bindings.

There’s more to Vim than just the key bindings. Otherwise we’d be using
vi.

Just as there’s more to emacs than its key bindings.

cheers,

···

–
Iain.

4

Some Vim lover out there (maybe, you?) could easily create a
^^^^^^

I take, then, you’ve done something along these lines?

I’ve not written any FreeRide plugins, nor any (reasonably complex) editor
key-binding code, so I’m wondering just how easily this could be done.

It would be nice selling point for FreeRide if bindings for vi, brief, and
so on were available. I would certainly be happier if I could use vim
keyboard commands.

James

···

Curt

5

But the keybindings would be a excellent start around which other
features could coalesce.

martin

···

Iain ‘Spoon’ Truskett spoon@dellah.org wrote:

[…]

Some Vim lover out there (maybe, you?) could easily create a FreeRIDE
plugin to implement Vim key bindings.

There’s more to Vim than just the key bindings. Otherwise we’d be using
vi.

6

“Iain ‘Spoon’ Truskett” spoon@dellah.org wrote in message
news:20021211230217.GR9705@ouroboros.anu.edu.au…

[…]

Some Vim lover out there (maybe, you?) could easily create a FreeRIDE
plugin to implement Vim key bindings.

There’s more to Vim than just the key bindings. Otherwise we’d be using
vi.

Just as there’s more to emacs than its key bindings.

You forget you have Ruby on taps.
“Simple” editors such as Scite are critized for not being powerful enough -
but fact is the standard key bindings does 99% of the job easier than emacs
and vim (I really did try to give each of these a go). The rest is advanced
functionality which isn’t really about editing. You can write plugins in
FreeRide to accoplishing any number of such tasks - its far more powerful
than vim or emacs which are also a kind of GUI framework and editor.
It’s always annoyning when keybindings are different for standard
navigation, and for those not customed with ctrl+x etc. for copy paste etc.
different bindings would be nice.
But auto-formatting, ftp, bookmarks etc. could well be jobs for new plugins.
In the end the Scintilla control is just a display engine and FreeRide
becomes the new editor replacing both Scite (Scintilla based editor), vi,
vim, emacs, you name it.
Of course, the benefits of vim and emacs is the existing modules - but then
we a lot of Ruby modules to pull on. Thus I advise to view FreeRide as an
entirely new editor, not a GUI that should accomodate all kinds of editors.
That said, you could probably create connections to external editors by
writing a FreeRide communiction plugin in vim and emacs.

Mikkel

7

It would be nice selling point for FreeRide if bindings for vi, brief, and
so on were available. I would certainly be happier if I could use vim
keyboard commands.

Yes, it amazes me how IDEs never seem to have editors that look like vi or
emacs (if they do, it’s some kind of hacked binding to their native set).

The thing that would make me use an IDE would be if I didn’t have to forsake
vim to use it. One spends so much time typing code in, or editing existing
code, that the editing functionality is incredibly important.

That’s why I tend to shun any kind of GUI. Just give me vim and command line
tools and I’m a happy boy :-). However, if someone provided 100%
compatibility with vim inside the IDE, I’d probably start using it and
discover I couldn’t live without some of the other features it provides.

I’m sure that people who are emacs, brief, joe etc. fans would feel the same.

I guess I just feel I’ve invested a lifetime in becoming “at one” with vi and
it feels comfortable, so why force myself to use some other … dare I say
“inferior” :slight_smile: … editing mechanism.

Sorry; yes, I’m a vim bigot !! However, I think that if the major editors
could be component-ised, so to speak, then one could use whatever the best
IDE was, with whatever they considered the best editor was. Ie, not
compromises.

Just my AUD 0.02 worth.

8

There’s more to Vim than just the key bindings. Otherwise we’d be
using vi.

But the keybindings would be a excellent start around which other
features could coalesce.

An awful lot of effort reinventing the wheel. I suspect it would
make more sense having FreeRIDE have editor plugins where we can
just plug in our existing editors.

Perhaps with some sort of standard API so we can modify the editors as
needed. Check the aims of Bram’s A-A-P project http://www.a-a-p.org/

Or am I missing a point of FreeRIDE?

cheers,

···

Iain ‘Spoon’ Truskett spoon@dellah.org wrote:
–
Iain.

9

There’s more to Vim than just the key bindings. […] Just as
there’s more to emacs than its key bindings.

You forget you have Ruby on taps.

And emacs has lisp on tap =) [and vim has its viml, but I’m not a fan of
viml, which is why it’s good vim lets one have ruby and perl built in]

“Simple” editors such as Scite are critized for not being powerful
enough - but fact is the standard key bindings does 99% of the job
easier than emacs and vim (I really did try to give each of these a
go).

Editors are personal things =)

I’d love to test Scite, but it appears to be Win/X based rather than
xterm/console.

Any editor that is programmable is powerful enough.

The rest is advanced functionality which isn’t really about editing.
You can write plugins in FreeRide to accoplishing any number of such
tasks - its far more powerful than vim or emacs which are also a kind
of GUI framework and editor.

Well, it is meant to be an IDE tailored for Ruby. v/e are generic
editors. I get to edit any sort of file. I’m not saying I’m against
IDEs, just that I favour consistency between editing different types of
files. Once one learns an editor and has used it for some time one
becomes used to its quirks. The number of times I’ve pressed Esc while
entering form data on a web page and thus succeeded in wiping what I’ve
just written is ridiculous (thus w3m and Webite get points for having
textareas edited in one’s $EDITOR).

It’s always annoyning when keybindings are different for standard
navigation, and for those not customed with ctrl+x etc. for copy paste
etc. different bindings would be nice.

Not just standard navigation, but routine tasks. Someone used to vi(m)
expects modal editing. They expect the : command line, and for the
commands one is used to to work. A transition to a ‘better’ way is fine,
but an abrupt switch could be painful.

But auto-formatting, ftp, bookmarks etc. could well be jobs for new
plugins.

Yes. I can’t say I use my editor for ftp, but then I don’t edit remote
files except via ssh+vim =)

[…]

Of course, the benefits of vim and emacs is the existing modules - but
then we a lot of Ruby modules to pull on. Thus I advise to view
FreeRide as an entirely new editor, not a GUI that should accomodate
all kinds of editors.

Which is where it loses, imho. And where most IDEs have lost me before.
I edit more than just Ruby. That said, I’ll take a look at what FreeRide
offers (when 0.5.0 is released) and see what I can nab for vim plugins.

That said, you could probably create connections to external editors
by writing a FreeRide communiction plugin in vim and emacs.

Good.

cheers,

···

“Iain ‘Spoon’ Truskett” spoon@dellah.org wrote:
–
Iain.

10

“Harry Ohlsen” harryo@zip.com.au wrote in message
news:200212121209.20854.harryo@zip.com.au…

Sorry; yes, I’m a vim bigot !! However, I think that if the major editors
could be component-ised, so to speak, then one could use whatever the best
IDE was, with whatever they considered the best editor was. Ie, not
compromises.

I believe you can run vim inside MS developer studio, although I haven’t
tried.

Mikkel

11

Of late, I’ve been wishing for better project management tools - IDEs
are handy in that they don’t force you to think about file-level
structuring (no, ctags is not quite the same thing). Having several
panes is nice too (personal aesthetics, perhaps, but I’ve missed it in
thigs like vim and mutt). Lack of vi support has always stopped me,
though - I’d rather use vim than use an IDE, if I had to choose…
FreeRIDE is the first IDE that has made me think ‘okay, this is
something I’ll be willing to use despite it lacking vim keystrokes’, but
if it included them I’d be a happy camper. (I agree with whoever said
that vim keystrokes include at least the more common : commands).

anyway, just my 2 fils.

martin

···

Harry Ohlsen harryo@zip.com.au wrote:

The thing that would make me use an IDE would be if I didn’t have to forsake
vim to use it. One spends so much time typing code in, or editing existing
code, that the editing functionality is incredibly important.

That’s why I tend to shun any kind of GUI. Just give me vim and command line
tools and I’m a happy boy :-). However, if someone provided 100%
compatibility with vim inside the IDE, I’d probably start using it and
discover I couldn’t live without some of the other features it provides.

12

I agree. Actually, what I’ve often wondered is why someone doesn’t take the
guts of editors like xemacs and gvim and make it such that they can be
components (as in just another window pane) in other applications. Let’s
face it, most of what I want from Vim is the editing functions. Surely
that’s completely orthogonal to the other functions of an IDE.

I accept that you’d probably need some kind of bindings somewhere, to allow
the IDE to say, please open this file, save the file, etc. But, surely
that’s a very small effort, compared to trying to shoe-horn the entire set of
key bindings from one editor into another?

···

On Thu, 12 Dec 2002 11:21, Iain ‘Spoon’ Truskett wrote:

An awful lot of effort reinventing the wheel. I suspect it would
make more sense having FreeRIDE have editor plugins where we can
just plug in our existing editors.

13

Not just standard navigation, but routine tasks. Someone used to vi(m)
expects modal editing.

Some editors that have vi bindings tend to get this right.

They expect the : command line, and for the
commands one is used to to work.

However, they generally don’t get THIS right, which is something one uses a
bit less frequently, I guess, but when you want it, you WANT it :-).

Yes. I can’t say I use my editor for ftp, but then I don’t edit remote
files except via ssh+vim =)

… or, even better, samba or NFS, so you don’t even need to worry that
they’re on another machine.

14

Well, it is meant to be an IDE tailored for Ruby. v/e are generic
editors. I get to edit any sort of file. I’m not saying I’m against
IDEs, just that I favour consistency between editing different types of
files. Once one learns an editor and has used it for some time one
becomes used to its quirks. The number of times I’ve pressed Esc while
entering form data on a web page and thus succeeded in wiping what I’ve
just written is ridiculous (thus w3m and Webite get points for having
textareas edited in one’s $EDITOR).

The number of times I’ve hit ^W (delete word in insert mode in Vim) while
editing something in Internet Explorer (where ^W == close window) …

It’s always annoyning when keybindings are different for standard
navigation, and for those not customed with ctrl+x etc. for copy paste
etc. different bindings would be nice.

Not just standard navigation, but routine tasks. Someone used to vi(m)
expects modal editing. They expect the : command line, and for the
commands one is used to to work. A transition to a ‘better’ way is fine,
but an abrupt switch could be painful.

I’ve coded 2500 lines of Java in the last six days, and it works. The reason?
IntelliJ. AFAIC, nothing could ever be a better text editor than Vim, and
IntelliJ doesn’t come close. But Vim doesn’t understand Java. IntelliJ does,
and it is 1000 times better at coding Java than Vim is. IntelliJ can do
very-high-level things - automatically include “import” statements, rename
classes, methods, variables (with all usages - and ONLY usages - renamed),
extract methods from blocks of code, create methods from usage, create iterator
templates, extract interfaces/superclasses from existing classes, inline a
method/variable, alert you to all kinds of errors, move classes to different
packages, handle CVS, …

Long story short: using IntelliJ, I manage code more than write it. And
thanks to its “external tools” support, when I need some raw editing power, I
hit ALT-V and it opens the current file in Vim at the current line number.

My unsolicited advice to the FreeRIDE team: keep up the good work. Concentrate
on the ability to do very high-level things with Ruby code, and the editing
details will be immaterial. As I’ve mentioned in an earlier post, much of the
brilliance of IntelliJ relies on Java’s type system, but seeing as automatic
refactoring began with Smalltalk, I’m sure there’s potential for Ruby.

Gavin

···

From: “Iain ‘Spoon’ Truskett” spoon@dellah.org

15

I’ve coded 2500 lines of Java in the last six days, and it works. The reason?
IntelliJ. AFAIC, nothing could ever be a better text editor than Vim, and
IntelliJ doesn’t come close. But Vim doesn’t understand Java. IntelliJ does,
and it is 1000 times better at coding Java than Vim is.

I found the same to be true for me with emacs and Eclipse. I love emacs; been
using it for a long, long time, but I’ve abandoned it for any java work (which
is what I get paid to do) in favor of Eclipse, simply because IT DOES IT BETTER.

Long story short: using IntelliJ, I manage code more than write it. And
thanks to its “external tools” support, when I need some raw editing power, I
hit ALT-V and it opens the current file in Vim at the current line number.

Oo, eclipse doesn’t have that. Cool.

16

Gavin Sinclair wrote:

I’ve coded 2500 lines of Java in the last six days, and it works.
The reason?
IntelliJ. AFAIC, nothing could ever be a better text editor than Vim, and
IntelliJ doesn’t come close. But Vim doesn’t understand Java.
IntelliJ does,
and it is 1000 times better at coding Java than Vim is. IntelliJ can do
very-high-level things - automatically include “import” statements, rename
classes, methods, variables (with all usages - and ONLY usages - renamed),
extract methods from blocks of code, create methods from usage,
create iterator
templates, extract interfaces/superclasses from existing classes, inline a
method/variable, alert you to all kinds of errors, move classes
to different
packages, handle CVS, …

Without a doubt, IntelliJ IDEA is as good as it gets for Java development –
don’t code without it!

From the start of the FreeRIDE project, we viewed IntelliJ IDEA as a model.
IntelliJ knows Java – deeply. Similarly we want FreeRIDE to know Ruby and
provide the same level of programmer support. Its more difficult to do for
Ruby because of the dynamic typing, but I believe that it is possible to do
at least 90% of what IntelliJ does for Java.

This is also why it makes more sense to develop key bindings and such to
emulate other editors, rather than simply plugin create editor plugins. With
an Vim editor plugin you would probably miss out on these high-end features
that will be intimately tied in with the editor (code completion, code
assist, all sorts of refactoring support, etc). But creating key bindings to
emulate your favorite editor (to the extent possible) would leave these very
valuable features intact.

I always said that if FreeRIDE simply tried to clone IntelliJ IDEA for Ruby,
that alone would be a killer Ruby development tool. But we also have visions
that go beyond IntelliJ. For example, we really want to support remote
collaborative development with facilities like remote pair programming
(synchronized editing) and integrated chat. I’d like to see built-in support
for Agile/XP development practices, although I don’t know yet exactly what
form that would take.

We’ve got a lot of really smart and capable people in the Ruby community.
And FreeRIDE’s goal is to provide a solid platform that makes it easy for
Ruby programmers to build and integrate Ruby development tools while writing
all of this in Ruby itself.

“Build it, and they will come” :slight_smile:

Curt

···

Long story short: using IntelliJ, I manage code more than
write it. And
thanks to its “external tools” support, when I need some raw
editing power, I
hit ALT-V and it opens the current file in Vim at the current line number.

My unsolicited advice to the FreeRIDE team: keep up the good
work. Concentrate
on the ability to do very high-level things with Ruby code, and
the editing
details will be immaterial. As I’ve mentioned in an earlier
post, much of the
brilliance of IntelliJ relies on Java’s type system, but seeing
as automatic
refactoring began with Smalltalk, I’m sure there’s potential for Ruby.

Gavin

17

IIRC, you can plug gvim into MSVC++ or some such development
package.

···

Harry Ohlsen (harryo@zip.com.au) wrote:

On Thu, 12 Dec 2002 11:21, Iain ‘Spoon’ Truskett wrote:

An awful lot of effort reinventing the wheel. I suspect it would
make more sense having FreeRIDE have editor plugins where we can
just plug in our existing editors.

I agree. Actually, what I’ve often wondered is why someone doesn’t take the
guts of editors like xemacs and gvim and make it such that they can be
components (as in just another window pane) in other applications. Let’s
face it, most of what I want from Vim is the editing functions. Surely
that’s completely orthogonal to the other functions of an IDE.

–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

18

Hi Harry,

They have it’s called the vim Kpart for KDE :slight_smile: FWIW on their project page they
describe the difficulties they have encountered in trying to make a vim
component Sign in · GitLab

Signed,
Holden Glova

···

On Thu, 12 Dec 2002 13:55, Harry Ohlsen wrote:

On Thu, 12 Dec 2002 11:21, Iain ‘Spoon’ Truskett wrote:

An awful lot of effort reinventing the wheel. I suspect it would
make more sense having FreeRIDE have editor plugins where we can
just plug in our existing editors.

I agree. Actually, what I’ve often wondered is why someone doesn’t take the
guts of editors like xemacs and gvim and make it such that they can be
components (as in just another window pane) in other applications. Let’s
face it, most of what I want from Vim is the editing functions. Surely
that’s completely orthogonal to the other functions of an IDE.

I accept that you’d probably need some kind of bindings somewhere, to allow
the IDE to say, please open this file, save the file, etc. But, surely
that’s a very small effort, compared to trying to shoe-horn the entire set
of key bindings from one editor into another?

19

Emacs too. Generally the plugins talk to the MSVC++ IDE fairly well.
To the point that asking to “jump to a function def” in the IDE GUI
side, sends a message to the editor to open a the file and goto a
line. (At least the emacs plugin that I used to use did this).

I’m sure that at some point the FreeRIDE code could be accessed via
some sort of API, their design looks nicely architected. Once they get
a stable release out there, I’m looking forward to trying to write
some refactoring tools in the FreeRIDE framework. Imagine clicking on
“move method to other class” then having the code put up a list of
lines to review for changes.

···

On Fri, Dec 13, 2002 at 05:07:29AM +0900, Eric Hodel wrote:

Harry Ohlsen (harryo@zip.com.au) wrote:

I agree. Actually, what I’ve often wondered is why someone doesn’t take the
guts of editors like xemacs and gvim and make it such that they can be
components (as in just another window pane) in other applications. Let’s
face it, most of what I want from Vim is the editing functions. Surely
that’s completely orthogonal to the other functions of an IDE.

IIRC, you can plug gvim into MSVC++ or some such development
package.

–
Alan Chen
Digikata Computing
http://digikata.com

20

They have it’s called the vim Kpart for KDE :slight_smile: FWIW on their project page
they describe the difficulties they have encountered in trying to make a
vim component Sign in · GitLab

Brilliant!

So, the big question now is, would it be possible for the FreeRIDE team to use
this? I can’t remember what framework FreeRIDE is using, but it’s probably
not Qt :-(.

Oh well, at least we know it can be done, so maybe someone with GUI experience
will be able to do the same thing for that framework.

Harry O.