RailsConf 09: Robert Martin, "What Killed Smalltalk Could K

Robert Martin (Object Mentor, Inc.)
"What Killed Smalltalk Could Kill Ruby, Too"

[@llothar68]

And 6 years later, it looks like Ruby and Rails is dying.

[@rrr00bb1]

computers stopped getting faster, while devices get smaller and take on more demands. battery life and power consumption now matter. if you scale up, you need to pass on your AWS bill to your customers. pouring a bunch of micro-services into a cluster needs to be efficient. so static-oriented languages are making a comeback (C/C++/ObjectiveC++ not really going away, D, Go, Rust, etc). We are getting diminishing returns from yet another language that makes big performance tradeoffs for higher-level code. Now it looks like we are headed to better tools to just find bugs at compile-time. A factor of 10 in memory consumption and speed matters greatly if you end up running on a mobile device.

[@llothar68]

+rrr00bb And don't forget that more and more code is done on the client side and the server side is just a bit business logic and json database. Even templating is done on the web browser.

[@rrr00bb1]

Lothar Scholz i was going to mention pseudo-javascript compilers/minifiers, NaCl, etc. it's more urgent in the server-side where the product-seller pays the bills and has to concentrate the compute power. but it's definitely an issue, just sending out the compiled javascript/resources and having it run nicely on a tiny phone - without a horrible battery-sucking experience or terrible queueing and latency.

[@KeldonA]

Play this at 1.5 speed you'll swear blind you're listening to Steve Martin! Thoroughly enjoyed the talk.

[@nickbarton3191]

I love uncle bob's talks, they are so real and speak to me of my every day experiences as a software developer. I've been struggling with some UI code of which the logic should be in other objects making it difficult to test. Tomorrow (Monday) I'm going to refactor it and develop those objects TDD style.

[@mmille10]

Liked his definition of professionalism: Someone who, in the face of pressure, falls back on their rules and discipline, and operates without fear.

[@kevingrieger]

This is my favorite programming video on youtube

[@philippebackprotips]

Well, Pharo is quite on its way to the spotlight! Anyway, having been programming with a lot of languages, Smalltalk still feels the best of the bunch. Like in "Pleasure to program".

[@mbalagueraj]

Maravillosa charla...! delightful talk, thanks Robert.

[@richardgreen7225]

