Can Great Programmers Be Taught? - John Ousterhout - Agile LnL
Вставка
- Опубліковано 12 вер 2022
- People have been programming computers for more than 80 years, but there is little agreement on how to design software or even what a good design looks like. As a community, we talk a lot about tools and processes, but hardly at all about design. In this talk I will describe my recent work to identify and communicate a set of software design principles, including a new software design course at Stanford that is taught more like an English writing seminar than a traditional programming class, and a book on software design, which is based on the concepts from the class. I will also present a few of the design principles, such as "classes should be deep" and "define errors out of existence."
- Наука та технологія
The really beautiful code is like an elegant mathematical proof - all polished and universal when you look at it top-down and gracefully collapsing to all edge cases when you analyse it in detail. Like a perfect clockwork ! 🤩😅
This video appeared in my feed and I'm so glad it did. Great video and great channel!
I think the idea of changing the student's project and add new to it is an amazing idea. Like it or not, this is what we software engineer do most of the time. We either create the mess or clean the mess of others. I think this kind of exercise will help the student to be more aware the next time they create shitty code.
00:52 Most important concepr in computer science
02:01 Problem decomposition
04:28 Everyone can do it
08:18 How we teach it?
11:15 Secrets to be a great Programmer (sumary od the philosopy)
14:53 Clases should be deep
17:04 Example what not to do
18:49 Java's illlnes classitis
23:57 Unix File I/O as good example
25:45 How to design a new Class ?
27:30 Why general porpouse ?
28:05 An example
30:34 General porpouse Aproach
33:53 Tactical vs Stategic mindset
36:55 Why strategic is best ?
40:56 How much to invest
45:00 Small investments
49:17 Is the course working
52:00 Phylosophy of software - Harvard CS190 Boock
53:15 Conclusion
55:30 Question 1
57:09 Answer 1
1:00:40 Question 2
1:01:10 Answer 2
1:01:40 End and farewell
22:55 This supposedly being an example of "too many, too tiny classes adding complexity" is a fallacy.
The fact that nowadays one CAN create a BufferedInputStream directly in one call is exactly what resolves the issue. Many thin classes is not the problem. The problem was a lack of "glue code" to glue it together.
It is a perfectly valid, fantastic even, approach to keep responsibilities small, to have classes that make up the external API of a library use more and more classes internally. It is good for maintainability, extensibility, testability and ease of understanding each part individually.
The solution was precisely NOT to just cram everything into 1 "deep" class.
I suspect the root cause of this fallacious belief is that 99% of programmers still think in terms of how computers operate, procedurally. Not in terms of composable objects. Even if they write Java, C++ etc.
Real OOP is very declarative and hardly distinguishable from FP.
I clicked this in anticipation to disagree with pretty much everything. To my surprise, John's observations and recommendations were on point and seem to be based on actual, hands-on experience. Wonderful talk, bravo!
Wow im so happy this popped up in my feed.
I've read "Talent is Overrated" and "The Talent Code" and "Peak: The New science of expertise" and i think they're all great books with entirely novel ideas. I'm surprised particularly about how many TEACHERS, who entire profession is dedicated to overcoming the concept of "natural talent" oppose the ideas in those groundbreaking and optimistic new sciences of instruction.
Perhaps they don't like the message: the student can learn and if they are not learning then there's something wrong with your teaching.
To be fair, every profession tries to avoid liability to some extent.
@@teeletsetse445 it's like avoiding liability by totally invalidating your whole profession
@@TreeLuvBurdpu Yes.😂
So, if composition is the most important thing, then why is there no discussion of category theory? I feel like there's a serious disconnect between the aphoristic introduction and the entire rest of the talk; there was an abrupt switch from computer science to software engineering. This is especially surprising because I would have said that the most important concept is functorality, which is not something easily recognizable without an introduction to categories.
Hi! Really enjoying the video and the approach! Thank you for sharing your experiences and insights.
One thing about the size of the classes for me thinking and that's considering each class as separate, while sometimes the value of all all small pieces combined may be bigger than a simple sum. What do I mean by that? I have a large C struct and created a getter and setter function for each variable in the struct. While sometimes it is more easy to simply get the current state of a variable by not using the getter function, in other cases it adds a lot of value due to the complexity hidden behind the getter function. Now, the user doesn't need to think about this important detail anymore. Anytime you want a value you just get_struct_variable(struct) and it always works.
I hope a similar explanation is not coming later in the video while I am still watching.
@13:00 : I think the benefit of this method is you can quickly search for all places where you are doing this logic without having to write a regex . Typically something like this should be a macro , but this looks like Java or C# which does not have macros .
Amazing talk
35:00 - One shortcut here, one shortcut there and soon enough your codebase is a mess and you're screwed
53:00 - when you can't scale, write books, create courses, etc.
great talk. ty.
I think I read somewhere that Linux embraces the "avoid special cases" approach to design, such that algorithms should operate cleanly over all cases rather than handling the 'happy case' primarily and adding checks and special code for the others.
I think there's also a hint of the single responsibility principle here, and that classes should be designed to exist within their own very well defined interface and data structure boundary.
So avoiding special cases by making the happy case the only case?
@@AgileLnL dont think they meant avoid special cases, but rather early return on special cases with if conditions, flags etc
But the function should mostly be designed around the happy path
i have seen your graph before with data to back it up. in the state of devops report by jez humble and others they look at what makes teams move fast. they found that writing code with lots of test in small chunks makes the biggest difference. this is basically continuous integration. more importantly, when they looked at the worst performing teams, they discovered that the code chunks were bigger, harder to understand, buggier due to the relatively fewer tests, and individual changes took longer due to high levels of technical debt.
they do this report annually, and wrote about it in the book accelerate.
,
Most important concept in computer science: naming phenomena...
What he’s advocating for cannot be done optimally at universities. Universities are not vocational schools. Universities do not and should not teach you to become a practitioner, they should teach the fundamentals the practice is built upon. They should not, because they cannot, thus should not teach how to do code reviews. They teach you how to debate, elucidate, disambiguate - communicate. But since Stanford was founded originally as a vocational school serving the industry du jour of Palo Alto and thereabouts, the history keeps rhyming.
Everything that makes a good programmer can only be properly taught in situ, in a master/apprentice relationship. Any other alternative is doomed to fail. However, programming, as it is currently practiced, happens to be an endeavour that does not value wisdom and has a raging problem of ageism. This is not conducive for an apprenticeship culture to take hold, and the whole practice of programming suffers as a result.
Teams of two is exactly how we hire: both people are responsible to each other. Its much harder for someone not to be pulling their weight when paired with someone they recommend to work with. Yes this hiring practice does not scale, but I have never heard of a company failing because they didnt scale fast enough.
maybe that's exactly why you never heard of a company failing that didn't scale fast enough. when they failed it didn't make any noise?
I don't think this is the correct usage of XP. You might want to review your hiring practices because pair programming is done for other objectives.
This is a really good video
Like everyone else on UA-cam, this guy rambles about himself and I swear to God for 15 minutes then he finally start this time
The most important part of CS is correctness and performance (speed). If it doesn't work it's useless. And if it doesn't work until everyone is dead it's also useless.
Abstraction, Problem Decomposition, etc... are all (at best) second order goals
the issue pointed out about communicating how to be good at what you do has a two part answer.
when you go to college your goal is to communicate to the tutor that you have understood as much of the information presented to you to someone who already understands it. this only gets worse when you make academia your career. this is a completely different skill from communicating one or two points clearly someone who does not know it.
bad as this is, it pales in comparison to the problem that knowing how to do a job is a completely different skill to knowing how to teach someone else how to do the job. that is why apprentiships came into being in the first place, because then you only have to deal with one of these hard problems at once.
This is a great adjunct to the work in OOP by Yegor Bugayenko
He has a YT channel
really good talk with great well presented points, looks like they come from a lot of experience
29:40
I think what you're describing is something akin to cleaning up expressions in algebra where you combine like terms and factor out pieces so you can turn something like "3x -x^2 +5 +2x^2 -x -4" into "(x+1)^2". It's still "specialized", you aren't talking about some general polynomial a_0*x^0 + a_1*x^1 + ... and the added complexity of handling the general case, you've just simplified what the specific thing you had. You could even make an aesthetic decision as to whether x^2 + 2x + 1 or (x+1)^2 was better.
This would be like deciding whether insert/delete is a better basis for text editing than replace(start, end, text).
In that sense, the goal is actually to start with the specialized case, and rather than generalize you "simplify".
Not only are low skill developers less productive, they create code which requires skilled developers to refactor or completely redo.
The topic covers some interesting topics, mainly about the bad things that come with defensive programming, but sadly this course is only as good as the vision of the author.
If we talk about removing complexity from the design, what can be simpler than having pure functions, data structures and managed side effects?
People use the OOP as a silver bullet to throw at their problems, praying that it will work, making all these theories (classes should be deep) not based on any practical facts and fighting with each other when someone doesn't agree. I watched a few videos of Uncle Bob and he is not a experienced developer but a cult leader.
The key to simplicity is actually limiting the tools the designer has access to, and make the ones left very good. I have at least 3 years in both writing in OOP languages and functional languages and I can tell you that designing, managing and reading a codebase written in a functional language is 100 times eaiser, because these languages actually constrain you very hard on what you can do: no mutations, functions without side-effects, no classes and the other abomination following this such as inheritance. You can open a file randomly and read a function and understand what it does, it receives data, transforms it and returns new data, good luck doing that with classes, especially if they do side effects too, and don't start me on concurrency and how bad it is implemented in OOP languages.
Great one! I only find it confusing that in english "complex" and "conplicated" have as noun "complexity" although there are not the same. And here, the difference is crucial.
I think the word you might be looking for is "complication"
35:33 well doing a quick tactical prototype to figure out a better strategic plan can be a useful approach
The amount of code expected in 3 weeks seems very, very low. Am I just a good programmer if I can put together 3-5x more than that in 3 weeks? Assuming what I'm writing is readable, logical, practical, etc., of course.
@2:50 I think the SICP book teaches this.
So for what it’s worth, I require my engineers apply S.O.L.I.D. design principles as part of development and code reviews.
Don't think it's wise to isolate 'tactical programmers' as bad. If 10% is a wake of destruction what's the 90% they got right. The solution can always be refactored, at least you'd have one.
I think the most important concept in CS is abstractions
CS is about solving problems, not hiding complexity
@@jma42 how do you solve complex problems without creating layers of simplifications? My POV is that you are being fooled by front end frameworks like React, Vue and Angular. Most of the youth like you think CS is web development.
I think that "deep classes" are good in principle, but they can really hurt you if the abstraction of their API fails in one edge case and you suddenly have to start debugging them. All this complexity that you have been shielded from will suddenly become a nightmare. Just being "deep" alone is not enough. The implementation of all this functionality also has to be solid. Yes, it's just the ugly wiring behind your shiny facade, but someday somebody will have to untangle that and understand it, because your facade was only 99% perfect.
I think you are right. We can have an ideal state, but if the chances are high that in trying to hit the ideal state we make something that is worse than a slightly less than ideal state we might sometimes be better with the safer less ideal approach.
Debug the system into existence 😂 40:32
Ready with the video right after the start. The most important concept in computer science is computability you know what Allan Turing was all about. If they get that so wrong why bother with the video for the rest.
Just that Turing completeness doesn't mean anything in real life. No computer is Turing complete because it always has finite memory. It's just as nice as the big bang theory and Stephen Hawkins ideas of black holes and maybe as false.
@@llothar68 For example any time you want to do something with your code like optimize it or check if it is correct you have to consider it. You can never think of an algorithm that takes you to the optimal result it is always going to be an approximation whatever the computer power you have.
@@remcogreve7982perhaps you’re responding to the term ‘computer science’ when the speaker should have used ‘software engineering’. Llothar is just responding to the spirit of the talk.
I'm on the edge with this video. You must learn how to write a design on paper before you write a single line of code. UML is a great tool for such. I think professor needs to learn a bit of "paper" design. Abstraction and composition. Go through design patterns and then compose software in your head. Good thoughts but not confident that I would take his course. Though it would likely be a good learning exercise.
you have missed the point. he is not saying that you should not learn good design, he is saying that the big upfront design model might work well when operating in well trodden paths, but in software that is not where we live, and every big software failure tried it and did not abandon it quickly enough. data from successful projects shows that between 40 and 60 percent of the specifications are not only unknown at the start, but are usually unknowable at the start, hence the move to incremental evolutionary design instead.
@@grokitall Sure, evolutionary design is the way to go and, in fact, the only viable way to go. I still think paper design is foundational to any good project, before you write a single line of code. It has proven to be the case for me and my teams. So many times I've stopped bad ideas and $$$$ from even taking place by simply asking to at least document it or talk it through.
@@dragonmax2000 sure you need to document your design decisions, and referring back to them is a necessary part of good design, but how do you take into account the unknowable stuff to create the upfront design in the first place that you seem to be advocating?
@@grokitallI really don't think he means he will only start coding whem he is 100% sure he has 100% of the system on paper. I really don't understand what's the confusion you having with the op saying it's good to have a design on paper first or conceptualized it on your head before rushing to write code.
I keep finding UA-cam gold
The answer is no, in case anyone was wondering. Thanks Betteridge.
The posix I/O system is a terrible design. I know he celebrates it, but it literally is a shallow interface. Sure tou have read and write, open and close. But those methods giarantee the bare minimum and to get anytjjg done robustly you need to rewd theouhh tons of documents snd figure out which other ioctls/syscalls/fns you should call to do things robustly or with timeouts, etc.
Its like 13 layers of cruft.
his uncle Bob's reference is misleading at best at worst deliberately misrepresented....
In no shape or form Uncle Bob's advice on smaller method has any bearing on creation of classes...
Uncle Bob doesn't advice creating new classes due to method sizes... he advocates creating new classes when your class is doing too many things, and it has NOTHING to do with method sizes...