search
Login | Signup | Support
  • 0
  • ×

    Add as FriendSoftware development approaches

    by: Rogers

    Current Rating : Rate It :

    291

    Views

    Download
     
    1 : Software development approaches(views and opinions) Bjarne Stroustrup AT&T Labs – Research http://www.research.att.com/~bs
    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 IDL XML 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< vector > 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++ source XPR
    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 Circle Triangle 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 Circle Triangle 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 Circle Triangle 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

    Presentation Tags

    Copyright © 2019 www.slideworld.com. All rights reserved.