Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After reading “Rails is yesterday’s software”, I need to reply

codethinked.com

Post reply on HN
Print view View original

111–120 of 219 posts

Re: After reading “Rails is yesterday’s software”, I need to reply

#111

Post by TheOtherHobbes »

dschiptsov wrote: post #93

There is, perhaps, a law, such that any project with a strong tendency to pile up more crap instead of reducing it to "just right, when nothing else could be removed" (a-la 9P2000 protocol, and few foundation libs of Plan9) will end up in a J2EE-like pile of collective stupidity. At least, everything in nature tends to get reduced to a local optimum by a straightforward optimization process of trial and error. There…

This should be studied in comp sci. Instead of building compilers and interpreters in the abstract, there should be a serious study of how languages/frameworks are created and developed in the wild.

I suspect there are easily visible patterns and trends, and they tend to repeat over and over.

The corollary is that specific languages can't fix cultural issues unless they're designed to do that.

Re: After reading “Rails is yesterday’s software”, I need to reply

#112

Post by dragonwriter »

carsongross wrote: post #41
67726e wrote: post #33

Earlier quoted context omitted.

What makes you think that being able to produce HTML is such an important piece, and that Raila delivers better than most other frameworks?

HTML gives you HATEOAS without thinking about it: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... and is the minimum level of complexity necessary for a human web interface. Rails isn't necessarily better than other platforms at producing HTML: it does support rendering partials which is nice: http://guides.rubyonrails.org/layouts_and_rendering.html . So, rails is pretty good at it, but I can imagine…

> HTML gives you HATEOAS without thinking about it

No, it doesn't, though it certainly makes it simpler (than something not designed as a hypermedia format) to do HATEOAS if you think about it.

Re: After reading “Rails is yesterday’s software”, I need to reply

#113

Post by 0xfaded »

Dynamic languages reduce the formal overhead required to develop new ideas.

I can't imagine that an "eliminate boilerplate via convention at the cost of explicitness" mentality would have evolved independently in a world where assurances are earned by proving extra properties to the compiler.

However mordern compiled languages now formalise the shortcuts afforded by dynamic languages, e.g. type inference, generics, implicit conversions, typesafe macros, type classes, etc.

Similarily conventions popularised by rails-esqe frameworks are being formalised using the tools listed above.

I fall into the scala camp, but have used rails at a previous job. My guess is I need 1.5x scala lines vs Ruby which I believe is a justified cost. Opinions of course vary.

Re: After reading “Rails is yesterday’s software”, I need to reply

#114

Post by jamespo »

lmm wrote: post #48
criddell wrote: post #29

Earlier quoted context omitted.

> In the future it might mean using (gulp) Java + WebAssembly You know, after being out of the Java world for about ten years now, I'm starting to get the itch to use it again. I was one of those people that used to joke about programming in XML, but that's really just a layer of indirection which is often a good solution to a problem. It's a very nice language, is fast, and has so far not been destroyed by Oracle. P…

Let me take the opportunity to plug Scala, which gives you (better than) the expressiveness of Python or Ruby but with (better than) the safety of Java. (OCaml, F# or Haskell are other options in a similar quadrant).

It certainly doesn't give the readability of Python or many other languages

Re: After reading “Rails is yesterday’s software”, I need to reply

#115

Post by engineerDave »

heartbreak wrote: post #75
Benjamin_Dobell wrote: post #67

Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x... 4.1.x -> 4.2.x It was, and still is, a nightmare. Technically speaking Rails itself upgraded in a reasonably straight-forward way, just follow the documentation (well and a few blog posts here and there for the things missed in the official docs). But all the additional Gems, and dependencies of those Gems (and so on) made the process excruc…

I hear horror stories like this, and I have one of my own. 1. Absolutely no tests of any kind 2. Over 100 gem dependencies Upgrade from 3.2.x to 4.2.x took one developer (me) three weeks of work. I don't know if that's a lot or not, given the major version upgrade and all of the gems (which were a huge pain). I've not had any problems in production reported via Honeybadger or by end users, so I think the upgrade was…

In cases like this when I ask why TDD isn't done the answer is usually some variant of "its working" to which I usually reply "how do you know?". :P

Re: After reading “Rails is yesterday’s software”, I need to reply

#116

Post by lmm »

jamespo wrote: post #114
lmm wrote: post #48

Earlier quoted context omitted.

Let me take the opportunity to plug Scala, which gives you (better than) the expressiveness of Python or Ruby but with (better than) the safety of Java. (OCaml, F# or Haskell are other options in a similar quadrant).

It certainly doesn't give the readability of Python or many other languages

It absolutely does, if you stay away from bad libraries. Most of the time you can translate Python directly 1:1 into Scala, or do better (e.g. none of the junk repetitive "self.x = x" constructors you get in Python).

Re: After reading “Rails is yesterday’s software”, I need to reply

#117

Post by narrator »

neverminder wrote: post #72
lmm wrote: post #48

Earlier quoted context omitted.

Let me take the opportunity to plug Scala, which gives you (better than) the expressiveness of Python or Ruby but with (better than) the safety of Java. (OCaml, F# or Haskell are other options in a similar quadrant).

Scala + Play Framework, which incidentally was inspired by Rails, however in my opinion is much more consistent amongst other things.

I'd like to add that ScalaJS on top of Scala + Play is really a pleasure to work with for web applications. The integration with existing Javascript libraries is very smooth and Play/SBT transparently handles the transpiling when you reload a page.

Re: After reading “Rails is yesterday’s software”, I need to reply

#119

Post by ryanmarsh »

eric_h wrote: post #94
beat wrote: post #86

Earlier quoted context omitted.

A huge upgrade on code with no tests and a bunch of magical dependencies? The problem wasn't Rails there.

There's an argument to be made that Rails, by not actually enforcing conventions like TDD, gives an amateur/impatient developer a very high calibre footgun. Unfortunately, of course, that gun doesn't usually go off until it's handed to someone else.

Not enforcing TDD? Rails' own creator bemoaned the culture of test cargo culting in the Rails community. This is pretty well documented. If there's something Rails falls down on it's certainly not testing.

Re: After reading “Rails is yesterday’s software”, I need to reply

#120

Post by engineerDave »

busterarm wrote: post #109
engineerDave wrote: post #102

Earlier quoted context omitted.

The main problem I see in the ruby community, in this regard, is the willingness to make breaking changes and justify it via Semantic Versioning. While on the surface this seems ok the underlying problem, as I see it, is the old version isn't maintained, so essentially the only maintained version now has breaking API changes. There are few ways this could be addressed, e.g. separate branches for old gems, and some de…

I think this is the source of the early focus on unit testing in the Ruby community. The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march. A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and…

Fair points all. But the breaking changes I'm referring to are items like changing method names, most likely because OCD, and helper methods, etc. While good/great tests will catch this type of stuff in your code, it will still be a lot of chasing your tail refactoring code because someone didn't like the way something was named. I see this a lot in the ruby community. Its like some sort of crazy insanity that ruby devs exercise when changing publicly exposed API methods just because _____. smh
Post reply on HN