3 ms·

I like Clojure (and its community) mainly because every time I saw a github Clojure project, it comes with a few things: test-automation (/test folder) and some

I like Clojure (and its community) mainly because every time I saw a github Clojure project, it comes with a few things: test-automation (/test folder) and some way to build the project: get dependencies, run tests, package it up, and ready for deployment (using leiningen, a'la Maven). That for me feels like home. (Plus I put premium on projects with test automation: it shows to me that the developer cares). But I don't necessarily agree with Neal's first few minutes regarding "I'll choose technology X, knowing it will fail, over technology Y, knowing there's a risk but might achieve big win". There's no big win when it comes to the so-called "Enterprise Project". Either you met the requirement (pray it doesn't change too often, even if it does, pray that the management extends the deadline), or you under-deliver but within budget (cut features). And most of the time it, the failure, is rarely because of the technology (.NET, Java, Ruby, Clojure) any more these days (excluding SAP, PeopleSoft, and some of the truly heavyweight). It's usually something else: management, people, developer's skill, overall culture, process.

moonchrome 15y ago
>And most of the time it, the failure, is rarely because of the technology (.NET, Java, Ruby, Clojure) I disagree, while it won't come down to C# vs Java - things like libraries, tools (that are tied to languages/platforms) and their suitability for the task that you're trying to solve can make or break your project, especially with a short deadline.
- hello_moto 15y ago
  Uh... sure... What kind of "snowflakes" (very unique) project you're talking about? And how short is short? I'd like to know the silver or gold bullet we're about to discuss here, I'm curious. (just don't bring ASM/C vs Java/Ruby lame example though, you know, them kind of example that is too obvious and too weak to disprove generalization-but-not-100%-always type of statement).
  - moonchrome 15y ago
    Quality UI tools and frameworks ? Ever tried to use those fancy thin-client frameworks like Cappuccino or ExtJS ? Spend days figuring out esoteric language/syntax/API and then fight with fragile implementations and no error checking + the ridiculous amount of boilerplate and bad structure. Compare that with XAML/C# with VisualStudio and tell me you don't see the productivity boost. Not to mention entirely different platform characteristics/capabilities. As for libraries - just a week ago I was writing an app for image processing, among other things it needed to do indexing on images by extracting meta data in image headers and different formats (IPTC,EXIF,XMP) and there was no library to do that on Mono/C# that actually worked and after a day and a half of mucking around with half-assed wrappers I wrote the app to feed the DB in clojure with a Java library in few hours. Sure in some abstract 10000 feet view tools don't make a difference, or if you're doing the simplistic CRUD stuff, but in day to day work it matters a lot that you get to use tools (eg. debuggers, intellisense, profiling), libraries, frameworks etc.
    - hello_moto 15y ago
      Uh hang on. Cappucino or ExtJS vs XAML/C#? Are you trying to compare Apple vs Orange or JS vs Flash/SilverLight? One of the previous companies I worked for bet on WPF and it didn't go well. Memory hog, crashes, boilerplate code (sometime hidden by VS.NET), and the consensus was that WPF pretty much sucks out of the box (have to work very hard to make it look good). By the way, another company I used to work for used GWT + Ext-GWT (GWT port of Ext-JS). It was pretty good as long as you don't have to modify the Look-n-Feel to be something it is not.
      - moonchrome 15y ago
        >Uh hang on. Cappucino or ExtJS vs XAML/C#? Are you trying to compare Apple vs Orange or JS vs Flash/SilverLight? Silverlight vs Cappuccino and ExtJS. We tried both before silverlight and eventually gave up as the code became a complete mess (javascript and that monstrosity objective-j), debugging was hell (especially with objective-j) and documentation substandard (cappuccino had the assumption that you were keeping the apple cocoa reference handy I guess). OTOH Silverlight and MVVM Prism worked like a charm, we were able to redo the months front-end work in few days (everyone needed to pick up Prism). Things were super easy to mock and provide concepts with the Blend tool. If they only had TPL it would have been ideal. >One of the previous companies I worked for bet on WPF and it didn't go well. Memory hog, crashes, boilerplate code (sometime hidden by VS.NET), and the consensus was that WPF pretty much sucks out of the box (have to work very hard to make it look good). So you agree then - tools and platforms do matter ? If there was no time to "work very hard" would the project succeed ?

moonchrome 15y ago

>And most of the time it, the failure, is rarely because of the technology (.NET, Java, Ruby, Clojure) I disagree, while it won't come down to C# vs Java - things like libraries, tools (that are tied to languages/platforms) and their suitability for the task that you're trying to solve can make or break your project, especially with a short deadline.

hello_moto 15y ago
Uh... sure... What kind of "snowflakes" (very unique) project you're talking about? And how short is short? I'd like to know the silver or gold bullet we're about to discuss here, I'm curious. (just don't bring ASM/C vs Java/Ruby lame example though, you know, them kind of example that is too obvious and too weak to disprove generalization-but-not-100%-always type of statement).
- moonchrome 15y ago
  Quality UI tools and frameworks ? Ever tried to use those fancy thin-client frameworks like Cappuccino or ExtJS ? Spend days figuring out esoteric language/syntax/API and then fight with fragile implementations and no error checking + the ridiculous amount of boilerplate and bad structure. Compare that with XAML/C# with VisualStudio and tell me you don't see the productivity boost. Not to mention entirely different platform characteristics/capabilities. As for libraries - just a week ago I was writing an app for image processing, among other things it needed to do indexing on images by extracting meta data in image headers and different formats (IPTC,EXIF,XMP) and there was no library to do that on Mono/C# that actually worked and after a day and a half of mucking around with half-assed wrappers I wrote the app to feed the DB in clojure with a Java library in few hours. Sure in some abstract 10000 feet view tools don't make a difference, or if you're doing the simplistic CRUD stuff, but in day to day work it matters a lot that you get to use tools (eg. debuggers, intellisense, profiling), libraries, frameworks etc.
  - hello_moto 15y ago
    Uh hang on. Cappucino or ExtJS vs XAML/C#? Are you trying to compare Apple vs Orange or JS vs Flash/SilverLight? One of the previous companies I worked for bet on WPF and it didn't go well. Memory hog, crashes, boilerplate code (sometime hidden by VS.NET), and the consensus was that WPF pretty much sucks out of the box (have to work very hard to make it look good). By the way, another company I used to work for used GWT + Ext-GWT (GWT port of Ext-JS). It was pretty good as long as you don't have to modify the Look-n-Feel to be something it is not.
    - moonchrome 15y ago
      >Uh hang on. Cappucino or ExtJS vs XAML/C#? Are you trying to compare Apple vs Orange or JS vs Flash/SilverLight? Silverlight vs Cappuccino and ExtJS. We tried both before silverlight and eventually gave up as the code became a complete mess (javascript and that monstrosity objective-j), debugging was hell (especially with objective-j) and documentation substandard (cappuccino had the assumption that you were keeping the apple cocoa reference handy I guess). OTOH Silverlight and MVVM Prism worked like a charm, we were able to redo the months front-end work in few days (everyone needed to pick up Prism). Things were super easy to mock and provide concepts with the Blend tool. If they only had TPL it would have been ideal. >One of the previous companies I worked for bet on WPF and it didn't go well. Memory hog, crashes, boilerplate code (sometime hidden by VS.NET), and the consensus was that WPF pretty much sucks out of the box (have to work very hard to make it look good). So you agree then - tools and platforms do matter ? If there was no time to "work very hard" would the project succeed ?