The Artima Developer Community
Sponsored Link

Weblogs Forum
Programmers Shouldn't Touch the Source

83 replies on 6 pages. Most recent reply: Jul 11, 2006 5:02 PM by Hossam Mashhady

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 83 replies on 6 pages [ « | 1 ... 3 4 5 6 ]
Robert Fisher

Posts: 1
Nickname: rfisher
Registered: Nov, 2005

Re: Programmers Shouldn't Touch the Source Posted: Nov 8, 2005 6:21 PM
Reply to this message Reply
Well, mentioning XML was a mistake. I believe the underlying file format isn't the point.

The point is the IDEs could be going even farther in the direction of allowing the programmer to work directly on the structure--the AST--than they do now. Instead of selecting, copying, & pasting text we should select, copy, & paste expressions & statements. That sort of thing.

Syntax errors would be a thing of the past.

& yes, it's nothing new, but it's still rare.

Now, I'm not convinced this is THE way to go. I think it is worth exploring more.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Programmers Shouldn't Touch the Source Posted: Nov 9, 2005 2:50 PM
Reply to this message Reply
> > Why do these constant translations between textfile
> formats (including
> > parsing the source), when you can parse it once, and
> potentially display and
> > edit it in any way you like, without having to re-parse
> the source after every
> > change?
> I don't get it. You have to parse an XML file too. So
> where is the difference? And unless you want to edit the
> raw parse tree (I doubt it...) you still have to re-parse
> parts of the "source view" after every change. Isn't that
> what modern IDEs are already doing?

Yes, you're right. It has to do some parsing, of the user input, at least. Yes, I was thinking of the representation being showed to the user in some form, while internally being stored in an efficient data structure (probably not XML). And, yes, modern editors do this to more or less extent.

What I was not at least thinking of, was that the IDE could use this extra information (from the parsing) to do more of what it starts to be able to do, today, such as include/exclude various information in the view (or show it in a different way), e.g. so that you can read the code "unobstructed" by JavaDoc comments, for example (as I said in a posting).



Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Programmers Shouldn't Touch the Source Posted: Nov 9, 2005 3:16 PM
Reply to this message Reply
> > > Every article that begins with the author
> > > expressing wonder that Unix has survived for so long
> is
> > > immediately suspicious; I think the author is either
> > > inexperienced in the real world, unable to learn
> > > something difficult, or a crank.
> >
> > I don't understand what you refer to here, because I
> don't
> > find anything of this sort in Christopher's blog, or
> the
> > linked-to article. Could you provide a quote?
> My comment was about Mr. Wilson's article, not any of Mr.
> Diggins' postings. I'm sure you run across articles and
> blog postings that begin by wondering why text files,
> Unix, vi, emacs, C, what have you have hung on for so
> long, followed by the author proposing a better whiz-bang
> solution. What they often miss is that the longevity and
> hardiness of the simple formats and tools is the reason
> for their continued usefulness and adaptibility. Mr.
> Wilson attributes the persistence of text files and vi to
> aging stick-in-the-mud programmers like me. I attribute
> the persistence (and ongoing adoption by lots of young
> programmers every day) to their usefulness. That's why I
> predicted that in ten years I (and lots of other
> programmers) will still be saving text files of source
> code from vi and its like, and XML will find its proper
> place as a replacement for proprietary binary EDI
> formats.

There may be a lot to that. As the "Pragmatic Programmers" have pointed out (in the chapter "The Power of Plain Text"): A common standard of information storage and exchange, means that tools from anywhere can work together, if they use that common standard. Plain text is one such universally understood standard.

> > You may scoff of this, but I also think this may be the
> > "next big thing". A lot of indicators point in that
> > direction, such as numerous research projects (several
> > links were given in a posting by Christopher),
> conferences
> > on "generative programming", etc.
> When any of that moves beyond research projects into
> something useful I'll gladly change my mind. The
> disconnect between what researchers do and what happens in
> the world of real data and real programs is pretty big.

Yes, but remember that things like high-level languages, OO, and generic programming, were once "research projects", as well. :) But, yes, so far, it's mostly research. I didn't say "This is the biggest thing", or something like that. I just find it interesting, and that it _may_ become a big thing.

When I first read about "generative programming" (in the book by the same name - quite a lot to read, but, to me, very rewarding), and in particular the example of "Intentional Programming" (Microsoft's research project), it was an "a-ha!"-moment for me. You see, many years ago (15-20) I played with the idea of a language where you could define your own language (keywords, etc.). I didn't really pursue this idea further, but when I read about IP, it was, like, "They've done it!" :)

