@borkdude: (IMO, of course) - I consider Ruby syntax a bug, not a feature. Plus it’s not the JVM or JS, so is pretty much a non-starter for anything I need to do.

hehehe, I thought I was the only one that disliked ruby syntax. The entire “ruby optimizes for developer happiness” bugs me. It certainly doesn’t give me any joy. 🙂

I used Ruby for a while, but I just don't like the whitespace indentation, just like in Python

Also in RoR: too much magic

I’m on the fourth iteration of Coursera’s "Programming Languages" (Prof. Grossman, Univ. of Washington), and it uses Ruby for Part C… and doing that course really turned me off Ruby 😸

I don’t like the syntax much (using punctuation to signify certain variable scopes is … icky!) and I don’t like how crazy dynamic it all: you can’t read a + b and be sure it really adds two things together because someone may have patched it at runtime to do something else.

Most of all I find several of its features only "half thought out" and inconsistent (and then there’s ten ways to do almost everything which I also find very annoying since it makes "best practice" hard to establish).

@seancorfield: you're doing a course four times?

@seancorfield: or does it have something new each time?

First time as a student, 2nd / 3rd times as Community Teaching Assistant, 4th as a Community Mentor.

But I love the course. It’s fun.

aah

what are things you learned from it, that you wish you knew earlier?

Standard ML in Part A (statically typed FP), Racket in Part B (dynamically typed FP), Ruby in Part C (dynamically typed OOP). The assumption is more people use statically typed OOP in their jobs so they don’t need to dig into that from a PL design p.o.v.

It’s a good refresher on "pure" FP thinking and the "wax on, wax off" mindful practice of FP techniques.

Mostly I enjoy the practice and the cross-language / cross-paradigm comparisons. There wasn’t really anything "new" for me (given my formal C.S. background and that I did a PhD in FP back in the 80’s!). First time thru it was a good way to learn Ruby more deeply.

ok, I kinda know the languages mentioned (static FP: Haskell, Scala, F#; Lisp: Common Lisp, Clojure; dynamic OOP: Ruby) so I don't think it would offer me many new things

I did a course on university where they contrasted OOP, FP and logic programming, it was fun

The FP/OOP comparison is probably the most "interesting" part but I do enjoy the "mindful practice" of back-to-basics stuff to hone "muscle memory". I did "Introduction to Systematic Program Design" a couple of times for that as well...

well, keep mentioning those titles here, so we'll have the chance to join when they start 🙂

…that was particular cool because the instructor is Gregor Kiczales

When I heard about aspect oriented programming for the first time, I thought: what's the big deal, this is trivial in Common Lisp 😉

maybe it's not true though, I haven't really given it much attention

an old colleague mentioned this name when he talked about a Lisp book

LOL… yeah… I did a fair bit of Lisp at university back in the early 80’s and it was core to my PhD work, while I was surveying other FP languages.

http://dblp.uni-trier.de/pers/hd/k/Kiczales:Gregor.html <— list of tech papers by him

He’s done a bunch of stuff on AOP coincidentally.

I think both Lisp and Smalltalk would have been much more successful if they’d had more conventional tooling, like other languages. They mostly both had these "walled gardens" of a complete self-contained "environment". Very cool in and of itself but not so good in the "plays nice with others" aspect.

I remember in the 90’s HP was looking at creating a similar environment for C++ (when I was on the ANSI C++ Committee) but abandoned it due to the paradigm shift needed for tooling.

Talking about ruby, a colleague of mine had to update his build server running jenkins, which introduced a new mysql version which broke some gems. He had a lot of "fun" getting everything running again. At first I was like, ok, gem hell, then I was like, ok, I heard the same thing about nodejs and npm and then I remembered our own application which uses gradle and a lot of dependencies + who knows how many more transitive dependencies and regularly breaks (especially different jackson / jersey versions are very fun to deal with). And finally I remembered that its all been there already. The first time I heard about that was the DLL Hell from windows. I find it kind of interesting that there seems to be no programming language that has a working dependency story. Rust has similar problems, breaking stuff on upgrades (not rust itself, but project dependencies updates). The same goes for C / C++ with its dynamic / static linking...

Folks keep telling us OSGi will fix that for the JVM but it’s been around for ages without huge adoption (it seems) so I’m guessing that it trades off one set of problems for a different set of problems…?