The Artima Developer Community
Sponsored Link

Weblogs Forum
A Brief History of Scala

61 replies on 5 pages. Most recent reply: Jun 23, 2006 8:18 AM by James Watson

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 61 replies on 5 pages [ « | 1 2 3 4 5 | » ]
Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 14, 2006 8:09 AM
Reply to this message Reply
Advertisement
I can't think of one good reason to embed XML in code.
Maybe you'll find a reason in the Microsoft XLinq docs - XML literals will come to C# and VB.

XLinq: XML Programming Refactored (The Return Of The Monoids)
http://research.microsoft.com/~emeijer/Papers/XMLRefactored.html

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 14, 2006 8:34 AM
Reply to this message Reply
> I can't think of one good reason to embed XML in
> code.

> Maybe you'll find a reason in the Microsoft XLinq docs -
> XML literals will come to C# and VB.
>
> XLinq: XML Programming Refactored (The Return Of The
> Monoids)
> http://research.microsoft.com/~emeijer/Papers/XMLRefactored
> .html


Actually right off the bat I see a fairly good argument for not doing it:

"We propose in this paper that general-purpose languages should extend their query capabilities based on the theory and established practice of monads, allowing programmers to query any form of data, using a broad notion of collection. This proposal is in opposition to the common practice of inserting specialized sub-languages and APIs for querying XML one way, databases another way, and objects a third way."

Having XML support in a language would have seemed like a good idea to me when I didn't have much experience with XML. XML is just one of many ways to display data and not always appropriate or convienient. In other words, it's a view.

EDI is very common and much more established. Why not include support for EDI formats? And why stop there? How about language support for PDF and Open Document formats? And people use a lot of SQL and LDAP.

I find it a little discouraging that Scala has been loaded onto this particular bandwagon.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 14, 2006 9:25 AM
Reply to this message Reply
> I can't think of one good reason to embed XML in
> code.

> Maybe you'll find a reason in the Microsoft XLinq docs -
> XML literals will come to C# and VB.

XML literals are also supposedly coming to Java. This doesn't mean it's a good idea.

I can't help but feel that the people pushing for this either don't work with XML on a daily (or frequent) basis or that they are frustrated by the common solutions that are used. The things is that embedding XML in code is a specious solution. I used to have to work with reams and reams of PowerBuilder code. PowerBuilder had this 'great' feature that you could write SQL in your source and tie it to your variables. Very similar to what Scala lets you do with XML, really.

The result was that all the code was tightly coupled to the database schema. Any non-trivial change in the database schema required modifying and retesting hundreds and sometimes thousands of lines of code. This tedious and error prone work became the lion's share of our development.

I think the real problem with using XML in 'standard' programming languages is that the tools avialable try to solve the wrong problem. They try to make it easy to convery XML structures into code (e.g. JAXB 1). Not only is this really awkward and difficult, it doesn't get you anywhere. All you've done is take the original problem and relocate to your source. You still need to write all the code to get the data out of the elements and this tends to require more code than just writing a handler for a SAX parser.

What these tools need to do is model Objects as XML. XML can express much more complex structures than most OO languages and with much richer detail. Once you've modelled thew Object with an XML schema and can serialize back and forth between XML and Objects, mapping data from arbitrary XML input and to arbitrary XML output is easily handled with XPath or other XML focused languages. JAXB 2 has a class to schema tool for Java (that I have not used). All you need after that is a good tool for writing stylesheets and a framework for putting it all together.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Down with XML Posted: Jun 14, 2006 3:31 PM
Reply to this message Reply
/* Having XML support in a language would have seemed like a good idea to me when I didn't have much experience with XML. XML is just one of many ways to display data and not always appropriate or convienient.
*/

I'm currently looking for a decent C++ reformatter in the tradition of UNIX's indent. I've found several people announcing that they'd take this on, but very few who actually did.

