Content Preview: rss
792 days ago
Domain Specific Language (DSL) is a technique for crafting a special-purpose languages to create solutions within a specific and well-defined problem space. The potential is immense. They may be a little over-hyped (in some circles), and I think we’re still a ways from business analysts writing their own systems… Nevertheless, I assert that DSLs are important and will increase in popularity and utility as the tooling improves to allow “DSLs for the masses”. SQL, HTML, XAML, UI and Process design surfaces. These are all examples of DSLs and all revolutionary in power and productivity. I’m of course not advocating that everyone build a new DSL for every project, but when there are “product families” which share a problem space, the power of DSLs is undeniable. The power of DSLs comes from working with high level code elements that are “abstract” but not “imprecise”. It’s like one of these trade-off triangles. Everybody knows the ...
860 days ago
At the risk of not only stating the obvious, but also sounding like a prognosticating blowhard… I’d say that developers with a skill-set that only involves programming to a spec should worry about being automated out of their jobs. This has happened countless times through our history of near-continuous economic revolution and there’s no reason to believe that it can’t happen with software. (that was the blowhard part) The frameworks we code against have increased in sophistication and utility a tremendous amount over the last decade, and the previous decade for that matter, though it seems to be accelerating. What was once many lines of code is now few and I expect this trend will continue. Add to that the coming (this is the prognosticating bit) rise of domain specific languages and you can see that the design and the code will be converging and folks who make their living off the current delta are going to feel the squeeze.
1029 days ago
I saw a preview of an interesting new feature in Enterprise Library (EntLib) 3.0 this morning. When released this will allow EntLib users to create delta configurations . In practice, the user first creates a base configuration and then adds new top-level configuration sections called for example Dev, Test, or Production. Then, for each of the nodes in the main configuration, there is a subnode (Dev) which allows you to override the property definitions in the base configuration and specialize them for the different environments. Then you can select the top level delta node and export the XML combining the base configuration with the delta overrides. There is also a command line version that allows you to integrate this into your build process. Good Stuff!
1176 days ago
Seeing incorrect spelling in computer print all the time detracts from the visual image of the correct spelling. I'm not sure if everyone uses that sort of spatial relationship and image to recognize words, but that's a big part of how I do it. It's a visual gestalt of the word and not a remembered sequence of letters. If I'm wondering about the spelling of hand-written words I just recall the print version to see if I've got it right. Or at least I used to. The change toward online media has created a situation where everything can have the "in print" glamour of correctness, no matter how ill-informed or tawdry. Now that everything is hard text online and full of errors, yet still set in "official" looking type, it seems more difficult to just see a word and know if it's correct. Or it could be age. And it’s not just spelling, but also basic grammar and usage. I see this all the time in the debased language on internet forums. Their there loss has ...
1192 days ago
Blog Help Some thoughts about the boundary between what we traditionally think of as thin and thick client apps. With the increasing complexity of the browser environment I think the distinction is blurring between using a browser as an execution host vs. a “traditional” run-time as an execution host. In the beginning there was the native client, and it was good. For a while at least, until IT departments found out how expensive it was to maintain that software configuration. So came the radical shift towards thin client, with a goal of zero client side application footprint. There were two options: · Distribute a runtime and enable it to run network portable code. Like Java and Applets. · Use a browser and send lightweight markup over the network. Well, at the time there were problems with the runtime approach: · Distributing the Java runtime was problematic for many network connections. ...
