Lambda World 2018 - What FP can learn from Smalltalk by Aditya Siram

If you're tired of hearing about the virtues of Smalltalk (like I was at one point) and ask "if it is so good, why isn't it popular?", then watch @deech's talk (Aditya Siram) - "What FP can learn from SmallTalk" - ▶ this video I think it is the most accessible explanation of the marvel of Smalltalk, for those who were not lucky to work with it during the late 80-90s. Also I think Ruby is the mainstream language that is closest to Smalltalk today, with the idea that everything is an object and late-binding as much as possible. One thing I can't help point out is that Smalltalk / Alan Kay's vision of interconnected objects forming a recursive computing system is not the only "true" vision of OO out there. From Simula thru C++ and then Java and C# also are object-oriented (or class-oriented for those who care about the distinction), but they are statically typed. It is also OO because OO is a word, not a mathematical definition, and when people talk about OO, there is enough similarity between all these variations that we consider all of them to be in the same camp. Plus with the growing move towards strict static typing even in interpreted languages, which I think is driven by actual industry needs and programmer preferences than external marketing, it is becoming a disservice to think of statically typed OO languages as being somehow inferior to the true ideal of object-oriented programming.

in “Design Principles Behind Smalltalk (1981)” · View on HN

I am really glad they mentioned Smalltalk! I recently had a chance to experience Smalltalk and it was just mind blowing. Check out a video demo of the code introspection and visualization at minute 17 in ▶ this video

in “The Database Inside Your Codebase” · View on HN

I'd also add this talk "Lambda World 2018 - What FP can learn from Smalltalk by Aditya Siram " ▶ this video as well as the whole series of things that Tudor Girba & co. are doing with Glamorous Toolkit [link] I'd still recommend folks use Pharo over GToolkit for most things, as GToolkit lacks a bunch of polish and documentation (not to say that even Pharo documentation approaches anything of the quality of the Rust and Python ecosystems).

in “On Repl-Driven Programming” · View on HN

I think it's fair to say Smalltalk(s) have had in many aspects the most advanced IDE in existence at every moment since its introduction. Demos for a couple old versions: [link] Demo for Pharo: ▶ this video

in “IDEs we had 30 years ago” · View on HN

Not so much .NET/Java but Structured Programming (1972 Edsger W. Dijkstra, Ole-Johan Dahl, and Tony Hoare) has prompted the gradual backlash against switches. ( [link] , re: Duff's Device). Senior developers should watch the whole thing to understand how block scope and functions and classes relate. Modern development has drifted toward lots of small functions (which causes a mess because modern IDEs dont have supporting features like this: ▶ this video , re: gtoolkit). A switch requires you to look inside and reason about the internals of a function to understand how it will behave before exiting, as the compiler. This doesn't matter so much if you dont care about early exits (no branch prediction, etc). Either way, it's extra cognitive overhead and error prone for a small improvement in readbaility. It's the line where programming becomes tricky programming. As a thought experiment, imagine there is ANOTHER keyword that acts like an if/else (or switch with mandatory breaks). If A. it's terse, B. it's structured, C. it's readable, would that be better? We primarily use switch because it's easy to read (versus a ton of if {}/else {}), as it gives us almost-block scoping without having to define another indirection/function. Python has this switch equivalent in match/case, but you have to use Python to get it. Switch use is a syntax problem. Lots of software is colored by bad syntax and language design^. ^ I think most people realize that type hierarchies are a brittle/limited form

in “When are enums not a code smell?” · View on HN

To answer the question in a more practical sense than the plugging of a specific workflow and asking "Is this the future?", that the article posits: 1. Back to easy indirection resolution ( ▶ this video , re: gtoolkit) 2. Comments that are not inline, but can point to various blocks/parts of code and overlap (multiple comments can apply to single parts of code). 3. More support for unit testing. function call tracking ( [link] ). 4. Conducting behavioral studies via opt-in submission of eye tracking data. A great deal of data is flowing through IDEs and not being leveraged to improve the daily tools of developers.

in “What's the Future of IDEs?” · View on HN