Hi Grzergorz, I've been reading of this thing of "write the same stuff using just a few lines, not like in java" all over in the last two years, and I tested it out using a large number of these languages, from Python to Ruby to Scala, and I can assure you that it is mostly FALSE.
On one side, surely Java IS a verbose language, and surely there can be more concise ones, but the entire idea of line counting is an error. I can pretty well write Xalan in a single line of Java code, it's just a matter of executing s/\n// on the whole source code :) :) In fact : - Many tools out there (CLOC just to mention one) consider also the closing bracket a line of code, while obviously it is not. - Using chaining (like A.b().c().d().e().f()) will reduce 5 "lines of code" to one, but in reality you are always writing 5 calls .. same amount of headache and possible bugs, or even more cause your code is less readable. Also considering a better metric, like the number of join points or branches or whatever else, there are a number of reasons why these claims are at least exaggerated : - Many of these languages have huge libraries, with hundreds of methods that accomplish most tasks that would require you to write lines of code in java. This is not a bad thing in itself, but to make an appropriate count of lines of code you should put all these stuff in a separate library (commons is there for this reason), and see how many "lines of code" are present in your CORE code. - Most of these libraries are not customizable in any way, they do work perfectly 90% of times which is good, but you will end up having to re-implement part of these. Java went the opposite way : the bare minimum on the common library, no facades except where really really useful, which will require a lot of code from the programmer. None of the two is the perfect way, both have drawbacks. - Many of these libraries are tiny in number of lines because they are also tiny in functionalities. For example : ... They don't implement what they claim to completely, or implement an early version of it, partially and in a buggy way. ... Have not gone thru the pain of adding all the features users will ask you to add, which can make a simple one-man-show library grow up to thousands of hundreds of lines in a few years. ... Have not gone thru any test or bugfixing, and bugfixing WILL ENORMOUSLY increase the "size" of code (and also make it a mess). ... Usually does not have all the fluff around the basic core, like utilities, error messages, handling of special cases or exceptions, and so on ... that will also make your code multiply in size. Obviously, there are languages which are easier than Java, more concise, more performant and all the rest, functional approach is easier than passing Runnables, there are no doubt about the fact that our industry is young and there is huge space for new technologies, and probably Cocoon would greatly benefit from some of them. But take these revolutionary claims for what they are : propaganda, not necessarily real facts, or at least not THAT MUCH as they try to demonstrate. Just my 2 cents. Simone Grzegorz Kossakowski wrote: > Reinhard Pötz pisze: > >> Grzegorz Kossakowski wrote: >> >>> Cocoon 3.0 started by Reinhard looked promising to me but now I >>> realize that the main idea of its existence is to more or less >>> rewrite C2.2 and add some RESTful features. >>> >> Yes, that's explained by the first paragraph of the Cocoon 3 website. >> > > Ahhh right, I've looked at source code of C3 but forgot about the website. > Apparently, I have to > check recent developments of C3. > > >> You probably have missed it but with Simone we actually have one very >> active committer and I know that many other people are fond of the >> Cocoon 3 pipeline module. >> > > Yes, sort of. > > >> Currently the main problem is that most developers don't know that there >> is such a simple thing as the Cocoon 3 pipeline library. I've already >> started to provide documentation but haven't got very far yet. But be >> assured that it has a very high priority on my opensource todo list. >> > > Good to hear that. Some advertising company on e.g. Pipeline library that > would show us it's > potential would be useful but it might be that I ask for way too much. ;-) > > >>> Has anyone here thoughts on this topic or it's only me who has a >>> problem? >>> >> When I started Cocoon 3 my main goal was to solve two problems: 1) >> provide a plain and simple pipeline API that is easily usable from >> within any Java environment 2) make Cocoon a simple platform for RESTful >> services. >> This made *me* excited about it and solves *my* problems. I haven't done >> any market research about what would have excited others. >> > > It would be very nice if you could provide some more details how it solved > your problems and what > kind of problems. I suspect that you have lots of ideas how this thing should > evolve and what kind > of new opportunities it brings to us. > > I would really like to help you with building up the community but before I > can start doing that I > need a solid background, a vision so I can guide others. That's why I'm > asking for all of that all > of the time. > > >> Anyway, I don't think that it makes much sense to talk about what an >> anonymous mass of people might want. So Grzegorz and all others reading >> this, what would make *you* excited about Cocoon 3 so that *you* would >> be willing to contribute? >> > > Actually, I find myself at the crossroads now. I haven't done anything really > pleasant that would > make me happy with C2.2. The COCOON-2216 issues almost killed my whole > motivation when it comes to > C2.2. I feel like the time I can hack C2.2's core is over for me. Until > someone helps me with this I > will probably stay away of C2.2 completely because this issue blocks most of > my plans when it comes > to C2.2. > > That's a reason for me to look for something new. > > SSF should get some attention so SAX forwarding is implement and some caching > bugs are fixed. > Anyway, I would like to leave this task for someone else as it's a bad > situation that it looks like > only me and you have an idea what's going on there. I want someone else to > become involved. > > > So the only thing left is C3. What would make me excited? The best thing > would be to rewrite C3 in > some pure functional language like Haskell. ;-) > > Ok, that's a joke but an introduction to something more serious. I've been > off-line a while which > was a perfect chance to read some books and papers. Let's start with a quote > from a master thesis > "Implementing an XSLT processor for the Haskell XML Toolbox" by Tim > Walkenhorst[1]: > > "The processor is written in a purely in Haskell 98 and does not make use of > any advanced > libraries. [...] It might be possible to make the implementation even shorter > and more concise by > using this features; however, the basic implementation should enable > interested volunteers > to gain familiarity with the code rather quickly. The entire implementation > has about 1800 > lines of code and is thereby 192 times smaller than the XALAN Java > implementation which > has about 347000 lines of code.[...] > Of course, we could not implement the full functionality of > such a huge tool within one master thesis; however, it should be possible to > perform the > most common kinds of stylesheet transformations within the subset of XSLT we > implemented." > > You read it correctly. The XSLT processor implemented with 1800 lines of > Haskell vs 347000 lines of > Java. I've checked features and parts of specification that are not > implemented and I found that > they don't form a big portion of the whole specification and seemed to be > rather trivial implement. > Of course, this processor does not additional features of Xalan like support > for debugging, etc. > > Anyway, can you think of almost complete implementation of XSLT 1.0 spec. in > 2000 lines of Java? I > cannot. > > Even more surprising, I can moderately easily read that code even if I'm not > fluent in Haskell. I > guess I'm not the only one realizing that a reason for such a phenomenon must > be something more than > just a fancy syntax. > > > -------------- o0o -------------- > > > Of course, proposing to reimplement something like Cocoon would be just a > joke because there is only > a little industry support for Haskell and Apache is definitively > industry-oriented. However, there > is a compromise solution called Scala[2]. The main advantage (and > disadvantage at the same time) of > Scala that it's been designed from scratch to play well with Java but at the > same time incorporate > functional programing features and ideas. > > It's looks to me that in C3 the idea of using scripting language for > flow/controller has been > abandoned. I've never been a great supporter of scripting languages with weak > typing like > Javascript. At the same time, I can understand those people that see > scripting languages sexy. > Obviously, there are some constructs that are awkward and verbose (thus > overly complicated) in Java > and much simpler counterpart in some scripting language. On the other hand, > lack of refactoring and > need for extensive unit-testing for every little-stupid-thing is a major > problem with scripting > languages. A nice paragraph[3] on that can be found in "Real World Haskell" > that has just hit the > shelves and additionally is available for free online. > > Anyway, there is a third option provided by functional languages which *are* > strongly typed (at > least those that I'm aware of) but at the same time provide flexibility found > in scripting > languages. Therefore I would like to work on integrating Scala into Cocoon. > > This idea is rather fresh and I'm only starting with Scala but idea would be > to implement two parts > of Cocoon in Scala: > 1. Sitemap (or something corresponding) > 2. Controllers > > I guess this e-mail is already long enough to cut it here. If you are > interested in my ideas on > providing functional implementation of sitemap (that would be inspired by > some characteristics of > bash) I could write a little bit more on it with some details. > > If there is no interest in such subject and I do not find any other > interesting thing to do I'll > probably start a fork of C3 at GitHub so it won't interfere with your work > here. > > > Having pipelines as capable higher-order functions seems to be a neat idea... > > > > [1] http://www.fh-wedel.de/~si/HXmlToolbox/xslt/thesis.pdf > [2] http://www.scala-lang.org/ > [3] http://book.realworldhaskell.org/read/types-and-functions.html#id577931 > [4] http://en.wikipedia.org/wiki/Pure_function > > -- Simone Gianni CEO Semeru s.r.l. Apache Committer http://www.simonegianni.it/
