I have blogged before about my dissatisfaction with the rate of improvement of the Java platform. While the situation is understandable, it still leaves me annoyed. Below is an updated wish list that I would like to see in Java 8.
I am increasingly considering getting my hands dirty in adding some of these features. If only I had more time. So my first wish is for a clock with a big 'stop the world' button on it. Having an infinite amount of time, with high energy levels, no risk of rsi and no risk of interruptions would be great. Please create this for me Mr S. Hawking.
jvm
support jar level constant pools to reduce class sizes
enhanced gc
transactional memory support
add method parameter names to reflection
access to javaadoc from api (provide in optional packaging that can be accessed via reflection); include comment following abstract method.
Simple syntax sugar
.?
multi line strings
versioned jar file/module system
drop the annoying diamond operator (<>) added in Java 7 but keep the functionality
optional method parameters with default values
language syntax for reflection
language support for collections
pre condition support on method signatures
More involved language features
mix ins
closures
Language support for custom types
replace try-close with keyword; keyword declares that an object is not to escape the stack
Inferred type support (eg var s = "abc"; s is strongly typed to String why double declare it)
Showing posts with label musing. Show all posts
Showing posts with label musing. Show all posts
Sunday, 12 June 2011
Saturday, 21 May 2011
Refactoring is not the same as rearchitecting
Refactoring is a small scale technique, a collection of small transformations that when applied with skill to a code base helps to improve the readability of the code without changing its behaviour. Unfortunately it has become all to common to use the term with management to hide a project rearchitecturing exercise or rewrite. Such work may be required, however the purpose of refactoring is as a low cost tool to use daily as part of ones programming practice; which helps avoid entropy in the first place.
For more information see: http://refactoring.com/
Thursday, 12 May 2011
So what is Software Development? Art, Craft, Science or Engineering?
What assumptions, preconceptions or heuristics help you as a Software Developer? Both now, and those that guide your learning and exploration of new techniques?
Like many practitioners of my age I have flirted with SWD (Software Development) as an Art form, a Craft, a Science and Engineering practice many times over the years. I was trained at a University as a Software Engineer, by Engineers with a background in either Electrical Engineering, Mathematics, Physics or Computer Science. I have worked with developers who considered themselves to be solely artists and/or craftsman, and I have worked with scientists.
But why care? Does it matter which field Software Development is most like? Each time that I have considered SWD as just one of those forms, I took inspiration from those fields and I found that there was elements of my work that were strengthened, however I have also found that as a whole my work was weakened. At first I did not notice that the whole was weakened, at first I did not have enough breadth of experience to see the effect. Or perhaps as I was learning in the early days I lacked enough skill for there to even be a decline to observe.
However once the observation that my work was weakened as a whole was made, it has lead me to not be so interested in whether SWD is any one discipline, other than SWD is SWD. SWD is a young field dating back only five decades or so; this is young when compared to other fields that date back hundreds or thousands of years. So instead I postulate that SWD has the most to learn by infusing elements from each of these sister fields.
The view of SWD as an infusion of trades is a pragmatic one, I am not sure if it is at the essence of SWD or an acceptance of its young age. Before Science was viewed a Science its practitioners were as much Artist, Craftsman and Engineer as they were Scientist. Perhaps Artistry and Craftsmanship can be viewed as a base that Engineering, and Science are built upon.
As of the time of writing this post I find the guide that I am currently using the most is to view Artistry and Craftsmanship as a base for SWD and Engineering as an extension that helps with the coordination of larger teams of developers.
Put another way, Artistry reminds me that working without putting ones soul into it is work that is not worth pursuing, Graphic Design aids me with understanding how to improve the communication of my software designs both to the end client AND to other developers who follow after me by improving the communication of the code base itself. Craftsmanship keeps me practical and learning by doing (rather than being overly theoretical, which is a tendency of mine) and Engineering keeps the rigour in the process that helps to coordinate cross skilled teams effectively.
Like many practitioners of my age I have flirted with SWD (Software Development) as an Art form, a Craft, a Science and Engineering practice many times over the years. I was trained at a University as a Software Engineer, by Engineers with a background in either Electrical Engineering, Mathematics, Physics or Computer Science. I have worked with developers who considered themselves to be solely artists and/or craftsman, and I have worked with scientists.
But why care? Does it matter which field Software Development is most like? Each time that I have considered SWD as just one of those forms, I took inspiration from those fields and I found that there was elements of my work that were strengthened, however I have also found that as a whole my work was weakened. At first I did not notice that the whole was weakened, at first I did not have enough breadth of experience to see the effect. Or perhaps as I was learning in the early days I lacked enough skill for there to even be a decline to observe.
However once the observation that my work was weakened as a whole was made, it has lead me to not be so interested in whether SWD is any one discipline, other than SWD is SWD. SWD is a young field dating back only five decades or so; this is young when compared to other fields that date back hundreds or thousands of years. So instead I postulate that SWD has the most to learn by infusing elements from each of these sister fields.
The view of SWD as an infusion of trades is a pragmatic one, I am not sure if it is at the essence of SWD or an acceptance of its young age. Before Science was viewed a Science its practitioners were as much Artist, Craftsman and Engineer as they were Scientist. Perhaps Artistry and Craftsmanship can be viewed as a base that Engineering, and Science are built upon.
As of the time of writing this post I find the guide that I am currently using the most is to view Artistry and Craftsmanship as a base for SWD and Engineering as an extension that helps with the coordination of larger teams of developers.
Put another way, Artistry reminds me that working without putting ones soul into it is work that is not worth pursuing, Graphic Design aids me with understanding how to improve the communication of my software designs both to the end client AND to other developers who follow after me by improving the communication of the code base itself. Craftsmanship keeps me practical and learning by doing (rather than being overly theoretical, which is a tendency of mine) and Engineering keeps the rigour in the process that helps to coordinate cross skilled teams effectively.
Subscribe to:
Posts (Atom)