One really hard part is how to present a meaningful interface to the user. The AST of even a moderate size program can be very complex, and the structure may easily be lost in a sea of details.

> It was Mr. Wilson who offered XML as an alternative to
> text and ridiculed aging programmers and their devotion to
> text-based tools. The original posting by Mr. Diggins
> offered XML as a structured alternative to plain text. I
> don't know what the deal is with "tree structures" that
> keeps coming up. An outline (in text) can, for example,
> represent hierarchies. What do tree structures have to do
> with program source code?

From what I understand, you can more or less represent a program in such a structure (an AST). However, there may of course be links between the nodes, across the tree.

> > What you talk of as "personalized Towers of Babel",
> others
> > may call a DSL.
> A DSL is great as long as it stays in its specific domain.
> What Mr. Wilson and Mr. Diggins describe is DSLs released
> into the wild.

What I've read of projects like these, is that they are more of a "meta-language", i.e. a language to define a language (such as a DSL).



Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Programmers Shouldn't Touch the Source Posted: Nov 9, 2005 3:59 PM
Reply to this message Reply
> We shouldn't reinvent approaches but rather go back to
> using what others designed in an earlier more innovative
> age.

"Way back, in a more enlightened era; a civiliced era: before the Empire..." :)

> People are slow to adopt really revolutionary technology.
> We haven't had a major innovation in the OO space since
> Smalltalk and Self. All others seem rehashing of the same
> concepts with a lot less success.

I guess one reason other languages have become more mainstream, may be other forces: performance may be one of them, the requirement of an IDE (for Smalltalk, at the time), may be another, and so on. There may be other forces, too, such as education. I read an article, recently (at ZDNet), where the author was one the experts on .NET at Microsoft, where he claims that:

a) Visual Basic was never intended as a professional language for enterprise-class applications: it was conceived more of something between a "professional language", and Excel macros.

b) During the dot-com boom of the '90s, the demand for programmers became much higher than universities and other institutions could supply, and that had companies been able to hire C++ programmers, they would never considered VB, but there weren't enough of them. So they said to themselves: "Ok, so what do we do? We can't hire C++, so let's do it in VB, because we can hire VB."

As something of a C++ fan, this was like music to my ears. :)

