Comments on Moserware: Towards Moore's Law Software: Part 1 of 3

dave (I assume your David Bacon that Wikipedia's <...

2009-05-31T14:10:14.575-04:00

dave (I assume your David Bacon that Wikipedia's SETL page mentions?:

Thanks for stopping by! I agree that set theory in applications like SQL is a really good language for data. I'd have to see more of SETL to see other types of applications.

I'm curious if you read part 3? Is it possible to do something like the small TCP implemention in SETL?

By the way, there is a universal language of mathe...

2009-05-18T20:47:00.000-04:00

By the way, there is a universal language of mathematics. It is called set theory. SETL, a language based on set theory, was created in 1970. I worked on it for over a decade.

I'm not writing a compiler for it from scratch that will translate SETL to machine code. The Python to machine code compiler is being done as part of this work.

thanks,dave

Steve: Very thoughtful comments. Thank you!

2008-04-14T22:10:00.000-04:00
Steve: Very thoughtful comments. Thank you!

I'm interested in what your thoughts will be regarding part 3 where I discuss some actual examples of what I'm thinking of.

You make a good point that components can help; indeed, COM helped some towards this goal with VB.

However, I still think that components can only go so far. For example, look at how much you have to write in C++ or C# to say "Hello World." Certain languages require a set of boilerplate code that is effectively 'goo.' The program language designers defend this saying that as the program grows bigger the goo is amortized over more code.

Thanks again for the comment, especially the 3 things to balance that you mentioned.

Programs are a balance between
1) finding the r...

2008-04-14T15:04:00.000-04:00

Programs are a balance between
1) finding the right abstractions
2) being able to respond to future changes
3) getting it working ASAP

Short-code typically has (1) and (3) well-solved, but it does not necessarily handle (2) very well. In addition, some languages are more suited to particular types of abstractions - therefor it is no surprise that they can be shorter. As you noted, there is no perfect language - the brevity for one task will make another task impossible.

(1) and (2) are the domain of software architecture - which is a black art at this stage of our evolution. Languages are only relevant in as much as they fit a particular abstraction, and are supportable.

(3) is interesting to me too, because it often occurs in the absence of architecture (and testing and all-round good sense). Nevertheless, it is sometimes best to avoid architecture in the interests of "getting it done". Your 6x example of Java code being long is an example of (3). It is long because it was written to get out the door ASAP.

With more thought, you *could* write the Java code shorter - by inventing similar abstractions to those that Scheme had, and encapsulating them in a library (Put the goo somewhere else). Overall, the code would have been even longer, but the parts relevant to the specific problem would have been short, probably even shorter than the Scheme version.

That was the genius of Visual Basic - it did not matter that you could not write certain types of code. Someone else would always write a component that did it for you. You could avoid the goo.

Comments on Moserware: Towards Moore's Law Software: Part 1 of 3

dave (I assume your David Bacon that Wikipedia's <...

By the way, there is a universal language of mathe...

Programs are a balance between1) finding the r...

Programs are a balance between
1) finding the r...