Subject: mailing-list for TeXmacs Users
List archive
From : Offray Vladimir Luna Cárdenas <address@hidden>- To: address@hidden
- Subject: [TeXmacs] Componentization of TeXmacs
- Date: Sun, 25 Oct 2009 04:33:20 -0500
Hi,
Recently I have been discussing about a educational centered CAS called mathrider [1]. In a way that for Free Software CAS was pioneered by TeXmacs, Mathrider is made with plugings that extend the functionality of a basic core. Sage has taken a similar approach integrating multiple programs in a single interface, with unified syntax and developing new functionality that none of the integrated programs can offer. So the trend for, not only one, but several free software CAS to be used in research and education is visible. And so a question about how they will talk each other and create a coherent integrated experience that can be set up by their users to suit their needs is upcoming also. For me the most important attribute of the TeXmacs experience is the fluidity of writing and the core of it is in equation editor and the way it combines with the textual one. Having shortcuts, markup, icons and so on to write maths, delimitators for the scope of and environment and real time visual feedback with beautiful typography is the most pleasant part of using TeXmacs (extensibility via CAS sessions is another, but that is addressed in other places of the trend). TeXmacs has been until now a interface that provides a integrated (almost) experience for the writing and use of other math programs, but now that this trend is present, ¿Could TeXmacs be thought as a component of other interfaces/integrations?. I know that there is an important effort on porting TeXmacs to another toolkit and so giving it the possibility to run easily on Windows also, but my question is about if some components of the experience could be isolated and offered as a "service" of another writing experience. For example, using the equation editor as part of the math writing experience in a web browser.
[1] http://mathrider.org/
Cheers,
Offray
Ps: here comes the initially referred talk:
Ted Kosan wrote:
Offray wrote:
>> My opinion on the text-oriented interface vs. a calculation-oriented>
>> interface issue is that a student needs to learn how to program first
>> before using a calculation-oriented interface. One reason for this is
>> that after one knows how to program, learning mathematics is
>> significantly easier.
> Is an interesting alternative approach.There is a deeper argumentation
> of this? My undergraduate studies were in Informática Matemática
> (informatics and mathematics some kind of middle place between both) and
> in fact I remember how much insight I gain from learning math at the
> same time that I was learning programming, data bases and so on, but I
> never thought the other way around and this is an approach I will like
> to explore. In fact, in the documentation, you mention the blog post
> that I have read, but if you have any deeper info I would like to read
> it also.
Aside from my own experience, observing my students for a long period
of time, and Steve Yegge's wonderful blog post on the subject, I have
no further information to support this idea so I probably should have
stated that it was my opinion :-)
> Yes that's my experience also. Calculation-oriented interface could help
> with the basics but is no warranty. But I should make myself clearer
> about "textual-interface". When I say this I was thinking more about a
> document processor instead of a text processor, following the
> distinction made by the people of JEdit in their FAQ: Text processors
> work with text that is used as input of another thing: code for
> compilers/interpreters, markup languages for browsers, and so on.
> Document processor on the other hand introduce a metaphor so people is
> not working with the textual representation, but with the visual
> representation or something between (like in the What You See Is What
> You Mean approach of LyX/TeXmacs). I was more pointing to this kind of
> interface, but I don't use the word "document"-oriented interface
> because document is a wide word (code snipped, CAS sessions,
> spreadsheets, mails are all documents). So my distinction was more about
> where is the center of interaction in interface: in calculation or in
> writing. TeXmacs for example has it on writing while Sage Notebook it is
> in calculation. Of course there are intermediate places and my question
> was more about "how is to be on that places for you?" (you addressed
> that also, so see my comments behind)
I understand what kind of interface you mean now. A while ago I used
TeXmacs fairly regularly and I very much liked the design.
> I'm a user of TeXmacs. I wrote my undergraduate and master thesis on it.
> I believe in its slogan: "Writing is a pleasure", at least inside
> TeXmacs. The thing I like more about it is the fluid experience of
> writing (and interface is about the experience): you can go to write
> text to math easily, you have shortcuts, markup, icons, extensibility
> with CAS sessions. The problem is that using it in Windows is not easy
> (the most used OS for the students) and that Sage is too big so their
> integration in a Virtualized Linux that runs inside Windows has
> penalties in disk space and speed for some computers. Mathrider is
> cross-platform and I would like to see the same fluid attributes of
> TeXmacs in it.
>
> I see that you can "embed" java apps in frames of the Mathrider
> interface. Recently I have being testing the use of tablets to give my
> classes. And I wonder if there is a possibility to integrate a journal
> tablet interface as the writing math-docs centered part of the
> interface. The inspiration comes from things like MathJournal[1] and
> Rapid Pi[2] and Xournal / Jarnal[3]. The idea is to have a frame similar
> to the ones of Geogebra/Jung and so on with Jarnal in it (how difficult
> this could be?) and that some parts of Mathrider could be embedded in
> Jarnal as objects keeping correspondence with their origins, in a
> similar way to the "drop connected objects interface" of Mathcad. So, if
> you double click on one of them, you go to the app that is the creator
> of that object and can made modifications that would be updated in the
> Jarnal doc.
One of the reasons I chose to base MathRider on JEdit is because JEdit
was designed from the ground up to be easily extended via scripts and
plugins. Beyond this, it has all the "plumbing" which is needed to
allow these plugins to communicate with each other so that useful
applications like the one you describe can be created without too much
effort. So beyond its role as an environment for teaching beginners
how to program a CAS, MathRider is also a rapid prototyping laboratory
where numerous mathematics oriented applications can be created and
experimented with to determine if the approach they embody is useful
or not.
The especially useful applications can also be spun out of MathRider
as stand-alone applications that do not need to run inside of
MathRider at all. For example, MathPiper can easily execute outside
of MathRider and it be found in a file called
mathrider/jars/mathpiper.jar in the MathRider distribution. If you
open a command line shell and execute the mathpiper.jar file using the
following command:
java -jar mathpiper.jar
A GUI console will be launched which will give full access to
MathPiper. If the following command is executed, the GUI help
application for MathPiper is launched:
java -cp mathpiper.jar org.mathpiper.ui.gui.help.FunctionTreePanel
Most of MathRider's plugins can be run outside of MathRider like this,
either individually or together as part of some application. The hand
full of plugins that are currently distributed with MathRider are
mostly a proof-of-concept for the hundreds of plugins that I envision
it will eventually support. I have quite a long list of plugin
candidates and I have already added Jarnal to the list :-)
The reason that MathRider is designed this way is because I don't
think anybody can predict what the useful mathematics-oriented
applications for education are going to be so MathRider makes it
relatively easy to experiment with various application designs to see
which ones work and which ones don't. Of course, the primary
difficulty that educator's who have an idea for an application face is
that most educators are not application programmers. This section
from Karl-Dieter Crisman's post touches on this problem:
> Add to that the fact that most of the people who would be most
> passionate about the teaching aspects have heavy teaching loads and/or
> a weak computer science background, and the result is not surprising.
> Ted K. is probably quite unusual in coming at it from the CS side, and
> you can see it in that he can create something like MathRider! I
> couldn't imagine that in my wildest dreams. Most of the people I've
> talked to who really want to improve the ed side have some computer
> background, but not the expertise to do really amazing things.
This "educators with an idea but no way to implement it" problem is
fundamental and it is one that I developed a solution for when I was
active in the Sage project. As it turns out, a side benefit of
teaching a large number of students how to program is that a
significant number of them will find they have a real talent for it
and they will want to do more of it. It is not a coincidence that
MathRider is developed with MathRider configured as an IDE (complete
with a build system, integrated source code repository access tool,
etc.) So then one a) teaches these talented students how to do
application programming and b) puts a process in place which enables
them to work with educators in order to create plugins and
plugin-based applications. This then becomes a software engineering
problem and the discipline of software engineering contains standard
methods for solving it.
> Being this a list on Sage and education I will keep the discussion here
> because ideas on interface could be useful for sage in particular and
> for education problems and CAS in general. If it becomes too much
> general or Sage unrelated and this is not the place for it, please tell me.
I think we have indeed strayed into the "Sage unrelated" category, so
if you would like to continue this discussion feel free to contact me
off list :-)
Ted
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-edu" group.
To post to this group, send email to address@hidden
To unsubscribe from this group, send email to address@hidden
For more options, visit this group at
http://groups.google.com/group/sage-edu?hl=en
-~----------~----~----~----~------~----~------~--~---
- [TeXmacs] Componentization of TeXmacs, Offray Vladimir Luna Cárdenas, 10/25/2009
Archive powered by MHonArc 2.6.19.