I can think of several reasons. 

First and most important, code is data, but source files are not code.
They are source and include many things a lot of which do not obey the
syntactic rules of the language. Comments and indentation are the most
obvious ones.

Second, reason is that not only do you need a special tool for editing,
you need a special tool for diffing as well. And version control. Maybe
you will have to rewrite these for every language now, rather than using
the lowest common denominator line-orientated syntax.

Also, you will have to update your editing environment for every new
version of the language.

Finally, source code is often wrong, or a work in progress. Okay, with
paredit, Clojure can be mostly kept correct (syntactically) most of the
time, but lisp is the oddity, and you need all the brackets to enable
this. Even with paredit, for me, editing in this way fails often enough
for me, that I wrote something to switch paredit off rapidly, and then
back on again when I've fixed it.

It sounds like a nice idea, but I think it's not. In fact, one of the
motivations behind my clojure library (Tawny-OWL) was to move away from
manipulating a program (well, not a program, but a complex, formal data
structure, but it's the same thing) by changing an live data structure,
and move toward a flat file that has to be parsed. Sounds like a
backwards step, but isn't.

Phil


Thomas Huber <th0mas.hu...@googlemail.com> writes:

> Hi, here is an idea that has been in my mind for a while. I wonder what you 
> think about it.
>
> In Clojure code is data, right? But when we program we manipulate flat text 
> files, not the data directly.
>
> Imagine your source code where a data structure (in memory). And 
> programming is done by manipulating this data structure. No text editor and 
> text files involved. 
>
> Your editor directly manipulates the source data and later saves it on disk 
> (maybe as a text file). 
>
>
> These are the benefits I can think of:
>
>  - It enables you to use any Clojure function to manipulate your source 
> „code“. Giving you hole new opportunities for refactoring.This functions 
> can be provides as library. 
>
>
> - Really nice auto complete. 
>
>
> - Visual programming. Source code can be represented in many different ways 
> (not just text) . The easiest example I can think of is color. It can be 
> represented as text of course (#23FF02)
>
> but that’s a quite bad interface for humans. Why not display the actual 
> color and provide a color picker? Or what about music notes? Or Math 
> formulars? Or what about a tree view to move and rename functions like 
> files? 
>
> This could all be implemented in a way that every library can ship there 
> own „views“. I think this „views“ are basically macros that are not limited 
> to text. 
>
>
> - You don’t have to worry that you text files are in the same state as your 
> JVM (when developing interactive). You only work on your sourcedata and it 
> gets loaded into the JVM automatically.
>
>
> - Answer questions about your source code. What is the most called 
> function? Who depends on this namespace? Where is this function used? What 
> is the biggest function? Thinks like that become easy. Again you can ship 
> this queries as a library.
>
>
>
>
> The drawback is you can’t simply program using any text editor. You need a 
> special tool. But we have that anyway (syntax highlighting, paredit etc.). 
> Nobody programs using a bare text editor. 
>
>
> Maybe this idea is not new? What do you think?

-- 
Phillip Lord,                           Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics,             Email: phillip.l...@newcastle.ac.uk
School of Computing Science,            
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to