Here is a comprehensive list of ways to support inheritance in JavaScript.
JavaScript Inheritance
17. August, 2011
Leave a Comment » | 
Software | Tagged: JavaScript, OO, Programming | 
Permalink
Posted by digulla
Some Software You Should Know When You Work on DSLs
8. August, 2011DSLs is all the rage but it seems the technology is actually useful 🙂 So here is some stuff that you’d probably want to know about:
Intentsoft created a workbench which can capture business information in the way the business wants.
JetBrains did something similar called Meta Programming System or MPS.
Want to know more about your own code base? Try MoDisco or Moose.
Lastly, using LL parsers is usually a big pain. Syntax Definition Formalism or SDF is another approach to define a syntax which avoids many of the problems of context-free grammars.
Leave a Comment » | Software | Tagged: DSL, Intentional programming, MoDisco, Moose, MPS, Programming, SDF | Permalink
Posted by digulla
Boo
8. July, 2011It seems a dream of mine has come true: A language like Python, compiled into something that can be executed as fast as Java or C++ and which allows to extend the compiler at compile time.
Ladies and gentlemen, please a warm welcome for Boo.
Guess I’ve found a reason to install Mono.
Leave a Comment » | Software | Tagged: Boo, Programming, Python | Permalink
Posted by digulla
Jazoon 2011, Day 2 – How frameworks can kill your projects and patterns to prevent you from getting killed – Sander Hoogendoorn
26. June, 2011How frameworks can kill your projects and patterns to prevent you from getting killed – Sander Hoogendoorn
Sander talked about frameworks and the usual problems with them:
- How to choose the best framework from over 9’000?
- Some frameworks integrate only specific things (like logging or building a UI), others include everything and the kitchen sink. Which is better?
- How do you convince your management to buy a framework, train the developers, testers, support people for it?
- How do you get the other developers to agree to your choice?
After selecting a framework, the trouble starts:
- What do you do it an important feature is missing? Do you add it? How do you maintain it? Do you file a bug report? What if it’s being ignored?
- Half along the project, you find a framework that is better suited.
- How do you handle bugs in the framework?
- When do you upgrade after a new version comes out? What if the new version has dramatic changes that break a lot of your code?
- What if development of your favorite framework stops? Do you take over or walk away?
- If one framework isn’t enough, you’ll find that dependencies tend to kill you because all the problems above multiply.
- Sometimes, framework A has a hidden dependency on logging framework B but your company uses logging framework C.
The way to answer these questions:
- Know your architecture. What do you need where?
- Instead of using the framework directly, put in an abstraction layer that says what you want and does it using the features of the framework. If “something” happens, chances are you only have to change the abstraction layer.
- Use dependency injection to clean up your code from unwanted dependencies.
1 Comment | Conference | Tagged: Frameworks, Jazoon, Programming | Permalink
Posted by digulla
Composite Oriented Programming With Qi4j
9. June, 2011
Composite oriented programming (COP) addresses one of the short comings of OO: That the meaning of an object depends on the context.
In most OO languages today, it’s hard to change the type of an object. Actually, Object Oriented Programming should be called Class Oriented Programming because the class (the type) is the core feature which we use to build application.
But in the real world, objects can have several types. This isn’t polymorphism. It means that COP allows you use the data in an instance within the context of several classes.
For example, in Java, we have two methods which should be context sensitive: toString() and equals(). When I call toString(), I want a certain conversion but that can change depending on in which context I call it. In a debugger, I might want all fields. In the debug log, I might just want the name. In the UI, I will want a nice, user-configurable conversion.
equals() is a similar beast. Different contexts need different equals() methods that work on the same instance. For example in Hibernate, equals() should use the business key. Which is stupid: As soon as a primary key is assigned to the instance, it would be much faster and precise to use that to check for equality. But if you write a tool to compare graphs, your needs will be vastly different.
DI and IoC tools try to fill the similar gaps: At a certain point in time, your code needs a service and you can’t know ahead of time which implementation will be executing the service. While that works somewhat, it’s just a workaround for a fundamental flaw in todays OO languages: Type rules, instances are part of the problem.
Qi4j tries to solve this fundamental problem. Instead of writing huge classes that do everything, the application is created from small building blocks.
The typical case is names. A lot of instances have a name. Instead of writing this code once and using it everywhere, 10 lines of code are copied into every class: The field definition, getter and setter. And maybe you want to set the name from the constructor, so you need 8 more lines (one default constructor and one with the name parameter).
In Qi4j, you define this once. After that, you just add “extends NamedObject” in all the places where you need it. Almost no duplication. Since NamedObject is just an interface, you can collect several of these building blocks in your entity.
9 Comments | Software | Tagged: Java, Object Oriented Programming, Object-Oriented, Programming, Qi4j | Permalink
Posted by digulla
Project Ceylon, Successor for Java?
14. April, 2011A lot of languages compete for the king’s seat taken by Java. Most of them solve a lot of problem with Java but none of them really takes the win. As I say: “Why is there more than one database? Because they all suck.”
Now Ceylon enters the stage (slides from the presentation). The main goal is to clean up the SDK while keeping an eye on what was good and what was bad with Java.
I’ve had my share with programming languages. On a scale between 1 and 10 (best), Python gets 9 from me. Java gets 6. Scala gets 5.
So how does Ceylon fare? At first glance, I’d give it a 7.
Pros:
- Compact syntax. No packages, no classes.
- I like to idea of the recursive block scope which gets rid of the very limited public/private and the ill fated package public. My only concern is how you can declare friends to something at a nested scope (for example for tests).
- Short syntax to avoid NPEs. The approach allows to catch null pointers when they are assigned instead of when they are used. This means: If you find a bug, you’ll actually know what to do about it.
- No new keyword! I really never understood why they added that.
- No checked exceptions. No one got them right, anyway.
- Just one constructor per class. I never use them anyway, and the new named argument syntax solves many of the existing problems.
- Method references
Cons:
- = vs. :=. Come on. In 2011, I still need to tell the compiler something it already knows? Also, looking at my code, I’ll probably use := a lot. So that means extra effort for me. Bad. Not everyone’s brain is wired for immutables.
- “if (exists foo)” to check for null values. If I already have to use a special syntax to mark something as “can be null”, why do I need to mention that again in a condition? What’s wrong with “if(name)”?
Things that leave me puzzled:
- local vs shared. I understand that the compiler can’t infer types for shared references in a single pass but who cares? The compiler is a tool that has to make me more productive. If the compiler needs two or three passes to resolve dangling type reference, so what?
- How is the module system working? How do you bundle types in a container to keep the namespace clean?
Leave a Comment » | Software | Tagged: Ceylon, Compiler, Java, Programming, Software Development | Permalink
Posted by digulla
TNBT – Object Teams
15. March, 2011Object Teams, or OT/J for short, is a solution for the old Java problem “there is no I in ‘team'”: Most Java code is written as if the whole world was openly hostile. It’s riddled with final, private static, singletons, thousands of lines of code which almost do what you need except for this one line .. that you can’t change without copying the other 999.
Groovy’s solution: AST transformation. A topic for another post.
OT’s solution: create a Java-like programming language which allows you to extend code that isn’t meant to. A great example: Extending Eclipse’s Java compiler.
The Eclipse Java compiler is one of the most complex pieces of code in Eclipse (“5 Mbytes of source spread over 323 classes in 13 packages“). Unlike other compilers, it can compile broken code. The same technology is used to create byte code and error markers in the editor.
Stephan Herrmann wanted to add support for @NonNull and @Nullable. Usually, you’d create a branch, keep that branch in sync with the main branch, etc. Tedious. For every change that someone makes in the main branch, you must update your development branch. Even if the change is completely unrelated. CVS has a very limited concept of “related”. DVCS like Git or Mercurial are better at merging but they also don’t understand enough of Java to give the word “related” a useful meaning. “Same file” is the best you can get.
So instead of the tedious way, he used OT/J to create an OT/Equinox plug-in which patches the JDT compiler byte code. Sounds dangerous? Well, OT/J does all the ugly work. You just say “when this method is called, do this, too.” Sounds a bit like AOP? Yes.
Unlike AOP, it communicates intent more clearly. The code wasn’t designed to be the most compact way to define a “point cut” and then leave it to the reader to understand what this is supposed to mean. It better communicates the intent.
I’m not completely happy with the syntax, though. I don’t have specific points, only a general wariness. Maybe a careful application of Xtext would help.
Related Articles:
- The Next Best Thing – Series in my blog where I dream about the future of software development
Leave a Comment » | Software | Tagged: Bytecode, Compiler, Eclipse, Java, Java compiler, Object Teams, OT/J, Programming, TNBT | Permalink
Posted by digulla
TNBT: JetBrains’ MPS
10. March, 2011Disclaimer: I’m not a fan of IntelliJ IDEA.
In the past, I’ve always had an eye for people who replaced the ASCII text editor with something … better. Imagine you could use a table to define your constants in Java. And with table, I mean “Excel” not “align-with-space-until-it-you-go-insane.”
JetBrains is working on this: Table support in MPS 2.0
Let me make this clear: A DSL is nice. But there are so many things that you simply can’t express well with text. State machines. Repeated code. Sometimes, you don’t need the exact words to convey the idea.
I think I’ll waste some time with MPS 2.0 M3 next weekend. There are a couple of tutorials and demos.
Related Articles:
- The Next Best Thing – Series in my blog where I dream about the future of software development
1 Comment | Software | Tagged: ASCII, IDE, IntelliJ IDEA, Java, JetBrains, Open Source, Programming, Text Editor, TNBT | Permalink
Posted by digulla
TNBT: Persistence
19. February, 2011In this issue of “The Next Big Thing”, I’ll talk about something that every software uses and which is always developed again from scratch for every application: Persistence.
Every application needs to load data from “somewhere” (user preferences, config settings, data to process) and after processing the data, it needs to save the results. Persistence is the most important feature of any software. Without it, the code would be useless.
Oddly, the most important area of the software isn’t a shiny skyscraper but a swamp: Muddy, boggy, suffocating.
Therefore, the next big thing in software development must make loading and saving data a bliss. Some features it needs to have:
- Transaction contexts to define which data needs to be rolled back in case of an error. Changes to the data model must be atomic by default. Even if I add 5,000 elements at once, either all or none of them must be added when an error happens.
- Persistence must be transparent. The language should support rules how to transform data for a specific storage (file, database) but these should be generic. I don’t want to poison my data model with thousands of annotations.
- All types must support persistence by default; not being able to be persisted must be the exception.
- Creating a binary file format must be as simple as defining the XML format.
- It must have optimizers (which run in the background like garbage collection runs today) that determine how much of the model graph needs to be loaded from a storage.
Related Articles:
- The Next Best Thing – Series in my blog where I dream about the future of software development
Leave a Comment » | Software | Tagged: Data, Data Warehousing, Database, Databases, Persistence, Programming, TNBT, XML | Permalink
Posted by digulla
Text editors again
23. November, 2010Mark Pilgrim says it pretty well in WrongRoom: “you’re writing a text editor. Stop doing that. It’s 2007.”
Q: Why is there more than one text editor?
A: Because they all suck.
So after struggling with SWT’s StyledText for a while, I’m back with jEdit.
jEdit has its own flaws, though. The text renderer is … basic. No unit tests. But it seems the developers are more approachable than the Eclipse guys. So maybe it will be less effort to add the missing features.
Leave a Comment » | Software | Tagged: Editor, Programming, Text, Text Editor | Permalink
Posted by digulla
Dark Views 