From Rails to Clojure, Then to Java, Then Back to Rails • Hacker News Board

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#21

Post by _diyu » Wed, Mar 21, 2018, 4:46 PM UTC

tcopeland wrote: post #2

In the "things learned from Ruby" section: Focus on strong object oriented programming What I've learned from Ruby is to favor functional programming concepts - minimize side effects, isolate state mutation, etc. Ruby is definitely OO, but when my Ruby code is more functional it's less buggy, easier to understand and move around, and generally less convoluted.

I've always had better luck restricting FP to using things like map, reduce, filter, (etc) inside methods as an implementation detail, but having the structure of the app use OOP.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#22

Post by yxhuvud » Wed, Mar 21, 2018, 4:47 PM UTC

bitwize wrote: post #14

tcopeland wrote: post #2

In the "things learned from Ruby" section: Focus on strong object oriented programming What I've learned from Ruby is to favor functional programming concepts - minimize side effects, isolate state mutation, etc. Ruby is definitely OO, but when my Ruby code is more functional it's less buggy, easier to understand and move around, and generally less convoluted.

I've learned to think of objects as not exactly monadic, but monad-like in their pattern of use: whenever there's a bit of state that I need to track and isolate from all other state in the system, wrap that in a class. The allowable state transitions then become methods.

Right, and most of the times, if state have different life times, then it should be in different classes.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#23

Post by mattnewton » Wed, Mar 21, 2018, 4:49 PM UTC

erokar wrote: post #20

oregontechninja wrote: post #15

Earlier quoted context omitted.

It's because we don't like or approve of rails. It doesn't make business sense to us (us being a completely anecdotal group of young developers I'm friends with). There are other solutions that provide sufficiently more developer speed and safety, while also providing much better performance than any rails application. Edit: I guess I just hang out with like minded people, but our biases shouldn't negate the fact tha…

What other solutions are you youngsters using then? Elixir/Phoenix? Django/Python? Node? Haskell?

Not OP but in my limited experience the MVP slot is mostly held by Django, with Node + typescript, Go and Elixir being the “safer, faster” variants “kids” are using.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#24

Post by noahc » Wed, Mar 21, 2018, 4:49 PM UTC

yxhuvud wrote: post #22

bitwize wrote: post #14

Earlier quoted context omitted.

I've learned to think of objects as not exactly monadic, but monad-like in their pattern of use: whenever there's a bit of state that I need to track and isolate from all other state in the system, wrap that in a class. The allowable state transitions then become methods.

Right, and most of the times, if state have different life times, then it should be in different classes.

What do you mean by life times?

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#25

Post by yxhuvud » Wed, Mar 21, 2018, 4:53 PM UTC

noahc wrote: post #24

yxhuvud wrote: post #22

Earlier quoted context omitted.

Right, and most of the times, if state have different life times, then it should be in different classes.

What do you mean by life times?

Is the state eternal or not (ie is it immutable)? Will the state typically change at the same time as some other state (like an address, or stuff related to some other event)?

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#26

Post by lkrubner » Wed, Mar 21, 2018, 4:59 PM UTC

This is a bit odd, that concurrency would be listed as something they gained from Java, rather than Clojure:

"Clojure: considering the difference between being easy and being simple. Clear difference between data and logic that changes that data. Distinction between pure functions and functions with side effects, try to separate them. Let’s try to make simple code by default."

"Java: performance, concurrency and strictness."

Maybe they mean they were forced to think about concurrency in Java?

I don't think any reasonable person would argue that concurrency is easier in Java than in Clojure.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#27

Post by markoman » Wed, Mar 21, 2018, 5:00 PM UTC

tonyedgecombe wrote: post #5

Another thing I’m getting is that the new kids won’t like rails, and it’s being harder to hire. I'm surprised by this, to me the language used would be a long way down the list when evaluating an employer.

Ruby is still a beautiful language, particularly for its object oriented-ness. And I think Ruby's nature, simplicity and power appeals to young people, however the resurgence of a towering Javascript/NodeJS is hard compete with. These are market forces that really matter when you're wondering what language & platform to use for your MVP. In recent surveys, Ruby & Rails has fallen to the bottom of the list among the former stars of programming languages. Python has data science & machine learning to keep it strong and new stars Elixir/Phoenix and Golang are sucking up a lot of oxygen that would otherwise go to Ruby & Rails. And let's not forget Bubble (visual app building) and the Zero Code Startup.

I really think Pedro (the blog post writer) has an excellent point about being a polyglot but trying to qualify as a Senior Engineer except I'm older and have even more platforms & languages behind me. Its a serious problem because I have the experience to easily be a Sr. Engineer or manager but my experience isn't concentrated long enough anywhere to make me useful enough to warrant the role.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#28

Post by mullsork » Wed, Mar 21, 2018, 5:08 PM UTC

blunte wrote: post #16

tcopeland wrote: post #2

In the "things learned from Ruby" section: Focus on strong object oriented programming What I've learned from Ruby is to favor functional programming concepts - minimize side effects, isolate state mutation, etc. Ruby is definitely OO, but when my Ruby code is more functional it's less buggy, easier to understand and move around, and generally less convoluted.

Ruby used functionally is great, but it takes an already time-inefficient language and amplifies that weakness (lots of creating new collections and returning them, whereas normally in Ruby you would modify elements within the collection).

Isn’t there something called LazyEnumerator that deals with this? In terms of chained .map at least

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#29

Post by pjmlp » Wed, Mar 21, 2018, 5:11 PM UTC

tonyedgecombe wrote: post #5

Another thing I’m getting is that the new kids won’t like rails, and it’s being harder to hire. I'm surprised by this, to me the language used would be a long way down the list when evaluating an employer.

It is always on by top list, after learnig what the application and domain is all about.

The majority of HR departments tend to suffer from myopia for anything beyond the last couple of months on the current employer.

So always take care not to land in something that will be hard to get out of.

Re: From Rails to Clojure, Then to Java, Then Back to Rails

#30

Post by ken » Wed, Mar 21, 2018, 5:12 PM UTC

blunte wrote: post #18

Clojure does not have an alien syntax. As with Lisps in general, it has almost no syntax. (operator param param ...) Done.

It has much more syntax than any other Lisp I know, and it seems alien even coming from Common Lisp. In addition to the usual (list) and 'quote and `backtick and :keyword and ;comment, it has [vector] and {map} and #{set} and #(function) and @deref and #"regex" and ^metadata and #?(:conditional) and ...

(Yes, several of those are implemented as reader macros. I don't see how that would make them any easier to learn than the same feature implemented as "syntax".)

That's not a knock against it. I think Clojure is the best general-purpose language today, but we've come a long way in the past few decades. Lisp is no longer a language whose implementation fits on a blackboard (and everyone extends it in their own way). We've discovered a bunch of common functionality that almost all programs need, and pushed it up into the stdlib and language.