A nearly heretical thought entered my mind. C++ was a proper super set of C. I used to work in C from a C++ compiler for example and the advantage was that I had C with a little bit of syntax freedom. Like the ability to declare variables anywhere in a function. In fact I had forgotten that you couldn't declare variables just anywhere in C during an interview where the interviewer felt like he needed to really grill me on my knowledge of C.
It isn't hard for me to imagine then that Groovy is nearly a proper super-set of Java and is therefore similar in relationship to Java as C++ was to C.
With a little tweaking your tool chain could be set up to see things the same way. It could see Groovy as Java++. The change would aid adoption and aid in developer migration. In fact you can see here (in my own post) that you can write Groovy/Java and not really Groovy/Groovy. Props to Andres pointing out how I'm not really thinking in Groovy yet.
I'm sure I'm not the first person to have this thought but I thought I'd go ahead and voice it here since I've not read anyone else taking this point of view.
2008-11-11
2008-11-10
Top Ten reasons *not* to buy GroovyMag
Here are some reasons NOT to read GroovyMag...
10. You don't care about the future...
9. Programming is a fad...
8. You fear change...
7. You are a rock, you are an island...
6. The internet is for losers...
5. Nothing will ever top assembly for writing clear and concise code.
4. Bah. Technology.
3. You don't have an email... what is this email thing?
2. The internet is just a series of tubes...
1. You can't read.
Go read GroovyMag!
10. You don't care about the future...
9. Programming is a fad...
8. You fear change...
7. You are a rock, you are an island...
6. The internet is for losers...
5. Nothing will ever top assembly for writing clear and concise code.
4. Bah. Technology.
3. You don't have an email... what is this email thing?
2. The internet is just a series of tubes...
1. You can't read.
Go read GroovyMag!
2008-11-07
More fun with Groovy and Reflection API
This time in a TagLib I need to see all the properties of a domain class but I don't want to look at anything that isn't sent to hibernate.
... in another method I'll filter out the Closures by checking against Closure.class and the property's class.
import java.lang.reflect.Modifier
static getFields(obj) {
def names = []
def fields = obj.getClass().declaredFields
fields.each({ field ->
if(!field.synthetic)
if(!Modifier.isStatic(field.modifiers))
if(!Modifier.isTransient(field.modifiers)) {
names.add(field.name.toString())
}
})
return names
}
... in another method I'll filter out the Closures by checking against Closure.class and the property's class.
2008-11-06
Top Ten ways to spot a Groovy Programmer
10. Still addicted to Java but doesn't complain about getters and setters
9. Sunglasses. Really. Sunglasses.
8. More productive and lest angsty
7. Not worried about Java 7
6. Breezes through XML and JSON work
5. not afraid of FP or currying
4. pals around with GinA and likes DSL
3. asks did you mean the BGG, DGG or DGG2?
2. still has lots of boats because the boats are not burned... (ask Scott Davis)
1. reads GroovyMag!
9. Sunglasses. Really. Sunglasses.
8. More productive and lest angsty
7. Not worried about Java 7
6. Breezes through XML and JSON work
5. not afraid of FP or currying
4. pals around with GinA and likes DSL
3. asks did you mean the BGG, DGG or DGG2?
2. still has lots of boats because the boats are not burned... (ask Scott Davis)
1. reads GroovyMag!
2008-11-05
It's Programmable... It's configurable...
How much difference is there between a program and a configuration?
Consider that a program is a set of instructions for a universal Turing machine. If a configuration determines how a program does something... if the configuration becomes sophisticated enough so that it even includes a DSL when does it cross the line from merely a configuration into a programming language.
When does a program become configuration? When does a configuration become a program? What is the difference?
2008-11-04
GroovyMag
I'm very happy to see the first edition of GroovyMag published. Please go out and support the Groovy Magazine for Groovy and Grails developers. I'd love to see this magazine get some good circulation! I'm thankful to Michael Kimsal the GroovyMag crew for helping me launch my career in writing!
Get the word out and start getting Groovy today.
Get the word out and start getting Groovy today.
2008-11-03
It is all UI even API
It is all UI and UI leads us down certain paths.
This is an idea I've had for a long time but it hasn't been posted here before so let me lay down for you the why behind the tag line of this blog: "The power of software is the power of thoughts and ideas."
These are important concepts: The purpose of the UI is to aid the user in thinking about what they are doing inside their machine. The UI should match what they are thinking about as closely as possible.
This is all well and good for users. It gives them pretty looking sites that are easy to use and understand. It leads to ideas about making user customization of content a certain flavor of easy that involves allowing for graphical interaction with the system.
But, the programming language is UI too.
I have recently graduated into a tier of programmers that write programs for other programmers to use. But, I have always known that unless you are building the system from nothing then you are the user of another person's UI. It may be called an API but it is still UI.
Programming languages are UI too, they are UI with a limited audience, developers. Just as EE folks design CPU with a "programmer's model" in mind so too should library developers develop software with application developers in mind.
The best way to do this is through "dog-fooding" which is to say that a developer should be forced to eat their own dog-food. When you develop something you should have to use it. If you can't use it you can't really make well informed decisions about how that product should work.
As a developer I try to get inside the minds of the people who use my products. I try to anticipate what they will do, how they will do it, and what ways they may want to do things differently. I can operate this way because after nearly two decades of working with computers in one fashion or another I am convinced there is no right or wrong intrinsic in the machines themselves.
Any meaning, purpose, or sense of working or brokenness is determined by the user. To make a system that is bug free you have to know the user. The technology therefore must be designed from the user back to the machine.
The problem is compounded by the fact that there are multiple types of users. You can build classifications for each of them profiling what their expectations are and building their view of the system around that. Working for one user is broken for another. To design a truly beautiful system you need to account for as many of your user classes as possible.
Often what system designers and developers leave out of their design consideration is themselves. Developers are users too. The must live with their own design choices over time and are prone to the same flaws that other user classifications are prone to as well.
The reasons technologies succeed and fail are tied up in the intersections of actual functionality and perceived function and value. These are emotional decisions as much as logical ones. Very technically speaking any Turing complete language is capable of any task that any other Turing complete language can do.
So the power we find in expressive software is actually the ability to cleanly express some thought or idea. We are attempting to communicate both to the machine and the user some expression of action, computation, art, or logic that will achieve the goal of the user. The software is most effective when the developer and the user understand each other through the lens of the software.
This is true for your web application, mobile application, programming language, or your developer API.
The web framework developer is working for their user which is the web application developer. The persistence layer developer is working for their user which is both the framework developer and the application developer. The application developer is working for the end users of their system.
The most effective developers will be the ones that realize this and deliberately cross as many disciplines as appropriate for their application space. This kind of renaissance developer will be most effective at knowing how what they will write will be received. This kind of developer will know implicitly that it is all about user interface and developers are users too.
Just as architects have known for generations that a building must be beautiful both on the outside and the inside yet still respect the laws of nature so too must computing grow up. So in my phrase "the power of software is the power of thoughts and ideas" is nestled the concept that not only power but beauty and value of software is the beauty and value of thoughts and ideas.
The metrics of our beauty in software is the cognitive dissonance we create in attempting to enable our users to create their art with our tools. When you create software you are implicitly directing the thoughts of another person or machine. Just as an Orwellian language could forbade certain thoughts your API could forbid a design or direct users down a path. The challenge is to match your design to the users' thoughts and direct them toward good solutions without imposing a mental fascism.
The converse is side of this is that you want to direct your users toward maintainable and workable designs. The goal should be to guide not to force. So working out an good design is a balancing act.
Just some thoughts that I've had while looking at possible improvements to an existing development framework.
Edit: Oh yes, I saw this shiny "follow" gadget and added it to the upper right hand corner. Won't you do me a favor and click it a few dozen times so I don't feel too bad about having "0" followers. Thanks.
This is an idea I've had for a long time but it hasn't been posted here before so let me lay down for you the why behind the tag line of this blog: "The power of software is the power of thoughts and ideas."
These are important concepts: The purpose of the UI is to aid the user in thinking about what they are doing inside their machine. The UI should match what they are thinking about as closely as possible.
This is all well and good for users. It gives them pretty looking sites that are easy to use and understand. It leads to ideas about making user customization of content a certain flavor of easy that involves allowing for graphical interaction with the system.
But, the programming language is UI too.
I have recently graduated into a tier of programmers that write programs for other programmers to use. But, I have always known that unless you are building the system from nothing then you are the user of another person's UI. It may be called an API but it is still UI.
Programming languages are UI too, they are UI with a limited audience, developers. Just as EE folks design CPU with a "programmer's model" in mind so too should library developers develop software with application developers in mind.
The best way to do this is through "dog-fooding" which is to say that a developer should be forced to eat their own dog-food. When you develop something you should have to use it. If you can't use it you can't really make well informed decisions about how that product should work.
As a developer I try to get inside the minds of the people who use my products. I try to anticipate what they will do, how they will do it, and what ways they may want to do things differently. I can operate this way because after nearly two decades of working with computers in one fashion or another I am convinced there is no right or wrong intrinsic in the machines themselves.
Any meaning, purpose, or sense of working or brokenness is determined by the user. To make a system that is bug free you have to know the user. The technology therefore must be designed from the user back to the machine.
The problem is compounded by the fact that there are multiple types of users. You can build classifications for each of them profiling what their expectations are and building their view of the system around that. Working for one user is broken for another. To design a truly beautiful system you need to account for as many of your user classes as possible.
Often what system designers and developers leave out of their design consideration is themselves. Developers are users too. The must live with their own design choices over time and are prone to the same flaws that other user classifications are prone to as well.
The reasons technologies succeed and fail are tied up in the intersections of actual functionality and perceived function and value. These are emotional decisions as much as logical ones. Very technically speaking any Turing complete language is capable of any task that any other Turing complete language can do.
So the power we find in expressive software is actually the ability to cleanly express some thought or idea. We are attempting to communicate both to the machine and the user some expression of action, computation, art, or logic that will achieve the goal of the user. The software is most effective when the developer and the user understand each other through the lens of the software.
This is true for your web application, mobile application, programming language, or your developer API.
The web framework developer is working for their user which is the web application developer. The persistence layer developer is working for their user which is both the framework developer and the application developer. The application developer is working for the end users of their system.
The most effective developers will be the ones that realize this and deliberately cross as many disciplines as appropriate for their application space. This kind of renaissance developer will be most effective at knowing how what they will write will be received. This kind of developer will know implicitly that it is all about user interface and developers are users too.
Just as architects have known for generations that a building must be beautiful both on the outside and the inside yet still respect the laws of nature so too must computing grow up. So in my phrase "the power of software is the power of thoughts and ideas" is nestled the concept that not only power but beauty and value of software is the beauty and value of thoughts and ideas.
The metrics of our beauty in software is the cognitive dissonance we create in attempting to enable our users to create their art with our tools. When you create software you are implicitly directing the thoughts of another person or machine. Just as an Orwellian language could forbade certain thoughts your API could forbid a design or direct users down a path. The challenge is to match your design to the users' thoughts and direct them toward good solutions without imposing a mental fascism.
The converse is side of this is that you want to direct your users toward maintainable and workable designs. The goal should be to guide not to force. So working out an good design is a balancing act.
Just some thoughts that I've had while looking at possible improvements to an existing development framework.
Edit: Oh yes, I saw this shiny "follow" gadget and added it to the upper right hand corner. Won't you do me a favor and click it a few dozen times so I don't feel too bad about having "0" followers. Thanks.
Subscribe to:
Posts (Atom)