Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software development approaches (views and opinions) Bjarne Stroustrup AT&T Labs – Research

Similar presentations


Presentation on theme: "Software development approaches (views and opinions) Bjarne Stroustrup AT&T Labs – Research"— Presentation transcript:

1 Software development approaches (views and opinions) Bjarne Stroustrup AT&T Labs – Research

2 My perspective Researcher –Research manager –Programmer/designer –Teacher –Consultant (not on a fee basis) C/C++ community Unix/Windows Systems programming / embedded systems Not primarily –IT –Production –Applications

3 Overview Generalities Tool chains –Project-focused discussion Programming techniques –C++ based (that’s what I know best) Standards –Everybody got a few So what can we do to make progress? –(provocative horror show – it’s Halloween)

4 Generalities Our civilization runs on computers –More and more of a computer is software –More and more of our environment contain computers –We need More software Built in less time More reliable With more “features” –“High tech” v.s. “Cheap labor” Curious trends: lots of “tech” with expensive labor Because software is crucial, money talks (shouts!) –Makes it hard to make technical decisions

5 Communities The software development community has fractured –Web designers –VB programmers –Analysts/designers –Traditional skilled programmers –C/free-software hackers –Academic FP-community –Licensed company X internals specialists –… These groups don’t understand each other’s languages, tools, and work methods –Each group has sub-groups who don’t understand each other’s languages, tools, and work methods E.g. C, C++, Java, Ada –This is not just specialization Tower of Babel

6 Modularity and communication “separating things are easy” –It’s having separate entities communicate that’s hard Have “reuse” succeeded or failed? –Certainly the hype was wrong (surprise!) –Huge components Compilers, operating systems, communications packages –Tiny components subroutines –Medium-sized components This is where it gets interesting/difficult Plug-ins, some CORBA objects, some COM components, libraries

7 Buzzwords “Objects” –are not everything (I promised you that they wouldn’t be ) –Are useful in their proper roles IDLs (Interface Definition Languages) –Try to become systems development platforms Data definitions, actions, … Language independence –reduces expressiveness, has binding costs –A language independent language is an oxymoron Integrated development environments –Monoliths, proprietary, try to do everything for everybody

8 Tool chains I love ascii! (unicode is also ok) –Human readable and writeable –Key to modularity –Hard to make proprietary Examples –Unix intermediary formats –HTML –XML –Postscript –Source code

9 A common, simple, problem Simple distributed computing –No shared memory –No real master –Some communication asynchronous –Sometimes communications fail –Sometimes modules fail One module Another module A third module

10 A common, simple, problem Pick a module/communication system –CORBA, COM,.net, Java, … Now, have you chosen? –Programming language –Vendor –Performance limits –Database system –Development platform –Hardware supplier –Education for your developers –Culture –…

11 XTI/XPR Related problems –Programming distributed systems Marshalling/unmarshalling Multitude of IDL “standards” Poor C++ bindings –Serialization –XML reading/writing –Program manipulation

12 Distributed programming in ISO C++ “as similar as possible to non-distributed programming, but no more similar” // use local object: X x; A a; std::string s("abc"); // … x.f(a, s); // use remote object : remote_proxy x; x.connect("my_host"); A a; std::string s("abc"); // … x.f(a, s);

13 Program manipulation: XTI/XPR C++ source C++ compiler Symbol table XPR generator XPR RPC generator Object code XTI IDLXML XTI

