dawidloubser's comments

Life, arguably, is a competition. Evolution inherently rewards winners.

...said nobody before the Y2K bug...

I do enjoy using Atom as an everyday editor for ECMAScript / React apps, where the convention is to have many very small files. ES6 + Hasklig font + Ligatures make for a particularly visually-pleasing coding experience.

Unfortunately, Atom has severe performance issues with files that are anything above "tiny". For example, a 500-line XML file will lock Atom up for many seconds, to several minutes, while it's inefficient little ECMAScript parsing engine tries to chew through it. I build the latest version almost daily in anticipation of improvements in this area!

This is what prevents my adopting this otherwise lovely, vibrant, flexible editor for all my tasks.

A real IDE like IntelliJ has no problems with applying various tooling (parsing, validation, de-bugging of XSLT, etc etc) to a 15,000-line XML file.

In the longer term, I do hope that somebody is addressing this - which I think is literally the only thing that Atom has going against it.

I'm not trying to be facetious, but do you literally just mean Haskell? Because none of the languages widely used in corporate / industry do.

I'd settle for 1990s tech over 1970s tech any day when it comes to contracts (APIs).

Sure, but that is incredibly weak from a typing point of view, and not compiler-checked in most languages.

You have no clean way of describing multiple pre-conditions (refusal reasons), or to evolve those over time in existing systems, without assuming that developers will somehow correctly read your API documentation, and manually write the code everywhere to handle all possible exceptions, with no help from your compiler or your language's type system.

This is how to indicate exceptions in the 1970s. The world has moved on since then :-)

Absolutely not - the people who do that, don't understand the difference between refusal (precondition not met), and failure (unexpected system error). In your particular case above, I would never let IOException leak "up" into a client-facing contract.

How could I? I would have designed that interface long before implementing it. No, in that case, this is an unexpected system error - for example, an unchecked RuntimeException in Java.

Just because people don't know how to write software contracts properly, doesn't mean that languages and protocols should remove the notion of a checked exception.

When used properly, they are an essential part of an understandable contract. And that's before we even look at it from a type system point of view, where it's absolutely silly to use the same response message to represent either success of failure, greatly increasing the cognitive overhead of the developer calling your service.

I concur. Many people have an insufficient understanding of contracts - especially concerning the difference between refusing a service, and failing because of an error.

An inherent requirement for any contract language is a signal to refuse a service if the pre-conditions are not met (for example, refusing to withdraw money because of insufficient funds in an account).

The most pragmatic solution to this inherent feature of contracts are typed (checked) exceptions - anything else is a less robust, incomplete solution.

Only if you don't understand XML.

* XML has a formal, class-based description language (XML Schema) with strong typing, polymorphism, and - best of all - self-descriptiveness.

* Languages like Java have a seamless, bidirectional mapping to XML Schema.

* XML has a rediculously powerful and elegant transformation language (XSLT) which makes scraping, selective data extraction and processing trivial.

The problem with XML is that people who require instant satisfaction are not willing to invest the time to understand it, and the mature tooling ecosystem around it.

The XML ecosystem solves problems, and contains solutions to problems, that the JSON / JavaScript ecosystem can only dream of, and is hell-bent on partially re-inventing.

If you need strong-typing and self-descriptiveness, you're out of luck with JSON. Binding JSON to a strong-typed language like Java or Haskell is a total ball-drag compared to XML + Schema.

I've had some terrible experiences with migrating, and maintaining, Java EE apps before. But every single one of those were caused by how the teams built the system, and not by Java EE itself.

The added complexity, and choices, imposed by Java EE require a degree of understanding, maturity, and ability to abstractly design that is beyond the average programmer that just quickly wants to hack together a couple of REST services.

I'm not trying to paint successful Java EE developers as some sort of elite here, but there is no doubt that people with a solid understanding can, and have, built long-lasting systems of beauty with it, whereas the average un-informed team, having managed to soundly lock themselves into awful pre-2005 app servers, have created conterted messes of Java code beyond belief.

Both Java EE, and OSGi, are soundly beautiful in their own ways, but both have suffered from some awful implementations and libraries that have caused a lot of pain.

For the past 5 years, my experiences with Java EE has been everything but "heavyweight". I consider it a rapid application development environment. Especially now that nobody does any server-side view frameworks anymore (it's all ECMAScript in the browser).

In this world, I challenge any environment to put more horsepower behind your REST services, for less effort.

I've also suffered a lot of pain in trying to get libraries that were not design for OSGi (i.e. legacy) to work well.

However, when having the luxury of implementing a clean set of services from scratch, OSGi is lovely. We run a large OSGi based system in production, and the modularity, hot-deployability, strong-typing-with-contracts, etc is just lovely.

I certainly won't try to say that OSGi is simple, but for complex systems that have to evolve over a long time span, it solves problems no other environment even nearly does.

Dropwizard also requires a container to run. Only difference is, they are bundling a particular container (Jetty), as opposed to the model of deploying into a container that you set up.

I wish I wasn't at work right now, but I'll bite. Watch this space...

One of the strenghts of the Java platform is the separation of vendor-neutral standards (e.g. JAX-RS, and all the REST concepts, and annotations, it provides) and particular implementations (e.g. Jersey).

Java EE is a collection of such standards, providing enormous capability while not tying you to a particular app server - I'm busy with a rather painless JBoss -> Glassfish migration as we speak.

Secondly, Java has ample platforms that allow for the developer-driven assembly of various cool libraries into a "platform" - for example, OSGi.

It concerns me that this library absolutely ignores these two most valuable concepts in the Java world.

If you want high-performance web services with much more powerful backing technologies (EJB, JPA, JMS...) without locking into a particular haphazard collection of libraries, just write and deploy a JAX-RS module into your free, lightweight app server of choice (Wildfly, Glassfish, etc).

The Java ecosystem is much more mature than the Node.js-based "arbitrary assembly of X cool libraries" that this little project is emulating, and I would encourage people to put that same effort into understanding Java EE, which over the past 5 years has become a lean, lightweight platform indeed - but one with real horsepower for serious systems when you need it.

Not denouncing the greatness of the libraries that have been combined here, I'd steer clear of this project - you're missing out on what is really possible.