21–30 of 40 posts
No. Where are the plethora of libraries for Erlang that Java enjoy? Java is great because you can stand of shoulders of people releasing brilliant libraries. Who cares about Availability, Performance, Scalability ... if you can't ship?
No. Where are the plethora of libraries for Erlang that Java enjoy? Java is great because you can stand of shoulders of people releasing brilliant libraries. Who cares about Availability, Performance, Scalability ... if you can't ship?
This says so much about why the world of enterprise java is a complete pile of shit that I just don't know where to start...
That being said, there are some amazing libraries out there.
Google Guice, Google Collections Framework, struts2, BDB JE to name a few. They help me ship.
Lots of great software if you poke around.
What a classic linkbait submission title.
What a classic linkbait submission title.
In my experience, it takes at least a couple of years to introduce a new technology to a large corporate (i.e. the ones that actually run enterprise apps).
Many large corporates will have multi-year enterprise licenses for things like IBM WebSphere. It might be years before they even consider a technology shift, let alone that shift becoming dominant.
The reasons are many and varied - resistance to change, need to prove the technology, integrating the technology with existing systems, changes required to methodology and process, instrumenting the new technology, vendor support, cost, skills availability, access to quality training, access to recognised certifications, tooling (dev/test/deploy), infrastructure, regulatory compliance... The list goes on and on.
Even when you take all of these... Nobody ever actually decommissions anything.
Cultural and methodology changes are massive in the enterprise space.
Earlier quoted context omitted.
That's nice, but how easy is it to understand those 2 pages of brilliance later and how brittle are they? Remember - the author is the smartest person who will ever see a given piece of code. The reader, even if it's the same person, will be dumber. Programming isn't literature or poetry. No one ever had to add a mail reader to"Ode to a Grecian Urn".
I think it's a lot easier to understand what some code does if you don't have to read a lot of language imposed cruft that surrounds the actual 'meat' of the algorithm. Erlang really is easier than Java -- both to read and to write. I think people too often confuse "different" with "difficult".
Earlier quoted context omitted.
Shhh, don't tell anyone :-D On a more serious note yes, but again that's a cultural thing. Languages like Erlang (and OCaml, and Haskell, and...), you spend more time thinking than typing. You don't (need to) write much code, and if you think of a better way you might completely overwrite yesterday's work. You might deliver a huge chunk of functionality in a couple of pages of code that took weeks of thought, but tha…
That's nice, but how easy is it to understand those 2 pages of brilliance later and how brittle are they? Remember - the author is the smartest person who will ever see a given piece of code. The reader, even if it's the same person, will be dumber. Programming isn't literature or poetry. No one ever had to add a mail reader to"Ode to a Grecian Urn".
Part of writing good code, whether two pages of brilliance or twenty of gradual brilliance, is conveying intent in the human-readable parts. The parser doesn't care if all the functions have names like doTheNextThing() or french_onion_soup, but it would be a slap in the face to any future maintainers.
Choosing informative names and separating a program along clear conceptual boundaries can be a greater aid to understanding than any syntactic redundancies. Well-placed comments help smooth things over, particularly notes on why a particular approach was chosen. The names themselves should be able to convey what is going on in most cases.
(For distilled wisdom along those lines, see _Thinking Forth_ by Leo Brodie, also online at http://thinking-forth.sourceforge.net/.)