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 2: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 2 3 4 5 6 | » ]
robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Programmers Shouldn't Touch the Source Posted: Oct 23, 2005 8:29 AM
Reply to this message Reply
Advertisement
> > i'm too lazy to go look it up. my impression is that
> XML
> > regimes are Not Replacing EDI for these functions. nor
> > should they.
>
> Quite a few industries have adopted their own XML-based
> standards for data interchange, and those are replacing
> proprietary EDI.

but the original assertion is "invoices". that's financial data. any company which sends such over http in clear text is mad. the value of EDI is the VAN on which it runs. https is close, but no cigar.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

re-distributing data... Posted: Oct 23, 2005 9:16 AM
Reply to this message Reply
There appear to be two matters here: externalising compiler intelligence, and adding more information to source code.

Making the source format XML/similar is not really adding anything. It is moving data from compiler to source. Other tools could then do more, more simply. Editors firstly -- such a format would encourage development of more powerful ones. Maybe other similar things would be helped...

Perhaps aiming the 'semi-compiled' format towards something common between multiple languages is an avenue of consideration. Or aiming toward some other format already existing (or incipient)... The tool-simplification benefit could be pushed wider.

History and changes seems a separate matter: new data is being added to the source. But only from another tool like the compiler, so the same kind of thing is happening. Of course both source-config-managers and compilers operate, partly, above the level of single files, so there are limits to what can sensibly be externalised into single files (if the format *is* separate files...).

Essentially, augmenting source code means: The benefit of any processing is shared widely. That sounds good.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Programmers Shouldn't Touch the Source Posted: Oct 23, 2005 12:49 PM
Reply to this message Reply
> >In ten years
> > we'll still have Unix and C and vi, and XML will be
> > forgotten except as a legacy format used to send
> invoices
> > and shipping manifests around.
>
> i'm too lazy to go look it up. my impression is that XML
> regimes are Not Replacing EDI for these functions. nor
> should they.


And then there's the issue of whether everyone using XML will have to pay royalties because of these patents: http://news.com.com/Small+company+makes+big+claims+on+XML+patents/2100-1014_3-5905949.html?part=rss&tag=5905949&subj=news

From the article:
Bryant said that Scientigo over the past several months has had discussions with 47 companies regarding the patents, including large software providers Microsoft and Oracle.

Based on these talks, Bryant said he is confident that the company's patents will command royalties from software companies and other large organizations, such as Amazon.com, which use XML.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Programmers Shouldn't Touch the Source Posted: Oct 23, 2005 1:21 PM
Reply to this message Reply
> And then there's the issue of whether everyone using XML
> will have to pay royalties because of these patents:
> http://news.com.com/Small+company+makes+big+claims+on+XML+p
> atents/2100-1014_3-5905949.html?part=rss&tag=5905949&subj=n
> ews

You scared me pretty bad for a second, but the patent claim is complete nonsense. Take a look at the patent:

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,842,213.WKU.&OS=PN/5,842,213&RS=PN/5,842,213

Specifically:

"The present invention simplifies the data modeling process and enables its full dynamic versioning by employing a non-hierarchical non-integrated structure to the organization of information."

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Programmers Shouldn't Touch the Source Posted: Oct 23, 2005 7:07 PM
Reply to this message Reply
> but the original assertion is "invoices". that's
> financial data. any company which sends such over http in
> clear text is mad. the value of EDI is the VAN on which
> it runs. https is close, but no cigar.

You went off into the weeds somewhere. No one mentioned HTTP or HTTPS or any other transport. XML is a data interchange format; it's not a transport mechanism, and it doesn't rely on any specific transport mechanism.

Perhaps you aren't aware of companies adopting XML-based standards for data interchange, or that industry consortia have sprung up to move their members from proprietary EDI formats to XML. That doesn't mean it isn't happening, and it doesn't change my statement about XML surviving the next ten years mainly as a data interchange format.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Programmers Shouldn't Touch the Source Posted: Oct 24, 2005 5:49 AM
Reply to this message Reply
or that industry consortia
> have sprung up to move their members from proprietary EDI
> formats to XML.

they're the result of standards (ANSI X12), much like XML schemas (although these tend to be ad hoc). neither is self-describing; both need programming to figure out the data. EDI, as the term is typically used, means not just the data encoding, but also the transport. same with XML. EDI/VAN, XML/HTTP. as to which encoding is "better", name a specific document and XML schema to compare. wasn't the idea of binary XML (yikes) from the replace-EDI-with-XML crowd?

