HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
GOTO 2018 • Old Is the New New • Kevlin Henney

GOTO Conferences · Youtube · 6 HN points · 5 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention GOTO Conferences's video "GOTO 2018 • Old Is the New New • Kevlin Henney".
Youtube Summary
This presentation was recorded at GOTO Chicago 2018. #gotocon #gotochgo
http://gotochgo.com

Kevlin Henney - Programming+Patterns Practice+Process

ABSTRACT
Everything is changing. Everything is new. Frameworks, platforms and trends are displaced on a weekly basis. Skills are churning.
And yet... Beneath this seemingly turbulent flow there is a slow current, strong and steady, changing relatively little over the decades. Concepts with a long history appear [...]

Download slides and read the full abstract here:
https://gotochgo.com/2018/sessions/371

https://twitter.com/gotochgo
https://www.facebook.com/GOTOConference
http://gotocon.com
#fundamentals #programming #SoftwareArchitecture

Looking for a unique learning experience?
Attend the next GOTO Conference near you! Get your ticket at http://gotocon.com

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
https://www.youtube.com/user/GotoConferences/?sub_confirmation=1
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
I've read only the The Mythical Man-Month from this list. It is amazing how the project management really did not change much. Similar ideas (sometimes same) to similar problems.

I would recommend watching this talk [0] from Kevlin Henney to anyone who likes that book.

[0]: https://youtu.be/AbgsfeGvg3E

The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff.

However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now.

I think the truth is that we're always missing the forest for all the trees -- only at increasing levels of abstraction: at first, everything is foreign, then syntax becomes fluff, then APIs become fluff, then patterns, then languages, then compilers, then ... I look forward to learning what the next level of fluff will be.

> The majority of the stuff being released every day is just a rehash of the same ideas. Truly revolutionary stuff only happens every few years.

Maybe not even that often. I can recommend Old Is the New New by Kevlin Henney for a good, historical perspective on how little actually changes sometimes: https://youtube.com/watch?v=AbgsfeGvg3E

Edit: now this was more interesting than I anticipated. What is the next level of fluff? Concurrency? Advanced data structures? Phrasing problems for SMT solvers? Probabilistic modeling?

Or are the things I picture as fluff just specific techniques, because the next level of fluff is so meta I wouldn't even recognise it now?

sanderjd
I've been having this experience recently. I used to be a voracious reader of programming books. But for a long time starting, gosh, maybe over 5 years ago, I just couldn't get excited to read them anymore. Just recently I thoroughly enjoyed reading Designing Data Intensive Applications, and I have just started Streaming Systems, which I'm also enjoying a lot. I think this idea of fluff at different levels of abstraction explains it: I used to enjoy reading books about programming languages and frameworks, but at some point it just felt like fluff and I could no longer get through it. But there are books about techniques for solving particular classes of problem (in the case of my recent reading: data processing) which don't feel like fluff to me. But maybe they will eventually, and maybe you're already further on this continuum and would find these books fluffy as well. I'll definitely be thinking about this fluff at different levels of abstraction model and checking my self-education against it as I go now!
net4all
Not sure how to write this. I am hoping the next level of fluff to be removed will be implementing concrete algorithms in procedural or functional style in day to day coding. Instead we should be leveraging other programs (such as SMT solvers, but not limited to those) to produce a suitable implementations of solutions. That is, we should try to focus more on specifications, in one form or another.

So much of the software I work with could plausibly have been written by a machine instead.

MaxBarraclough
> then languages

Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages.

C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it's easy to learn another, I assume that person doesn't know much about programming.

battery_cowboy
I'm one of those people, but there's more nuance than that to it. I've learned about 20 different languages to some degree, from Python to brainfuck to Elixir currently. When I learn a new language, I go to the source material, so for elixir I used the tutorials at the elixir home page and their API documentation. I read the tutorials, writing each line of code into my editor, running each, modifying it to see how it works, etc. Then, everytime the tutorial links to or mentions an API, I'll go read that documentation page in full and experimenting. Then I'll make some projects with that language, look at how the more experienced Elixir (or whatever) developers code by exploring their repos, etc.

After doing that 10+ times, it becomes easier to see the patterns in languages, and easier to understand how their underlying structure will affect how you have to code. There's only so many ways to write a compiler or interpreter, and if you know how they work and you know that your language is, for example, optimized for tail recursion, then you get your experience from other similar languages as a bonus.