My quest brought me to GCC-XML ( http://www.gccxml.org/ ), which of course reads in C++, runs it through gcc's internals, and outputs C++ devorated with XML. I keep running into links suggesting that a source code formatter could be built on top of that. Apparently some people out there think it's a good thing to take plain text, have a program classify it and output XML, then parse the XML, extract the plain text, and decide how to indent the code based on that discarded XML. I'm not one of them.

I really can't think of any great uses for GCC-XML, although I can understand why the project exists: it's meant to make formatters, highlighters, etc. easy to write. However, it would make more sense to me to output a parse tree based on STL containers (that is, with the same interface, not the same implementation). And for source highlighting, use Doxygen.

So, I agree, XML is just one of many ways to display data and not always appropriate or convienient.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Read the FAQ Posted: Jun 14, 2006 3:36 PM
Reply to this message Reply
OK, GCC-XML doesn't exist for highlighters, formatters, et al. Instead "GCC-XML was originally created for the C++ parsing support needed by CABLE for generating interpreted language wrappers for ITK" ( http://www.gccxml.org/HTML/Sponsors.html ).

Which reminds me of a certain example I wrote about C++ templates. ...

Werner Schulz

Posts: 18
Nickname: werner
Registered: May, 2005

Re: A Brief History of Scala Posted: Jun 14, 2006 3:42 PM
Reply to this message Reply
Martin,

thanks for reading and answering.

I agree that at this stage you need to pick your priorities. And some are well chosen, even "simple" things like providing an Eclipse plugin. We developers certainly want that. And also that you don't want to "offend" Java programmers by being too radical, but if something in Java is bad, it must go, otherwise you will suffer for a long time. Just see how C++ suffers from its C inheritance.

Regarding the language support for algebraic structures, this came partially from my recent attempt to define an interface for a group. Now, some group requirements are very hard to code explicitely, e.g., associativity. Here is my attempt:
interface AdditiveGroup<T> {
   T negative();  // the inverse
   T plus(T x);   // how I would like a "+" in Java
   T minus(T x);  // as T plus(T x.negative());
   // can't do: static T zero(); // the neutral element
}

What's frustrating in Java is that I cannot define a class-level method to return the neutral element as Java's interfaces don't allow static methods. An instance-level method is not really viable since I would need to create an object before I can get the one and only neutral element of the group.

Actually, what I'd really like to define is this (in pseudo Java):
interface Group<T, op> {
   T op(T x);
   T negative();
   static T id();
}
 
// example: group of all integers  Z = {...,-2,-1,0,1,2,...}
public class Z implements Group<Z,+> { ... }
, i.e., parametrise on the type, T, and the operation, op.

The above Java interface is an example where the language design restricts/hampers/denies developers to express important concepts. And writing a library doesn't help. I can't think of any reason why static (class-level) methods shouldn't be defined in interfaces; the restriction is an arbitrary design decision (like early binding of static methods in Java).

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 14, 2006 5:35 PM
Reply to this message Reply
What these tools need to do is model Objects as XML. XML can express much more complex structures than most OO languages and with much richer detail.

Did you read past the introduction? :-)


Try this it will gives a better perspective on how the XML integration fits in
http://research.microsoft.com/~emeijer/Papers/ICFP06.pdf
"While ideally XML is just a serialization format that is hidden from the programmer, it has now become so pervasive that in those situations where we do need to deal with XML, it should be as convenient as possible.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 15, 2006 2:07 AM
Reply to this message Reply
James Watson wrote
> XML can express much more complex structures than most
> OO languages and with much richer detail.

That is one of the primary needs I'm aiming to satisfy with CEDSimply, along with the constraint of the language being particularly forgiving for amateur or non-programmers. Whilst these may goals may appear somewhat ill-matched, I think an increasing amount of end-user computing will involve consuming rich data.

In the scientific and mining fields in which I work at CSIRO, that is already the case. (Counting many scientists as amateur programmers.)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Advantages of mathematics (Was Re: A Brief History of Scala) Posted: Jun 15, 2006 6:50 AM
Reply to this message Reply
> What these tools need to do is model Objects as XML.
> XML can express much more complex structures than most
> t OO languages and with much richer detail.

>
> Did you read past the introduction? :-)
>
>
> Try this it will gives a better perspective on how the XML
> integration fits in
> http://research.microsoft.com/~emeijer/Papers/ICFP06.pdf
> "While ideally XML is just a serialization format that
> is hidden from the programmer, it has now become so
> pervasive that in those situations where we do need to
> deal with XML, it should be as convenient as possible.