What killed Smalltalk? (and could kill Ruby) - Too Easy . . . to make a mess (lacking TDD). - Arrogance: - - Walled community . . . isolated from the outside world. - - - Dealing with poor industry standards / frameworks / schema / protocols. - - Parochial . . . failure to address needs of Enterprise. What could save Rails? - Professionalism - - Sticking to professional practices (e.g. TDD, Clean Code) (don't hack) - - Solving the problem of nasty architectures / schemas.

[@bhabanism]

And Ruby is dead.

[@RomyIlano]

what a great, passionate speaker!

[@CurtisOvard]

"Tests eliminate fear" - great statement

[@zetaconvex1987]

Every minute was entertaining, especially the last one.

[@AreHusby]

I feel his points apply to Scala too, perhaps even more so than to Ruby.

[@billsix]

I was confused by the introduction, as it appeared to have nothing to do with rails, or programming at all; but oh man I was wrong.watxhing how he weaves various themes together towards his end purpose is inspiring.

[@randito]

What a fantastic speaker...

[@horridohobbies]

It's easy to make a mess in any language; Smalltalk is not particularly predisposed in this regard. In my decades-long career, I've seen many large, messy projects...and none of them was written in Smalltalk! (Full disclosure: I've professionally used FORTRAN, Tandem TAL, C, C++, C#, Objective-C, Java, Smalltalk, and Python.) The key to avoiding a mess is strict project discipline and good quality management.

[@Urthor1]

Pretty sure, as everyone knows, the truth is it all revolved around "you can't charge money for a programming language." They teach kids Java in high school because it's free. Who can compete with that (equally free Python!).

[@horridohobbies]

@@Urthor1 Smalltalk is free, too. Pharo is free. Squeak is free. Dolphin Smalltalk (for Windows) is free. GNU Smalltalk (for command line lovers) is free. Amber (for front-end web) is free. Cuis Smalltalk is free. Take your pick. Many businesses prefer robust industrial support for their programming tools. For them, there are Instantiations, Cincom, and GemTalk Systems. So there is something for everyone.

[@Urthor1]

@@horridohobbies Oh well yes it is now, in the 2010s. I was thinking historically, certainly there was a helluva lot less "free (and yes, absolutely free as in beer)" Smalltalk stuff around the late 90s, when the Java/C# inflection point really got going. And free (as in beer) is very important, given what you said: "Many businesses prefer robust industrial support for their programming tools." This is the most important thing. These days this robust industrial support now comes via Github Issues. The FOSS community has *directly out competed* all sorts of paid platforms. This was before I learnt to read, but FOSS absolutely tore Digitalk et al, and many others to bits. The FOSS community plus the Red Hat/MongoDB "open source with platinum grade enterprise hoo-ha" model took apart small talk like a tin can. Because ultimately the Github Issues -> "readable source code" -> feedback loop between hobbyists/academics and industry worked out. It's really important episode to think about a lot of ways, because building those feedback loops, community building, is now the most important thing in open source software. I truly believe that in this era, writing a good README is almost as important as writing good software. Being a community builder who gets a community behind you is more important to getting your software to go further than writing the code almost. From a community building aspect, I wonder how Pharo et al can fit in. The syntax itself is lovely.

[@Urthor1]

Unrelated issue I really think about re the failure of Smalltalk, I'm seeing in Pharo. I think, the degree to which Pharo is divorced from the file system is pretty extraordinary. I've truly never seen any similar *anything* on a desktop computer that completely ignores the wonderfully integrated paradigm of file system, text files, tree graphs. The syntax and the *latency* of the Pharo is extraordinary. Getting my head around a completely different dependency graph of classes is such a challenge. The marriage between mathematical linear evaluation, text parsers, the file system, and functional programming is a very *intuitive paradigm.* That functional/procedural paradigm is very much the zeitgeist right now (lovingly talking about Haskell days in college whilst spitting out Javascript/Python/C# one liner routines in multi-paradigm languages is corporate software in a nutshell. Purity is impossible, instantiating struct blueprints is pretty important for some things). There's a lot of strength there, a lot of intuitiveness. Such a very strong connection to the underlying operating system and how we pass equations to our evaluators via registers. Figuring out how to fit what I have there and love into my model of how Pharo works, while I plough through Pharo by example, is going to be a big challenge. With Pharo especially, you have the graph of how all the subroutines are laid out being very orthogonal to the linearly parsed subroutines themselves. That's very... my head is working at 100% to understand that. And I haven't even touched merge conflicts yet.

[@Urthor1]

Maybe the answer is Elixir haha.

[@_mxgel]

That opening is sick....wow!

[@horridohobbies]

And irrelevant to a discussion about Smalltalk.

[@kurrator1]

I agree. When it comes to simplicity and ease of use Smalltalk language and its browsers are IMHO better than everything I've seen so far for Java or C#, Ruby, Python, etc.

[@CBaggers]

Wow, this guy is a phenomenal speaker. Best case for test driven development I've seen. Also seems very relevant for lisp

[@curiosull]

Almost all the reasons stated I say they apply now with cpp. Instead of enterprise needs we may refer to the web needs.

[@ads]

TLDR: it's just too easy to make a mess (21:40)

[@HMijailAntonQuiles]

Still, the whole Ward Cunningham intro is worth the 15 mins. (I wonder what were the very first 5 mins about...?)

[@Khaltazar]

@@HMijailAntonQuiles - Robert Martin always does that. He says he likes to do it to be unique and to get the audience's attention and get them thinking.

[@HMijailAntonQuiles]

Sounds like another way of saying that his talk isn't unique and interesting enough per se, so he decided to waste 5 mins of everyone's lives. :/

[@ads]

41:59 professionalism is discipline to wielding of power

[@ibraheemmoosa]

What did eventually kill Ruby?

[@ruffianeo3418]

What no one ever mentions is that a large base of test code also can prevent fixing stuff which would change the functions interface of the code under test, because it would require tedious maintaining of the test code. Having unit tests is important but not the solution to all problems and they also create new fears while removing others.

[@Dacusx]

Referring to the last statement, I would prefer that surgeon who operates on my heart finishes before "deadline", instead of calmly allow me to die. Also it seems to me CO's and managers of enterprises would want developers to behave similarly.

[@fdeutschs]

@stingerster No way ! I personally think it totally kills the elegance of the Smalltalk language. Is not that bad but I find it very confusing syntax, particulary dealing with the different ways to handle memory, and not that dynamic as ST or Java. My point of view, of course.

[@horridohobbies]

IBM thought highly enough about Smalltalk in the enterprise to launch the VisualAge family of software tools in which Smalltalk was deeply entwined. Smalltalk could very well have served enterprise needs, but it was derailed by competitive forces. Smalltalk needed better PR and marketing. Smalltalk is taking a run at web development via Amber and Seaside; it could use some PR and marketing NOW...

[@reiknir]

"IBM thought highly enough about Smalltalk in the enterprise to launch the VisualAge family" and then get rid of and cancel it wholesale ........

[@horridohobbies]

reiknir Exactly. "Derailed by competitive forces." IBM saw Java as a threat and reacted badly to it (as they often do).

[@llothar68]

The problem was that when someone complained about the license fees they arrogantly replied that a software developer seat will cost a total of $50000 in licenses (or was it Rational?). Java was free. It was Open Source that killed Smalltalk.

[@horridohobbies]

Well, Smalltalk is hardly dead: hackernoon.com/what-makes-a-programming-language-cool-f40401f0f929. But you're right, Smalltalk couldn't beat "free." Today, it's a much different story. There are many free Smalltalks. Pharo is most actively being developed. And Smalltalk continues to be commercially used, as it has been for over three decades.

[@reiknir]

"Java was free. " It was not free, it was only open sourced a decade after its introduction and even then only partially. Even though IBM implemented their own Java stack, they paid licence fees to Sun.

[@Archie3D]

I don't use TDD. And I don't do debugging that much. Why? I use design by contracts.

[@rrr00bb1]

tests are far more popular in environments where you don't have rich types or contracts, as a lot of the tests are effectively doing contract checks (where types are a subset of what you can do with contracts). if you had a dependent type system (even if it were only simple things like null checks) and dbc, you actually do have the simplest tests. dbc would also allow languages to get rid of a lot of unsafe code that is tolerated for performane's sake. i really wish that the long OOP detour of the 1990s had been spent taking DBC into the mainstream.

[@ads]

45:59 Green band and TDD

[@coop4476]

Ryan Ponte he's talking about you : )

[@samsmith1580]

Smaltalk never died because it was never a thing. It never had it's day in the sun because it was just too diferent. We have spent the last 40 years coming to terms with what Smalltalk is. C++ and Java were created because people couldn't wrap their head around OO so they created Class orientated Languages. Only now are true OO languages coming back into fashion as the failures of Class based design and design patterns become evident. True OO programing does away with the need for both. Ironically it is java-script with Its incredible flexibility that has opened the worlds eyes to true OO. But JavaScript has too many flaws and Ruby is a far better and consistent language. The main problem Ruby has is that its interpreter is slow. Millions has been pored into the optimizing of the PHP interpreter and Ruby has a very long way to go to catch up.

[@piecepaper2831]

13y later ruby died 😢

[@berkut2006]

@kefsound lol

[@Tygryss84]

not that I don't like bob, but I get the feeling that if you seen one his talk, you've seen them all :) - He's a great speeker, and enjoy his listening to him, it's just that I don't feel I learned anything :) - but still it's an hour well spent :)

[@zeroxcub]

TLDR: too easy to make a mess + developers arrogance

[@saf271828]

Every minute to run tests? My ass! Try every five seconds! :-) Unit tests should run fast so you can get immediate feedback. A minute is just too long.

