On this topic, I'm not a big fan of the premade Lego sets for Star Wars or Harry Potter or whatever. Kids need the generic box of bricks and plates.
Actually, a decent percentage of pieces in the Star Wars sets are standard generic pieces. Yeah, you get some of the ultra-modern custom ones, along with some semi-modern non-traditional ones, but they don't take away from the fun factor any, IMO.
I'm not claiming silver bullet status. Far from it. I'm simply stating that software engineering requires contracting and better interface design techniques as part of its standard repetoire. Add these to the hard work and discipline you mention.
Reusable, reliable, quality software begins with the interface. If someone cannot tell what a routine or module does with just a quick read, then all is lost. They'll cease to believe what the documentation (if any) says, and go on to write it themselves.
The solution is better interface design. Clear, concise naming without ambiguity. And including the specification is absolutely necessary. With the contract included as part of the interface, there is even less chance for error and/or any ambiguity. Testing is aided because the rules for calling a routine are right there with the routine interface and comment.
Unfortunately, most programming languages refuse to support contracting in any form, and most developers don't see the benefits. Until this hurdle is breached, quality software will not be achieved.
The Flamingo Kid was the first movie given a PG-13 rating, but it sat on the shelf for a few months before it was released. See the trivia page for Red Dawn on IMDB.
Perfect game means no one reached base. You could actually pitch a perfect game in 27 pitches, all first pitch hits. This is why pitch count doesn't matter.
I've always enjoyed the superior edit-rerun cycle that comes with many interpreted languages. You bang out a few lines of code, hit return and see the results immediately.
You can get close to this with compiled languages that use incremental compilers, like the Eiffel compiler from Eiffel Software. You still have to hit the Compile button (it's an IDE), but it will only compile what it has to. If you've only changed a line or two, the compile step could flash right by. The compiler is even good enough to figure out what has been affected by your change, and only compile those portions (even if they are just at the routine level). All this without a make file, no less.
Then, when you're ready to ship, you compile to native code (the above is more or less interpreted), with full optimizations on, and you're set.
The extra benefit comes when you've got a lot of existing code that may or may not be affected, even in small ways, from your new work. Compiles might take a while in traditional systems, but they don't have to if your compiler is smart enough. All that saved time can add up.
Generics weren't innovated in C#. The syntax is semi-borrowed from C++, while the constraining capability was borrowed from Eiffel. Both languages had this capability before C#, while Eiffel had it before C++.
So you like writing container classes for every possible type that could go into one? Yeah, that's the way to do it. None of this saving time and getting reusability in the horizontal (with inheritance being in the vertical). Why would someone do that?
And there are techniques to get better performance with generics, it's just that the C++ compiler camp hasn't found them yet.
And isn't Lisp effectively a typeless language, or at least dynamically typed? Generics are actually there by default then.
He may not refuse, but he's been adamant that DbC isn't needed. That's where he's missing the point of DbC.
And why isn't my proposal there? Because I don't like C++, I just use it at my work. I'm an Eiffel guy, which is where my outlook on DbC comes from. Once you go DbC, you don't like having to go back.
It's worse on my current project at work, where it's obvious they've never heard of anything like placing the specification into the interface, and people are breaking class rules left and right because they're not sure what's what.
He's discussing class invariants, and how they help one design interfaces, and how they must be maintained. But he's refused to put that into C++! For years he'd been asked about adding some form of contracting to the language, but he'd always come back with how that's not needed. (I always thought part of it was due to his hatred of Bertrand Meyer (of Eiffel fame)).
Has he now seen the error of his ways? Is contracting (in any form other than assert) going to get added to C++?
That price includes the compiler, automatic dependency tool (like make, but way better), editor, debugger, CASE tool, metrics tool, profiler, etc., all in one fairly slick IDE. A GUI builder is also included.
And that price is for the commercial version, which means you can sell what you've created. The license on the free version says that you can't sell anything you've created. Also the GUI builder with the free version is simply a demo.
To start with, DBC in Eiffel is at the interface level. Asserts in C/C++/Java are part of the code, and are not visible when you extract just the interface. They are in Eiffel.
Second, DBC in Eiffel integrates with inheritance. Contracts are inherited along with their routines, and there are rules for how they can be modified.
Also, when contracting is turned on in Eiffel, the calls only go one level deep. That is, when a routine is called, it's contract is tested. If the contract contains a routine call, that routine will get executed, but the contract on that next routine will not. Saves time and eliminates potential infinite recursion. Not the same with asserts in C/C++, which will get executed until no more are available to call.
Finally, DBC does connect with exceptions. When they are turned on, and one fails, an exception is thrown and the IDE will kick in the debugger on that point. The DBC paradigm lets you determine whose fault it was (caller or callee), and lets debugging go much smoother. When DBC is off, no exception will be thrown, and behavior is technically undefined. There was discussion on the ISE Users Group on Yahoo recently about how exceptions and contracts relate, mainly from a Java/JML point of view.
You can in Eiffel. Contracts can (and should) go anywhere.
Re:Chips, Dips, Taco and the Dot
on
Slashdot Turns 5
·
· Score: 1
Do I remember the days of 'Chips n Dips'? Shoot, my bookmark for this site still says that! That's how long I've been here. (This isn't my first account, and I didn't get one right away).
Slashdot Mirror
On this topic, I'm not a big fan of the premade Lego sets for Star Wars or Harry Potter or whatever. Kids need the generic box of bricks and plates.
Actually, a decent percentage of pieces in the Star Wars sets are standard generic pieces. Yeah, you get some of the ultra-modern custom ones, along with some semi-modern non-traditional ones, but they don't take away from the fun factor any, IMO.
Steve
I'm not claiming silver bullet status. Far from it. I'm simply stating that software engineering requires contracting and better interface design techniques as part of its standard repetoire. Add these to the hard work and discipline you mention.
(Also note these are not tools, but techniques.)
Reusable, reliable, quality software begins with the interface. If someone cannot tell what a routine or module does with just a quick read, then all is lost. They'll cease to believe what the documentation (if any) says, and go on to write it themselves.
The solution is better interface design. Clear, concise naming without ambiguity. And including the specification is absolutely necessary. With the contract included as part of the interface, there is even less chance for error and/or any ambiguity. Testing is aided because the rules for calling a routine are right there with the routine interface and comment.
Unfortunately, most programming languages refuse to support contracting in any form, and most developers don't see the benefits. Until this hurdle is breached, quality software will not be achieved.
Steve
--
The Flamingo Kid was the first movie given a PG-13 rating, but it sat on the shelf for a few months before it was released. See the trivia page for Red Dawn on IMDB.
Perfect game means no one reached base. You could actually pitch a perfect game in 27 pitches, all first pitch hits. This is why pitch count doesn't matter.
I think you mean all first pitch outs.
I've always enjoyed the superior edit-rerun cycle that comes with many interpreted languages. You bang out a few lines of code, hit return and see the results immediately.
You can get close to this with compiled languages that use incremental compilers, like the Eiffel compiler from Eiffel Software. You still have to hit the Compile button (it's an IDE), but it will only compile what it has to. If you've only changed a line or two, the compile step could flash right by. The compiler is even good enough to figure out what has been affected by your change, and only compile those portions (even if they are just at the routine level). All this without a make file, no less.
Then, when you're ready to ship, you compile to native code (the above is more or less interpreted), with full optimizations on, and you're set.
The extra benefit comes when you've got a lot of existing code that may or may not be affected, even in small ways, from your new work. Compiles might take a while in traditional systems, but they don't have to if your compiler is smart enough. All that saved time can add up.
Generics weren't innovated in C#. The syntax is semi-borrowed from C++, while the constraining capability was borrowed from Eiffel. Both languages had this capability before C#, while Eiffel had it before C++.
Steve
So you like writing container classes for every possible type that could go into one? Yeah, that's the way to do it. None of this saving time and getting reusability in the horizontal (with inheritance being in the vertical). Why would someone do that?
And there are techniques to get better performance with generics, it's just that the C++ compiler camp hasn't found them yet.
And isn't Lisp effectively a typeless language, or at least dynamically typed? Generics are actually there by default then.
Steve
He may not refuse, but he's been adamant that DbC isn't needed. That's where he's missing the point of DbC.
And why isn't my proposal there? Because I don't like C++, I just use it at my work. I'm an Eiffel guy, which is where my outlook on DbC comes from. Once you go DbC, you don't like having to go back.
It's worse on my current project at work, where it's obvious they've never heard of anything like placing the specification into the interface, and people are breaking class rules left and right because they're not sure what's what.
Anyway, I'm just ranting.
He's discussing class invariants, and how they help one design interfaces, and how they must be maintained. But he's refused to put that into C++! For years he'd been asked about adding some form of contracting to the language, but he'd always come back with how that's not needed. (I always thought part of it was due to his hatred of Bertrand Meyer (of Eiffel fame)).
Has he now seen the error of his ways? Is contracting (in any form other than assert) going to get added to C++?
That price includes the compiler, automatic dependency tool (like make, but way better), editor, debugger, CASE tool, metrics tool, profiler, etc., all in one fairly slick IDE. A GUI builder is also included.
And that price is for the commercial version, which means you can sell what you've created. The license on the free version says that you can't sell anything you've created. Also the GUI builder with the free version is simply a demo.
~Steve
To start with, DBC in Eiffel is at the interface level. Asserts in C/C++/Java are part of the code, and are not visible when you extract just the interface. They are in Eiffel.
Second, DBC in Eiffel integrates with inheritance. Contracts are inherited along with their routines, and there are rules for how they can be modified.
Also, when contracting is turned on in Eiffel, the calls only go one level deep. That is, when a routine is called, it's contract is tested. If the contract contains a routine call, that routine will get executed, but the contract on that next routine will not. Saves time and eliminates potential infinite recursion. Not the same with asserts in C/C++, which will get executed until no more are available to call.
Finally, DBC does connect with exceptions. When they are turned on, and one fails, an exception is thrown and the IDE will kick in the debugger on that point. The DBC paradigm lets you determine whose fault it was (caller or callee), and lets debugging go much smoother. When DBC is off, no exception will be thrown, and behavior is technically undefined. There was discussion on the ISE Users Group on Yahoo recently about how exceptions and contracts relate, mainly from a Java/JML point of view.
~Steve
You can in Eiffel. Contracts can (and should) go anywhere.
Do I remember the days of 'Chips n Dips'? Shoot, my bookmark for this site still says that! That's how long I've been here. (This isn't my first account, and I didn't get one right away).