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

#141

Post by pimeys » Thu, Mar 22, 2018, 9:57 AM UTC

kureikain wrote: post #137

pimeys wrote: post #95

Earlier quoted context omitted.

It looks nice, but then again: irb(main):002:0> 10.methods.count => 133 Oh well...

What's wrong with this? What is your expecation?

Depends of course what kind of systems you're building. Just the footprint of an integer is too large in Ruby to do anything fast. I'd expect features such as `days` to be a part of Date library that holds an interface accepting certain kind of objects giving dates back. If I don't need these features, I don't want to hold the functionality at all inside an integer.

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

#142

Post by pimeys » Thu, Mar 22, 2018, 9:59 AM UTC

innocentoldguy wrote: post #112

hashmal wrote: post #89

Earlier quoted context omitted.

> Community feels like the good old Ruby days, but better I really miss that old Ruby community. It was full of that hacker spirit, everyone trying stuff, no one to crush your creativity. Then the startup hipsters took over and came up with good practices, style guides, gems you absolutely had to know to get hired, etc. It drove me away from Ruby, actually. It just wasn't fun anymore. I hope it doesn't happen with Ru…

Your comment really speaks to me. I'm in the process of transitioning my career out of development altogether for the reason you mentioned getting out of Ruby. It just isn't fun anymore. I haven't been able to find a company with a good hacker-spirit since 2010. I like programming, and will probably continue with languages like Elixir and Haskell, but as far as the day-to-day work goes, I'm done.

Just go into lower level. In many companies people have message brokers that need consumers. That's a good place to introduce languages such as Scala, Rust, Haskell and so on. Try to stay away from frontend and hack away.

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

#143

Post by mullsork » Thu, Mar 22, 2018, 10:10 AM UTC

djur wrote: post #118

bbatha wrote: post #70

Earlier quoted context omitted.

There is absolutely a benefit to lazy if you're doing more than one combinator even if you ultimately need to iterate over the whole list such as the join case. The lazy version basically turns into a = "" (1..1000).each { |i| next if i.odd? i *= 2 i += 1 a Where as the non lazy version turns into: odds = [] (1..1000).each { |i| odds Which means that you have you went from N iterations to 5*N iterations, with 5 inter…

That's how it could work theoretically, but in practice lazy iterators are much less efficient due to their implementation. I benchmarked it here: https://gist.github.com/mboeh/bb480d93c71046e23816f2c24c23e3... When applied to the same amount of work, lazy iterators consume more memory and take more CPU time than the equivalent non-lazy chained iteration. There's a place for lazy iterators, but you should pretty much…

Thanks a lot for the insight!

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

#144

Post by joncampbelldev » Thu, Mar 22, 2018, 10:59 AM UTC

yxhuvud wrote: post #97

joncampbelldev wrote: post #72

Earlier quoted context omitted.

Except if you're using immutable data, pure functions and explicit state there's a lot less room for OO which (as presented by ruby, java etc) involves mutable data accessed/changed via methods that conceal their state.

Nothing in the concept of OO enforces mutability. The paradigm doesn't enforce anything at all there. You want immutable objects that never changes once created? Fine, go for it.

And yet 99% of code written in Java, Ruby, is based on mutable objects.

Its not about what is possible, we're all familiar with the turing completeness of everything. It's about what is: the default + easy + encouraged in the ecosystem.

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

#145

Post by jashmatthews » Thu, Mar 22, 2018, 11:47 AM UTC

pavlov wrote: post #140

tinco wrote: post #121

Earlier quoted context omitted.

It's not just 'anything' that objects are extended with in Ruby, they are extended with suitable methods pertaining to the domain at hand. 'seconds' is a conversion method of one type into another. You might as well ask why do objects have a 'toString' method. Because it is convenient.

Why does one conversion method have the “to” prefix and the other doesn’t? I guess because the inconsistency looks somehow prettier. But this is what drives me up the wall with the Ruby ecosystem: seems that whenever API designers had the choice between consistency and fun gimmick, they chose the latter. It makes some people feel happy, but often makes the next person who has to read and maintain the code miserable.

10.seconds is not part of the Ruby stdlib. It's Rails ActiveSupport. That's why it's different.

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

#146

Post by jcadam » Thu, Mar 22, 2018, 12:15 PM UTC