[@kefsound]

4 viewers use PHP.

[@rh9280]

I can't say I like this guy's attitude. Sound's like he knows everything. It's enough to put me off Rails!!

[@3amsleep]

well... google him and then tell me if he's entitled or not...

[@3amsleep]

im sorry, maybe you googled "lame butthurt comebacks"

[@MCNOISE666]

🤡

[@JosephAnnino76]

Great insights. I had felt a real sense of arrogance from the Ruby world. It for a long time was the hipster programming language. But that changed. Node.js has provided some competition for cool. Lots of other frameworks in many other languages now compete very well with Rails. There is also a PHP renaissance going on. A lot of ideas the Ruby world was pioneering in putting into practice have made it to other languages, benefiting them greatly, and vice versa. All of this I think has given a little more humility to the Ruby world, which it badly needed, and is important for its survival. Otherwise, this guy is a bit of a sexist blowhard. He has to check some of his own arrogance. For those watching something like this from the outside, his attitude doesn't always jibe well with his otherwise knowledgeably articulated notions of professionalism.

[@crabsynth3480]

Sexist blowhard? Was that because of the harmonal thingy? Because that is ridiculous... it was simply a ying yang metaphore... and you have no idea how much he speaks up about the gender gap in programming... ive seen him strongly defend the case for women in programming during many of his interviews and talks.

