Slashdot Mirror
Software Tools of the Future
An anonymous reader writes "What are the sofware tools of the future going to be? It's an interesting question, with many facets. Here are some important trends in design and construction tool strategy, which will effect the kinds of software tools that will be delivered in the future. It looks at how to improve software development efficiency through visual modeling, generating code from abstract models, and systematic reuse."
To affectively effect the future of software tools, the obvious support must come from the developers, but the obvious support for developers are their sponsors.
At least three of the five points are almost directly targeting at the sponsors, i.e. PHB and friends.
They don't see(care) if a particular system/software/whatever is most powerful, flexible or easy to use, they're looking at things from the business point of view, e.g. which one brings more profit in the next xx years, and which tool they can easily pretend to understand.
So a tool that's business-"sense"-driven, transparent and offers lower TCO is likely to be more favorable.
Rock that crushes, Paper & Scissors that don't matter.
emacs
Gosh, these are tools of the future but I have already found several job openings asking for 5 years experience in each tool...
94% of Repubs and 21% of Dems voted to renew the Patriot Act
Good code generators. Yeah, and AI that works too. And flying cars. Utopia is always around the corner. Oh, wait. We have code generators - in India.
I'm less interested in the new directions dev tools can take, and more interested in getting the good parts of existing tools more ubiquitous. MS tools (like the .NET Dev Studio) are very nicely created, with flexibility and convenience. I would like to see tools with the same capability for C on Linux.
.NET programming like they poo-pood VB programming... but part of the reason for their popularity is the quality of their development tools. Bring some of those enhancements over to C on an alternate platform, and I think the results would be quite interesting.
A lot of developers poo-poo
Raven
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
This article, is simply looking at the obvious research efforts on currently used techniques... It has no vision about what might be done entirely differently. It doesn't even consider the potential of things like using different programming paradigms like functional programming or graph programming.
Bob
As long as automake and autoconf aren't software tools of the future, I'll be happy.
I'd like to see more projects moving towards SCons or jam.
I remember when legal used to mean lawful, now it means some kind of loophole. - Leo Kessler
My employer is working on an Eclipse-based development environment for their Cascade product, instead of developing yet another custom environment from scratch with all the incompatibility and test overhead that that entails.
Jon.
0. Alan is a Distinguished Engineer at IBM Rational
translates to: Buy Rational Rose - scaratch that see 5... Rent Rational Rose
1. Connecting business with IT: Business-driven development
translates to: What do you mean that it will take 8 weeks to rewrite? We are already selling the service, you must change it tonight or be fired.
2. Greater transparency in the software development process: Auditing, traceability, and accountability
translates to: We must find some one else to blame, because we don't need to test the part, the system drew it that way.
3. RAD using new programming models
translate to: do not design first. build it first , then find out if it mets the need. Wait that is why the want to find someone else to blame it on.
4. Collaboration among individuals and teams
translates to: Talk to each other. Stop work in the castles with moats that where built between managers!
5. "Pay-per-use" software tools: New licensing and subscription offerings
translate to: We need more money, so we are following M$ model, charge for everything at least twice. Remember: give away the razor, sell the razor blades. Wait that is what Lexmark is doing now.
thats a fact, Rational tools in my experience are way over-repesented - One group at work proudly used the Rational tools to generate some code - it was the most obscure code I had ever seen - it was not even clear what half the modules did or were suppose to do. They gave me an executable to take to a subcontractor and try out - the subcontractor laughed at it (and so did I...) There is no escaping these tools, we just need to minimize the wasted time they cause... IMHO
Features include:
FAST
It can be compiled to native code that is just as fast as C.
Type inference
In the function , it knotws that the paramter foo is a string, and it won't even compile code that tries to pass something besides a string, ever. However, it also supports polymorphic functions. For instance, can take anything what so ever as x, since it isn't used in a way that requires a specific type
Garbage collected
No malloc() or free(). Ever. Oh, and it's efficient, and can handle things like circular references just fine.
Technique agnostic
While fundamentally a functional language like lisp or haskell, it has superb support for imperitive and object-oriented programming, including multiple inheritence and all the usual goodies.
Good standard library
Things like printf, regexs, hash tables, etc, are already implemented, and always available.
It really is a great language, and you should investigate it.
A few helpful links
Offical Site
Free online book, best place to learn the language
TODO: Something witty here...
I develop in Java, and my environment consists of Emacs and Ant, mostly (hardcore, right?). I work with people who use NetBeans and Eclipse, and they keep running into weird problems interfacing them with CVS, or with mysterious classloading "features" that they have, or other obscure problems. Invariably, they don't know how to fix the problems, and I can't help because I never run into them.
I would like tools of the future to be as transparent as possible, to prevent this sort of situation. If tools are so magical that their users don't know the real theory and practice behind them, they end up relying on them to do any work. Their flexibility is very limited, and the tools end up compounding or obfuscating the "real" issues facing them.
I've already seen one post dissing code generators, but I expect to see that general class of software development tool to greatly increase in popularity over the next couple of years...
Why? Well mostly because they are getting better. Many of the newer code generation tools are very flexible and have some ability to preserve changes to the code; making them easier to fit into real development cycles. Also we are already seeing 'just in time' code generation as an optimization tool; that functionality, when combined with runtime environments like the Java Runtime or the CLR, is going to get easier and more powerful.
So, in the end, we may see developers tweaking code generation templates and filling in design forms/creating design diagrams in order to create some classes of software -- business software and game levels would probably benefit greatly from this scenario.
Obviously there are other classes of software development which would see much less benefit...
- -
Are you an SF Fan? Are you a Tru-Fan?
...and being a developer is a (mentally) tricky job, and all the crutches you can lay your hands on are useful to have if they improve your quality and/or productivity.
However you have to be a master of the tool, rather than its slave unsure of how it does its magical stuff.
I've never really got why the die-hards hate any sort of automation in their environments. Why? I understand you want the direct grip on the code... which is exactly what you get in something like Eclipse (well, you have to tell it your source dirs and your classpath, otherwise you can use it as just a text editor with syntax colouring, if that's what you really want).
There are days as a Java dev when a good tool is absolutely worth its weight in gold. For instance, if you're in maintenace mode on a large codebase which you know nothing about, and you change a method's behaviour, what upstream code will that affect? Ctrl+Alt+H in Eclipse will tell you. A text editor which doesn't actually understand the structure of your code would require you to do a lot of fumbling around and regexp searching and cross fingers you're not missing anything.
Pay-per-use implies a secure authentication mechanism, which then opens the door for abuse of one sort or another. If you are developing a product which will compete against something Microsoft already does (or plans to do), and MS gets wind of it, will there be "technical problems" in contacting the authorization server the next time you start up VC++? What about the SCO v. IBM debacle? SCO claimed they could terminate IBM's license for AIX, and if pay-per-use had been in place, SCO could have flipped a switch on all IBM's customers. Do you think that would have affected IBM's willingness to settle? Yes, they could have got a court order to turn it back on, but how many customers would have been down for a day or two, and said, "Screw this, I'm buying my unix from the people who OWN it!"
Pay-per-use is NOT the wave of the future so long as I have any say in it. When my boss asks me for tool evaluations, I'll always favour the least-encumbered tool. And yes, that means even if it's sub-optimal. We can always make changes to F/OSS stuff to meet our needs, and the freedom to do so, IMHO, more than makes up for the extra work involved.
-paul
Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
I think that we will see a movement to better languages than the currently ubiquitous C-like and Java-like ones (heck, even VB.NET is Java-like these days). These languages lack flexibility and get in the way of rapid application development and adapting to changing requirements. I think the world will move to more dynamic languages.
Also, with multiprocessor systems, clusters, and other forms of parallel systems becoming more and more common, I think we will see an increased usage of languages and paradigms better suited to that than the current imperative ones.
The tools of the future, then, will obviously be the tools that we write to support these new languages and paradigms. Dynamic languages can be optimized by figuring out which parts are static and leaving out the dynamic checks for those. Or programs can be optimized at runtime, by seeing which execution paths are most frequently taken and speeding up those.
Please correct me if I got my facts wrong.
Hist first item shows a fundamental problem right off. I've dealt with projects that were driven directly off the business requirements. The problem is that they were driven directly off the business requirements. The next project was for a slightly different set of business requirements, and because they were slightly different none of the work on the first project could readily be transferred over. By contrast in other projects I managed to divorce the business requirements from the actual work, and I could step back and instead of addressing the business requirements create tools and facilities that I could then use to address the business requirements. The next project in that line, with it's slightly different requirements, required only some relatively easy extensions to the existing work and we were in business. It took a fraction of the time. Most of the problems with business-process-driven software design and development, IMHO, is that it's too focused on the end result to be good at front-loading the solving of meta-problems that can speed up later work because solving the meta-problem doesn't provide any immediate advantages for the problem immediately to hand. In mathematical terms, it looks for a local maxima at the expense of an even better global maxima that's on the other side of a minima.
His second item about auditability also aims at the wrong point. When, for example, designing the control software for an ABS system, the goal is to have it work correctly. All else, auditability, certifications and such, are supposed to be means to insure the goal is met. That implies that you judge their usefulness not on their own but on how well they help meet that goal. He's aiming at those things as goals in themselves. ISO 9000 falls into the same trap: it concerns how well you followed a process and not how the final results turned out. This is useful if someone at the top has their eye constantly on the final result and is willing to boot the process out regardless of how thoroughly it complies with ISO 9000 if the end results aren't meeting spec, but all too often the process becomes the goal and a shield against actually being judged on the end results.
Here's my set of software predictions. Some more detail to fill in for that other guy's blog entry.
Here we go:
Some links to check out on these topics:
Semantic Designs (makers of a very powerful, generic transformational environment) http://semdesigns.com/
Link to Nic Rouquettes slides from a talk on MDA at the UML 2003 conference) http://ase.arc.nasa.gov/uml03/rouquette.pdf
Link to an article from ACM Computer magazine (last january I think) about MDS, and project at JPL which aims to incorporate some of these ideas into the design of a robust, re-usable flight software platform http://www.computer.org/computer/homepage/0104/Reg an/r1059.pdf
Refactoring Browsers were a radical change 2 years ago, and improved coding immensely.
But the claim that they "aren't commonly used" is bunk. They are in very common use today. Eclipse, IDEA, JBuilder, etc. Java IDES have made a huge leap in the last 2 years, and they rock.
They succeeded because they weren't trying to reinvent programming. They just aim to make coding easier and better.
Why non-Java IDEs haven't caught up, I don't know. The worst part by far of having to deal with C++ is that these days the tool support just isn't up to the standard of Eclipse or IDEA. emacs does great stuff with syntax, but it can't replace an IDE that is tracking the codes semantics and making clever use of that knowledge.
sean
AmigaVision it was called. It came with my A500, but without a HDD and 2 megs ram it was pretty useless.
I saw some pretty impressive presentations done with it.
There have been a lot of attemps and experiments since the early 1970's to improve the software development and management process. However, there has not been any magic bullet. Most improvements are incrimental and often disputed.
.NET run-time engine in which different languages compile to the same thing, but perhaps use relational and more declarative techniques instead of the map-based "database" and imperative-intensive approach favored by OOP proponents and languages. OOP is generally a code-centric way of thinking and is not very condusive to DPFM in my opinion. It is a fight that has to be settled one of these days.
Graphical tools have generally proven ineffective because there is no one "proper" viewpoint. All the possible viewpoints needed by different departments or situations cannot fit onto the same sheet of paper or screen without being messier than the coded counterpart.
Another thing the article mentions is getting closer to how the user thinks about things. The problem with this is that everybody thinks differently. There is no one "right" way to think and the variations are wide. Plus, people with different ways of thinking have to use the same software or same information. Delivering different viewpoints of the same info leads to the next item:
One area I would like to see explored more is divorcing presentation from meaning (DPFM). Rather than use linguistical syntax to store algorithms and attributes, if such information was treated more like a database, then one's view of the algorithms and information could be altered to how a given developer or user wants to see it.
It is roughly similar in concept to Microsoft's
Hierarchical approaches to managing such information have generally failed to scale. The real world and its change patterns are not really tree-shaped. Philosophers have known this for quite a while, and computer scientists keep rediscovering it the hard way.
One would be querying info instead of relying on file and code browsers so much. Some things, such as math and Boolean expressions, are still best represented as code (although they don't have to be stored that way under DPFM), but the size of such units can perhaps be reduced, similar to how code is reduced to mostly individual event snippets in event-driven UI systems. But to study event snippets, you query for them if there is no UI click-and-point approach available for a given search.
Yes, all this may take more horsepower, but better abstraction usually does take more.
Table-ized A.I.
I agree. Anyone who doesn't understand the importance of abstractions is likely to get left behind.
There was a time when you planned to work for your company until retirement, your company had ONE computer, and you used a small set of tools plus technology-neutral algorithmic and domain knowledge to write software.
These days the diversity of technologies that matter is mind boggling. If you don't use something at your employer this month, you'll need it at your next employer next month.
Getting the XML right, getting the HTTP protocol right, etc., etc., involves using tools that automate a lot of things for you. (Libraries are included in what I'm calling "tools".) You just don't have the time or the mental bandwidth to use all of these things quickly and well if you insist on doing everything manually.
IDEs that organize the protocols, handshaking, and plumbing between technologies, that fill in the blanks for you with valid information, that bring the right documentation to you at the moment you need it, that give you one-click builds and deployment, that give you debugging views in every increasing variety, etc., are only going to increase in importance.
I'm with the grandfather poster when it comes to my desire to have tools so simple that you know what's happening when things go wrong. When I can, I use them. But, more and more, it's becoming impossible to do so.
It's just like my father, who mourns the loss of cars with engines so simple and transparent in function that normal people could repair them. For cars, that time has past, and software is going that way, too.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Ooh - sorry for responding to myself but I thought up another. It might be nice if there was more security/workflow in a version control system.
One simple example of security might be something simple like - you do not have permission to edit this file. I bet this can already be accomplished with file system permissions and what have you.
But what would be even better would be for the environment to support basic workflow style processes. For example, if Bob is the expert on the Data Access Layer, and you make some changes and check them in, Bob should receive a notification with a note from you and perhaps and automagically generated report detailing what interfaces changed. This same kind of tactic has been employed on some wiki's to reduce vandalism. It could also be implemented as an approval process.
Moving along in that workflow direction, it also might be nice if the development environment was formally aware of the to-do list. In other words, if we bring in more version control functionality, why not add project management integration.
You might start the day by opening a task. Then you edit several files accomplishing the task. The changes you made in the version control system become associated with the task as do a record of the files that were changed. If someone else needs to see what changes you made for a particular task or bug or project, they can drill down from the top instead of trying to figure out what you did by looking at comments in version control.
This is a combination prediction/wish list:
Microsoft will continue to integrate third-party tools into their Visual Studio suite, demolishing the companies that manufacture them. This will suck for third-party tool builders, but it'll be pretty cool for us developers. Here's what I see them putting in:
* Expansion of their project templates to include a comprehensive set of patterns for just about anything you might want to do in an enterprise. Got a project coming up? Click an icon and you'll be given a complete set of skeleton code for you to modify. Useful, but dangerous: more productive developers = fewer developers.
* expansion of modelling tools as the VB guys get more comfortable with object oriented programming. Integration of UML tools with Visual Studio.
* Expansion of tools that allow managers to directly code business rules using prebuilt code blocks. This is going to be a big deal; everyone's already scrambling to build it.
* Integration of unit test tools with Visual Studio as Microsoft catches on to the whole test-driven development thing. Right now, you've got to hand-build your tests. Not for long...
In the JAVA world, I've got a wish list, but I think it's pretty realistic:
* Sun, under pressure from Microsoft's ease of use, will create a new GUI layer that is simpler than Swing and AWT, works more quickly, and provides 90% of the functionality programmers use the most. Swing and AWT will still be available, of course, but we'll have this easier option and it'll get integrated into IDEs as a project type, making everyone's life easier.
* Java IDEs will continue to embrace visual development, making life easier on everyone.
* One thing I think would be nice would be for IDEs to incorporate patterns as templates that you can drop into a project. So, say, if my main GUI is MVC, I can drop an MVC template into my project, and other templates in for specific parts of the backend... Sort of a quickstart, right?
* And, since Microsoft is going to do it, some of the Java IDEs will too: prebuilt project skeletons for common business needs, and tools to easily build business rules so Managers can handle all the client-meeting shit.
I know, my predictions are boring as always. I'm not a revolutionary, I'm a code monkey!
Farewell! It's been a fine buncha years!
I've spent the last two years in a OOD project with a team of 5 - 15 SW Engineers. I can't speak for the Rational XDE tools, or Rose RT, but Rational Rose really really sucks bad. It's the kind of tool that will make you claw your eyes out.
/some/really/long/pa, really helpful.)
Any company that can sell a tool like this and claim to be in the buisness of "improving" your software process and productivity has absolutely no credibility with me.
Rose has Modal, non-resizable, dialog boxes that display paths. If the path doesn't fit in the box it is truncated. You can't resize the box. So.. You can't see the end of the path.. ( Error could not write to
Rose has modal, non-resizable, scrolling boxes. With these it is at least possible to see the path if you need too. But you'll still go mad as the box is only big enough to hold about three 30 character lines. Of course I'm looking through a list of 200 files, and all the paths are 100 characters long.
Rose has sequence diagrams that forget their sequence, and can't be rebuilt.
Rose has a bug that makes it just go insane if a version 0 of a file gets created in UCM/Clear case. And it can't tell that it has gone insane.
Rose can't keep track of files that have changed underneath it. It has a bad habit of hijacking files and not telling you.
Rose has no good way to merge many parts of models.
Rose has a bad habit of "disappearing" modeled objects during a reverse engineer step, and not telling you. If you accidently screw up a path to a file, and reverse engineer, your modeled object will disappear. And all of the other artifacts that depend on it will get corrupted. And god help you if you check everything back in that way.
I'll take my coffee black. I'll take tcsh and vi as my integrated development environment and OOD tool over Rose any day of the week.
Kevin
"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety"-B.Franklin
Many of the newer code generation tools are very flexible and have some ability to preserve changes to the code; making them easier to fit into real development cycles.
The way I look at it, there's only one good kind of code generator: the kind whose output I almost never look at and never, ever tweak. Compilers, for example, are a kind of code generator that I love.
The other kind of code generator strikes me as just half implemented. Somebody has come up with some sort of interesting abstraction, but they haven't pushed it as far as a service, library, or compiler that you can use happily. These days I never use them.
What's the difference? Maintenance cost. A code generator produces a lot of code that is, pretty much by definition uninteresting. That means that you've hidden the actual interesting code in a whole mess of boring code, which makes it really expensive to maintain. And generally the generated code is highly duplicative, meaning if you want to change certain things, you have to change them in a lot of places.
To me, it seems like code generators dramatically worsen the cost-of-change curve. For any project where you aren't already planning to throw out the code, this strikes me as a mistake.
One group at work proudly used the Rational tools to generate some code - it was the most obscure code I had ever seen
Somebody will probably have already said it, but generally code generation is a sign that your language or abstractions are not powerful enough. Code generation takes a more compact form of information and creates a less compact result (generated code). One should use the more compact form to tell the software how to operate, not turn it into bloated code. It is almost like turning a table in a database into a bunch of set/get classes that just echo attributes. That is reverse abstraction. The only justification is perhaps performance, but you are sacrifacing maintainability and simplicity in the process. It is to make the machine happy, not people.
Table-ized A.I.
How about a SQL DB of source code, particularly C/C++? Just tokenized code, not the text of the source. SELECTing code by block inserts whitespace and comments according to user preferences. The compiler SELECTs code for generation, INSERTing large binary objects into other tables, including executables. Configuration options fill other tables. Scope is per block across the entire project, rather than the ancient file scoping paradigm. The entire filesystem granularity of C/C++ is a straitjacket.
Just the whitespace options would make it worthwhile for me. Then there's concurrency of team access, backups, distributed repositories, versioning, redundancy optimization, and all kinds of other better interfaces for the rest of our toolchain. That's the kind of bionic source infrastructure I'd like to see in my future.
--
make install -not war
Back in 1981, we were writing a word processor -- dedicated box, 64K (yes K) memory, Zilog Z80 processor.
Management complained that dev was taking too long... and yes, we were writing in assembler.
Proposed by co-worker:
Given that testing is perfect, and programming takes too long, why not start by writing your test cases? Then, generate a one-byte program. If it fails a test case, reject. If it can't complete, tentatively keep, and if all cases are met -- ship it.
Given the second case, generate another code byte (there are only 256 to go through), and repeat the test process.
Obviously, the final product will be perfect -- all test cases will work, and (as a bonus), the program will be the optimal size. As another bonus, the company can dispose of all programmers, as these roles would no longer be needed for the developement of new software.
This document still exists in the archives of the company. I wonder how many people have looked at it in the past twenty years and laughed?
Plu ca change.
Ratboy.
Just another "Cubible(sic) Joe" 2 17 3061
I see they're still trying to replace the programmer after thirty years. This is nothing new folks. Let me explain the situation. The people running businesses hate programmers. Maybe it's because we have real degrees instead of MBAs, or maybe it's just because we didn't join the right fraternities. But they just don't like us. So they keep trying to come up with ways to fire all the programmers.
It all started with Cobol, the language that didn't need a degree to use. In more modern times it was Visual Basic, the language that even monkeys could use. You've got entire programming environments where all you do is drag and drop stuff around the screen. Rational [sic] salesmen claim you can generate your entire application from UML.
For some generic "fill in the blank" type applications, they're correct. For maybe half (wild ass guess) of applications out there all you need is to wire a form into a database. But what about the other half of applications? And what about the remaining 90% of software that is NOT an application?
At the core of Google is a Damned Big(tm) database, but does anyone in their right mind think Google could ever have gotten off the ground without real programmers writing real code in a real language? Or what about the Linux kernel? Does anyone think it could have been created with a CASE tool? Is there anything in GNOME, KDE or Mozilla that could have been automatically generated from UML? Would you feel safe driving a car which had an ignition system written in Visual Basic?
Programmers aren't goin to go away, no matter how advanced the tools become. They'll make the programmers' jobs easier, but they won't replace them.
Don't blame me, I didn't vote for either of them!
If you hear that all the time, aren't you kind of curious what all these people are talking about??
.. the framework he wrote is open source.
Here's a site I use to manage big important projects, written entirely in Ruby by ONE PROGRAMMER in about a month: http://www.basecamphq.com/
The whole site is something like 4000 lines of code. I've seen XML configs for Java ORM layers longer than that!
Here's the programmer's blog: http://www.loudthinking.com/
Search around for the comments from many Java programmers who have taken a look and realized they've been wasting their life.
Numbers don't really mean anything. If I can work more effectively in a programming language that nobody else uses, I will. It doesn't hurt that Ruby is very easy to read and learn and is becoming more popular by the day (I believe Gentoo.org is dropping AxKit in favor of a 100-line Ruby program to render their web site's XML).
But "numbers" aren't a valid argument. PHP is extremely popular, but only because so many *inexperienced programmers* use it. It's a rotten language.
I would say 50% of my work is in Ruby, the rest in more boring languages. If the client doesn't care, I use Ruby and I finish most things in a few *days*. I don't know what "important" means, but I have Ruby code running that medium-sized business *depend* on. I bet in 5 years, you'll see Ruby in the big companies too. Amazon.com has asked some Rubyists to come over and give presentations, for instance.
Again, if you have to use a code generator rather than just writing everything in one language, you're doing more work, and more *complex* work than I am. You like doing less work, right?
Do yourself a favor, learn a little about these other languages and decide for yourself.
-
The importance of understanding the business context for IT investment has never been more obvious than it is today. More organizations are recognizing the role of IT as a determining factor in the efficiency of their operations, and a bottleneck in their ability to innovate. I am spending a lot of time with customers who want to explore business alternatives, drive IT projects more directly from business needs with well established business goals and ROI, choreograph services to realize their business processes, and monitor those services in execution to relate operations to the needs of the business. Support for that flow (in its myriad variations) is essential. As we use the current generation of tools in this context we are seeing the emergence of new roles, usage scenarios, and support needs. The lessons from this work are leading to a complete refactoring of tooling capabilities.
Let's try that again, in a different context.-
The importance of understanding the business context for office furnishing investment has never been more obvious than it is today. More organizations are recognizing the role of office furnishings as a determining factor in the efficiency of their operations, and a bottleneck in their ability to innovate. I am spending a lot of time with customers who want to explore business alternatives, drive office furnishing projects more directly from business needs with well established business goals and ROI, choreograph services to realize their business processes, and monitor those services in execution to relate operations to the needs of the business. Support for that flow (in its myriad variations) is essential. As we use the current generation of tools in this context we are seeing the emergence of new roles, usage scenarios, and support needs. The lessons from this work are leading to a complete refactoring of tooling capabilities.
See? It's a totally generic statement.A developer is basically somebody, that closes the semantic gap between the idea as it is presend in the human mind thinks and the code that has to be interpreted by the machine. A good tool is a tool, the reduces the burden of this process, so that more complex ideas can be realized.
Of course, not everybody has yet understood this simple fact, e.g. I frequently call him Linus "writing kernel code should not be simple" Torvalds in casual Linux design problem discussions.
But yet more problematic is the fact, that we have not really (yet?) understood, how the process works. Do you know how a program to be is initialially represented in your mind, before you start decomposing it into modules and even smaller parts drawing from learned knowledge and books which algorithms to apply and which techniques to use? I surely don't ... the same way I do not actually know, how my brain composes a series of strange markings on a surface in to legible text.
Yes, neuro-psychology has made progress in understanding the inner workings of the human brain, but they are far from knowing how it really works.
But the worst part: Software designers and exspecially programmers have a long history of ignoring scientific progress, not only in their own area of expertise, but even more concerning other sciences.
All of the discoveries in natural language programm have been deliberatly ignored by newer languages such as C#. And languages like PHP and Perl are even inconsistent from a pure computer scientists point of view.
There are things, I would like to see:
- easy design of self-learning user-interfaces
- real natural language programming
- globalized object stores
- ...
but most of these things are just not going to happen.Either because somebody is to traditionalist about something or simply because clean, simple, standardized interfaces are definitely not what you get with such a heavily divers and varying area like current in-the-field programming.