I see your point if you're saying, on a surface level, that, "you know one, you know them all," is wrong, but if you dig deeper I think you'll see that, for the experienced (as in: someone who's been around a while) developer, you kinda can say that, with some reservations.

I think anyone can do the same thing, it just takes a decade or more to get there. I'm kinda dumb, too, so if I can do it, anyone can.

lioeters
I'm with you on this - I don't know so many languages but have studied a wide range, and am fluent in several programming and human languages.

What I've found that is that once you learn more than one language with different paradigms, it becomes easier to learn another one with a similar or another different paradigm.

As you pointed out, there are only so many ways a language can be designed/structured, and becoming multilingual means getting familiar with the shared (and implicit) models and operations underlying all languages.

battery_cowboy
Your 2nd paragraph says what I meant to say, but much more sussinctly. Thank you.
net4all
Well, as someone who has taught different languages as first, second and third languages to students and young pupils I would say it becomes easier. Not easy in an absolute sense. It still requires effort.

I would however agree with you that those who say "it's easy to learn another" in an absolute way has usually only considered languages from the same group so far.

lymitshn
I also agree with this. Some people treats languages like forks. It's just a fork why pick another it will do just fine right? Well languages are more like artist tools I think. Of course you can draw a perfect horse with pen/pastel/charcoals as in writing really good i.e Chat Server with Java/Erlang, but each of them has different taste, feeling, community. Picking a language is pretty different than picking a fork. And those all the way Javascript / Java lovers feels like 0.7/0.5 mechanical pencil users that tries draw everything with that. How about trying a brush? (Maybe I shouldn't have pushed this analogy this far)

No offense to, my fork lover friends.

bonoboTP
Or they program different things than you do. In data science for example it's not a big deal to jump across Matlab, Python, Julia, Lua etc.

If you know Java, you'll not take very long to be productive in another JVM language or in C#.

Yes, deep specialized expertise will take time. Also, switching across paradigms or levels (C -> Prolog or Python -> assembly) will take much longer. But that's not what people usually have in mind when they say switching languages is easy. It's usually the domain that takes longer to learn.

apotheon
> If you learn to program in one language, it's easy to learn another.

That's often the case: many people who think that don't really use the strengths of the languages they use.

On the other hand, I've written a basic lambda calculus parser for fun and gone on to write (non-distributable, if I care about people) software using it, also for fun; I've written idiomatic, well-formed code in BASIC, C, Perl, Ruby, Scheme, Standard ML, and a wide range of other things; and I've basically added features by removing code. At some point, even if you know what you're doing, there comes a point where, kinda-sorta, it becomes easy to learn others.

It just takes a lot more than learning only one language to get to that point. Whether the person who first coined that comment about learning languages meant it as a simplification of a wise concept or was a blubdev who never really figured out the significant differences between programming languages is a question I'd like to see answered definitively, based on knowledge of the individual rather than guesses.

sanderjd
They might not mean "easy" in the same way you mean. I sometimes find myself saying "easy" when what I mean is something more like "approachable" or "without many ambiguous roadblocks". I very much believe it is "easy" in that way to learn new programming languages. It is still hard work, requiring lots of reading and trial and error and plenty of failure, but it doesn't have that same experience of complete stuckness as the first time learning to program.

But I wouldn't say it is "easy" after learning one language. It definitely takes two or three, with step-changes each time you learn a language in a different paradigm than you have before.

tasuki
I would expand that to "If you learn to program in one language, it's easy to learn another within the same paradigm".

If you know Python, Ruby or PHP will be pretty easy for you to pick up. You might have some difficulties with Haskell and Lisp.

SaxonRobber
I'd add that spending some time to play with the languages that are hard or different will pay dividends down the road.

Learning some Haskell was probably the most worthwhile time I have spent learning a language because it forced me to fundamentally reevaluate how I think about programming. Now I don't use Haskell at work, and likely never will; but, years later, the techniques I learned from it I still apply daily when I write C, Python, JS or whatever. It made my code far cleaner.

LandR
I feel this same way about Clojure, I won't likely ever use it professionally, but it's made me a better programmer having learned it.
ben-schaaf
Whenever a newish programmer has asked me what language they should learn next I always say prolog. I fully expect them to never touch the language afterwards, but writing prolog was a truly a mind opening experience. More so than learning functional programming imo.
megaframe
I routinely write in no less than 4 languages for work... comfortably in all of them. Each certainly have their own nuances but the skills translate and made learning the others easier. At worst I (have had to and do) sometimes look up syntax or end up using a design that's less than optimal for that languadge, but that still works.
kqr
I absolutely agree with you. Being able to call languages fluff comes from me having tried to build real applications with C, Python, Prolog, Erlang, Haskell, Ada, POSIX shell, AWK, Common Lisp, Perl, R, and so on.

Crucially, I don't just think of languages as different syntax for Java.

echelon
> If you learn to program in one language, it's easy to learn another, I assume that person doesn't know much about programming.

