Slashdot Mirror

it looks like we're just going to roll over and leave whatever innovation is left in the software field to the Chinese and the Indians.

And Brazil and other countries of South America.

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

With this topic, I expected discussions on such technologies as MDSD, MDA, or AOP yet there is no mention of these here. Does everyone here consider them to be DOA?

OP is not specific to Java -- I've seen it done with Python

And it was invented by Kizcales working in Common Lisp. For example, see this brief history.

Those [like the grandparent] who do not know history...

Links

• "Aspect-Oriented Programming with C++ and AspectC++"
• http://www.aosd.net/
• http://www.aspectc.org/

The X developers should rewrite the server from scratch using the Aspect Oriented methodology and for example the AspectJ programming language. Many of the X extensions really touch all parts of the server which is exactly the kind of problem aspect oriented programming was designed to solve.

Using AspectJ, an extension such as the Damage extension could be written in a weekend.

Also rewriting the server in AspectJ would allow the developers to leverage the full power of the Java language. With Java reflection the core dispatch code in the server could be replaced by just a few lines of code. The RENDER extension could be completely removed from the server and replaced by using the delegate design pattern to forward X requests to Java2D

The Fresco project had huge potential, but never managed to escape the legacy language C++. It seems everybody working on window system is stuck in the software engineering practices of the seventies.

Basically, you can define an aspect to capture points in your program that are of particular note, and then do debug handling at those points. Aspect oriented programming allows you to break out that debug-handling logic into seperate modules, keeping your main sourcecode nice and clean.

Aspect-oriented programming (AOP) has a lot of other uses too. I think in 5 years or so talking about AOP will be as commonplace as talking about OOP. They are orthogonal concepts.

Cheers, Me

The way I see it, the benefit of garbage collection is nearly canceled by the lack of stack variables and guaranteed destructor calls. I want to just declare a "Socket" variable in the middle of my function and have a guarantee that the socket will be closed when the block is existed in whatever way. finally or with just don't cut it. Say, I use 2 sockets, 1 file, a mutex and a temporary hash table entry at different points in a function. Imagine the mess of nested blocks, especially since Socket.close can actually throw an exception!

You can easily solve this problem by using Aspect Oriented Programming (AOP). The nice thing about AOP, is that you can solve this kind of problem in a reusable and modular way. This allow you to write cleaner and less buggy code.

Aspect Oriented Programming. In depth information is here.

Today it's implemented in a lot of different langugages, maybe sometime in the future a whole development system is created using this technique.

Don't mistake Pointcuts as the only feature of AOP...

Another long list of links and a comprehensive introduction of the pioneers.

Check out the Avalon project. If is a framework encompassing the ideas of Component Oriented Programming and Separation of Concerns.

Also, read about Aspect oriented Programming, which "modularize[s] crosscutting aspects of a system" by allowing a programmer to specify "aspects" of a class or component such as logging, security, remotability, and more.

I read about it about a year ago in Java Pro.

Here's an article

And here
And here

Hope that helps.

I found more information on AOP here.

"Aspect-oriented software development is a new technology for separation of concerns (SOC) in software development. The techniques of AOSD make it possible to modularize crosscutting aspects of a system.

Like objects, aspects may arise at any stage of the software lifecycle, including requirements specification, design, implementation, etc. Common examples of crosscutting aspects are design or architectural constraints, systemic properties or behaviors (e.g., logging and error recovery), and features.

Researchers in AOSD are largely driven by the fundamental goal of better separation of concerns. So while crosscutting tends to be a significant focus of their work, they also incorporate other kinds of SOC techniques, including such well established approaches as OO and good old-fashioned structured programming. This is reflected in the way much of the work in the field blends support for many different kinds of modularity including block structure, object structure, inheritance as well as crosscutting."

Aspect Oriented programming is a brand new programming paradign, kinda of like the switch you made when going from functional programming to object oriented programming. It's a different way of expressing your programs

The reason that Aspect Oriented Programming was created was due to "cross-cutting" concerns that cannot be easily modelled in object oriented programming. I read the presentation for AspectJ and the example they used was logging in Apache Tomcat. Bascially the code that is used for logging is scattered throughout the whole program on hundreads of different lines, not all in one nice neat class. Aspect Oriented Programming wants to give the programmer the tools to gather all of this code together.

Bascially, Aspect Oriented Programming is supposed to result in: less tangled code (code that is fragmented throughout your program because you are unable to modularize it well), more natural code, shorter code, easier to maintain and evolve, and more reusability.

One question I had about the book that the review didn't seem to answer was did the book talk at all about designing using Aspect Oriented Programming? Just like Object Oriented Programming, it's a great tool until you get some inexperienced programmer who just knows how to program functionally, and thus doesn't use the advantages of aspect oriented programming. I too would like to learn more about how to go about designing a program in an Aspect Oriented way; such as how to identify aspects, what are some common aspects, etc.

In all, I'm very excited about Aspect Oriented programming. I think it has the ability to allow programming to shape thier programs more naturally, make their programs easier to understand, and make the whole process much eaiser. But of course as with any new technology, it has some growth and refinement to go through yet.

Those of you who would like more information can check out the AspectJ webpage, or the Aspect Oriented Software Design webpage.

You need to handle pointers and references, google for pointer swizzling. Garbage Collection by Richard Jones and Rafael D. Lins explains some of the issues involved. Alexei Andresceu's Modern C++ Design gives a sample implementation. This is one of the tasks that reflection, aspect-oriented programming or a meta object protocol makes easier, otherwise you need to add a .serialize() method to each object.

BTW, when compiling standard Java, the AspectJ compiler produces the same bytecodes that are produced by a standard Java compiler because the same compiler is used.

The first incarnation of the compiler produced Java code that was then compiled by a standard Java compiler. The second produced bytecode directly, and the current version -- I believe -- uses a modified Eclipse compiler.

Not sure if it was invented by college kid, but AOP seems pretty promising:

aosd.net

Aspect-Oriented Programming
Subject-Oriented Programming
Hyperspaces
Conceptual Modules

It seems that what you are describing is related to Aspect Oriented Programming (AOP), which is a potentially emerging new programming paradigm.

To some extent you can do that in Functional Programming. It all depends on how you design the functions. You can use 10 super functions to call a varing number of subfuntions the get futher specified as you go down.
As someone else pointed out, a mixture of functional and OOP is probably your best bet. This way you continue emphasis the best tool for the best job. OOP is just another methodolgy of writing programs. More will come along--such as aspect oriented programming. (Don't ask me the detail because I haven't had time to delve to deep into it yet, and for more information on that see AOSD.)
With each new methodology I learn, I add it to my belt of tools. I expect to keep on doing this. You never know when we will need to revert back to some older methodolgies--although I doubt I will go back to spaghetti code.