> Why Ruby when you Smalltalk is a better Ruby than Ruby!
> (Same goes for Java, C# and C++)

I doubt Smalltalk is a better Ruby than Ruby, or people would just use Smalltalk (unless there are other reasons, as mentioned above). As Bjarne Stroustrup (C++'s creator) has said it (when people ask him if C++ is "a better Smalltalk"): "C++ isn't a better Smalltalk. Smalltalk is the best Smalltalk." C++, and the other languages, should be judged based on their design goals, not on the design goals of another language. Smalltalk would do equally badly when judged against C++'s design goals, as vice versa. Smalltalk did not have C++'s design goals, and vice versa, and they have different strengths in different areas. Trying to compare so different languages is rather like comparing apples to oranges.

Some of what I like most about C++ is it's multi-paradigm nature: You're not forced into the mindset that everything is an object (Smalltalk), everything is a function (functional programming languages), etc., but can use the most appropriate paradigm for the situation. Some of the most power comes from combining paradigms, letting you do things that neither paradigm, by itself, can do. Iterating through a type-safe collection (genericity), calling polymorphic functions on the elements (OO), is an example that comes to mind.

Also, C++ has to some extent an ability to create "DSL"s in the language, through operator overloading, etc. (such as the Spirit parser framework, which enables an approximated EBNF-grammar to be written directly in the code, etc.).

And to set the record straight on where OO came from:

"C++ got its Object-Oriented concepts from Smalltalk?

No. C++ got the key notions of classes, derived classes, virtual functions (in other words, the notions of encapsulation, inheritance and polymorphism) from Simula just like Smalltalk did. In terms of family relationships, C++ and Smalltalk are siblings." (



Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: Programmers Shouldn't Touch the Source Posted: Dec 2, 2005 10:08 PM
Reply to this message Reply
John Brown wrote
> Errr... Let me get this straight. You are saying that we
> can simplify things by _adding_ information and making
> structures more verbose and complex?

Do you use a code editor that applies colouring?

What if you wanted to use different colouring etc. in different source, or apply rich formatting to comments?

Just a trivial example, but this is metadata that needs storing in addition to the compilable code.

One of the interesting things about coming from a Mac background is being used to every file having a resource fork which is a simple typed database, allowing tools to maintain such metadata without noise going into the source code.

In the spatial data environments I'm working in now, XML is rapidly replacing plain text formats because things like tabular CSV don't allow for rich modelling.

Annotation is power and being able to store it with the target makes a lot of sense.

Mike Swaim

Posts: 13
Nickname: swami
Registered: Apr, 2004

Re: Programmers Shouldn't Touch the Source Posted: Dec 6, 2005 4:16 PM
Reply to this message Reply
> John Brown wrote
> Do you use a code editor that applies colouring?
> What if you wanted to use different colouring etc. in
> different source, or apply rich formatting to comments?

I doubt that I'd want to apply different colorings to different source files, because it could get confusing. Also, what if I use different colors than someone else? With colors as an IDE setting, that's no problem. If you stick the colors in your source, you get a whole new variant of the old formatting wars.
This is probably not a good thing.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: Programmers Shouldn't Touch the Source Posted: Dec 13, 2005 3:08 PM
Reply to this message Reply
Mike Swaim wrote
> If you stick the colors in your source, you get a whole new
> variant of the old formatting wars.
> This is probably not a good thing.

Formatting wars occurred because there was only one set of the formats - the text itself.

What if being able to set colours in your IDE was similar to being able to override colours in a web browser - you can choose to use a page's originals or your preferred set.

Now think about the much richer model of overriding provided to browsers by Cascading Style Sheets.

Your personal sheet overrides can be interwoven with the main version server but a page can still have a local style included for a specific item.

This is a richer model and a community where lessons have been learned about how to combine rendering information.

In contrast, typical IDE rendering (colours and font control!) is like HTML 1.0 :-)

The interesting thing about this whole thread is how there's been a debate about where to keep extra annotations.

There is no single answer to this and can be no single answer. Given a set of extensible annotations to plain text source, a toolchain might supply them from a local cache, a server of some kind (inc repository) or you might save a fully-expanded tree for offline browsing.

The source of the metadata is an abstraction. How it is applied is another one that will probably vary according to the users' choices.

Providing a good set of default behaviours is the key to avoiding a descent into chaos (remember this is supposed to help us!)

There are parallels (and lessons already learned) in the XML Schema community, eg: a schema defines a model which is legal no matter how leaf items are included:

physically, with repetition, or

refs back to local definitions in the file, or

refs to a relative URI, server absolute URI etc.

It's like the difference between using lookup tables in a referential database and having duplicated strings.

One annoying tidbit is that, until recently, XML processors such as XSLT engines were not aware of the schema's abstract model so you had to write pattern-matching code for a single physical instantiation of the above possibilities.

Emil Cristian Alexandrescu

Posts: 13
Nickname: mkcoos
Registered: Jul, 2006

Re: Programmers Shouldn't Touch the Source Posted: Jul 11, 2006 8:43 AM
Reply to this message Reply
Source size XML size ratio is 8/42.
Whatever cool might it look on a CV, I still can't get why do they stick this sheety-XML downto our throats?!
Isn't that literate programming good enough?

Hossam Mashhady

Posts: 2
Nickname: xhossamx
Registered: Jul, 2006

(Job) AJAX Developer- California, USA Posted: Jul 11, 2006 5:02 PM
Reply to this message Reply
Title: AJAX Developer
Location: Mountain View, CA
Type: W2-Contract
Length: 6 Months
Pay Rate: Market

Job Description

- Extend a browser-based client into new UI areas and help us create the right environment for users.

- By pushing the boundaries of what is possible with our AJAX-based client software, we are looking to dazzle users with a high utility, highly intuitive interface and drive the competition nuts with imaginative and off-the-hook search solutions.


o Everything AJAX: DHTML, CSS, DOM, XML, XSLT, JavaScript (OOP).
o Fully conversant in web programming techniques and web based applications (HTTP, REST, etc).
o Thorough understanding of Web 2.0 technologies and concepts (blogging, feeds, wikis, etc).
o Analytical, thorough, resourceful and very detail-oriented.
o Self-motivated, hardworking, flexible with an ability to learn quickly.
o Strong communication and documentation skills.

Desired Background

• Minimum of 2-4 years of commercial development experience.
• Formal structured programming education.
• Experience with Ajax libraries/frameworks.
• Proficiency with Perl, Python, Java, HCI, SQL, Unix.
• Rapid development processes.
• Open Source interest/experience.
Please submit your resume to:

Hossam Mashhady
ESG Consulting

Flat View: This topic has 83 replies on 6 pages [ « | 3  4  5  6 ]
Topic: Programmers Shouldn't Touch the Source Previous Topic   Next Topic Topic: Language Purity and Dirty and Clean Functions

Sponsored Links


Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us