I understand why this is thought to be a good idea. I just don't agree. It's only convienient to the initial developer but it's a hack and a shortcut. All it does is make bad hardcoding easier.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: A Brief History of Scala Posted: Jun 15, 2006 7:02 AM
Reply to this message Reply
> Martin,
>
> thanks for reading and answering.
>
> I agree that at this stage you need to pick your
> priorities. And some are well chosen, even "simple" things
> like providing an Eclipse plugin. We developers certainly
> want that. And also that you don't want to "offend" Java
> programmers by being too radical, but if something in Java
> is bad, it must go, otherwise you will suffer for a long
> time. Just see how C++ suffers from its C inheritance.
>
> Regarding the language support for algebraic structures,
> this came partially from my recent attempt to define an
> interface for a group. Now, some group requirements are
> very hard to code explicitely, e.g., associativity. Here
> is my attempt:
>
> interface AdditiveGroup<T> {
>    T negative();  // the inverse
>    T plus(T x);   // how I would like a "+" in Java
>    T minus(T x);  // as T plus(T x.negative());
>    // can't do: static T zero(); // the neutral element
> }
> 

> What's frustrating in Java is that I cannot define a
> class-level method to return the neutral element as Java's
> interfaces don't allow static methods. An instance-level
> method is not really viable since I would need to create
> an object before I can get the one and only neutral
> element of the group.
>
> Actually, what I'd really like to define is this (in
> pseudo Java):
> interface Group<T, op> {
>    T op(T x);
>    T negative();
>    static T id();
> }
> 
> // example: group of all integers  Z =
> {...,-2,-1,0,1,2,...}
> public class Z implements Group<Z,+> { ... }
> 
, i.e., parametrise on the type, T, and the
> operation, op.
>
> The above Java interface is an example where the language
> design restricts/hampers/denies developers to express
> important concepts.

Can you explain what this interface means a little bit? Are classes that implement it a member of the group or members of the set of group?

I think there may be a way to get what you want in Java but I'm not sure.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: Advantages of mathematics Posted: Jun 15, 2006 12:19 PM
Reply to this message Reply
<Werner>Still, I have a need for arrays, esp. arrays where the index can be more flexible than just zero-based. Imagine some annual stats for the years 1996-2006. An array stats[1996 .. 2006] would be much more expressive than stats[11] ... And again, other languages have been much more forthcoming with support for this, but the C-family has been very myopic here.</Werner>

<James>You mean like slices in Python?</James>

I don't think Werner means like slices in Python. He's showing his Fortran background here. As you know, arrays in the C family always start with index 0. In Fortran, you can specify what index values you want the array to start and end with. IIRC, this is also true of Pascal arrays.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Advantages of mathematics Posted: Jun 15, 2006 1:11 PM
Reply to this message Reply
> <Werner>Still, I have a need for arrays, esp. arrays where
> the index can be more flexible than just zero-based.
> Imagine some annual stats for the years 1996-2006. An
> array stats[1996 .. 2006] would be much more expressive
> than stats[11] ... And again, other languages have been
> much more forthcoming with support for this, but the
> C-family has been very myopic here.</Werner>
>
> <James>You mean like slices in Python?</James>
>
> I don't think Werner means like slices in Python. He's
> showing his Fortran background here. As you know, arrays
> in the C family always start with index 0. In Fortran, you
> can specify what index values you want the array to start
> and end with. IIRC, this is also true of Pascal arrays.

Now that you point it out it seems obvious. Thanks.

I would respond by saying a class called AnnualStats with a constructor AnnualStats(begin, end) would be even more expressive than such and array declaration.

It seems to me that a lot of times when people complain about things like this, they have never realy moved on and taken advantage of the features of the new language. I'm not saying that these features he desires aren't good but that any tools is likely to seem inadequate if you don't use it as was intended.

Werner Schulz

Posts: 18
Nickname: werner
Registered: May, 2005