This is flat out wrong.

If you know Python, it'll be easier to learn Rust than having to learn Rust from zero. Engineering is about problem solving and formulating solutions with algorithms and data structures. If you don't know what those are yet, it'll take much longer to learn.

Learning one of anything makes learning the next one easier. Programming languages, spoken languages, musical instruments, sports cars, martial arts, sports, weapons, drawing, etc. Your brain builds a rich scaffold you can hang new concepts from.

ddek
It’s also worth noting that projects are rarely contained within the bounds of a programming language.

If you’re building a web app, what’re language you use will still come down to HTML/css. You’ll also probably be using SQL, which is also unlikely to change.

But there’s the other side to that. If you’re graphics programming, OpenGL provides the same features regardless of language. The OS APIs are broadly the same - the steps to set up a TCP listener don’t change with the language.

The APIs for all these may be subtlety different between languages, but not significantly. It’s a case of translation rather than relearning, and although I can’t speak for anyone else I find that translation quite painless.

fiddlerwoaroof
Learning Python before Haskell also made learning Haskell significantly harder for me, because I kept trying to write Python in Haskell
bcrosby95
Sure, but it will still be a while before you aren't just writing Python in Rust.
jghn
However the more languages you know and the more they're spread across different paradigms the shallower the learning curve will be for any language one wants to pick up.
apotheon
Be fair to the original comment, which referenced people saying something about learning a language, and it making learning any others easy, not about learning many languages, and it making learning any others easier.
scabarott
Writing Python in Rust unlike say writing C++ in Rust, might actually be a desirable thing. Put it this way, It will be a while before you are writing Rust like Python.
jbeam
It’s still easier than if you had never previously written an if statement. If there weren’t a lot of differences between languages then we wouldn’t have so many languages, but that doesn’t mean that there are not a lot of concepts that are used widely across many languages.
MaxBarraclough
> If you know Python, it'll be easier to learn Rust than having to learn Rust from zero.

> Learning one of anything makes learning the next one easier

Agreed, but I put easy, not easier. I suspect we really agree on all points.

If you know C#, it's easy to learn Java, as most the concepts are shared, and even the syntax is very similar. When someone says If you learn to program in one language, it's easy to learn another, it betrays that they don't understand that some languages are similar, but some are very different and have unavoidable learning curves.

C++ is a good example. Learning C++ is not easy, no matter what your background knowledge of other concepts and languages. It's a huge language, in which nothing is simple. Even the build model is a minefield. Having a solid understanding of imperative programming and OOP (from knowing Java, say) is certainly an important head-start. I wouldn't recommend C++ as someone's first programming language. There's still an enormous amount to learn about C++ specifically, no matter your background knowledge.

Jan 24, 2020 · 1 points, 0 comments · submitted by mpiedrav
Dec 18, 2019 · 1 points, 1 comments · submitted by kqr
kqr
If anyone knows of texts or presentations of similar wisdom value, please send them my way!
You remind me of this Kevlin Henney talks that manages to cover a rather big range of programming concepts that keep getting recycled as the big new thing https://youtu.be/AbgsfeGvg3E
There's a talk well worth watching by Kevlin Henney called 'Old Is the New New' [1], where he points out that waterfall was initially conceived with design iteration in mind and yet that part was just essentially forgotten and replaced by something overly-simplified in common understanding.

[1] https://www.youtube.com/watch?v=AbgsfeGvg3E

heymijo
What's a word or phrase to describe this idea/principle?

It feels like the Bruce Lee idea of "take what is useful and leave the rest" but either the opposite or a bastardized version. Like, take what is easy and leave the nuance

I see, whatever this idea/principle would be called, all over.

AnimalMuppet
"Implementation without understanding"?
Jtsummers
Also known as cargo cult behavior. Taking the visible behavior without the invisible understanding or behind-the-scenes behavior.
heymijo
I think you nailed it! From the Wiki on 'Cargo cult programming' but I think 'programming' can be subbed out for anything.

> Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle.

> Cargo cult programming is typically symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution

> The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position.

https://en.wikipedia.org/wiki/Cargo_cult_programming

howard941
Ha! $NEW_JOB instituted "daily scrums" alias "standups" like my second week here where 10 of us sit down in a meeting room for anywhere from 15 to 45 minutes every damned morning to talk about what we did the day before and what we're doing that day. Maybe what we do is ScrumFail? We had no process at all before other than what apparently is not actual waterfall but fits the literal description of a waterfall in that requirements pour down upon us from a tall precipice.
Jtsummers
That is a great example of the problem. This is also why I keep trying to get people in my office away from specific practices and big-M Methodologies and focused more on the principles at play.