so the issues:

- which is the better encoding? toss up
- is there any gain from creating a new encoding? toss up
- which is the most secure? EDI/VAN
- which is cheaper in the short run? XML/HTTP

Michael

Posts: 12
Nickname: target
Registered: Jan, 2005

Re: Programmers Shouldn't Touch the Source Posted: Oct 24, 2005 6:06 AM
Reply to this message Reply
I know that critique is what all new ideas faced with. But can't keep silent :)

XML is good for messaging and bad for data storage.
XML source code representation is a storage in fact. And it is not good, since advantages just out there, but problems... You'll have them for sure. To edit any source file you'll have to use a kind of special tool. And how about scripting labguages? PHP developer kill himself when he will not be able to edit file using notepad or any other tool like that.

Michael D.

Ron Ruble

Posts: 10
Nickname: ronr
Registered: Aug, 2004

Re: Odd idea Posted: Oct 24, 2005 6:45 AM
Reply to this message Reply
I'm not an unrestricted fan on XML, but I have a few observations.

The primary reason people like text (either plain or XML) over binary data formats is the fact that so many developers barfed up a disgustingly ugly, messy hairball when they created their binary data formats.

Text isn't immune to crappy data formats anymore than binary. Some text formats are good, others are pretty bad.

Quite a few developers barfed up a disgustingly ugly, messy hairball when they created their -text- data formats.

>> - it is a mature format
>
> text: YES
> XML: not really, it's still evolving

Sorry; have to object. Text isn't a data format, anymore than binary is a data format. The format is the additional meta-information that structures the data. XML provides -some- of the rules for doing this, but not all; as you mention, it's still evolving, and it's free-form enough to allow multiple representations of the same data.

You -can- format text according to a number of mature, tested methods. But that isn't the "text" format; that's the xxx format, which is encoded in plain text.

That's true of the next few comments. I feel your point would be better phrased as "you don't need somthing as complex and verbose as XML do achieve [blank], and if you do so using other, rather traditional methods, you'll get better results."

I tend to agree with that.

>> - it can be easily extended
>
> text: infinitely
> XML: yes, as long as the extensions are described
> unambiguously

And that's really the laudable goal of XML. I don't think it -achieves- that goal. But it tries, and the goal is laudable. I think structuring the syntax of XML to -require- unambiguous representation and simpler parsing rules is one of the worthwhile things about it.

>> - it is robust (i.e. works with partial information)
>
> text: yes
> XML: not in my experience -- parsers crash and burn
> on bad XML XML is inherently more fragile than text
> because there is a lot more to go wrong

Well, this is a choice, like whether the application should core-dump on an error or try to recover. For some applications, failing to render partial or defective information is the right thing to do.

You're right about the verbosity of XML offering more opportunities for failure.

> ...how bad a home-grown solution would be in
> comparison. Most non-trivial data representation
> formats that are hand-rolled are riddled with
> bugs, ambiguities, and often lead quickly down
> a road to incompatible versions from every vendor.

God, yes.

> That pretty much describes the state of XML today.
> Everyone is rolling their own using a more bloated
> language.

Regrettably true.

Robert Parnell

Posts: 22
Nickname: robparnl
Registered: Jul, 2005

Re: Odd idea Posted: Oct 24, 2005 8:29 AM
Reply to this message Reply
Here is some guys paper on it - embedding XML in Haskell. (If Heron is functional enough - it must be?)

http://www.cs.uu.nl/~franka/papers/embed-pause.pdf

Yes, this has nothing to do with EDI. Chris

RobP

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Why XML? Posted: Oct 24, 2005 9:55 AM
Reply to this message Reply
I think the main benefit to XML is the fact that each tool that deals with this "source" bag of bits can simply search for tags that are important to it, and ignore everything else.

There's no need to remember if /** starts a documentation comments or /*% or /*!, just look for <documentation>. And if you've got a great idea for the next tool, you don't have to worry about how you'll abuse the programming langauge's comment structure and whether other tools have abused the comment structure in exactly the same way. Instead you just need to pick a nice tag.

In which case you're using tags to convey meta-information. That's (IIRC) the original rationale for XML. And even if it's not the *original* purpose, it's one which XML is well-suited for.

