techpeace

I use it through both the chat interface and the Cursor IDE: https://www.cursor.com/

Just checked Huncwot out - looks like a great project, thanks!

And congrats to mojombo and team! You probably already use something Tom wrote without realizing it.

Congrats on hitting 1.0.0! Thanks for all the hard work. The Elixir community is producing some really exciting stuff.

Right you are! I didn't realize it had beaten Rails to the punch by a year. But yes, I will stand by my claim that Rails was responsible for popularizing the notion in the wider web development community.

Could you name a major web framework that implemented the MVC pattern prior to Rails?

Here's a handy test to determine if two technological terms mean the same thing: are they used interchangeably? If I said to someone, "oh that looks like you need a SOAPful interface," would they assume that I meant RESTful? Probably not, since they're two different technologies. The move to REST was actually inspired by the perceived deficiencies in WSDL and SOAP.

The funny part is that technically Rails and Rails-inspired REST frameworks get it wrong.

Well, that's a bit tangential to my original point. I wasn't claiming that you specifically liked the way it was implemented, just that Rails, and thus the Ruby community, was responsible for its popularity. Despite the length of this thread, neither of you has managed to debunk that claim with anything resembling evidence.

Find a reference to Tomcat using REST before 2007, and give us the link. I'd bet you can't, since Rails was the first major web framework to implement REST.

REST hit it big with the www, www is REST's killer app.

Since REST was invented in 2000, and the web itself had been around for a bit before that, I fail to see how this could be true.

WSDL/SOAP are not REST. I'm telling you that REST was popularized by Rails, because it was the first major web framework to use it. You've yet to refute that argument, but you do continue to be rude, so have a good one!

CoffeeScript doesn't work because it requires you to learn a new language on top of JS.

The folks that have been quietly productive with CoffeeScript for years, and have and continue to make millions of dollars because of it, would likely disagree with you on that point.

Your point is that Ruby's role to all of the developments you mention is essential and unique. I'm arguing it's not. By far.

The only remarkably unique thing about the Ruby community I keep noticing as an outside its rise and fall of the Brogrammer culture and the aftershock we're still experiencing to this day. But even that, I think, would have happened even if Ruby never existed.

Well, you've failed to sway me on that (by far), and the clear chip on your shoulder you have regarding the Ruby community as a whole leads me to believe your vociferous arguments to the contrary might be motivated by something other than your desire to spread the truth.

It was a major factor, yes, but claiming this purely as an accomplishment of Ruby is silly.

A major factor in popularizing it, as I claimed. Personally, I had never heard of it before DHH's 2006 RailsConf keynote. Could you point me to another web framework that had implemented it before 2006?

Some of the syntax was influenced by CoffeeScript (nobody doubts that -- in fact, TC39 members have explicitly referenced it on more than one occasion) but the features are neither novel nor unique to Ruby.

Again, CoffeeScript was popularized by the Ruby community, as uptake increased greatly when it became a default in Rails. The syntax was heavily influenced by Ruby, which then found its way into ES.next.

Front-end build tools

The Rails asset pipeline was actually listed as the inspiration for Brunch, the closest you can get to replicating its functionality in JavaScript. This went a long way towards popularizing the notion.

I agree that CoffeeScript is the first one that gained major traction in the startup scene although most teams seem to have realised that the drawbacks aren't really worth it (not just the transpilation...

Yes, and CoffeeScript first gained traction within Rails. You also seem to be discounting the obvious popularity of ES.next transpilers.

The Ruby community is very vocal and self-important but it's neither as uniquely innovative nor as much of an influence as its members like to make it out to be. If PHP is the kindergarden of programming languages, Ruby is the angsty teenager complaining about how nobody understands them and writing blog posts about their deep insights gained from flipping through Atlas Shrugged.

This is rude, untrue, and unhelpful. Be civil. https://news.ycombinator.com/newsguidelines.html

I didn't claim that the Ruby community invented REST. Rails 1.2 (2006) was the first major web framework to implement it. Do you have any evidence to support your claim that I'm incorrect?

Could you point me to a major web framework that used REST before Rails 1.2 (2006)?

What the f* are you on? Or were you born a few years ago and just worked with Ruby since then?

I've been using Ruby professionally for 10 years.

Here's a quick (incomplete) list of web innovations you can thank the Ruby community for either popularizing or inventing outright:

* REST * Many parts of ES.next * Front-end build tools * CSS pre-compilation * JS transpilation

I spent years happily using multi-line template strings while JS developers informed me how idiotic I was for using a transpiler. Since Ruby's goal is to be a language that brings joy to the user, I see nothing wrong with bringing that ethos to other languages. You yourself acknowledge the impact it had on the development of JavaScript.

We in the Ruby community will keep innovating, and you keep hoping that we'll stop, and we'll see which happens.

This whole story seems like pretty poor form. You based your business, in part, on a closed-source product, failed to test your multi-platform product on... any of the other platforms you planned on releasing it for, and then wrote up a lengthy blog post blaming the author of same closed-source product for failing to address your pet issue, as if your business being dependent upon it being fixed should somehow be his concern.

