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

About PayPal's Node vs Java “fight”

developer-blog.cloudbees.com

Post reply on HN
Print view View original

201–210 of 216 posts

Re: About PayPal's Node vs Java “fight”

#201

Post by ExpiredLink »

porker wrote: post #129
UK-AL wrote: post #114

Earlier quoted context omitted.

"It fosters Anti-Patterns like 'Dependency Injection' that give you the illusion of modularity but instead create dependencies within the application ('Dependency Injection' needs to be taken literally)." What? Any system with separated modules is going to have dependencies. At least with DI, classes are written to a interface and different versions easily be swapped in and out.

> Any system with separated modules is going to have dependencies. Thank you. I thought I was the only doing my nut in over "I've done DI, now I have all the same dependencies" ... adds DIC ... "Now I have all the same dependencies but higher up, and.. oh I need to add logging to 80% of the objects" [Goes to kill myself] I have OCD about writing beautiful code. The more I try, it seems to real world prevents it from…

Try dependency management instead of dependency injection. Layered, modular, hierarchical design instead of 'anything injected into anything'. Divide and conquer instead of DI spaghetti. Testable independent modules instead of mocked-out stubs...

Re: About PayPal's Node vs Java “fight”

#202

Post by bad_user »

gfody wrote: post #140
ebiester wrote: post #111

Earlier quoted context omitted.

Has the Mono story gotten better? How feasible is it to develop without thousands of dollars of Microsoft software these days?

Mono has gained serious traction the last few years. I've personally been using it along side .Net and am loving it. You could develop in Windows with the Free/Express versions of Visual Studio etc. and deploy binaries to Linux. You could also use monodevelop ( http://monodevelop.com ) in Linux or OSX. There are C# plugins for Eclipse and IntelliJ as well. Relevant: http://www.mono-project.com/Companies_Using_Mono ht…

> There are C# plugins for Eclipse and IntelliJ as well

No, there aren't. And MonoDevelop has gotten better, Xamarin is doing a good job, but it's still a far cry from IntelliJ IDEA. If you want to target Mono, spare yourself the effort and just use Visual Studio.

Re: About PayPal's Node vs Java “fight”

#203

Post by EdwardDiego »

bad_user wrote: post #200
_random_ wrote: post #147

Earlier quoted context omitted.

We build those kind of projects and our team is successful with C#. Perhaps we just know a thing or two about decoupling on all levels. С# comes from the world that brought us Reactive Extensions and TPL. If you call runtime generics, continuations, dynamic typing and value types 10% syntax improvement, then perhaps you should grab a book or two and catch up a bit?

"Runtime generics" (they are called reified generics btw) is one of the things that keeps the CLR from being a multi-language VM like it was advertised, as at the bytecode level they are very hard to work around. That's one of the reasons for why dynamic languages on the CLR never took off and that's why F# has two generics systems in the same language. I'm much happier with the generics type system provided by Scala…

> that's why F# has two generics systems in the same language.

For real? Do you have any reading I can do on this? It sounds... interesting

Re: About PayPal's Node vs Java “fight”

#204

Post by frowaway001 »

Ygg2 wrote: post #179
frowaway001 wrote: post #138

Earlier quoted context omitted.

What's wrong with implicits?

Magic.

... done right?

I mean the most hated implicits are implicit conversions and they basically exist for Java compatibility.¹