mnm1 wrote: post #123

jcadam wrote: post #34

I've tried a lot of different languages over the years including Ruby, Go, Scala, and Haskell. Ruby actually isn't too bad if you don't use Rails. Between Rails and stuff like Spring over in Java-land I've developed a strong hatred of huge frameworks :) Clojure, however, is the one language that just 'clicked' for me almost immediately. In fact, I'm pretty certain I'll be sticking to Lisps as much as possible from he…

Same here. It's really hard for me now at my day job when I have to write OO. Clojure and functional languages opened up my eyes to OO shortcomings I've been trying to work out for over twenty years. Since I started, I've always felt that there were many things not right about OO and developing using these giant frameworks with so many useless abstractions has gotten old and tiring. Most of my time is spent working a…

I know. You think I'd be sitting here slinging Java code if there was a shortage of Clojure programmers?

Even in my local area (not a tech hub), I'm aware of one small software shop using Clojure, and they have no trouble finding people.

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

#147

Post by wrmsr » Thu, Mar 22, 2018, 2:52 PM UTC

cutler wrote: post #126

dogweather wrote: post #117

Earlier quoted context omitted.

Yes - Ruby makes it easy. I'm run into the downside, though, that Ruby isn't optimized for immutable operations - tons of object instances created. I've needed to 'pythonize' my Ruby code in the worst cases - using mutable functions to dramatically reduce memory usage.

Can you say more about this Pythonisation process? How is Python any better at immutable operations? Ruby and Python are both OO languages which can be used in a procedural style. Hell, you can write a whole app in Ruby without creating a single class if you so choose.

I think what they mean by 'pythonize' is ditching fluent functional style and embracing dumb imperative mutability for the sake of efficiency. Rewriting sequence compositions as stateful for-loops. Idiomatic Python is more pragmatic than Ruby in that regard, stupid=good (yet ironically Ruby's strings are mutable and Python's aren't :p).

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

#148

Post by ken » Thu, Mar 22, 2018, 3:00 PM UTC

dragandj wrote: post #73

ken wrote: post #30

Earlier quoted context omitted.

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 t…

It's only optional though. You can use (list 1 2 3), (vector 1 2 3), (hash-map 1 2 3 4), and (fn [x] (inc x)).

I wouldn't say features like [vector] are optional alternatives to (vector), if you can't write even the simplest function without using the [vector] syntax.

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

#149

Post by blunte » Thu, Mar 22, 2018, 7:02 PM UTC

yxhuvud wrote: post #96

blunte wrote: post #88

Earlier quoted context omitted.

While I much prefer writing Ruby to Python, Python is just dead simple to get real work done with. It's not elegant, but it's still so much less nasty than C++ or Java. Ruby's #1 problem, for me at least, is that your small project someday runs into a performance wall. I don't know the latest benchmarks, but last I recall Python was about 8x faster than Ruby when both are being interpreted. Yes, there's JRuby, but th…

Say what? Ruby has been faster than Python for interpreted code for years now. Granted, Python is faster for tasks like those Numpy solves, but in arbitrary execution performance, python is just slower. 8x has NEVER been true. That must have been you doing some really bad stuff in one of them but not both.

I stand corrected. I used Ruby for 6 years, up to 2015. I wasn't using Python during those years, but I thought I had heard or read about the 8x speed difference in favor of Python.

For sure, Ruby was slow for what we were doing... processing millions of rows of data was so slow that it caused me to decide to try Go (and the same Go program was hundreds of times faster). But I didn't try Python then.

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

#150

Post by hashmal » Thu, Mar 22, 2018, 8:12 PM UTC

MrBuddyCasino wrote: post #106

pimeys wrote: post #93

Earlier quoted context omitted.

This definitely feels my own golden age now being able to write Rust and seeing all these great people doing interesting projects and hacking things...

The ecosystem and the community is fantastic. But I have to say, Rust is a harsh mistress. Guess I need more practise.

Rust is a very different beast indeed. The fun clearly doesn't come from the "flexibility/easiness" of the language (compared to Ruby), but really from the feeling that we're all still discovering a new paradigm, new ways to do things using its various features. Building state machines out of the type system is an example. Rust is still kind of a blank canvas just asking to be painted on.