21–30 of 74 posts
For those interested in learning Scala I'd recommend the free chapters from Scala for the Impatient: http://logic.cse.unt.edu/tarau/teaching/SCALA_DOCS/scala-for...
Scala is a fantastic language, but my heart seems to resist due to things like this (slide 27/42): implicit class RichSeq[A, C[A]
Scala, Haskell treat syntax as a chore.
As a Ruby developer, I can't get through these sorts of slides. My other languages are C, Go and JavaScript, and the Scala syntax is totally inscrutable to me. Isn't the point of slides presenting something that can be easily absorbed? And I can't just quickly look up these declarations either — Scala is too complex for that given my experience level. Is there a gentle introduction talk for Scala around so I can eval…
As a Ruby developer, I can't get through these sorts of slides. My other languages are C, Go and JavaScript, and the Scala syntax is totally inscrutable to me. Isn't the point of slides presenting something that can be easily absorbed? And I can't just quickly look up these declarations either — Scala is too complex for that given my experience level. Is there a gentle introduction talk for Scala around so I can eval…
As a Scala programmer I find Ruby syntax complex and inscrutable, almost like Perl.
To me, this type of development is much more natural and sane than the "one big clusterfuck" type of projects I've seen in Java et.al.
Edit: Also, dynamic languages let you make the tradeof between safety and speed. Sometimes you go slow and steady (simple code, tests..) and sometimes you just want to test something out.
As a Ruby developer, I can't get through these sorts of slides. My other languages are C, Go and JavaScript, and the Scala syntax is totally inscrutable to me. Isn't the point of slides presenting something that can be easily absorbed? And I can't just quickly look up these declarations either — Scala is too complex for that given my experience level. Is there a gentle introduction talk for Scala around so I can eval…
As a Scala programmer I find Ruby syntax complex and inscrutable, almost like Perl.
Here's a Ruby snippet. I don't want to pick on this particular project [1], rather, I've found that this is typical of Ruby code:
state_machine :state, initial: :active do
after_transition any => :blocked do |user, transition|
# Remove user from all projects and
user.users_projects.find_each do |membership|
return false unless membership.destroy
end
end
scope :not_in_project, ->(project) \
{ project.users.present? ? \
where("id not in (:ids)", ids: project.users.map(&:id) ) : scoped }
This is a copy-paste of a comment I made [4] weeks ago on another article.
[1] https://github.com/gitlabhq/gitlabhq/blob/4caaea824cf51670d1...
[2] https://github.com/gitlabhq/gitlabhq/blob/4caaea824cf51670d1...
[3] I split the line and inserted backslashes because HN gives me a horizontal scrollbar when it's a single long line; apologies if this transformation isn't legal Ruby, or changes the meaning of the code.
Earlier quoted context omitted.
Why do microsoft and google insist on static compiled languages?
Because they allow us to put very useful limits on the degree to which changes in a large and evolving codebase will violate the expectations of developers. When adding and changing code in large collaborative projects, the primary question in every developer's mind is "OK, what else depends on this, i.e., what is possibly going to break?" This goes back to the old wisdom of separating interface from implementation.…
Can you give me an example of a single ruby developer who thinks this is a good idea when writing new code/a library?
Earlier quoted context omitted.
Why do microsoft and google insist on static compiled languages?
Because they allow us to put very useful limits on the degree to which changes in a large and evolving codebase will violate the expectations of developers. When adding and changing code in large collaborative projects, the primary question in every developer's mind is "OK, what else depends on this, i.e., what is possibly going to break?" This goes back to the old wisdom of separating interface from implementation.…
Scala is a fantastic language, but my heart seems to resist due to things like this (slide 27/42): implicit class RichSeq[A, C[A]