[@MCNOISE666]

🤡

[@YoLninYo]

does linux kernel team use TDD? case closed.

[@saadazzz]

7 viewers use PHP

[@holz_name]

You don't need TDD for clean code. Just write your code and in parallel write the unit test that tests for every inputs that are documented. You do have a vision&scope document where the use cases are described? So, for every use case write the code and in parallel write a unit test that tests your code. No dogmatic TDD "laws" are needed, you can write production code and your tests in parallel, no excessive unit tests are needed either. What your use cases don't cover, just ignore it.

[@macgyver3239]

"Just write clean code". From your lips to God's ears. I know only two programmers who even tried to write clean code.

[@ppalacz]

Mostly entertaining fluff; questionable content. "Too easy to mess up" as the reason? you must be joking.

[@sarmala]

"Too easy to mess up" sounds like one of the best reasons something like a programming language can loose popularity.

[@raneksi]

Annoys me how he's walking around so anxiously.

[@holz_name]

Nice talk about TDD and tests. But in practice even if you cover 100% with tests and use your TDD on the punishment of whipping, nobody will just improve code on a production system. First and foremost, because in software development those maxims are king "what works, works" or "don't change a working system". Second, because of perceived "code ownership", i.e. don't change my code because reasons. Third, because nobody code if they are not compensated, i.e. paid for.

[@j-pg9669]

Holz Name. Yes "what works, works" until your boss ask you to change something in there. Having to make a change in a clean module take way less time because it take you way less time to understand what the code does. " i.e. don't change my code because reasons" If you have 100% test coverage, then your tests should show the behavior that you expect from a module and the programmers will know they broke something. If you can't trust someone touching your code... Why did you hire that guy?? "nobody code if they are not compensated". Thats an administration issue. If your boss does not understand the benefits of refactoring and clean code, that's sad for you... There is plenty of programmers who are paid for doing some refactoring here and there. sorry for my english...

[@holz_name]

J-P G I was comparing the theoretical TDD approach to the real world. In the real world we have those issues, which are economical and social issues. But I agree with you mostly. I myself, I don't think the TDD approach is practical. I just programmed a prototype for an application that will get FOREX data via the OANDA REST API, and if I would have used TDD, I would have spend 1 week and with no design at all. Instead, I do a first a draft of the design, test my classes for my use cases, and if my use cases changed, I change the design and the tests. I more like the Use-Case-Driven-Development model. Is there such a thing? Maybe I invent it and go giving talks and seminars about it.

[@j-pg9669]

Holz Name I agree that TDD is not the answer for that kind of project! I had long terms apps in mind.