Re: Advantages of mathematics Posted: Jun 15, 2006 3:32 PM
Reply to this message Reply
>
> I would respond by saying a class called AnnualStats with
> a constructor AnnualStats(begin, end) would be even more
> expressive than such and array declaration.
>
That just shifts the problem but doesn't solve it. Sure, a wrapper is better than just an array, and I would do the same. (I wrap even small types inside objects rather than using primitives like String as it is more expressive.) But inside that class you still would be better off having an array X[begin .. end] rather than X[0 .. end-begin] (or is it 0 .. end-begin-1 or end-begin+1? Most people have to think about this one, BTW it is the first). Each time you access an element, you have to calculate the offset yourself, arrgghh, how tedious, just because someone insists that you must always start at 0.

And, yes, I can write my own generic array class that does all that, but each time I call some language-defined class I have to shift gear back to the zero-based one and the users of my class must also remember. It becomes tedious and error-prone. Not the classes themselves but the interaction. No, such fundamental classes must be defined in the standard language libraries and nowhere else.

And I take issue with the remark "have never really moved on". C++/Java are not synonymous with progress. These languages provided some progress via new features but they also stepped back in other areas. E.g., forcing silly restrictions like reserved keywords on us. Zero-based arrays in C/C++ is another one, leading to the infamous off-by-one error, not known in Fortran, which also knows the length of an array, rediscovered in Java (progess!). Terminating strings with null is still a huge security problem. Fortran (and Java and VB and C++ std::string) did much better, years before C.

Such small design decisions have consequences in real life. So let's make some real progress and move on to languages that make it easier to avoid mistakes, easier to express problems and solutions. And it is a fallacy to think that everything can be solved by writing a library class. Another fallacy is to think that things must always be used as intended. A lot of progress comes from unintented use. C is one of best & worst examples in programming languages.

Werner Schulz

Posts: 18
Nickname: werner
Registered: May, 2005

Re: A Brief History of Scala Posted: Jun 15, 2006 5:03 PM
Reply to this message Reply
James,

you are right. By separating the concepts Group and Element of Group one can get around my problems:
public interface Group<G> {
   public interface Element<G> {
      Element<G> inverse();
      Element<G> op();
      ...
   }
   public Element<G> id();
   ...
}

This has other advantages:
a) I can create several group instances which may provide isomorphs of each other (via arguments to Group).
b) I can define an important example, Z/nZ (or integer modulo), via the order n to the Group constructor.
c) Use generators for groups.

The Z/nZ was also an example where I would wish to have parametrized classes not just generics. C++ allows to use integer values in its templates. I wish Java had that.

I'll try that asap. Ta.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Advantages of mathematics Posted: Jun 16, 2006 9:43 AM
Reply to this message Reply
> >
> > I would respond by saying a class called AnnualStats
> with
> > a constructor AnnualStats(begin, end) would be even
> more
> > expressive than such and array declaration.
> >
> That just shifts the problem but doesn't solve it. Sure, a
> wrapper is better than just an array, and I would do the
> same. (I wrap even small types inside objects rather than
> using primitives like String as it is more expressive.)
> But inside that class you still would be better off having
> an array X[begin .. end] rather than X[0 .. end-begin] (or
> is it 0 .. end-begin-1 or end-begin+1? Most people have to
> think about this one, BTW it is the first). Each time you
> access an element, you have to calculate the offset
> yourself, arrgghh, how tedious, just because someone
> insists that you must always start at 0.

I wouldn't calculate it each time. Here's a little Java class to show what I mean:

class AnnualStats {
    private final int begin;
    private final Stats[] stats;
 
    // end inclusive
    AnnualStats(final int begin, final int end)
    {
        this.begin = begin;
        stats = new Stats[(end - begin) + 1];
    }
 
    Stats getStats(int year)
    {
        return stats[year - begin];
    }
 
    void setStats(int year, Stats stats)
    {
        stats[year - begin] = stats;
    }
}


Now, it's a little more verbose, yes but if Java allowed operatator overloading, you could make it work the way you want.

Flat View: This topic has 61 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: A Brief History of Scala Previous Topic   Next Topic Topic: Apprenticeship -- The untold story.

Sponsored Links



Google
  Web Artima.com   

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