Martin Baker

Posts: 3
Nickname: mjb
Registered: Oct, 2005

Re: Programmers Shouldn't Touch the Source Posted: Oct 24, 2005 10:03 AM
Reply to this message Reply
I had a try at creating an XML version of a Java-like language here:

http://sourceforge.net/projects/xes/

user guide here:
http://www.euclideanspace.com/software/language/xes/userGuide/

I think XML source would have a lot of advantages:

# When encoded an XSLT script XML Encoded Source could then be used to translate the code into other forms, such as:

* Conversion to other languages, XSLT might not easily do a complete conversion without error, but it could at least do the first step and take some of the drudgery out of human conversion.
* Generation of documentation such as UML diagrams and other diagrams possibly in SVG format.

# XML Encoded Source could be a good intermediate format for code generators.
# XML Encoded Source can hold code in a format where the first parsing stage of compiling has already been done, this would allow:

* code to be more quickly compiled on the fly.
* Open Source code to be distributed in this form with Linux so that it can be compiled more quickly and with less errors than distributing it
* To allow some small level of language independence in code distributing code without loosing any information.

# XML Encoded Source could define an intermediate language, like Java or C# intermediate code, which is more like the source code but could still be interpreted at runtime.
# XML Encoded Source could provide a much better way to mix scripting code in with XML data.
# XML Encoded Source could provide a more general way to define algorithms together with the data it is acting on

Martin

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Programmers Shouldn't Touch the Source Posted: Oct 24, 2005 2:48 PM
Reply to this message Reply
> I had a try at creating an XML version of a Java-like
> language here:

I think Java code described with XML may finally push past the one megabyte barrier of source code size for a "hello, world" application. Quite a few modern languages have already gone way past one meg for the executable, but until now we haven't had the right combination of technology to get the source code that big.

Dag Blakstad

Posts: 1
Nickname: pragile
Registered: Dec, 2004

Re: Programmers Shouldn't Touch the Source Posted: Oct 24, 2005 10:54 PM
Reply to this message Reply
Well XML IS readable, but would you like to read a book formatted as XML. XML is about structuring data, but it is not necessarily the best format to express logical statements.

XML comes with a heavy payload and I do not want to code or maintain all these tags when writing code. I am trying to imagine a editor that does this for me, and the XML tags is kind of hidden. But then, what is the XML good for?

Code is developed and tested far faster in clear text. What about developers trying to get familiar with a new piece of code. Code that is compact and self-excplaining is much faster comprehended than complex code with a lot of text not having anything to do with the subject at matter.

If it is desirable to have an XML-structured version of the code, computers transforms textfiles to whatever you desire in (nano)seconds! Mayby that could be the next evolotinary step for code analyzers?

Regards, Dag Blakstad

Martin Möbius

Posts: 2
Nickname: mmoebius
Registered: Oct, 2005

Re: Programmers Shouldn't Touch the Source Posted: Oct 25, 2005 1:14 AM
Reply to this message Reply
Its an old topic. The problem imo is that source code in general is represented as a file with text. Every tool to operate has to build its own model of the source code.

http://www.mindprod.com/projects/scid.html
gives some examples, what could be done when source code is more related to its abstract syntax tree.

For the XML thing
http://www.badros.com/greg/JavaML/
He wrote a converter based on jikes (java compiler) to convert java sources into a XML.

But the point is not XML, the point is to include more information into the source. Whatever technique its based on.

IDEs are required, all the emacs und vi users can use their tools, but the future is not plain ASCII/UNICODE within files. Tools allow to build more complex tools.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Programmers Shouldn't Touch the Source Posted: Oct 25, 2005 3:45 AM
Reply to this message Reply
> CornerStone (database engine from Infocom in the mid 80s)
> had an interesting feature---user defined names
> (identifiers) where seperate from the internal IDs used by
> the system. Imagine changing the name of a function (or
> variable), and having it automatically change everywhere
> else in the source code where used

The research project at Microsoft a few years ago, Intentional Programming, had this feature: You could freely change the names, as the underlying id remained the same.

There may come more out of this, also, as the founders of the project have founded a company dedicated to bring it to fulfillment: http://www.intentsoft.com

Regards,

Terje

Flat View: This topic has 83 replies on 6 pages [ « | 1  2  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



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use