A Possible Future of Software Development
HTML-код
- Опубликовано: 19 май 2008
- Google Tech Talks
July, 25 2007
ABSTRACT
This talk begins with an overview of software development at Adobe and a look at industry trends towards systems built around object oriented frameworks; why they "work", and why they ultimately fail to deliver quality, scalable, software. We'll look at a possible alternative to this future, combining generic programming with declarative programming to build high quality, scalable systems.
Speaker: Sean Parent
Sean Parent is a principal scientist at Adobe Systems and engineering manager of the Adobe Software Technology Lab. One of his team's current projects is the Adobe Source Libraries
The term Generic Programming was first coined in the paper: "Generic Programming", Musser and Stepanov '88. It is the process of defining algorithms and data structures in terms of the axiomatic properties of types and their operations rather than on specific, concrete, types.
Declarative programming is defining a program in terms of rules and constraints rather than specify an imperative sequence of actions.
Both constitute programming at a higher level of programming than is common today.
I know its been years past, but I am compelled to comment on this very important subject. [1] I think your approach and support of 'generic programming' as a fundamental is a good one. For, as you observe, much of the technology in CS (including hardware) really do possess a common root system (pun not intended). Service orientation, workflow, concurrency, grid computing, robotics (and any MOM), any form of networking (like network axiom) all share immense commonality, in principle.
Agreed. The video is a great case study on how to build a quality reusable library/framework.
Kudos to you and everyone involved to make ASL open source in MIT license. I'm one of the fortunate (paid) open source developers as well.
My original comment meant to point out that the title of the video might be a bit misleading to people who're expecting new methodologies and/or new tools/languages.
(cont.) Indeed developers must change the way to think about software code and design. We can thank the multi-core shift for that. The biggest primitive of all to manage is data vs messaging, which yields behavior. OOP is a nice paradigm for modeling data, but not as readily for modeling messaging. They must be married to be effective. Service orientation offers much to this problem but I think its a deeper problem. We need more primitives (software and hardware) to deal with these things.
@jgoemat "last" refers to the last position, not element, in the array, so yes, one past the last item. By convention this interval is denoted [first, last). For an array of n elements there are n+1 possible positions and n+1 possible results for lower_bound. The return value is the first place the element being searched for could be inserted without violating the ordering. This is an algorithm in the C++ standard library.
@ProphetVS concrete class with template constructor taking an arg of any T and holds the arg via type-erasure. Operations on the held arg are done through free-functions found via Argument Dependent Lookup.
This sounds a great deal like why Erlang uses functional programming (no side effects) and actor-based messaging. A spreadsheet is the most common sort of functional programming. You have established a sort of analogy between a spreadsheet, a DAG and your programming tasks. It seems like this suggests that we are going to see more functional programming. Time to brush up on Lisp/Scheme/Clojure, Erlang, Scala or F#.
@jgoemat The range is a semi-open interval. So you would call this as:
int a[] = {0, 1, 2};
int* p = lower_bound(&a[0], &a[0} + 3, 2, less());
The result for searching for 2 will be "&a[0]+2" and searching for 3 will be "&a[0]+3". The later being the end of the array so it would be invalid to dereference the pointer.
Sorry - I haven't been monitoring the questions here. Paper mentioned (incorrectly attributed to Doug Gregor - who's done other good work) is:
Ronald Garcia, Jaakko Järvi, Andrew Lumsdaine, Jeremy Siek, and Jeremiah Willcock. An Extended Comparative Study of Language Support for Generic Programming. Journal of Functional Programming, 17(2):145--205, March 2007
As with geometry, there is no royal road to computer science. It is a challenge to the industry to learn to collect our knowledge into (re)usable components and the responsibility of every professional engineer and scientist to contribute.
This is what Dijkstra said software development should be!
It's still the same old approach to software engineering though: look at a class of specific problems to see if it can be solved by a more general solution, which is basically a reusable library. By properly limiting the scope and expressiveness of the library via a DSL, you reduce the probability of errors. Somebody still have to have solved the class of problems before one can embark on writing such generic libraries.
There is just no silver bullet in software engineering.
this is awesome!
It has been four years since this presentation, did this work out commercially for Adobe and Photoshop?
Wonderful lecture but can you elaborate exactly what is generic programming and declarative programming? How exactly are they different from what's being used in today's computer programming?
@seanparent65 Ok, so instead of 'last' meaning the last element of the array, it actually means a pointer to one element past the end of the array?
Also, the caller must then check if the returned value is past the end of the array and add the element to the end if so?
And if the value is not past the end of the array, the caller must check the value at that location to see if it was actually found?
Seems like bad practice to me.
Hi...it's verry informative video...thanx mate..
(cont.) [2] My second point, however, will argue that we will never be able to boil away variation, only minimize it. Your view of the programming discipline agrees with this, since we must deal with complexity and consequently variance. Consider the problem of infinity in either mathematics or CS. One must gulp hard and accept it as a reality. In my view, a 'model' is inherently approximate and non-atomic, a perspective - a resolution - of reality. Therein lies the 'art' of science.
Google is great at tech talks!
great future!
How is that a correct binary search solution? If you have an array [0,1,2] it returns the same result when you search for 2 or 3...
Does anyone have a citation for the survey paper mentioned around 0:50:00?
If programming is maths, considering that computers can calculate...
This is flow based programming. It is (as most things in computer science) nothing now. Applications like Houdini have used it for years. However it *is* interesting how it is used here. I haven't seen that before.
To bad that his team had no exposure to Haskell since these ideas were already shared by Conal Elliot through FRP a couple of years earlier
Hey you broke the 5 years of no comments
No - I would have to say we haven't succeeded. STLab is no more (but we did manage to publish Elements of Programming before our demise). I've returned to Adobe working on mobile software (you can see a demo in my C++Now keynote). ASL is still kicking and used in _many_ Adobe products, but not to the degree I'd hoped. There is a research project at Texas A&M continuing the property model work (publishing and a JS library) - I'm hoping to collaborate with Prof. Jarvi on this next year.
What does adobe mean?
Wowowoowo ...♫♪♫☺
Adobe should be richer then that, but their product is to spensive so it free
yeah...real programmers work with a magnet.
Vejam este:
/watch?v=BPXzkli6NOg