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.
It will talk back to me... I'll be like "Computer, make me a program that can figure out how we can get out of this temporal rift"
Doesn't matter anyway... cuz the borg will be introducing new software to us soon enough...
emacs
..a case of wise linking. Not making something like "this article" into the link text or shit like that.
Congrats!
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.
In conclusion,
6. ???
7. Profit!!!
Why, exactly, should I take the word of a guy who works for Rational? The people who want to SELL me the tools to do these things?
See you, space cowboy...
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
In the future, if Joe Sixpack says, "you know what I needs, I needs a program that balances my checkbook and is completely automated." Then he will go out and buy Microsoft Visual Basic, draw the program, and have it balance his checkbook. Now if he could just write a program that would give his flying car a tune-up he would be all set.
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
More complete Refactoring tools for C/C++ would be nice.
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.
Well like I said over there. Smalltalk, the language that's also an IDE.
Forth for the other end of the spectrum. Maybe Object Rexx for the middle?
And last, yes history repeats itself, but that's because we didn't learn the first time.
I remember there was a type of object based visual language for programming/scripting on the Amiga, I can't remember what it was called. But I always thought that if someone could standardize that and make it more available and versatile that it would be the programming language of the future. And that it would allow everyone to make programs.
It's also kind of like in Star Trek: TNG, the episode where Dr. Crusher has to program the computer to calculate who all those speices DNA will map out to the star charts. You get the impression that she is doing something very complex in an object oriented way. Of course, that's Sci-Fi and made for TV, but still.
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.
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.
...will run under emacs.
Emacs, baby. All the way.
In the course of every project, it will become necessary to shoot the scientists and begin production.
Model Driven Architecture (MDA) is the future. It eliminates most of the design, development and deployment phases by allowing you to focus on the analysis which drives directly into a platform independent model. This model can be deployed to most platforms, redeployed down the road on commodity hardware, updated ... there's a million benefits. No more outsourcing, no more defects because of developers deviating from best practices.
In the future... We'll have software that protects against dupes!
Tools will make it easier to hire and fire programmers (and outsource for them), and they'll give middle management more control (or at least marketed that way.) Whoopee! What a Brave New World!
is Lisp.
I'm not sure if they have Harbor Freight outside of California so a lot of people might not get this reference.
It refers to a company that imports dirt cheap tools and sells them at rock bottom prices. Their products are basically the cost of the materials plus an extremely thin overhead, not altogether unlike selling software for the cost of the media.
Thirty years ago, Americans mainly bought their tools from stores like Sears which carried brands like Craftsman which had this deal where if you broke a tool they would replace it for free. Of course that was a cute policy since most people lose their tools long before they break them and these tools were prohibitively expensive to buy in the first place.
Harbor Freight just fucked that market up in a big way. The fact is, those imported tools are just as good for most household jobs and far, far, far less painful to replace if you lose them.
Of course the analogy between software tools and hardware tools is not all that great, but what I'm driving at is that even in the world of wrenches, hammers and screwdrivers the high-cost "quality" tool with the service guarantee strategy has already failed. Generic, standard and, most important, inexpensive tools eventually dominate and that is a very good thing.
People obsessed with the importance of brands should get out of the tool business and try the fashion industry. That's a market where brand consciousness is always in high style.
"doesn't even consider the potential of things like using different programming paradigms" That's because "new vision" has never really amounted to much of anything(outside of academia.) We will continue to used tired old paradigms until something truly disruptive occurs. I'm still dreaming about "artificial intelligence" doing the vast majority of programming. Time to start working on those "positronic brains!" haha
I disagree, at least from an European point of view.
BTW, I was a few days ago at the IST2004 European conference (The Hague Nederlands) and I heard the exact opposite view. Only high-value opensource tools would help Europe in not losing all its (unsufficient) IT industry.
Probably the US is in a different position: dominant corporations (including corporations behaving against laws and ethics, see recent anti-trust cases) - like MicroSoft- are american.
In all cases (and in all continents), the IT job market will evolve.
How to square a 2x2 matrix? Here is, what the Critticall tool has to say about that: C21=A21*A12; C11=A11*A11; C11=C11+C21; C22=A22*A22; C22=C22+C21; X=A11+A22; C12=X*A12; C21=X*A21; Did you know this?
Cb..
Us super evolved types are an intuitive bunch, and have long abandoned Emacs. My 14 fingered friends really enjoy using Apple Xcode with a single-button mouse.
Have you ever worked with QNX Momentics? It can be used to build programs in a variety of languages for a variety of platforms. I found it a lot more comfortable than MS Visual Studio .NET. Also, it's not restricted to just one platform. It costs quite a bit, though.
Please correct me if I got my facts wrong.
thats all anyone needs...
and gcc & make...
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?
Something from the past like LISP, lambda calculus, relational databases, etc., will be re-invented, re-named, and poorly re-implemented. Companies will sell it with hot new trademarks, fads will come and go, and software will still be full of bugs, and buyers will still not care.
Those of us who have been programming the same way for years will yawn, adapt to the new languages and wonder "what did they get wrong THIS time.. oh I remember when we had to start calling that 'refactoring'.. now the kids call it 'unduplicating', okay, whatever".
Emacs: The solution to our problems.
Emacs: The cause of our problems.
Imagine how different the world would have been if IBM has gone for ROMable Emacs instead of DOS.
...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.
I think the point about needing a way that normal people can develop software is key - tools can be a way of reducing the technical barriers & associated risks that exist in software production
For me vb, cyrstal reports and to a lesser extent rational rose, lint fit into this category..
I'm not sure you could call it a trend yet but there seems to be more than isolated occurences of companies producing client software with lower-risk languages/tools and buying in the more complex back end processing logic from outside.
Not sure about the disproving-liability point; tools can only automate process and I haven't seen a software process yet that could provide a legal standard of proof that something is fit for purpose.
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.
It looks at how to improve software development efficiency through visual modeling, generating code from abstract models, and systematic reuse."
I hear demonic voices howling these phrases in recurring nightmares I've been having.
Oh, wait, those were meetings at work.
Can we also "utilize synergy"? Pretty please?
any language that requires code generators is a broken language.
I've written code generators for PHP and Java (in Ruby). I had to do it because those languages are so badly designed (PHP especially has no excuse, it is completely possible to add dynamic features without breaking the existing syntax or semantics of the languages, yet the designers choose not to).
When I program in Ruby or Lisp I don't need code generators, I can "generate" code *within the language* at application startup time.
It said, "You're all still stuck with shitty Microsoft dev tools suckers!!!! And by the way, kernel 8.6.9 still doesn't support USB9. HAHAHAHA."
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.
Software development efficiency is affected more by the skill of the programmers and the flexibility of the design than by the use of such tools. Bad code is bad code, no matter how it was written.
Here's my set of software predictions. Some more detail to fill in for that other guy's blog entry.
Here we go:
With businesses growing more aware of security issues, we will develop tools that lead to better security. It's not enough to teach programmers about security and which pitfalls they need to be aware of. We need to systematically analyze the code and find and eliminate weaknesses.
Please correct me if I got my facts wrong.
We could also have meta-databases of pre-existing code. Need a sorting algorithm? Pull out a quicksort general sorting template (language neutral form) complete with information about the algorithm itself e.g.speed, accuracy, etc. Plus any correctness tests that need to be done, as well as documentation. Insert into code being worked on. Customize, run, fix as needed. Lather, rinse, repeat.
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
You know, I hear that kind of thing all the time about LISP, Ruby and various flavors of declarative languages. But it is important to note that no one uses them for anything important. (OK, not entirely true I will admit -- there are big projects in LISP at least; but it is certainly true in general.) So, until the rest of us stop using 'broken' tools to write the software that actually runs the world, you really don't have a point.
Someone smarter than me said it best: "There are two types of programming languages; the ones that people bitch about and the ones that no one uses." -- Bjarne Stroustrup
- -
Are you an SF Fan? Are you a Tru-Fan?
Python has existed for years.
You come up against limits imposed by information theory (or practice). You have to communicate the parameters to your tool in some way, the least repetition the better. I came to the conclusion that the easiest form to put the parameters into is a text file and the best way of doing that is a text editor of your choice. All the rest is just duct tape to get round shortcomings in the language and libraries (hmm, why are IDEs and code generators so useful with Java...)
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
Ask yourself, "How would I feel if my tools were exploited by the Americans to improve their weapons systems or their torture techniques against Iraqis and others?"
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'm not arguing that code generators and advanced IDE's are a form of duct tape -- only that they are a form of duct tape we need. Certainly there might be some magic tool out there that oblivates that nescessity; but until it is in general use I won't be using it to get my work done.
In other words, I live and work in the real world. In the real world things are often hacked together with twisted coat hangers, old pizza boxes and duct tape. So, to me, duct tape is a good thing.
- -
Are you an SF Fan? Are you a Tru-Fan?
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."
we'd all be doing VISUAL programming on holografic 3d images moving stuff with our hands. I hope VB is not part of his vision.
no one commented on the article via developerworks :-(
(it's a lame blog anyway), so i registered a
developerworks account and posted a comment linking
to here, -lol
ok, sad but i was boooooored
I would be interested in seeing better version control integration in development environments. In a traditional approach we have several distinct tools. There is usually a repository with a version browser, a diff viewer, and a your development environment.
If you want to see a the previous version, you often have to switch to your repository tools. If you want to see comments submited with a version, you have to go to the repository tools. If you want to compare the previous version to the current, you have to switch to your diff viewer. When you are back to development, you switch to the IDE editor mode.
I'd like to see an IDE completely integrated with version control and language commenting features. For example, the story of a file should be part of the program file document. It shouldn't reside in a version control database. If you want to see differences between the code your looking at and a previous version, you ought to be able to just right click and have the changed code show up a different color right in your editor.
Perhaps unrelated to cvs, I'd also like to see better association of comments to sections of code. As things get copied and pasted around, it is not uncommon for comments to become disassociated from relevant code. You might find yourself asking, what section of code does this comment cover: the whole file, this function, this loop, this line? If comments were formally associated with code regions (vs feature), it would define a scope for the comment. You also might find yourself looking at the code and the comment and trying to reconcile conflicting information. It might be useful to be able to view what the code for the region looked like when the comment was originally written (more cvs integration).
I'd also like to see better integration of development tools with version and development environments. For example, it should be easy to set up a version control system to run a style checker, compile code, and perform regression testing. When it encounters problems it should be able to determine (basically) what they are, when they were introducedm, and by who. You should also have the option of setting more pre-check in checks. Bits and pieces of this kind of solution exist (like Java's checkstyle), but setting up the environment to do everything is very unfun.
As a natural extension of the whole line of commenting, I'd like to see comments move more from a language feature to a program document feature. For example, if I add a change log entry to a function header, I don't want to just copy the text above and type everything freeform. I want it to be more like I'm adding a response to a message board. The IDE maintains the comments in some internal representation, it prompts me for the requisite information using some kind of unobtrusive form. It automatically identifies things like the date and the user. If my change log is a response to someone else's comment, the comment appears as a thread, etc....
Actually, I think that any (even rogue) state has enough power and money to buy (or steal) any software product (either sold or opensource). Of course, some snesitive software are not easily available (like e.g. numerical codes used in weapons) but these are not commercially available (nor opensource) products. So I really think that open-source is really a non-issue for bad nations. I mean that even today, poor nations can do a lot more harm than medium corporations or armies. As a case in point, when the Soviet system (sort of) worked -eg in the 1970s- it was able to produce weapons (even if we know today that their cost and quality has been over-estimated by the US policy). And it did'nt need any opensource software... Also, I would suppose (but I really don't know) that the former Iraqi army did not buy license for every Microsoft systems they have been running :-)
This is more or less the same kind of strategy the RIAA and MPAA employ (as often pointed out here on /.) It might be best for the old dominant companies but the overall growth of the IT market is slowed down by this kind of thinking. Who cares if the new, superior tools come from the US, Europe or China if the overall speed of development is increased from decades to years, from centuries to decades. The scientific community always worked best when all scientists around the globe worked together and not concurrently.
Linux is not Windows
Genetic algorithms have been used to solve a number of problems that would be hard to solve otherwise, problems where it is easy/fast to determine if a solution is any good or not.
If we combine this with test-first development, where you start writing testcases, then code until they pass, we would end up with a software development methodology where all the developers do is write testcases, then GA will provide a solution where all the tests pass.
Think about it, we have loads of processing power available so who cares if you have to run your tests every night on a huge system - when you show up in the morning you are likely to have a working solution that passes your tests (until you write more tests, that is).
Mind you, GA tends to write absolutely horrible code, and most of it by far doesn't even seem to be used at all - which is also the case with DNA, BTW. And for a complex system you need a huge number of testcases. Maybe the issue in the future will be how to automatically write tests?
</incoherent-rambling>See Parmalat, TotalFinaELF, Royal Dutch Shell...
Honestly, this sort of comment displays such complete ignorance it would astonish me how many Europeans spout it so proudly, if I didn't read your newspapers there and see nothing but "Enron...Halliburton...Enron".
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 say graphical programming is the future. Take programming out of the realm of nerds into the realm of designers.
By the way Softwire is free now. No excuse not to try it. Unfortunately for the Linux fanboys it only works with Windows and you need Visual Studio installed.
Easiest way to program ever.
There's one thing no one's mentioning. A good development environment needs a good CLI. Despite all the gooey this, and the gooey that. Text is still the interface used. What's that your typing in? A picture you say? Green screen environments have shown us that one can be productive.
Next, I need a tool large enough to distract from my nerdly geekiness.
Next, well, really, I could just use a larger tool...
Does that make me gay?
"What are the sofware tools of the future going to be?"
I suspect a tool that corrects spelling mistakes will prove to be a useful "sofware" tool.
I'm sure any new tool will need a substantial retail price to cover the cost of paying the licence fees for 236,542,876 various patents.
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
People will develop software like that right after we get world peace, have completely switched to renewable energy, and everybody exercises for 1h and flosses and brushes three times a day.
Increasing abstraction is necessarily the way of things.
Better languages give you increasing abstraction, which is a good thing. But tools don't really give you increasing abstraction, they just try to hide complexity.
The next wave is the ides that make the repetitive coding unnecessary.
That has also been the previous wave and the wave before that. In all those waves, people tried to get by with tools, but eventually they realized, they had to move to new languages. It's going to be the same this time around.
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.
I actually work with RoseRT on a daily basis and it is the only member of the Rose family that does not suck. Most important reason: complete code generation from model, and model based debugging.
Once you've gone through the learning curve, you become very productive. Mind you, there are always shortcomings. Parallel development and subsequent merges can be a pain because merging is not as visual (e.g model based) an experience as normal development.
Still, the whole package is actually very good. Must have something to do with the fact that Rational bought it (it was first called ObjecTime) instead of creating it from the ground up. Most of their other tools are a nightmare to work with. Ah well, every litter needs a price puppy.
And how is this not a completely xenophobic, nay racist comment?
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
The tool of the future will be some child chained to her desk churning out shitty code for 80 cents a day.
Get over yourselves, slackers.
Tools that are simple to use are complicated to develop and enhance.
The simpler the tools are to use, the more complex the projects are that they are used to create.
In addition, simple tools become more complex over time as new features are added and they are used to solve more complex problems. Whole sub-systems are reduced to a tool, which makes the resulting systems simpler at the expense of more complex development tools.
I don't see any way to avoid complexity. It just gets moved to a different level where different developers have to deal with it.
The future of software tools could be an endless cycle of moving complexity from systems to development tools and then back again to systems.
I think you missed my point: Code generators have improved so that the cost-of-change has gone down! At one time they were really only good for getting started by spitting out piles of repetitive, uninteresting code; afterwards you might tweak the generated code or have to change it for a bug fix, so you didn't want to regenerate. This is no longer entirely the case.
Check out some of the links here. Especially CodeWorker.
Mind you I am not entirely a fan of code generators myself, having been forced to use bad ones in the past. But they are good fits for certain kinds of problems, they really have improved recently and I was simply trying to answer the original question in the parent article in a meaningful way. I really do think they are going to be hot in the developer space soon. Unfortunately I expect a lot of PHBs are going to jump on the bandwagon and want us to use code generators in spaces where they aren't a good fit. For example, using a code generator in a case where a nice clean library is more suitable.
- -
Are you an SF Fan? Are you a Tru-Fan?
Come on guys, don't respond to this troll. Look around, this has been posted in various forms to many topics here, including space weapons, bio-engineering, etc.
Sleep is futile.
Because if it ain't spelled right you can't compile it. . .
DAHH
Oh, I shouldn't use words like 'dahh' or "ain't"
because you might not be able to understand me.
DAHh
It's a matter of time, but programming will eventually be easy enough to be done by the users themselves.
The programmer job of today is comparable to that of a typewriter in the early days. Those who don't embrace alternatives are just being naive.
I have crafted highly dynamic control systems in both C and C++ complete with animated graphical user interfaces.
These interfaces controlled real robots which are now used world-wide to do industrial production in the ******** industry. The machines sell for something like $30,000 each.
I would never have been able to do this real-time control in lisp or your other meta-languages.
You don't know what you are talking about.
It depends on the real-world application as to what language to use.
Why do people use C for real-time control:
Becase it works!
If you don't know how to do dynamic control in C or C++, how could you ever hope to pull it off in any language?
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.
Years ago -- okay, millenia ago -- any primate with an ounce of neocortex could re-engineer a lion femur into a very serviceable melee weapon.
To this day, any primate with an ounce of neocortex can make his own club. But just try to make a tactical nuclear weapon! For that, you need an entire army of primates -- and they'd better have more than an ounce of neocortex.
-kgj
-kgj
Obviously, new software tools are going to have to embody twisty little logic traps and lawyer skills.
Everybody's a libertarian 'till their neighbour's becomes a crack house.
Now, how many times have you seen someone tortured with the source code from EMACS? Just the source code- I know it's happened with the binary.
Also, if the Chinese can build a nuclear weapon, don't you think they could write a decompiler?
I have gas, but my car uses petrol.
Seriously folks, there is nothing to see here. Move along and don't take the free koolaid. Of the things this guy says that are correct (points 1,2, and 4) are addressed with changing your process, not your tools. Points (3 and 5) are just attempts to sell you a glass hammer (it's like the infamous "golden hammer", but breaks when you try to use it). Better programming models have been promised for over 30 years, and pay-as-you-go is just forcing you to behave the way some vendor wants you to. In this case, "some vendor" is IBM.
*CASE: Celluloid Assisted Software Engineering
*** Sigs are a stupid waste of bandwidth.
And I'm sorry that I'm not a purist like you, but if you'd like to write a few 100 KSLOC to control a commercial airliner, then have to test it and prove to some folks (who I'm assuming will be a lot smarter than you) that it's stable, then be my guest.
How is it that you are a 'real engineer'? Because you continue to do things despite the fact that they don't work? That sounds like a George Bush engineer to me. There's nothing more amusing that someone who chooses to defend themself with absolutely no backing to their argument, just mindless rants.
Also, you made the worst mistake possible in this topic: software engineers are *not* programmers. Yes, they program occasionally, but that is not and should not be their only activity. Any joe with half a brain can attend a trade school for 6 weeks and become a programmer -- it takes someone with some intelligence to look past the code, something I see you are incapable of doing. But I'd advise you to continue to think as you do -- maybe that's why you're out of a job.
And lastly, you missed the entire point of the post by thinking this was about kicking programmers out of a job -- it's about making smarter, more effective programmers who produce better code through the utilization of tools rooted in sound formal methodologies.
Hopefully you think my reply is as pointless as yours was. It's like the old saying, garbage in garbage out.
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!
And the upcoming version of emacs, emacs-u-later.
On the other hand, your post is a troll. It is just a whiny complaint that contributes nothing to this discussion. Moderators, please downgrade the parent post!
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.
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.
Why isn't the generator part of your build cycle?
Why isn't the generated code factored out of your application such that the interesting code and generated code are separate?
I mentioned in another reply on this thread that I live in the real world. And the sad thing is, here in the real world we get paid money to write code in languages other than [insert your favorite language here]. Hell, I even spent six years in the COBOL mines. By my own count I have programmed in upwards of twenty different languages for pay; and every single one of them sucked for one reason or another! I have to put bread on my table and support my family, so I did what I had to do, despite what my heart told me.
Here in the real world we often must do things like that. I envy those who have more choices. But I've only so much mind share and I need to spend it where it will return the most value in terms of dollars per hour, not personal satisfaction.
And if it was about personal satisfaction I would be nattering on at length about this programming language I have spend fifteen years designing and everyone should be using instead of [insert your favorite language here]. Sadly all I have to show for that wasted time is piles of yellow pads full of notes and about five thousand lines of partially working code...
P.S. Get a /. account and post with your real name. If your opinions are as sound as you feel they are, you shouldn't be shy about connecting your identity to them.
- -
Are you an SF Fan? Are you a Tru-Fan?
I once made a certificate for a colleague who went through "UGE Training."
-dw
-
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.can you elaborate what you mean by spatial code browsing?
....getting better tools?
... well... us humans. Elements or facets of abstraction physics include the actions of abstraction creation and use, such as defining a word to mean a more complex definition (word = definition, function-name = actions to take, etc.), Starting and Stopping (interfacing with) of an abstraction definition sequence, keeping track of where you are in the progress of abstraction sequence usage (moving from one abstraction to another), defining and changing "input from" direction, defining and changing "output to" direction, getting input to process (using variables or place holders to carry values), sequencially stepping thru abstraction/automation details (inherently includes optionally sending output), looking up the meaning of a word or symbol (abstraction) so to act upon or with it, identifing an abstraction or real item value so to act upon it, and putting constraints upon your abstraction lookups and identifications (when you look up a word in a dictionary you don't start at the beginning of the dictionary, but begin with the section that starts with the first letter then followed by the second, etc., and when you open a box with many items to stock, you identify each so as to know where to put it in stock.)
That being a better and common understanding of abstraction physics. Where like with physical reality we gain more control the better we understand the physical physics, we will have more control in understanding abstraction physics better...
Physics of Abstraction (abstraction physics)
Abstraction enters the picture of computing with the representation of physical transistor switch positions of ON '1' and OFF '0' or what we call "Binary" notation. However, computers have far more transistor switches in them than we can keep up with in such a low level or first order abstract manner, so we create higher level abstractions in order to increase our productivity in programming computers. From Machine language to application interfaces that allow users to define some sequence of action into a word or button press (ie. record and playback macro) so to automate a task, we are working with abstractions that ultimately accesses the hardware transistor switches which in turn output to, or control some physical world hardware.
Programming is the act of automating some level of complexity, usually made up of simpler complexities, but done so in order to allow the user to use and reuse the complexity through a simplified interface. And this is a recursive act, building upon abstractions others have created that even our own created abstractions/automations might be used by another to further create more complex automations. In general, if we didn't build upon what those before us have done, we then would not advance at all, but rather be like any other mammal incapable of anything more than, at best, first level abstraction. But we are more, and as such have the natural human right and duty to advance in such a manner.
There is an identifiable and definable "physics of abstraction" (abstraction physics), an identification of what is required in order to make and use abstractions. Abstraction Physics is not exclusive to computing but constantly in use by
Abstraction Physics has yet to be established/recognized in a broad "common acceptance" manner, similiar to the difficulty in the acceptance of the hindu-arabic decimal system (which included the concept that nothing can have value - re: the Zero place holder). It took three hundred years (from inception) for the innovation of the now common decimal system to overcome the far more limited Roman Numeral system. (NOTE: mathmatics and the symbol sets used are also abstractions and therefor a subset of abstraction possibilities and certainly an application of abstraction physics.) Though the act of programming is still younger than many who apply it, we are technologically moving at a much faster rate of incorporating innovations and better understandings of reality. There is a physics to ab
Dismiss? No way. However, I would recommend that perhaps people learn to create their own simple code generators for various needs.
One of my personal favorites is to translate tables in a document, such as HTML, into language X for use by a table driven processing engine. Another is to whip up record structures / objects + attributes.
Your mileage may vary. Eliminate redundancies, you have better uses for your time.
Yow! I'm supposed to have a plan?
The focus on comments over blocks of code seems to tie into Donald Knuth's "Literate Programming" where you write the documentation first, then embed the code, in any order you want. The build process then extracts the code in a working order / set of files and off you go to the compiler.
Not that I've ever been in an environment that used such a thing, but it sounds very interesting.
Yow! I'm supposed to have a plan?
I think DSLs are a better option.
As a hobbyist who enjoys programming, my interests are heavily biased towards "innovations" that make programming itself more interesting / enjoyable / satisfying, and less boring / mundane / repetitive. So, I especially like the visual/modular programming interfaces found in Max/MSP, Reaktor, Reason, and also in the software I'm currently writing called "Salvation" (http://www.slvtn.com) .
I guess there's no accounting for personal taste, but IMHO MetaOCaml doesn't seem too bad (and I agree that it's much much better than C++ templates
I believe someone has been working towards an LLVM backend for OCaml, which might end up providing better performance and optimization opportunities (since LLVM can also take into account run-time profiling info).
I kind of agree that this bit could be better, but for simple interface you can almost always use camlidl to great effect. For complex interfaces, I usually find that camlidl becomes more of a hinderance than help, and I almost invariably end up implementing the C stubs manually. YMMV.
HAND.
Regardless, in a fixed-layout system, the burden is on the programmer to take large fonts and other accessibility options into consideration. In a dynamic layout editor, these considerations are naturally handled by the code.
It's just like OO. There's nothing you can do with objects that you can't do with ordinary functional or even unstructured programming; you have to be a lot more careful, though.
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.
If you look closer at Linda you will have a deeper understanding of it. In its basic form it doesn't have triggers and there is no way to search the tuple space without removing (and reinserting) all the tuples until you find the right one.
The tuple space comes from above. Great assumption. Bah.
Simple:
1. vi
2. C
You guys should really check out KDevelop 3, and learn how to use it.
I always wonder why people think it's such a bad idea, since the syntaxes of almost all current languages require indentation/whitespace to be readable anyway... Just stay away from tabs (or alternatively stay away from stupid editors that treat tabs as anything other than aligned on 8-char columns) and you'll be fine.
HAND.
I'm curious as to what Tyler has in mind, since Common Lisp is a strongly typed language.
Perhaps his concern is that Lisp does its type checking at run time, rather than compile time. There are two aspects to this. Some compilers, notability CMUCL, make good use of the optional declarations to do type checking at compile time and produce fast code. More importantly, the actual issue is not compile-time versus run-time, but early versus late
You always want early type checking. If your development cycle runs: edit, compile, edit, compile, run, edit,.... then you want compile time type checking. If your development cycle runs: edit, run, edit, run, compile, run,... then you want run time type checking.
Even if the software is designed top down, a Lisp programmer would code in a bottom up, test as you go, style. One window has the program source, another has the Read-Eval-Print-Loop. Immediately a function is written, it is sent to REPL and tested interpretively. Once the code is correct, it is compiled, to get full speed, and work moves to the next stage: achieving performance goals.
Thus Lisp has early type checking, and that is what is important, not whether it is compile-time or run time.
See, this is a common mistake. For thirty years or so now people say, tomorrow users will be able to program themselves, but instead the programming tasks just get more complex.
Users doing ALL the programming (even the programming of the programming environments/languages) won't happen before real AI is developed which IMHO is scheduled for "never" (or at least not in this century).
Linux is not Windows
I think the answer is that a modeling environment which can "run" the model becomes its own computer programming language, and people are concerned that if something is perceived as yet another (fine) computer language, no one will want to use it. If the modeling system can spit out C++, you can point to that and say "here, it uses C++ and C++ is a portable language that everyone has heard about." Heck, C++ was originally a modeling environment for C (it was a preprocessor that generated C code).
The thing that bothers me about "code wizards" for C++ is that C++ has macros, it has classes, it has templates, and to supply a code wizard is an admission that you don't know how to use those three facilities in C++ to abstract what you are doing (ActiveX, Windows forms) in form you can get people to use, so you automatically generate C++ code that uses macros, classes, and templates in such a way that no one can read or hope to edit the code.
Microsoft has in a way given up on C++ for UI code with their C# language -- I think of it as Delphi, a highly Windows UI-oriented language that is a long way from its Pascal roots, with C syntax. On the other hand, the Windows forms side of Delphi configures widget properties by serializing objects to a resource file (the .dfm file that gets folded into the .exe when you compile) while C# .NET reverts to generating code to set property values. Then they try to hide that code in the editor. Maybe they think that is more efficient.
I think that it would be useful to have both charts and automatically generated C++ code in a modeling tool the charts and C++ were two different ways of looking at the exact same thing -- in a CAD tool for hardware, you could have a circuit diagram and a text net list. For this to be useful it is essential that they have a good round trip capability -- if you edit the C++ you don't lose the ability to get back to the charts. It would be helpful if the generated C++ code were readable. It could be verbose, that you wouldn't want to generate it by hand, but it would help alot that you could safely edit it if you wanted to.
It would be nice to be able to run your program before you have written it. For example:
We start the program running at prompt 2, write it at prompt 3 and 5, and get the answer, 112, after 6.
This would help with one off calculations, and with refining requirements via exploratory programming. I think the issue is more of a culture/management/training thing, rather than technical difficulty.
I love using code generation. About 9 months ago, I wrote an object oriented data access layer generator for .net. The code it made was somewhat messy, but the interfaces were clean, and it saved me a lot of time. Even more importantly, all of the manually written code was much more readable as a result of the extremely standard OO data access libraries. I heard the next version of .net was supposed to come with some kind of code generation for data access layers in the standard tools.
About four months ago, I discovered PHP/Pear's DB_DataObject which is pretty cool. It is missing some features I had in mine, but it makes up for it by being incredibly easy to use. Now I've set up a protected page on our website at work that allows anyone to regenerate the entire data access layer at the click of a button. I hardly ever have to write sql and, more importantly, it makes things much easier on the programming light-weights.
As a software engineer, i would ask one question first: What is it that makes our job difficult, what needs to improve?
I start from the ideal situation: If i know what to do - the requirements - i want to just make it happen. An ideal software tool would allow me to go straight from specs to a prototype.
I would estimate about 50% of the current total project time is spent developing specifications - the process of figuring out what exactly the customer wants. Even though that's probably the first thing taught in SE 101, i rarely see it done in practice. Software people don't listen, and the customers don't know any better. Note: Before you can implement a business solution, you must develop a full and deep understanding of the business process. Before starting the implementation.
All we can hope for in a realistic software tool is to save the other 50%.
Eclipse was a major step in terms of productivity, and i think it mostly works because even though it does a lot of stuff for you, you can always go in and text-edit something. Good tools are both transparent and powerful.
As for Rational tools: Power without transparencyt. I won't touch them with a 10 foot pole. They are great if you want to get away with failure (as you can point to them and claim that you used the best tools available), but if you are interested in developing great products - no way. It is the wrong solution for the problem.
What i want as a developer is very simple: I want the shortest path from conception to implementation, from idea to program. I don't want the tool to help me with the idea because it just won't work. Also, spending a lot of time talking to the customer and listening and tormenting them with questions is surprisingly easy.
When i implement things i try to automate everything that can be automated, but in Eclipse/Java, at least, i still end up with 80% of my time wasted on silly things. These i want a tool to take care of for me, preserving transparency at the same time.
To the Emacs/Java hard-core people: Get over it and use Eclipse. You can set it to Emacs keyboard shortcuts, You can bind in external programs with ANT, incorporate python for code generation, and last not least use all the great time-saving and quality-improving tools that are built in. And all of it completely transparent and free of charge.