OSNews

"As prototype based programming languages become fashionable again we may yet see some very interesting integration of revision control systems with exploratory development environments. "

Not just that, also how well it will be able to fit into the rest of the software development process. Software development is still wrestling with the issues between "I have an idea" and "here, code this up".

The benefits of fixing the program while its running are not limited to prototype-based languages. Class-based languages like Lisp and Smalltalk have been doing these things for years. What's really needed for this sort of thing is not a prototype-based language, but a language runtime that is tightly integrated with both the source code and the compiler. That way, when the source code is edited, the compiler is invoked to generate new machine code, and the runtime makes sure that the appropriate references are updated.

4,5,6,10 and 12 can be solved on debian thusly:

apt-get source <packagename>
dpkg-buildpackage
dpkg -i <.deb file>

I'm sure you can use srpms to do the same thing.

-Mark

Not if you have Woody in you source list. You'll be waiting a looong time

As much as I hate those "our goober solves that problem"-type posts, our goober -- DTrace -- does solve this particular problem, or at least Step 7 of it. DTrace can quickly point you to the errant problem in a running app (or collection of apps) without recompiling, relinking or restarting it -- usually so quickly and concisely that fixing it becomes the more difficult part. We have used DTrace with great success to find problems in gigantic software systems. More details on DTrace are here: http://www.sun.com/bigadmin/content/dtrace

Alternatively, you can look at the OSNews story on DTrace: http://www.osnews.com/story.php?news_id=5160

- Bryan

---------------------------------------------------------------------- ------
Bryan Cantrill, Solaris Kernel Development. bmc@eng.sun.com (650) 786-3652

Umm... Lisp Machine anyone?

I would have to disagree here. What you propose would be handy, but it still wouldn't fix the heart of the problem - The old fashioned try, test, debug, rewrite loop wouldn't be broken. The importance of prototype based languages over what you suggest would be the Dijkstra inspired top-down, post-condition, to specification, & {via recursive step-wise refinement} to eventual code generation. Even this though wouldn't suffice. Instead, it would lay the ground work for a tight coupling between prototyping & formal methods. What we need is a language in which we can write a specification & via stepwise refinement simultaneously generate the code & a proof of correctness. As long as we are stuck in the test & debug loop we can never guarantee that our code will always work. We need a mathematical approach that can prove the code is correct. Formal methods formal methods formal methods!

I really don't see how prototype-based languages address your concerns about top-down design. My comment was in response to the fact that the author attributed runtime modfication of code to prototype-based programming languages, while in reality it is attributable to any of the languages that have more highly-evolved runtimes.

As for your comments about formal methods, I (along with many others) am not a big believer in them. Alan Kay once said:

"Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects."

I don't believe we have gotten to a point where we can reliably and easily treat complex software with a mathematical level of rigour. The tools we do have today often sacrifice expressiveness for precision, which I consider an unacceptable trade-off. In the end, it comes down to the fact that the science of software development (as opposed to computational theory) is underdeveloped. Engineers in other fields have all sorts of formal methods for treating large, complex systems with a mathematical level of precision, and good tools to automate that process, but software developers do not. Until such tools are invented, I agree with Alan Kay that the next best thing is an extremely dynamic environment that allows for iterative, incremental devlepment.

but a language runtime that is tightly integrated with both the source code and the compiler

Maybe some ultra-JIT system could do that, but don't we really want some sort of uber-repository that can do a lot more that just slow down our execution?
Maybe IBMs integration of Eclipse with UML will be a step in the right direction...

ReactoGraph is an example of another visual prototype-based language that also uses message-passing and visual data flow programming...

http://www.cs.dal.ca/~gauvins

Enjoy!

This is why open source will never work. No one wants to spend time to make a serious, high performance program for free.

Eh? You don't need a JIT. Most such systems have native-code compilers. You do pay a 10-20MB memory overhead, for having the compiler integrated into the runtime, but a good implementation will stuff that into a shared library so you only have to pay it once.

To get a taste of what such development environments can do, there are a number of products you can check out. There is:
IBM's Visual Age Smalltalk: http://www-306.ibm.com/software/awdtools/smalltalk/
Dolphin Smalltalk: http://www.object-arts.com/
Cincom's VisualWorks: http://smalltalk.cincom.com/index.ssp

All of these have free demos that you can play with.
Lately, I've been playing with Functional Developer, an interactive IDE for Dylan. They've got a free basic edition IDE for Windows.
http://www.functionalobjects.com

Check out their debugging manual available:
http://www.functionalobjects.com/products/doc/env/env_100.htm

It does some really nifty stuff. You can do things like catch an exception, edit the offending methods or classes, and restart from where the exception was thrown. You can also run more than one program at the same time under the debugger, to make it easier to debug synchronization issues between client/server programs.

The window of innovation only opens every few years.

