Hi Phil, thanks for your reply. The source data structure doesn't have to contain only "bare" source code. It could contain everything that is in a text file, but just saved in a structured way. The data needs to be "compiled" to bytecode anyway.
I'm not sure if diffing is a huge problem. You can still pretty print you source data and save it into a text file. Diffing these files should be enough to get an idea what was changed. And if not a special diffing tool would have other advantages to I think. 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. You can still save your programm as a data structure even if its wrong. Or am I missing your point? Thomas Am Freitag, 14. November 2014 18:05:47 UTC+1 schrieb Phillip Lord: > > > > 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...@googlemail.com <javascript:>> 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: philli...@newcastle.ac.uk > <javascript:> > 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.