So on the one side you have terrible stuff hard-coded into the language (Java, C#) which you will never get rid of and on the other side you have a solution as a library which you just can de-import if you don't want to suffer from e. g. magic anything-to-String conversions any longer (I certainly won't).

That's a huge plus in my book.

¹ The two other main use cases, type classes and extension methods, seem to be hugely popular and I haven't seen any criticism concerning them.

Re: About PayPal's Node vs Java “fight”

#205

Post by gfody »

bad_user wrote: post #202
gfody wrote: post #140

Earlier quoted context omitted.

Mono has gained serious traction the last few years. I've personally been using it along side .Net and am loving it. You could develop in Windows with the Free/Express versions of Visual Studio etc. and deploy binaries to Linux. You could also use monodevelop ( http://monodevelop.com ) in Linux or OSX. There are C# plugins for Eclipse and IntelliJ as well. Relevant: http://www.mono-project.com/Companies_Using_Mono ht…

> There are C# plugins for Eclipse and IntelliJ as well No, there aren't. And MonoDevelop has gotten better, Xamarin is doing a good job, but it's still a far cry from IntelliJ IDEA. If you want to target Mono, spare yourself the effort and just use Visual Studio.

http://emonic.sourceforge.net/index.html

IntelliJ still seems to be a wishlist item. Surprised there is nothing considering how many other great C# tools JetBrains produce.

Re: About PayPal's Node vs Java “fight”

#206

Post by eddflrs »

kylequest wrote: post #159
eddflrs wrote: post #93

Does anyone know how vertx[1] fits into this picture? It gives you the JVM, JavaScript, and non-blocking I/O. [1]: http://vertx.io/

Nodyn is an effort to run node.js apps on top of Vert.x. JavaScript alone is not enough to make Vert.x popular for node.js people. You need to be able to leverage the node.js module echosystem. Hopefully Nodyn will do that, so you can use your favorite node modules on Vert.x. It's still a work in progress though.

Cool, Nodyn looks interesting. Thanks for the info.

Re: About PayPal's Node vs Java “fight”

#207

Post by vorg »

keypusher wrote: post #176
ebiester wrote: post #28

I fantasize about rebuilding the java ecosystem. Create "JPM", don't allow anything from the old Maven system in it. Create a new "hip" minimalist framework that ignores everything about java and its notions of OOP. Basic dependency management handled NPM-style. Developers encourage to put everything in the same package for their own stuff, and everything is package level. Getters and setters and encapsulation and ja…

Have you looked at Groovy/Grails/Gradle? You can use the existing Java code and ecosystem or you can choose to do things the new way, you have access to a web framework similar to Rails, it's pretty nice.

> you have access to a web framework similar to Rails

Then why not just use Rails for Java, i.e. JRuby ?

Re: About PayPal's Node vs Java “fight”

#208

Post by ebiester »

mattgreenrocks wrote: post #188
ebiester wrote: post #115

Earlier quoted context omitted.

In my case, I'm speaking of a reaction to Spring and Struts. I personally use Grails on my recent projects, which is as close to batteries-included as it gets, but I occasionally have problems with square peg round hole problems, and fighting against a framework is more painful than a library. The problem with the framework is that we run into a steep hill when we must diverge off the path. A good framework gives a g…

Do you know of any shops that use Uncle Bob's approach (besides 8th Light, of course)? I don't; I wish I did. I agree that isn't something you'd use every time, but I feel there isn't a whole lot of data out there when people have used it. All I see online are devs whining about the extra work. I don't know what it is about the web, but it's as if we decided all of software architecture didn't mean anything and threw…

I have plans to try it in a side project. I too am skeptical about the rewards of setting up a CRUD system like that.

It isn't that we've decided that software architecture meant nothing; rather, we settled on one architecture that is Good Enough. The View/Controller/Domain paradigm of Rails works for many projects.

Re: About PayPal's Node vs Java “fight”

#209

Post by vorg »

usrusr wrote: post #198
astral303 wrote: post #72

Earlier quoted context omitted.

Groovy with Gradle is a pretty good answer that is there today. Gradle way way way easier to work with than with Maven for your build system, publishes packages with dependency info, so you still get your dependencies sorted OK. Groovy has automatic setters/getters, a ton of functional-style helpers (closures, etc), dynamic & static mixins, delegates, etc.

Sorry, but in groovy, [[1 : 2]] - [["b" : "a"]] seems to be []. As long as they don't get fundamentals like this right i consider groovy only useful for demonstrating it's own deficiencies. The fact that this is in their Jira since 2010 and a fix would would be easy for anyone who understands the basics of hashcode and equals doesn't paint an all too rosy picture of the people behind groovy. I'd rather work with a la…

> a language that gives me reason to doubt that it is fully understood by the people who made it

It's really just one of the people who made it. Groovy has a non-technical project manager, and most of us who've programmed in corporate IT shops know how that goes.

A case in point: traits were announced for Groovy 2.2 ( http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td... ) in June (2013). A rather lengthy discussion (55 messages) followed planning them, but the traits never came. The very last message asked what happened to them but the project manager never replied.

Another case: tech lead Jochen Theodorou began a discussion about changes to the meta-object protocol (MOP) for Groovy 3 ( http://groovy.329449.n5.nabble.com/Groovy-3-tt5710334.html ) in June last year (2012), kicking off a 91 message discussion. But the project manager canceled the new MOP, diverting Jochen into other work.

Again: Groovy creator James Strachan's very last Groovy mailing list posting ( http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.h... ) to that project manager who replaced him just before he left the Groovy development team in Dec 2005:

"The MOP and introspection APIs do NOT solve the horribly broken name resolution rules in the current RI of Groovy [...] I see no argument yet for why we have to throw away decades of language research and development with respect to name resolution across the language as a whole [...] It just feels totally wrong to break Closures across the entire language just because of some use cases for Markup."

The project manager's behavior is typical of non-technical people working in Software Development everywhere. E.g. on 29 August this year, Groovy's 10th birthday, someone added the project manager's name to Strachan's as a "co-developer" of Groovy on its Wikipedia page ( http://en.wikipedia.org/w/index.php?title=Groovy_%28programm... ), giving him 3 titles (developer, project manager, and spec lead). I really had to undo it. Because the Spec was changed to dormant in April 2012 ( https://www.jcp.org/en/jsr/detail?id=241 ) after being inactive for 8 years, I removed Laforge's "spec lead" title also. I also added the 3 technical people who are listed in Groovy's Codehaus repository as "despots" to give to Wikipedia page more truth ( http://en.wikipedia.org/wiki/Groovy_(programming_language) ).

It's a pity how Groovy stagnated over the years, and maybe it's just a very public example of why "business people" shouldn't be allowed anywhere near programming language design and development.

Re: About PayPal's Node vs Java “fight”

#210

Post by dragontamer »

gngeal wrote: post #101
dragontamer wrote: post #95

Earlier quoted context omitted.

I think its more of the realization that types are actually freaking useful for determining "provability" of a system. C++ perhaps takes it too far with Const, but it allows the compiler to prove that certain functions will not attempt to modify certain variables. Compared to Python or Ruby, you're pretty much relying entirely on culture and good habits to ensure the proper rules of encapsulation. Any code may modify…

I think its more of the realization that types are actually freaking useful for determining "provability" of a system. C++ perhaps takes it too far with Const, but it allows the compiler to prove that certain functions will not attempt to modify certain variables. There is very little in terms of "provability" that either C++ or its types give you. Proving anything really interesting (for example, the absence of race…

Take for example, proper use of a unique_ptr > in C++. You can pass around the unique_ptr, and guarantee that you are in "unique ownership" of a particular lock at compile-time.

In C++, you may not be able to prove "the lack of race conditions", but you can prove things like "I'm the only one who is holding onto this mutex right now" thanks to stuff like unique_ptr... which tracks that stuff. These primitive proofs are performed at compiletime, and have little-to-no effect on runtime as well.

Stronger languages with stronger type-systems (ie: Haskell) can prove / disprove which code has side-effects... because you've explicitly passed the Monad around. (Note: Code without side-effects is guaranteed to not have race conditions).

So yes, there are important things you can prove using the type-system. More importantly, it is the compiler's job to automatically conduct these proofs every compile cycle.

Post reply on HN