Java crept in just as it was clear C++ was too complex. The window only stayed open for a year or so. Python was too late. Try again in five years.

Linux waltzed through the door to innovation just as the old unixes died and Windows looked around for any competition. SkyOS was too late. Maybe in a decade the door for a new OS will open again.

I'm not trying to be a troll - I'm serious in stating that you cannot hope to re-seed the marketplace with a new tool or method when that market has already picked the next model and has not found fault with it (yet).

The window for a new methodology of programming languages is not open. The Java/C# model, as repugnant as it might be, will need to run its course for another few years before people seriously start looking for alternatives. Frankly trying to push an alternative at this point is a waste of time, as is trying to push a linux alternative.

Rayiner Hashem quoted Alan Kay:

"Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects."

I find this strange. In my experience, the earlier the binding happens, the fewer chances for errors.

Furthermore, you can get a long way towards more maintainability and fewer bugs by adopting a good coding style. I'm not talking about rules about where to put your braces and spaces, but start by coding what you want done, and defer coding how to as late as possible. Generic programming helps here, and you can start working in this way today with C++.

I've explored a couple of packages using netbeans for java and the debugging tools address some of the problems, notably about understanding the what code does what behaviour....

The packages had visibly been coded using netbeans so that did help..

When you're using a prototype based language you can edit objects as they're running.

mh.. you mean something like:
if var
def object.method
..
end
end
else
def obj2.meth()
..
end
end

or you mean Object.define_method(code)? Or similar mechanism in ruby, smalltalk, python, CLOS..

There is no separate compilation step,

Oh so you mean an interpreted language..

and your program is always running.
..or an *image based* language. SmallTalk had this for looong time, this does not relates anyhow with prototypes.

As prototype based programming languages become fashionable again we may yet see some very interesting integration of revision control systems with exploratory development environments.

You never took a look at Squeak, right? never heard of monticello? Guess what? Squeak has open/always running/editable objects. And it has a versioning system built on his architecture. Like any other SmallTalk system.

I can't understand how prototypes have a role in this article.

"""but start by coding what you want done, and defer coding how to as late as possible. Generic programming helps here, and you can start working in this way today with C++. """
I've found that only works when you can design the whole system top to bottom and you have relatively static requirements. In most cases, an over all design, a data structure design, and a bottom up design seem to give a better success rate (anecdotally). As for generic programming in C++, yuck, ML derivitives offer a much better alternative.

As a hobbyist hacker, I shudder to even consider looking at C/C++ or even Java source code of a large project to find a particular bug. What would significantly help me overcome this hurdle would be if there were some good, documented UML for the software in question, in particular, class diagrams and maybe some sequence diagrams, and use case diagrams).

People are good at 'talking' the benefits of modelling, best practises development processes and design patterns. It's time people start 'walking' what they're 'talking'. Let's see some UML for Apache, Mozilla Firebird, MySQL, and even parts of the Linux kernel, Xfree86, bash, and such, with an emphasis on those areas most likely to be contributed to and/or bug-fixed by the community.

There is a saying in the Lisp community --- languages don't just determine how you express solutions to your problems, but how you think about your problems. The whole idea of late-bound languages, as Alan Kay refers to, is that they make it easy to think about your problem with code.

Solving "hard" problems in static languages is usually a chore. You have to deal with all sorts of requirements that having nothing to do with solving the problem. You have to specify types, for example, even though they just get in the way of refactoring your code. Thus, you have to think independently of the language, and once you think you've got a solution, implement it in the language.

However, many problems are much easier to think about when you have the computer to help. You can 'think' by prototyping in a late-bound language. You can toy with your ideas immediately, and quickly build working prototypes. Because of the ease with which dynamic code is refactored, that prototype can be easily turned into production code, so that effort is not wasted, and no bugs are introduced in rewriting the prototype.

Its a matter of top-down vs bottom-up development. In the former model, the computer doesn't help you solve your problem, it just offers a way to express the solution. In the latter model, the computer is an active partner in the problem-solving process. In the former model, you often have to write a significant amount of code to the spec before you can get any of it to work. In the latter, you start with at tiny core program, and gradually refactor and build it up, keeping it working the whole time. Its the whole idea of iterative development, which is taking off in extreme programming circles these days. There is a nice article about the history of ID here:

http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf

I've seen a few comments thus far that have basically amounted to "Smalltalk can do that!!" Clearly Smalltalk (and LISP) is the grandfather of runtime editable objects, but in the same breath that I mentioned runtime editability I also mentioned program understanding. In particular:

The software is easier to understand because you're not looking at it from above, you're in there with the objects telling them how they should behave. In a class based object oriented language like Java or C++ you're telling classes how they should tell objects to behave.

That applies to Smalltalk also. The level of indirection from programming a class and then instantiating that class is simply too great for runtime editing.