14 XPR struct B { int xx; }; Char* f(const int *); template struct D : private virtual B, protected B2 { int zz; char* (*f)(int); list > lst; }; B : class { xx : int public } f : (:*const int) *char D : class { #base : B virtual private #base : B2 protected zz : int public f : *(int) *char public lst : list > public } C++ sourceXPR

15 XPR (eXternal Program Representation) Easy/fast to parse Easy/fast to write Compact Robust: Read/write without using a symbol table LR(1), strictly prefix declaration syntax Human readable Human writeable Can represent almost all of C++ directly –No preprocessor directives –No multiple declarators in a declaration –No, >>, or << in template arguments, except in parentheses Can be thought of as a specialized portable object database Why not “simply XML”? –Bootstrapping –Tool chain

16 Programming Programming really is an interesting topic –techniques Programming languages do differ –Syntactic differences are quite uninteresting But syntax is the focus on religious wars –Programmers do only what they can express directly Libraries Distribution Teaching

17 Uncompromising performance

18 Matrix optimization example struct MV {// object representing the need to multiply Matrix* m; Vector* v; MV(Matrix& mm, Vector& vv) : m(&mm), v(&vv) { } }; MV operator*(const Matrix& m, const Vector& v) { return MV(m,v); } MVV operator+(const MV& mv, const Vector& v) { return MVV(mv.m,mv.v,v); } v = m*v2+v3; // operator*(m,v2) -> MV(m,v2) // operator+(MV(m,v2),v3) -> MVV(m,v2,v3) // operator=(v,MVV(m,v2,v3)) -> mul_add_and_assign(v,m,v2,v3);

19 Function Objects Function objects –Essential for flexibility –Efficient in practice, more so than inline functions important: sort() vs. qsort() –Some find them tedious to write Standard function objects –e.g., less, plus, mem_fun Can be automatically written/generated –Vector v2 = m*v+k;// matrix and vector libraries –find_if(b,e, 0

20 Object-oriented Programming Hide details of many variants of a concepts behind a common interface void draw_all(vector & vs) { typedef vector ::iterator VI; for (VI p = vs.begin(); p!=vs.end(), ++p) p->draw(); } Provide implementations of these variants as derived classes

21 Class Hierarchies One way (often flawed): class Shape {// define interface and common state Color c; Point center; // … public: virtual void draw(); virtual void rotate(double); // … }; class Circle : public Shape { /* … */ void rotate(double) { } /* … */ }; class Triangle : public Shape { / * … */ void rotate(double); /* … */ };

22 Class Hierarchies Shape CircleTriangle Users

23 Class Hierarchies Fundamental advantage: you can manipulate derived classes through the interface provided by a base: void f(Shape* p) { p->rotate(90); p->draw(); } You can add new Shapes to a program without changing or recompiling code such as f()

24 Class Hierarchies Another way (usually better): class Shape {// abstract class: interface only // no representation public: virtual void draw() = 0; virtual void rotate(double) = 0; virtual Point center() = 0; // … }; class Circle : public Shape { Point center; double radius; Color c; /* … */ }; class Triangle : public Shape { Point a, b, c; Color c; / * … */ };

25 Class Hierarchies Shape CircleTriangle Users

26 Class Hierarchies One way to handle common state: class Shape {// abstract class: interface only public: virtual void draw() = 0; virtual void rotate(double) = 0; virtual Point center() = 0; // … }; class Common { Color c; /* … */ };// common state for Shapes class Circle : public Shape, protected Common{ /* … */ }; class Triangle : public Shape, protected Common { / * … */ }; class Logo: public Shape { /* … */ };// Common not needed

27 Class Hierarchies Shape CircleTriangle Users Common Logo

28 Multiparadigm Programming The most effective programs often involve combinations of techniques from different “paradigms” The real aims of good design –Represent ideas directly –Represent independent ideas independently in code

29 Algorithms on containers of polymorphic objects void draw_all(vector & v)// for vectors { for_each(v.begin(), v.end(), mem_fun(&Shape::draw)); } template void draw_all(C& c)// for all standard containers { for_each(c.begin(), c.end(), mem_fun(&Shape::draw)); } template void draw_all(For first, For last)// for all sequences { for_each(first, last, mem_fun(&Shape::draw)); }

30 Vintage 1997 slide Our suppliers prefer us to use their proprietary languages

31 Standards Formal standards –ISO, IEEE Consortia –CORBA, W3C Corporate –Microsoft, Sun Users are always underrepresented

32 What can we do to make progress? Computer science –Hasn’t had a Copernicus, a Galileo, a Tycho Brahe, or a Newton No accepted basic model of our works No accepted standard for what an experiment is No accepted standard for measurement No predictive integration of experimental results and math –Hasn’t had a Hippocrates No accepted definition of professionalism As a science or an engineering discipline –We lack a shared scientific foundation –We lack a shared base of established practice –We lack a shared culture (history, heroes)

33 What can we do to make progress? Huge gaps between “academic” understanding and industrial practice –Much effective software development is cottage industry and craft –“best practices” are often defeated in fair competition –Marketing dominates –Non-system builders make crucial technical decisions Without acknowledging that the decisions are technical Huge variation between different groups doing similar projects –Tools (incl. Languages) –Techniques –Sociology (separation of tasks, management style)

34 What can we do to make progress? We must measure and classify –Measure things that are meaningful and useful –Develop the ability to predict We must develop tools for measurement –Performance –Complexity –Reliability –Effectiveness of techniques –… Who might be able to do this? –Academia: no (doesn’t have the right problems) –Industry: no (doesn’t have the freedom to experiment) –Industry and academia: maybe –Genius needed (methodologists cannot be primary) It’s going to take far longer than we would like

35 What can we do to make progress? Actually, I’m mostly an optimist –Because we are making progress But I’m less of an optimist than I used to be –Education Better educated people drowned by the half-educated Marketing dominance of much education Training Academic disengagement from real-world problems –Programming languages Much code in “Pidgin-C” Much emphasis on the half-educated –Design Still lack of feedback Process obsession –Tools Often drown us in incidental complexity –Science I’m still waiting


Download ppt "Software development approaches (views and opinions) Bjarne Stroustrup AT&T Labs – Research"

Similar presentations


Ads by Google