Fantastic work! Thanks for sharing it with the community. I'm excited to check this out further.

That doesn't mean nobody should ever want customization.

I fail to see where I made that claim. IDE's are also customizable - I would argue that they are, in fact, much more customizable than either vim or emacs, simply because of the breadth of features one may customize. I was addressing the parent's claim that "great programmers use vim or emacs."

Great programmers use vim or emacs

These kind of generalizations aren't helpful, simply because they aren't true. Are vi and emacs still going to be in wide use 500 years from now? Likely not. Then it stands to reason that there might be a way to improve upon them.

I use an IDE because I don't have to sink an inordinate amount of time into customizing my environment, since that activity doesn't deliver any value to the folks that pay me. I'd prefer to let a really smart team of engineers set those tools up for me. I do not, however, assume that anybody that doesn't use an IDE must be inferior.

Saying that you "don't understand" allegations of sexism at Amazon, as a white man, is going to be tough for folks to accept. You've likely never experienced the sexism. As a fellow white man, I've never really dealt with racism directed at me in general society. Does that mean I should assume it doesn't exist outside my personal experience?

+1

Also worth checking out: https://www.filamentgroup.com/lab/font-events.html

Haha, hey man! No, it's not really possible to decouple Marionette from Backbone, I just don't like typing "Backbone Marionette" every time, so I just use "Marionette." But for the uninitiated, Marionette is indeed a layer on top of Backbone.

I use Marionette: http://marionettejs.com/

1. You can grasp the basics in just a few hours, but obviously this is entirely subjective. A week-long training course will really get you going, though. The nice thing in terms of learning it is that the maintainers consider Marionette the "non-framework framework," in that it's just JavaScript, with no new paradigms to learn.

2. Hmmm, 3 for me, but that's also subjective. The more work you put into developing a sane architecture, the higher this number will be, but Marionette doesn't really impose an architecture on you, so YMMV.

3. 3, but see caveat from #2. Depends on how you write your code, really.

4. I chose it because, as stated above, "it's just JavaScript." I don't have to get my team up to speed on an entirely new development paradigm in order to use it. It's not really a "framework," per se, since you aren't given as much functionality out of the box as you would be when writing an Ember app. This means there's less chance of being hemmed in by the limits of the framework. This is a familiar tradeoff - a larger framework that gets you up and running faster, but with more chance of encountering an edge case that it doesn't fully support, vs. a smaller library that requires more up-front work, but is easier to mold to fit your own ends when necessary. In a few years, as the larger frameworks grow more mature, I'll be more likely to use them in my projects.

Yeah, this is one of those "feature not a bug" things that's been known for some time. As others have pointed out, sign your commits if this bothers you. It's even possible to get your fellow open source contributors to sign commits to your project, as we do with the Metasploit Framework: https://github.com/rapid7/metasploit-framework/wiki/Landing-...

Excellent work, thanks for sharing!

Except for the LIBOR scandal, of course. And the ISDAfix mess. But those only involved most of the world's largest banks, and combined, likely only affected anybody seeking credit, anywhere, for any reason.

I once worked for a startup in the education industry. One day, when Blackboard released a new product that directly competed with us, we noticed that their new logo was an obvious, clearly intentional rip-off of our own. It was actually gratifying, as a group of mostly recent graduates, to so clearly have threatened a billion dollar company.

GitHub repo: https://github.com/jeyoder/ThingsInSpace

Well, as the history of this country has been one of expanding the scope of rights to encompass more people, rather than one of limiting rights to only apply to folks that think and act like the majority, I'm for it. The only time we tried to limit rights with a Constitutional amendment (prohibition), things didn't go so well.

I would also take issue with your framing of this case. I view gender as just as arbitrary a hindrance as race, especially given that the "Biblical definition of marriage" also dictates things like how one should treat their sex slaves. It's also worth noting that it was religious conservatives that were also raging against the decision in Loving v. Virginia, because it violated "traditional" notions of marriage.

So, what's the difference between an "arbitrary hindrance" and an "expansion of rights"? Who gets to decide? Which one is allowed, in your view?

Location: Austin, TX

Remote: Sure!

Willing to relocate: No, sorry

Technologies: Marionette.js/Backbone.js (3 years), Ruby/Rails (10 years)

Résumé/CV: https://www.linkedin.com/in/mattbuck

Email: me@matthewbuck.com

"but that's a pretty resolved question at this point, and would require overruling about 200 years of precedent on the issue "

So, I assume you're leaving Loving v. Virginia out of that figure? [1]

[1] https://en.wikipedia.org/wiki/Loving_v._Virginia

As a lawyer, could you explain how denying over 1,000 federal marriage benefits to same-sex couples would be offering them equal protection under the law?

Hear, hear! Well done, GitHub! This will be an invaluable resource for the software development community for years to come. Congrats on 1.0.