Why does Kanban help in some offices and do nothing or hurt in others?

Two reasons for success: Luck or understanding. Two reasons for failure: lack of understanding or lack of commitment.

What does Kanban assist with, what principles?

It assists in elaborating and clarifying the workflow or processes in the organization or unit. This can be done many ways, Kanban is just one. But without understanding the, often unwritten, processes you cannot effect meaningful change (at best you're stabbing in the dark).

It also emphasizes focus by setting limits on "work in progress" which improves overall flow/throughput. It turns out that this is, generally, a good idea.

The ones who succeed don't succeed because of Kanban. They succeed because of those two basic principles (and other related principles and concepts that I'm not elaborating on here). Kanban was a mechanism which led to success by drawing on these ideas.

The ones who fail don't fail because of Kanban. They fail because they don't control WIP, or failed to describe their process accurately, so it provided no, or perhaps even negative, value. Why don't they control WIP? Maybe they aren't aware of that element of Kanban, or they don't believe that it can bring value and ignore it. They're too busy fighting fires so they don't have time to focus. Why don't they have an accurate process description? Often, because the process is dictated rather than discovered (You are doing X, even though you actually do A, B, and C).

That's just one practice and two principles that it is related to (there are others). This is the problem with Big-M Methodologies like Big-S Scrum and Big-W Waterfall and Big-A Agile, the easy part is the visible practices. So they're imitated. The hard part is the invisible principles and hidden practices (all the work that went into identifying the workflow, for instance). Repeat this across all the practices in these methodologies and you'll end up with a mess that succeeds by luck, or at least doesn't harm you so badly that you fail, but certainly doesn't offer significant assistance.

BurningFrog
Or is it "keep the new name and keep doing the old things"?
heymijo
From what I have seen it's probably more "keep doing the old things + add the name of and a part of some new thing."

Then like evolution, it's survival of the fittest with the entrenched old idea having the heavyweight advantage.

BTW, this is a great point you make! I hope my comment doesn't seem to discount it as your thought made my mind go to the experiences I have seen that led to this comment.

aedron
The term "waterfall" is a straw man, software development methodologies have always required iterations. Just look at the Rational Unified Process (the industry standard before agile): https://en.wikipedia.org/wiki/Rational_Unified_Process#Four_...

Every phase of the project has iterations, but iterations stress different things (requirements in the beginning, construction and handover in the latter phases).

pflenker
Some anecdotal evidence that waterfall is not a straw man: at least 10 years ago, waterfall was taught as waterfall without iterations at some German universities. This was the starting point, and many derived models, like the V-Model, where also taught, but iterations we’re nowhere in sight.
Jtsummers
Tragicaly, it's not a strawman, it's an enshrined project management method the DoD created from a misunderstanding of Royce, which escaped into the wild.

Now, most people who say they do Waterfall are quite mistaken. They don't, they do some sort of iterative method as you say. But they report as if they have distinct, linear phases with distinct linear steps, as if Waterfall were the reality and not an imagining. Which is itself problematic. This means that upper managemnet comes to believe that Waterfall works because they see it working, not realizing that the reports themselves are misleading.

Everytime one of the project managers tells me they're doing Waterfall I press until they admit it's "Modified Waterfall", by which they mean the V-model or Spiral or other models with explicit feedback loops/mechanisms. And it frustrates me to no end that they keep using the wrong terms rather than the precise ones, because now upper management has begun enshrining Waterfall again after two decades of improvements. Now we have to fight the same battles, to impress upon them that iterative methods are what we actually do, and that a strict linear flow is impossible.

Sep 01, 2018 · 2 points, 0 comments · submitted by fagnerbrack
I don’t think so. Building software is a creative process that benefits from team diversity in multiple aspects. You need both young and older people. I’m 54 and still going strong. :-)

Also, not every ‘new’ development is as new as it appears; “Old is the New New”. https://www.youtube.com/watch?v=AbgsfeGvg3E

childintime
I mostly work with firmware, which hasn't seen much innovation, especially on small devices (finally Rust is coming along). There is no way youngsters can compete with me in breadth of experience. They are still building their toolbox and design patterns, so they can learn a lot, including from me. I value their appetite.

I see myself as a child of my time, with home-grown skills typical for a time-frame. I see that time-frame fading into history much like pop-music is doing. Going by the example of rockstars, maybe my skills will still be in demand 20 years from now, because the original author has so much more depth.

In some ways I am at the peak of my skills, more focused on results and a well balanced, easy to evolve design. But grey, so not cool I suppose ;)

May 25, 2018 · 1 points, 0 comments · submitted by azizsaya
HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.