What's the difference between programming and coding - Leslie Lamport @ HLF 2019
Вставка
- Опубліковано 13 жов 2019
- Leslie Lamport is best known for his seminal work in distributed systems, and as the initial developer of the document preparation system LaTeX and the author of its first manual. Leslie Lamport was the winner of the 2013 Turing Award for imposing clear, well-defined coherence on the seemingly chaotic behavior of distributed computing systems, in which several autonomous computers communicate with each other by passing messages.
In this video Lamport speaks about the key differences between a programmer and a coder. The talk was recorded at the 7th Heidelberg Laureate Forum (HLF).
Credit: ZME Science, 2019. - Наука та технологія
80% of my code is written from the logic on my whiteboard. and 10% is magic that i managed to come up with after trial and error, and the remaining 10% is the idiotic need of my customer. "it must work like this"
The customer conveys the spec which best serves his personal needs relevant to a process that he needs done. It doesn't matter if the programmer likes it or not. It is just a spec to implement. Some programmers know nothing about the application and have the unnecessary desire to understand and personally like the way the customer's business works. It's none of his business - really. It is completely irrelevant if the programmer for some reason personally identifies with a different procedure. It makes no sense to compare what he likes and what the customer needs. The 10% is meaningless and has no application to anything.
I have been programming for decades for 50 organizations and I learned this long ago. Some programmers need to learn a little psychology to understand "different strokes for different folks". Or listen to Sly and the Family Stone.
Some things change and some things stay the same. I learned to program in two stages. In stage 1, I was handed a thick listing of the program I inherited and on which I learned. The listing was about four inches thick printed on 11x17 inch green-bar paper. (This was in 1962 and the computer was the IBM7080). I successfully solved two "impossible" important problems which caused me to be picked to participate on a team charged with completely re-designing and re-writing an entire application to run on a different computer (the 7080 instead of a 1410).
That began stage 2 during which I learned the lessons of Lamport's video. I believe those lessons are just as valuable today but I am dismayed at how they seem to have been forgotten by too many people.
When I joined the team of five, the "What" had already been determined: the existing and running 1410 system had to be functionally duplicated and those who were involved in the old system knew that if and when we were successful they would all lose their jobs. It was they who had to certify the results of our tests and believe me, they were tough critics.
My job, along with those of the three other programmers, was to start at the "Algorithm Level" and figure out "How" to write the programs for the new system. Our boss Larry, the fifth guy, explained the rules at our first meeting. We were to learn the specs and requirements for our programs and then start drawing flow charts of our algorithms on flip-chart paper. As soon as we thought a portion of it was ready, we were to bring the flowchart sheet to Larry for him to check. We were to do no coding at all until all of our flowcharts were done and ready. Only then would "Coding" begin and keypunch authorization numbers would be assigned to allow our code to become machine readable. The coding would all start on a specific Saturday, some weeks later. We were to work through that weekend, day and night, until all the coding was done. On the next Monday, testing would start.
Even though that was sixty years ago, I remember that first time I brought a flowchart to Larry. I felt cocky approaching his desk and handed him my first flip-chart page. I stood up straight and proud as Larry asked me what the program was supposed to do. I told him, and then he said, "Let's see. Suppose you have this input data", and he wrote some numbers on a scratch pad. Then he put his finger on the first block of my flowchart and said "You didn't initialize this variable for the first-time through". I felt like I suddenly got smaller and more humble. He handed me my flowchart and said, "Bring it back to me when you think you have fixed it."
With my tail between my legs, I left his office and returned to my desk. I used his method of writing some hypothetical input data on a scratch pad and began tracing through the flowchart seeing what my algorithm would do. I began uncovering bugs about as fast as Larry had. At that moment I made a vow to make sure I desk checked all of my flowcharts thoroughly before I brought them back to Larry. It became a method and a habit I used all through my career.
Coding started as scheduled on that Saturday. Coding was intense, mindless, and tedious. We had to write machine-level instructions on coding pads and put them in an out basket. People would periodically gather the sheets and bring them to the large, temporary staff of keypunchers. We coded until our fingers were frozen to our pencils. We stopped and went home in the middle of Sunday night only after all of our coding was done.
On Monday morning we picked up our programs (mine was about a box and a half of 5081 cards if I remember right) and prepared them for our first assembly runs. That caught typos and syntax errors. Then when you were ready you put test data together and began the testing runs. Debugging was probably a lot different in those days, but Larry's method obviated nearly all logic bugs. The hardest part was proving to the 1410 reviewers that the difference in results was not because of our bugs, but because of undiscovered bugs in the old system that had been there all along.
So for 60 years running, there has always been a difference between programming and coding.
Thanks for sharing!
Great anecdote! Thank you for sharing. In the name of efficiency, we get rid of valuable processes. Like flow charting with Larry.
Whoa! thank for sharing.🤲🏾
Larry is a genius. Cudos to you guys who made today's tech possible.
I time travelled with you. Thanks for sharing. Learning language is easier today with so many online tutorials and courses but job is rare. I am sure it was opposite in those times. Learning to code would be difficult and getting a job would have been easier ?
My first week in grad school many, many years ago was spent learning to program in Fortran. It was a new requirement that every student had to know how to program. This was pre cp/m, pre windows, pre ios. We moved from electromechanical programming to solid state logic to microcomputers, from a central data processing service using cards to a network of terminals serving the whole university in just a couple of years.
respect my friend , in which year this happened
A coder, a programmer, and a software engineer walk into a bar. The bartender looks up and says: Hi Dave, what'll it be?
I'm sorry Dave, I'm afraid I can't do that.
I don’t get it lol 😆
@@ahmedshifa Like the movie Split
Jajaja I Got it!
@@ahmedshifa dave is all 3 in one. he is a coder, a programmer and a software engineer.
Most programmers are bad at math, and the misconception among many people that "you don't need math for programming" stems from not fully grasping what math is, it's not only calculus or algebra. Graph theory for instance is a branch of mathematics most programmers think that it's just bunch of defintions and code snippets.
When people say that you don't need math for programming what they are talking about is Web Development, which is not programming.
@@eaccer That's a divisive statement. As a web developer I've had to add and even subtract numbers multiple times.
His work is insane man!
As a software developer I spend around 95% of my time reading code to understand it and 5% of my time writing code.
The codebase I work on is enormous and people who have worked with it for 10 years still don't fully understand it - we are asked not to add comments as the problem with comments is that if you update the code you need to update the comments too.
In some ways it's fun because it is a challenge understanding how to fix bugs or make changes.
What kind of excuse is that, not to comment code, because it could change?
One of the most important aspects in coding is readability!
Commenting code helps readability.
Once I was messing with the code from a ex-coworker which left his legacy to us so we can finish his work.
That was the hardest time in my profession, to finish his work.
* Absolutely no comments
* Most generic variable names i've ever seen ( e.g. key, value, item, dict, _dict, ... )
* Not adequately tested code
* And logic errors
It took me about 2 weeks to debug and kill some errors but 90% percent of the time was just trying to understand what he wanted to do.
I wish no one to mess with such code.
But I have to say, It improved my skill, to read and understand unfamiliar code, a lot.
95% of reading, 4% of copy-paste the code and 1% of editing :D
Omg I've been going thru this for the past 3 weeks. Trying to fix a large code set with 0 comments, generic and meaningless variable naming, tons of confused illogical follows etc. 'Challenge accepted' , but also, I'm in TEARS haha
@@GhostixMusicYou work with dynamically typed languages, don’t you? :P the problem with comments is that a change of the logic in line 1337 can affect the validity of comments in lines 13, 512, 666 and 747, and the only programmers that have that kind of memory to remember where all those affected comments are are those that are accustomed to getting no help from the compiler when they change stuff. Forgive us lazy people with our statically typed languages, but we trust more in the compiler‘s willingness to punish us (before we can even run the code!) if we make nonsensical changes than in a co-workers ability to comment properly. The only code quality standards that you should know are 1) good variable/constant/method naming 2) how and when to make good abstractions so they don’t become random helper classes/functions and 3) how to make the compiler do all the hard work for you (and for your co-workers)
Well most of the time of a software developer is consumed in learning the tools for fast and less effort developments. If you are already mastered, then writing code isn't a big deal - just watch a simple tutorial and you'll have the syntax ready.
I'm not sure if there's much logic involved in development. It's more about management, like where to place what stuff.
coding is only a one small part of programming, it is the process of allowing humans to speak to computers
so in your terminology programming includes - analyzing, software architecture definition, sources definition, eventual risks of outcome correctness, security area points, user authority levels etc. and coding, coding than is only the writing the program (sequence of commands, parameters etc. in specific IT language (whether it is python, c##, c++ or other its not important). In big corporations part of programmer work does analyst who summarizes company needs, defines the data and information sources, outcome users etc etc. and communicates this with programmers/coders no matter if they are company insider employee or outsourced
Last year a friend (who knows nothing at all about ptogramming or coding) said he bought a Python book to lear programming, and he was told Python was a good first lnguage. I said it was true, but it should be like the second step... that before learning Python, he should first know hot to program... how program works, how computer works, learn logic, what are procedures, loops, what are functions, how memory works, how secreen works, how files works... coding is really easy AFTER you know how to program.
That's why I recommend CODE by Charles Petzlod & The Pragmatic Programmer by Hunt + Thomas as a great first step while Structures and Interpretations of Computer Programs as an excellent next step.
Three Cheers for TLA Plus!
what would be the 3th subtask? I didn't get it
This may seem a bit hard but I wish he would have written it all down before making this video as he mentioned in the video. He seemed to wander all over the place and made me nervous just watching.
Yep, an ill thought out commentary. There is no difference.
1. what should a program do?
2. which algorithm should be used to solve the task?
3. documentation??
4:36 what is the word? before __???__ a tale so that...
"It should be in a level of detail so that...."
what would be the 3th subtask? I didn't get it
Very interesting all these i would like to learn it all if l had the opportunity
Can someone sum it up for me? Is there a clear distinction?
Programmers know the requirements (What the software does), Think well about how it should be implemented before the implementation, and Document it well so that it could be understood easily.
He making a distinction in order to talk about ideas, not because he wants to split hairs about the technical definitions of the terms.
Suppose you're trying to write a fantasy novel.
Coders would fuss over how to press the keys, using the right text processor, trying to spell words correctly, how to format the page, low level stuff.
Programmers would develop the plot, the characters, the setting, the narrative structure, the ideas to convey, high level stuff.
Tell a coder to adapt their book to a different language or to the big screen, and they can't, because they're stuck in the low level stuff of words on a page. To a programmer however, this is simple, because they deal with the high level ideas.
To be more concrete, coders operate within the code. Tell them to use a different programming language and they will struggle, because the code looks different.
Programmers are familiar with the higher level concepts and algorithms. They can explain their algorithms without writing a single line of code. The code is just an implementation detail.
Its the difference between understanding what letters, words, sentences and paragraphs are and writing your own sci fi novel.
No. There's no difference. Software engineer==programmer=coder.
Video over. Save yourself 7.5 minutes of your life for something more useful. :-)
So true!
Does it depends on 0&1 ,binarry
Good naming conventions and clear architecture go a long way, if the code is readable then you typically don't need much in the way of additional documentation. There's really only a need to document novelty and novelty should be avoided wherever possible.
What is architecture?
@@a46475 Architecture is the high level design of the system, expressing non-functional requirements like extensibility, maintainability, backwards compatibility etc. Which all become complicated if you dump all your code in a single file.
In practice, many programs are inherently complex, and documentation is quickly needed if humans are to use the code. I have seen many people saying that "code is documentation", or "if you find the documentation lacking, just read the code and write the doc"; the reality is what Leslie illustrates: yes, you can do this… in 2 days instead of 5 minutes if the code was documented.
Well I have always hated reading someone's code to understand what their program is doing...😂. They tell you it makes you a better programmer. I still don't get it.
3:40 „you should be thinking about how it’s done“ - I disagree. One should be thinking about *what* you want to do and try to write out a definition. If you write in functional style, this usually translates 1:1 to code. In a *second* step, you may want to refactor your recursions into loops for performance (if that is an issue) or to avoid stack overflows (if you couldn’t write it in a tail recursive style or your language doesn’t guarantee tail call elimination).
what is the third thing?? documentation??
@@anirbanc88 docume-what? Can you eat that?
poor audio
domain problem -> hire a programmer -> domain solution -> programming -> algorithm -> coding -> source code -> compiler -> software
🙂
By equating 'algorithm' and 'program', we can answer Lamport's title question:
Programming is making a program; coding is making a program machine readable.
I told that to the guy that pretend to sleep many years ago. But he wasn´t really asleep, as I now have found out. Damn. Why is this always happening to me?
Why is audio so low n intro title loud. Anyway it took me 30 mins to learn 5min video length of particular coding lecture. Understanding computer language is vast, like u gotta to learn 5 languages to create ur desire apps or website. I hope Ai can reinvent the difficulties into simpler approach
In Jesus' Name Amen ✝️
i would never differentiate on that level. If someone can't no program, he should not code. But for a good programmer, coding is quicker thing, though not easy. And by looking into the problems of coding, you like change the program and algorithms frequently. Sounds to me like a hint from a guy, who designed algorithms on university and higher leve, but never wrote large chunks of code. Maybe I am wrong, sorry, my humble comment. I have Written for sure more than 2 Million lines of code and did most of the design (Telco-SW 24x365).
do you know who he is ??
@@the_god_killah Did he sell Software for more than 50 Million ?
I'd say, you don't understand it, until you can prove it's true.
But the be honest, that's quite a lot to expect from an average student. I don't see such a course going past the definition of an algorithm very often...
@Roger Vieira They are not necessery to implement the algorithm. However, they are absolutely vital to understand why a particular algorithm is better than the other, and in what sense.
@Roger Vieira I'm not saying it's essential to get a correct result. It's just a question of whether the programmer UNDERSTANDS why a particalar algorithm is "better". I actually didn't want to specify exactly what "better" actually means, since it depends highly on the context.
It could be the speed, which is actually fairly easy to understand and proofs are often trivial. I'm guessing, that what exactly do you mean with "applying limits", but I'm pretty sure, that you're just using an already prooven theorem, that says, that describes the asymptotical runtime. Which absolutely all right. It would be silly to rewrite the theorem for each algorithm and proove it again.
But if we're for example talking about approximating DEs, we're generally trying to use the "better" for being closer to actual values (i.e. convergence order). And than we can choose the best algorithm with acceptable runtime.
It get's even more complex when you run your code on an actual computer, since rounding errors for floating point numbers are posing a signifficant difficulty, and it's not uncommon to get an error exploding to infinity, with a convergent algorithm.
And I'm sure, that for topics that I'm not familiar with, there are a lot of different definitions of "better". What I'm saying is simply: that's complicated.
So basically read the book 'How to Design Programs' and you should be fine.🤷🏿♀️
Not really. More like, spend time designing programs B4 u start coding. It's also a great way to make sure your not on your chair all the time. I like to pace around going thru the potential program logic, with a pen and paper close by to write down general pseudo code.
@@NF-ru8on I think the book conveys a similar message. It provides a checklist of things to think about before actually writing the code.
you say tomato, I say tomato
very bad outro music, jarring for ears, very bad, please change!
Fact: Everyone else uses the terms programmer, coder and software engineer to mean precisely the same job.
And I mean everyone, anywhere in the world.
Sorry, but this is just pedantry, the splitting of hairs for the sake of a clickbait video title.
Yes, people use these terms interchangeably, but the idea of the video is still relevant and should be considered. And, being pedantic for an academic is definitely a good thing. Besides, Leslie Lamport is not just anybody, his words probably come from his great experience.
The difference between a coder and a software engineer is like the difference between a cook and a chef
Definitely not pedantry, anyone mixing the terms does so out of ignorance
This is a childish opinion, but he has a beard.
LOL. I thought "coding" wasn't an actual term.. Just a slang used by off the street, lesser educated programmers.(those w no related degree)
They're all the same. In this respect, I strongly disagree witb Lamport and anyone having the same opinion. The distinction is baseless.
If you really know this guy and see what he's contributed to the world of computing, you'll understand what he's talking about. I invite you to have a look at his wikipedia.
@@TonyWorkspace Not needed. Wasting time.
a little bit of gatekeeping to say the least. So programming languages are higher level now. Sue me.
Seven minutes and thirty seconds on the usage of two different words? Get back to work, slacker, you're wasting time.
No seriously, those of us who work in the trenches of business and industry use the two words interchangeably, and
none of us care what acedemia thinks.
Literally: no one cares unless they have nothing better to do.
Those words are not the same
- Coding is like executing the steps of a predefined recipe to bake a cake.
- Programming corresponds to designing and creating the recipe, determining the ingredients, proportions, and techniques to achieve the desired outcome.
If you really know this guy and see what he's contributed to the world of computing, you'll understand what he's talking about. I invite you to have a look at his wikipedia.
buuuuh.... it's the same
This is idiotic. There are no formal definitions for these. Actually a coder is someone who codes medical claims in EMS’’s.