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…
About PayPal's Node vs Java “fight”
191–200 of 216 posts
Re: About PayPal's Node vs Java “fight”
#192Earlier quoted context omitted.
I still don't see any C# developers that are 200% more productive than Java developers due to limited infrastructure around the C# ecosystems. Say anything about Maven but the recent discussion about embedding Bundler to Gem is just one step closer to be like Maven (now if they merged Rake+Gem+Bundler then Maven is). Even if Maven is not "good enough", .NET is thousand miles behind Java when it comes to dependency ma…
Huh? C#'s had Nuget quite a while ago now. Why are Java developers always like 5 years behind on C# improvements? And build systems are something g you set up one afternoon, why are you so fixated on a tiny part of the programming process?
... And C# devs always borrow patterns and best practices from the Java ecosystem, so I think it's you guys who are always 5 years behind us.
... If you're using MSBuild or Nant and can set up an adequate build system in one afternoon, either your project is super simple crud, or you're not using enough tools to ensure proper engineering/verification, or you're the top 5-10% people who can bent .net build tools according to your needs, or you're exaggerating.
If you think that we shouldn't sweat over build scripts then that seems to be a hint that you have not dealt with large projects.
Re: About PayPal's Node vs Java “fight”
#193Earlier quoted context omitted.
Like Linux or Mac? http://www.mono-project.com/
Sure, you can run command line c# apps just fine but the web hosting solutions for c# web apps are terrible compared to IIS + Windows. And this is coming from a linux veteran who wrote a C# web app and hosted it in production on Linux for a few months and then had to re-write it in .NET MVC hosted on IIS. I hate Windows servers. Every time I have to RDP into them to change some configs instead of just vi'ing files in…
Ugh, maybe you should try out at least one of the several options for remotely managing IIS before you shoot (or embarrass) yourself?
Re: About PayPal's Node vs Java “fight”
#194Earlier quoted context omitted.
Your package system is inspired by Maven, minus a good build system and other functionalities. Try building a large C# projects with running unit-tests, integration-tests, packaging, code-coverage, code style baked into it, and a bunch of other plugins for your build systems without pulling your hair. Your DateTime library ain't there yet sir so you're pretty much at the same situation with Java (although both ecosys…
What? We do all those things and have hardly a problem. What ci / build server do you use?
Preparing dev workspace means to include csproj in your repo which may contain hardcoded paths. Is that portable across to Mono? In Java, all you need is a Maven pom.xml file and the code. Any modern IDE can read pom.xml file and prepare the project consistently cross platforms.
CI server is the easy part.
Re: About PayPal's Node vs Java “fight”
#195I've had the misfortune of using the PayPal Java SDK to integrate PayPal credit card and Express payment into a web application. Based on that experience, I find it especially difficult to digest any opinion that PayPal has on Java. They may be experts on handling money, processing credit card payments, fraud prevention, and the like. (Or maybe not, given their reputation.) But their opinion on Java is about as meani…
In the very unlikely event that the developer has any influence in the choice of payment processor (i.e. you are a startup that intends to trade in only one country) they still do not care, because they still need to do the usual due diligence to check whether your company is a fraud/ML risk, but they earn little in fees from you. They would rather let a smaller payment processor deal with you, then try to take over later after your product is established.
Re: About PayPal's Node vs Java “fight”
#196Earlier quoted context omitted.
"You've basically described C#" Unfortunately the CLR doesn't run on any useful platforms.
Like Linux or Mac? http://www.mono-project.com/
Re: About PayPal's Node vs Java “fight”
#197Earlier quoted context omitted.
Thanks but I've seen a lot of similar comparisons and they seem to focus on trivial things :/ For example the portion about "Asynchronicity" is a brief paraphrase like "Play is good in Rails its awful or doesn't exist". Performance isn't even mentioned really. I find that with Rails apps a lot of development effort is put toward optimizing for scaling rather than complex logic, where Play could potentially be stronge…
> looking at Play as a potential new framework for a CRUD app with a very fancy UI. Do you know of any frameworks that are good for that (but let you easily reach down for complex logic, e.g. where data processing or AI is needed)? Every project I do needs some form of CRUD, and making it work AND be pleasing to interact with takes a lot of time. I don't mind the language, just someone, somewhere must have solved thi…
Re: About PayPal's Node vs Java “fight”
#198I 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…
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.
I'd rather work with a language that _i_ don't fully understand (modersky seems to provide me with an infinite supply of intellecutal challenges) than with a language that gives me reason to doubt that it is fully understood by the people who made it.
Re: About PayPal's Node vs Java “fight”
#199Earlier quoted context omitted.
I'm pretty good with Spring and have even given trainings on it and I'd argue that Spring's main problem is that it needs to be seen in the right context: a poor man's DSL for declarative system configuration (it is last 10 years old after all.) That it creates untestable applications seems like completely nonsensical FUD however since the entire point of Spring is to keep code easily testable. Spring is an almost di…
I've done a lot of Spring side work and your first paragraph is the best explanation I've ever read for the framework. I also agree that if you can't test Spring code you are doing something wrong. I get the frustration with having to create test harnesses for some things, and the SpringJ4Unit stuff oftentimes feels a bit too magical, but I've never seen well written Spring code that wasn't easily testable at the bot…
Re: About PayPal's Node vs Java “fight”
#200Earlier quoted context omitted.
Your package system is inspired by Maven, minus a good build system and other functionalities. Try building a large C# projects with running unit-tests, integration-tests, packaging, code-coverage, code style baked into it, and a bunch of other plugins for your build systems without pulling your hair. Your DateTime library ain't there yet sir so you're pretty much at the same situation with Java (although both ecosys…
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?
Reactive Extensions are very nice. I'm experimenting with the Java port, RxJava. Actually I use RxScala, the Scala interface. However, for me they are of limited utility for my current usecase, because in comparison with Iteratees (a concept coming from Haskell, borrowed by Scala and championed in Play2), Rx Observables are very error prone to issues such as backpressure, whereas Iteratees are safe by design. So on one hand, Iteratees are better for handling streams, such as http requests/responses, handling big files and so on, while Rx Observables are better for publishing events to event listeners. I can see myself using Observables though. Erik Meijer is now contributing to RxJava btw.
The C# continuations are delimited continuations, or partial continuations. They are pretty cool, not arguing about it. But in Scala, the API for the standard Future, is much, much nicer than the API of Tasks in C#, therefore working with Futures directly is more comfortable. Plus, Scala's philosophy is to empower the developer to build on the same "magic" that the compiler uses, therefore instead of introducing LINQ or Async, Scala 2.10 introduced Macros. As a result, LINQ and Async are now possible as libraries. Here's DB LINQ (see the direct embedding tab): http://slick.typesafe.com/ ; and here's Async, which will be included in the standard library, but it's just a library based on macros: https://github.com/scala/async
On Value Types, there's nothing ground-breaking about it. On one hand they are great and it would have been cool to have value types on the JVM. There are proposals to include value types that people experiment with in OpenJDK. On the other hand, the JVM being more restrictive about managing memory, gave birth to the most advanced garbage collectors in mainstream usage. C#/CLR is great when a low overhead is required, such as on mobile devices, but in a server-side context no GC-enabled language can beat the JVM.
On syntax, it's true that Java is an abomination. However this gave birth to multiple languages that are flourishing and you can't say the same thing about .NET ... Scala, Clojure, JRuby, Jython, Groovy and Rhino are examples with flourishing communities and ecosystems. Similar efforts have been happening for the CLR, but they never made it or are moribund, except maybe F#.
I did want to use C# several times, as I view it as a mixed-bag language, as in a language with comfortable high-level features that also has some low-level stuff, which is pretty cool on top of resource constrained devices. And I definitely prefer C# over Java (thank God for Scala and Clojure). Unfortunately the platforms I build upon are mostly Unix and I prefer to build on top of open-source as I'm the kind of developer that likes being in control. And in spite of the best efforts of those people from Xamarin, or the recent moves from Microsoft to open-source some stuff, .NET doesn't really have an open-source community and it's very Windows/Microsoft oriented.
It's a pity because it could have been much more than it currently is. And maybe it will, as I'm seeing some encouraging signs, like Microsoft partnering with Xamarin.
We tend to treat languages like they are football teams. We really need to learn from each other and build on top of each other ideas. Cross-pollination is healthy. Conservatism is not. If we jumped between platforms more often, we wouldn't be separate communities.